Создание автоматизированного рабочего места технолога станции (стр. 2 из 4)

1. Имеет средства обеспечения целостности данных.

2. Informix поддерживает язык SQL.

3. Informix позволяет защищать базы данных на уровне пользователей.

4. В Informix’e имеются средства для организации совместного доступа к базе данных и механизм блокировки записей.

MS SQL Server и DB2 имеют такую же производительность и масштабируемость как и Informix, обеспечивают поддержку крупных баз данных, но в настоящее время используется Informix.

СУБД Informix вполне удовлетворяет требованиям, предъявляемым к проектируемой системе: защита информации осуществляется на уровне пользователя, возможно использование совместного доступа к данным.

СУБД Informix физически расположен на сервере под управлением ОС Unix. Физический сервер должен оставаться работоспособным при одновременном обращении 12 пользователей, т.е. иметь достаточную: вычислительную мощность, количество памяти и свободного пространства жестком диске достаточного для размещения ОС и БД.

На стороне клиента будет использоваться один из Web-броузеров (Internet Explorer, Netscape, Opera или Mozilla).

В виду перехода, в ближайшее время, на СУБД Oracle 8.1.7 выбирается язык реализации Java, доступ к БД будет осуществляться через JDBC. Применение JDBC позволит, не изменяя внутреннего содержимого программы, легко перейти на другую СУБД путём смены JDBC-драйвера.

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).