Учёт движения поездов по железной дороге (стр. 2 из 3)
2. ПРОЕКТИРОВАНИЕ ПРОГРАММНОЙ СИСТЕМЫ
2.1 Описание требований к системе
Пассажир является действующим лицом данной системы. Ориентируясь на его потребности, можно предположить, что от разрабатываемой системы ему необходимы обеспечение возможности заказа/покупки билета и информация по расписанию. Заказ или покупка билета включает в себя сведенья о количестве мест в поезде всего, количестве бронированных мест и стоимости билета, также возможность получить дополнительную информацию по расписанию. Информация по расписанию включает в себя сведенья о номере рейса, названии начальной точки отправления (вокзала), конечной станции, времени отправления, времени прибытия. Данные требования можно представить в виде диаграммы прецедентов (рисунок 1).
Рисунок 1 – Диаграмма прецедентов
Описание структурных единиц информации
В БД имеются 3 таблицы, в которых хранятся следующие сведения:
1.Компании
· Индивидуальный номер компании
· Название компании
· Город базирования
2.Станции
· Индивидуальный номер станции
· Название вокзала
· Населенный пунк
3.Рейсы
· Индивидуальный номер рейса
· Количество мест
· Бронированные места
· Дни следования
Для поддержания БД в устойчивом состоянии используется ряд механизмов, которые получили обобщенное название средств поддержки целостности. Эти механизмы применяются как статически (на этапе проектирования БД), так и динамически (в процессе работы с БД).
Входная и выходная информация
Входными данными является информация, занесенная пользователем в качестве значений полей новой или изменяемой записи любой из таблиц.
Выходными данными является информация, которую может использовать пользователь посредством просмотра записей таблиц, выполнения различных запросов.
Переход состояний
Каждый объект системы, обладающий определенным поведением, может находится в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данная диаграмма (рис.2) позволяет отразить это графически.
Для построения структуры данной системы можно использовать ER-модель, так как она удобна при проектировании информационных систем, баз данных, и других систем.
ER-модель является одной из самых простых визуальных моделей данных. Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области.
Рисунок 2 –Диаграмма состояний
2.2 Структура системы
На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется даталогической моделью данных по отношению к исходной ER-диаграмме.
Для создания БД необходимо построить так называемую ER- диаграмму в виде совокупности связей, сущностей и атрибутов, изображенных в виде диаграммы ER –типов (рис.3).
Рисунок 3 – Диаграмма ER-типов
На данной диаграмме (см.рис. 3) описаны три сущности : Кампания, Рейс, Станция. Класс принадлежности этих сущностей – обязательный. Связь 1 – m:n. Связь 2 – n:m.
Окончательный набор таблиц
Для такой схемы обычно создаётся 5 таблиц, но есть возможность сократить количество таблиц с помощью приложения DataBaseDesktop, создав таблицы Paradox.
Paradox – это таблицы, а не базы данных. У Paradox в одном файле храниться одна таблица. К тому же индексы хранятся отдельно от таблицы, что накладывает определённые неудобства.
Итак, база данных будет состоять из трех таблиц. В первой будут следующие поля (после тире стоит тип поля, а в скобках размер):
Ключ 1 – autoincrement (ключевое)
Индивидуальный номер – short
Название компании – alpha (размер 15)
Город базирования – alpha (размер 15)
Соответственно 2-я:
Ключ 1 – autoincrement (ключевое)
Ключ 2 – Integer
Индивидуальный номер – short
Название вокзала – alpha (размер 15)
Населенный пунк – alpha (размер 15)
Наконец 3-я:
Ключ 2 – autoincrement (ключевое)
Ключ 3 – Integer
Индивидуальный номер – short
Количество мест – short
Бронированные места – short
Дни следования – alpha (размер 15)
«Ключ 1» – это будет уникальное ключевое поле в обеих таблицах, поэтому поставить значок ключевого. «Ключ 2» во второй таблице будет связан с «Ключ 1», а «Ключ 3» – будет связан с таблицей 2 по «Ключ 1». Называются таблицы Companies.db, Stations.db и Flights.db. Для связи таблиц между собой можно сделать следующее, открыть таблицу Stations.db и из меню Table выбрать пункт Restructure. Должно открыться окно, которое уже было при создании полей таблицы (рисунок 4).
Рисунок 4 – Окно редактирования полей таблицы Paradox
Теперь в этом же окне можно вносить изменения, а именно добавлять индекс. В выпадающем списке Table properties выбрать Secondary Indexes (дополнительные индексы) и нажать кнопку Define (определить). Выбрать свой второй ключ и переместить его в список Indexed fields (индексированные поля). Для этого надо нажать кнопку с изображённой стрелкой вправо (рисунок 5). Можно нажимать OK. Сразу запросится имя индекса, введено Network12 и снова нажать OK. После этого сохранить таблицу.
Рисунок 5 – Окно редактирования полей таблицы Paradox
Аналогично создаем индексы для таблицы Flights.db. только вместо «Кey2» выбираем «Кey3», и имя индекса, введем Network23.
То есть таким несложным образом можно сократить количество ненужных таблиц, при этом устанавливая связь между таблицами.
Диаграмма модулей
В данной программе действуют классы, которые являются компонентами Delphi. На рисунке 6 представлена диаграмма модулей данного программного продукта.
Рисунок 6 – Диаграмма модулей программного продукта
3. РЕАЛИЗАЦИЯ СИСТЕМЫ КОНТРОЛЯ ДВИЖЕНИЯ ЖЕЛЕЗНОДОРОЖНЫХ ПОЕЗДОВ
3.1 Описание разработанной системы, техническое обеспечение
Автоматическая система разрабатывается для предприятий государственного или не государственного железнодорожного транспорта. Данная разработанная система будет использоваться для обработки первичных данных, поступающих от администрации железнодорожных компаний; для упорядочивания базы данных движения поездов; для составления анализа железнодорожного траффика по запросу руководителя. Непосредственный пользователь автоматической системы – потенциальный пассажир железнодорожного транспорта – будет использовать систему для проверки наличия билетов; анализа удобного маршрута и возможности совершения планируемой поездки.
Назначение АСОИ состоит в следующем:
– Экономия личного времени;
– Высокая скорость при обработке информации;
– Возможность оперативно получать необходимую информацию по требованию потенциального пассажира.
Техническое обеспечение
Техническое обеспечение АСОИ это комплекс технических средств - совокупность взаимосвязанных единым управлением и автономных технических средств, предназначенных для сбора, хранения, накопления, обработки, передачи, вывода информации, а также средств оргтехники и управления.
Техническое обеспечение должно выбираться по наиболее оптимальному соотношению цены и качества, что, в основном, зависит от финансовых возможностей предприятия. Также важнейший критерий, предъявляемый при приобретении нового технического средства – совместимость с ранее приобретенными.
Для эффективной работы программного продукта необходимо выполнение следующих требований к аппаратным и программным средствам:
1 Процессор 1000 MHz,
2 Видеокарта 32 Mb,
3 128 Mb оперативной памяти,
4 2 Mb дискового пространства для минимальной конфигурации,
5 операционная система Windows 2000/NT/Millenium/XP,
6 лазерная мышь,
7 клавиатура,
8 модем 56 Kb.
3.2 Организация взаимодействия клиентской программы с БД
Приложение разрабатывалось в среде BorlandDelphi 7.0. Взаимодействие с БД осуществляется с помощью следующих компонентов, входящих в стандартный набор этой системы:
1)ADOConnection;
2)DataSource;
3)ADOTable;
4)DBGrid;
5)ADOStoredProc;
6)DBlookupcombobox:
7)DBNavigator.
Компонент ADOConnection (соединение с базой данных) имеет ряд свойств для настройки подключения к БД.
Компонент ADOTable обеспечивает взаимодействие с таблицей БД. Для связи с требуемой таблицей нужно установить соответствующее значение свойствам DatabaseName, указывающему имя БД, и TableName, указывающему имя таблицы.
Компонент DataSource является промежуточным звеном между компонентами ADOTable или StoredProc и визуальными компонентами (например, DBGrid). Чтобы связать компонент ADOTable и компонент DataSource, указывают название первого в свойстве DataSet последнего.
Для представления пользователю полученных в результате работы данных в более удобной форме используют компоненты DBGrid (таблица).
Компонент DBGrid используется только для представления данных, а добавление, редактирование и удаление данных осуществляется с помощью системы хранимых процедур.