Разработка модели процессов объекта профессиональной деятельности

2 Разработка модели процессов объекта профессиональной деятельности

  2.1 Построение модели прецедентов

Требования, предъявляемые к функционированию проектируемой системы, удобно выразить с помощью языка прецедентов. Прецедент – это набор сценариев, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой или актером для достижения результата. Таким образом, с помощью прецедентов на понятном и доступном языке можно описать основные процессы, происходящие в системе и значения этих процессов для актера (пользователя системы).

В виду большого количества справочников будут рассмотрены лишь некоторые из них. Такая диаграмма приведена на рисунке 2.1.

Рисунок 2.1 – Диаграмма прецедентов использования системы

2.1.1 Прецедент «Ввод информации по специализации путей»

Основной исполнитель: технолог.

Заинтересованные лица и их требования

─  Технолог. Хочет быстро и точно ввести информацию, не допуская ошибок при вводе, т.к. тем самым он задерживает отправление поезда и снижает свою производительность.

─  Администрация станция. Хочет быстро сформировать поезд и быстро отправить его по назначению.

─  ГЖД. Хочет быстро перевезти груз и удовлетворить интересы получателя груза.

─  Налоговые службы. Хотят получать налог от каждой сделки.

Предусловия

Технолог аутентифицирован.

Результаты (постусловия)

Данные сохранены. Технолог занимается другими обязанностями. Поезд отправлен в нужном направлении. Груз получен. Налоги начислены.

Основной (успешный) сценарий

1.  Технолог выбирает из списка доступных ему таблиц: таблицу специализации путей;

2.  Система читает конфигурационный файл, описывающий логику ввода информации;

3.  Система показывает форму для ввода данных;

4.  Технолог выбирает путь, на котором будет сформирован поезд;

5.  Выбирает станцию назначения будущего поезда;

6.  Выбирает доминирующее назначение будущего поезда;

7.  Выбирает сопутствующее назначение;

8.  Система анализирует выбранные назначения и выставляет флаг доминирующего назначения в true;

9.  Система выбирает из таблицы назначения плана формирования значения:

·  Минимальное и максимальное значение графиковой длины;

·  Минимальное и максимальное значение графикового веса.

10.  Технолог проверяет выбранные системой значения и подтверждает ввод.

Альтернативные сценарии.

В случае неудачной аутентификации технолога, он должен обратиться к администратору, с просьбой предоставить ему доступ к БД. Реализуется средствами Unix, Web-сервера и СУБД.

  2.2 Построение модели процессов

На основе модели прецедентов построим модель процессов в методологии IDEF0. Модель IDEF0 представляет собой совокупность работ, преобразующих входы в выходы с использованием механизмов и управления. Модели процессов помогают понять особенности функционирования системы и взаимодействия с внешней средой. Для определения контекста модели процессов необходимо задать область моделирования, цель моделирования и точку зрения. В качестве примера построим модель для процесса ввода информации в справочник «Специализация путей».

Область моделирования. К внешней среде отнесем администратора и технолога. Технолог или администратор взаимодействует с системой посредством пользовательского интерфейса. При моделировании процессов интерес будут представлять отклики системы на действия оператора при введении информации о справочниках и в справочники.

Цель моделирования дать четкое и однозначное понимание процесса функционирования системы при вводе информации о справочниках и в справочники. Наиболее полно определить назначение каждой работы, производимой системой.

Точка зрения. Модель строится с точки зрения разработчика данной системы. Основная работа, производимая системой, – «Ввод справочной информации». На вход системы поступают различная информация в зависимости от назначения справочника.

На вход системе поступает информация об исходных данных и имени таблицы, куда собираемся вводить справочную информацию. Все эти элементы будут преобразованы или использованы данной работой в качестве «входных данных». В качестве управления выступает действия технолога. Механизм, без которого невозможно управление системой представлен технологом.

Последовательность работ отражена на диаграмме (см. Приложение 1) порядком их следования (сверху вниз, слева направо). Технологу сначала предлагается выбрать таблицу, которая будет хранить вводимую справочную информацию.

3 Разработка модели данных объекта профессиональной деятельности

Модель данных проектируемой системы разрабатывается с учетом предъявляемых к ней функциональных требований. База данных системы состоит из следующих сущностей: Специализация путей, Станции, Станционные пути, Назначение плана формирования.

Сущность Специализация путей должна содержать:

·  Идентификатор;

·  Номер пути, на котором будет сформирован поезд;

·  Код станции, до которой пойдет поезд (идентификатор из сущности Станции);

