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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Расчеты и оценки

5.1 Расчет требуемых ресурсов вычислительных средств

Реализация системы предполагается на языке Java. Требования к ресурсам обусловлены в основном минимальными требованиями для нормального функционирования ОС и библиотек Java.

Требования для компьютера технолога:

Процессор: Pentium 200 или выше.

Память: Для Windows 95 или Windows 98: 64 Мб памяти для операционной системы.

Для Windows NT 4.0: 128 Мб памяти для операционной системы.

Жесткий диск: 1 Гб.

Монитор: Монитор SVGA 17’’.

Рассчитаем примерный объем хранимых данных для оценки необходимого свободного места на жестком диске. Каждая запись в Специализации путей занимает около 40 байт. 5000 записей займет 200 Кбайт. Запись о Станции будет примерно занимать 50 байт и при хранении 60000 станций объём составит 3Мбайта. Оставшиеся сущности в целом будут занимать приблизительно 1Мбайт. Таким образом, для хранения годовой информации, при условии, что за сутки будет оправлено 20 поездов до 100 станций, потребуется 365*40*20*100= 29200000 байт. Таким образом, для хранения годовой информации о 20 поездах идущих до 100 станций в сутки потребуется 30 Мбайт. Весь этот объём данных будет храниться на отдельном диске, на сервере, кроме этого там будут храниться ежедневные копии БД (так называемых level backup), что дополнительно потребует около 2 Мбайт. Требования к серверу БД связаны с тем, что все действия (операции) с БД будет выполнять именно сервер БД, а компьютер технолога будет только отображать результат действий сервера. Кроме того, данный сервер будет использован для работы других АРМов и на нем будут работать несколько разных БД (10-15).

Требования для сервера БД:

Процессор: Pentium II 400 или выше.

Память: 512 Мб.

Жесткие диски: 4,3 Гб для системы + 10 Гб для хранения баз данных.

Монитор: Монитор SVGA 14’’(может отсутствовать).

Управление работой ОС Unix и СУБД предполагается осуществлять через сеть. Два жестких диска необходимы для того, чтобы отделить операционную систему от баз данных. Необходимо для облегчения перестановки ОС. Большой объем жесткого диска для БД связан с необходимостью хранить резервные копии всех БД, а также ежедневные копии БД для быстрого восстановления в случае сбоя.

5.2 Расчет по функционально-ориентированной метрике

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Для примера рассчитаем функциональность одной из пользовательских форм, которая будет использована в конечном продукте.

Рис. 5.2

При расчетах по функционально-ориентированной метрике используется 5 информационных характеристик:

1. Количество внешних вводов: 1 (кнопка OK); данный элемент ввода состоит из 7 элементов данных (1 поле ввода, 5 полей со списком, 1 командная кнопка).

2. Количество внешних выводов: 1 (сообщение уведомления); элемент вывода состоит из 1 элемента данных (командная кнопка).

3. Количество внешних запросов: 0.

4. Количество внутренних логических файлов: 4 (справочник ДоминирующееНаправление, справочник сопутствующееНаправление, таблица Станции, таблица Пути); таблица Станции состоит из 6 элементов данных, справочник ДоминирующееНаправление, справочник сопутствующееНаправление и таблица Станции – из 3.

5. Количество внешних интерфейсных файлов: 0.

Далее, для каждой информационной характеристики по известным таблицам определяются ранг и оценка сложности.