Создание автоматизированного рабочего места технолога станции

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Создание автоматизированного рабочего места технолога станции

Создание автоматизированного рабочего места технолога станции

28

3

Цель выполнения данного проекта является создание автоматизированного рабочего места (АРМ) технолога станции.

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

1. Разработка и анализ технического задания

Железнодорожные линии делятся на участки, а участки на перегоны. Границами смежных перегонов служат раздельные пункты: станции, разъезды, обгонные пункты. Границы участков - участковые или сортировочные станции.

Станцией называется раздельный пункт, имеющий путевое развитие, позволяющее производить операции по приёму, отправлению, скрещиванию и обгону поездов. На станциях размещены технические устройства, обеспечивающие пропускную и провозную способность железнодорожных линий: сооружения и устройства станционного хозяйства, локомотивные и вагонные депо, пункты технического обслуживания вагонов и т.д. От работы станции в значительной степени зависят: обеспечение выполнения плана перевозок пассажиров и груза; отправление поездов по графику и в соответствии с планом формирования поездов - полными по массе и длине, исправными в техническом и коммерческом отношении; безопасность движения поездов, их приёма, отправления, скрещивания, обгона и манёвров; регулярность, своевременность и сохранность доставки грузов; снижение себестоимости перевозок; выполнение комплексного показателя работы железных дорог - оборота вагона (за время своего оборота вагон находится в движении только 30% времени, а 70% - на станции).

Железнодорожные станции классифицируются по ряду признаков. По назначению и характеру работы они подразделяются на промежуточные, участковые сортировочные, грузовые, пассажирские и технические пассажирские. Так, например, на грузовых станциях производят приём, хранение, выдачу, погрузку и взвешивание грузов, а также расформирование и формирование отправительских маршрутов и передач. Грузовые операции выполняются на местах общего пользования и на подъездных путях предприятий.

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

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

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

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

На этапе предварительного проектирования к системе предъявляются следующие количественные характеристики:

1. количество рабочих мест равно 12, т.к. столько рабочих мест технологов станций;

2. время реакции системы на действия пользователя должно быть как можно меньше.

В проектируемой системе следует предусмотреть наличие нескольких рабочих мест: администратора, технологов.

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

2. Технолог может работать в соответствии с правами, предоставленными ему администратором.

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

Рассмотрим возможные варианты при решении поставленной задачи.

Вариант №1 «Новый АРМ - новый модуль работы со справочниками»

При таком развитии событий получается, что каждый программист при создании нового АРМа пишет модуль для работы со своими справочниками. Это приведет к затягиванию внедрения АРМа.

Вариант №2 «Использование DBACCESS»

DBACCESS - программа поставляемая вместе с СУБД Informix, предназначена для написания и выполнения запросов. Использование данного инструмента крайне затруднительно, кроме того, он не обеспечивает проверку корректности ввода данных. При этом неизбежно будут появляться ошибки, которые трудно затем будет отследить.

Вариант №3 «Использование предыдущих разработок»

Использование предыдущих разработок возможно в ограниченном объеме, только при работе с некоторыми справочниками. Структура справочных таблиц меняется, предыдущие АРМы имеют «жесткий» внутренний алгоритм и подстройка структуры программы к структуре измененных данных займет много времени (изменение программы + тестирование). Предыдущие разработки реализовывались на внутреннем языке СУБД Informix 4GL. Кроме того, при смене СУБД старые разработки пришлось бы переписывать заново.

Вариант №4 «Разработка информационной системы»

Разработка информационной системы позволит:

1. не зависеть от используемой СУБД, т.к. планируемый язык реализации Java (доступ к СУБД через JDBC);

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

3. сократить время других разработок, т.к. проектируемая ИС позволит вводить данные в справочные таблицы для каждого нового АРМа;

4. возможность одновременной работы с ИС нескольких пользователей;

Таким образом, разработка ИС является наилучшим вариантом решения поставленной задачи.

Проанализируем возможные варианты реализации предъявленных требований к создаваемой информационной системе.

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

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

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

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

Вывод: Для построения ИС расположим БД на выделенном сервере с доступом к нему по сети. Другие способы реализации в данном случае не эффективны.

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

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

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

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

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

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

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

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

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

Предусловия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессор: 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.

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

После сбора всей необходимой информации подсчитаем общую функциональную метрику (таблица 5.2).

Таблица 5.2

Аналогичным образом рассчитаем функциональность второго типа пользовательской формы (рисунок 5.2). Результаты расчета в таблице 5.2.

Таблица 5.2

С учетом того, что в проекте предполагается использование 3 пользовательских форм первого типа и 2 пользовательских форм второго типа, подсчитаем общую функциональную метрику для всего проекта:

FP = 3 * 36 + 2 * 32 = 172

Полученную общую метрику необходимо субъективным образом взвесить, используя следующую формулу:

FP = Общее_количество * (0,65+ 0,01 * 14i=1Fi), (5.1)

где Fi - коэффициенты регулировки сложности.

Таблица 5.3 - Определение системных параметров приложения

Каждый коэффициент может принимать следующие значения: 0 -- нет влияния, 1 - случайное, 2 -- небольшое, 3 -- среднее, 4 -- важное, 5 -- основное.

Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (таблица 5.3).

В результате количество функциональных указателей равно:

FP = 172 * (0.65 + 0.29) = 162

Используя таблицу перевода, а также учитывая, что реализация ИС предполагается с использованием языка Visual Basic, получим LOC-оценку проекта:162 * 32 = 5184 (строк кода).

Заключение

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

Система реализуется с помощью СУБД Informix с использованием языка Java. Данная СУБД была выбрана в связи с тем, что данная СУБД используется в настоящее время.

Язык Java была выбрана в виду направленности отдела ВЦЛП на Web-разработку, а также из-за перехода на другую СУБД (Oracle 8.1.7) с целью снижения возможных изменений внутреннего содержания программы.

Библиографический список

1. Серверы корпоративных баз данных. www.citforum.ru;

2. П. Ноутон, Г.Шильдт. Java тм 2: Пер. с англ.- СПб.: БХВ-Петербург, 2001.