·  Доминирующее направление, в каком направлении пойдет поезд;

·  Сопутствующее направление, через какое направление будет проходить поезд;

·  Флаг доминирующего направления, выставляется системой в случае совпадения Доминирующего и Сопутствующего направления;

·  Графиковая длина мин. и макс., какой макс. и мин. длины может быть поезд, который пойдет до некоторой станции (заполняется системой из сущности Назначение плана формирования на основании кода станции);

·  Графиковый вес мин. и макс., какой макс. и мин. вес может быть у поезда (заполняется системой из сущности Назначение плана формирования на основании кода станции).

Сущность Станции должна содержать:

·  Идентификатор;

·  ЕСР станции, код станции описанный в классификации МПС;

·  Код дороги, к какой дороге принадлежит станция;

·  Наименование станции, как называется станция (например, Орехово);

·  Краткое наименование станции, сокращение (например, Орх.);

·  Код пути, с какого пути отправляется поезд в Орехово (идентификатор из сущности Станционные пути).

Сущность Станционные пути должна содержать:

·  Идентификатор;

·  Номер пути, числовой номер пути;

·  Номер пути, числовой номер пути для АСОУП;

·  Условная длина пути;

·  Код станции, код станции куда с данного пути отправляется поезд;

Сущность Назначение плана формирования должна содержать:

·  Идентификатор;

·  Код станции, станция до которой идет поезд;

·  Графиковая длина мин. и макс., какой макс. и мин. длины может быть поезд, который придет до данной станции;

·  Графиковый вес мин. и макс., какой макс. и мин. вес может быть у поезда, который придет до данной станции.

В ERWin можно задавать идентифицирующие и неидентифицирующие связи

Идентифицирующей связью называется связь, которая добавляет признаки идентичности в дочернюю сущность путем миграции ключей родительской сущности в область ключевых атрибутов дочерней и таким образом делая дочернюю сущность зависимой от родительской в смысле своей идентичности.

Можно задать также и такую связь, которая не ставит дочернюю сущность в зависимость от родительской. Этот тип связи называется неидентифицирующей связью. В ERwin такая связь обозначается пунктирной линией с жирной точкой на конце, соответствующем дочерней связи. При неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в область данных (неключевая область), которая расположена под чертой в дочерней сущности. В данной работе неидентифицирующая связь не используется (см. Приложение 2).

Поскольку с одного пути могут уходить поезда на несколько станций и приходить с нескольких станций, то связь сущностей Стационарные пути и Станции является многим-ко-многим.

Сущности Станции и Назначение плана формирования связаны также связью многие-ко-многим, т.к. на одну станцию могут уходить поезда разной длины и веса и на несколько станций могут приходить поезда одной длины.

Сущность Специализация путей связана с сущностями: Назначение плана формирования, Станции, Станционные пути связью один-ко-многим.

4 Связь модели данных с моделью процессов

При проектировании информационной системы необходимо указать разработчику какие действия, над какими данными может выполнять конкретная работа. Для этого используется связь модели данных, построенной в ERWin и модели процессов, построенной в BPWin. Проследим процесс преобразования данных при вводе данных в сущность «Специализация путей».

Работа системы начинается с загрузки файла конфигурации. При этом происходит чтение и отображения содержимого сущности «Специализация путей», а также подготовка формы для ввода исходных данных. После этого Исходные данные и Готовая форма для ввода поступают в качестве входных данных в работу Ввод исх. данных.

 В качестве управления выступает Выбор, а в качестве механизма Технолог и Система.

Работа Выбор пути формирования поезда заключается в выборе пути, на котором будет сформирован состав (исходя из исходных данных).

После выбора пути формирования номер пути поступает в качестве входных данных на работу Выбор станции назначения будущего поезда, где выбирается, до какой станции идет сформированный поезд.

Результат выбора технолога в предыдущей работе передаётся на вход Выбор доминирующего назначения поезда. Здесь выбирается, в каком основном направлении будет следовать поезд.

В работе Выбор сопутствующего назначения поезда будет выбираться на основании Кода доминирующего направления, т.е. через какие дороги, станции будет следовать поезд.

На вход работе Анализ введённой информации, поступают: Код станции, Код доминирующего направления, Код сопутствующего направления. Здесь происходит сравнение кодов назначений и установка Флага доминирования.

На основании предыдущих результатов и кода станции система выбирает из сущности «Назначения плана формирования» максимальное и минимальное значение графиковой длины и на основании только Кода станции выбирается максимальное и минимальное значение графикового веса.