Веб-ориентированная подсистема учета работ на железной дороге
Рисунок 1.7 — Создание маршрута Рисунок 1.8 — Просмотр всех маршрутов Рисунок 1.9 — Создание перегона Рисунок 1.10 — Просмотр всех перегонов Рисунок 1.11 — Создание рейса Рисунок 1.12 — Просмотр рейсов Рисунок 1.13 — Создание состава Рисунок 1.14 — Просмотр всех составов Рисунок 1.15 — Анализ движения состава Рисунок 1.16 — Статистика отказа по перегонам Макет страницы для работы рабочей бригады… Читать ещё >
Веб-ориентированная подсистема учета работ на железной дороге (реферат, курсовая, диплом, контрольная)
[Введите текст]
Міністерство освіти і науки України, молоді та спорту України
ДВНЗ «Донецький національний технічний університет»
Факультет КНТ
Кафедра автоматизованих систем управління
" Затверджено"
_______________________
підпис викладача-керівника
«____"_____________20__ р.
Завдання на курсову роботу
з дисципліни «Проектування веб-орієнтованих комп’ютерних систем»
студенту групи ІУС-12м Авджи Ніни Іллівни___________________________
(група, прізвище, ім'я, по-батькові студента у родовому відмінку)
1. Тема курсової роботи: «Спроектувати веб-орієнтовану підсистему обліку робіт на залізниці.__________________________________________
(назва предметної області)
2. Вхідні дані:
3. Перелік питань, що підлягають розробці:
4. Рекомендовані засоби:
сховище даних: реляційна СУБД MySQL.
засіб розробки програмного додатку PHP, JavaScript
Рекомендована література:
6. Зміст пояснювальної записки: типовий, згідно стандартів .
7. Термін здачі роботи на кафедру:
8. Дата захисту роботи за графіком:
Завдання видано 05/09/2012.
Завдання видав_________________________________доц. Мартиненко Т.В.
(підпис, посада, ПІБ викладача-керівника)
Консультант_________________доц. Мартиненко Т. В., асс. Андрієвська Н.К.
(підпис, посада, ПІБ викладача-консультанта)
Завдання до виконання прийняв_____________________________________.
(підпис, ПІБ студента)
РЕФЕРАТ
Цель курсовой работы — разработать компьютеризированную подсистему «Управления движением поездов».
Задачи курсовой работы:
1. Анализ основных факторов (незапланированные «окна» в графике движения поездов, возникающие внештатные ситуации (и, как следствие, изменение пропускной способности), ограничения скорости движения поездов на участках, наличие и возможность подвязки локомотивов и локомотивных бригад), влияющих на организацию поездной и местной работы на станциях, участках, полигонах сети;
2. Исследование эксплуатационной работы, обеспечивающей рациональный уровень качества перевозочного процесса;
3. Изучение технологии организации перевозок на основе твердого графика движения поездов, системы идентификации подвижного состава, методов планирования и управления.
4. Выполнение обзора существующих систем
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ И СОКРАЩЕНИЙ
БД — база данных.
КП — компьютеризированная подсистема.
МД — модель данных.
ПО — программное обеспечение.
Организация движения поездов и местной работы на поездоучастке в соответствии с нормативным графиком движения поездов, а также соблюдение безусловного уровня безопасности движения и обеспечение максимальной экономической эффективности является одной из важнейших задач перевозочного процесса.
Железные дороги Украины из-за простоя и задержек полувагонов на подъездных путях за 6 месяцев 2012 года не смогли задействовать в перевозочном процессе 153,649 тыс. полувагонов и недополучили, таким образом, более 96 млн. грн.
Чтобы избежать этого, возникает задача разработки системы, которая отображала данные о передвижении поездов с учетом загрузки узлов, запланированных и незапланированных окон, возникновением внештатных ситуаций, с учетом ограничения скорости движения поездов на участках, с учетом наличия и возможности подвязки локомотивов и локомотивных бригад, что позволит уменьшить часы простоя поездов.
1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ СИСТЕМЫ
1.1 Назначение системы
Система предназначена для отображения данных о передвижении поездов с учетом загрузки узлов, запланированных и незапланированных окон, возникновением внештатных ситуаций, с учетом ограничения скорости движения поездов на участках, с учетом наличия и возможности подвязки локомотивов и локомотивных бригад.
Подсистема должна соответствовать современным требованиям и обеспечивать пользователей необходимыми сервисами (учет поездного положения, учет загруженности станций, данные о поездном положении с учетом информации о структуре и состоянии транспортной сети, с учетом пассажирских, пригородных и грузовых поездов высшего приоритета, с учетом запланированных и незапланированных «окон», получение данных о загруженности станции на заданное время, перегонов и местоположении локомотивных бригад).
1.2 Цели создания системы
Целями создания подсистемы являются:
— повышение эффективности использования подвижного состава;
— повышение эффективности планирования работы станций, отделений железной дороги;
— повышение эффективности планирования человеческих и материальных ресурсов различных служб:
1) службы перевозок (загрузки станций и перегонов);
2) локомотивной (оптимизация использования локомотивов и локомотивных бригад);
3) службы пути и службы автоматики и телемеханики (техническое обслуживание и ремонт пути);
— повышение эффективности местной работы;
Достичь поставленных целей может комплексное решение задач:
— анализ основных факторов (незапланированные «окна» в графике движения поездов, возникающие внештатные ситуации (и, как следствие, изменение пропускной способности), ограничения скорости движения поездов на участках, наличие и возможность подвязки локомотивов и локомотивных бригад), влияющих на организацию поездной и местной работы на станциях, участках, полигонах сети;
— исследование эксплуатационной работы, обеспечивающей рациональный уровень качества перевозочного процесса;
— изучение технологии организации перевозок на основе твердого графика движения поездов, системы идентификации подвижного состава, методов планирования и управления.
1.3 Требования к подсистеме
Требования, которые заложены в подсистему:
— надёжность, использование СУБД, которые зарекомендовали себя, обеспечивающие высокий уровень надежности;
— модульность, подсистема должна обеспечивать индивидуальную конфигурацию системы и разрешать расширять и дополнять функциональные возможности уже работающего решения без его остановки;
— широкие функциональные возможности, подсистема предоставляет полный набор функциональных возможностей необходимых современному пользователю;
— простота использования;
— удобство предоставления информации;
Требования к информационному обеспечению:
обеспечение конфиденциальности секретной информации;
достаточная производительность доступа к данным при выполнении запроса;
правильный отбор первичных сведений и источников информации;
правильная систематизация и классификация информации.
Требования к языкам программирования Для написания статичных страниц должен быть использован язык разметки html 5, для написания интерактивных элементов клиентской части и динамических страниц должен использоваться скриптовый язык php.
Требования к режиму работы:
Система должна функционировать непрерывно и круглосуточно без вмешательства технических администраторов.
Требования к диагностированию:
Диагностирование системы должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций.
Требования к защите информации от несанкционированного доступа:
— идентификация, проверка подлинности и контроль доступа субъектов;
— шифрование конфиденциальной информации;
— обеспечение целостности программных средств и обрабатываемой информации;
— физическая охрана средств вычислительной техники и носителей информации;
— использование сертифицированных средств защиты.
Требования к эргономике и эстетике:
1. Минимальное расширение для корректной работы сайта 1024×768.
2. Максимальное расширение неограниченно.
3. Элементы управления должны быть сгруппированы однотипно-горизонтально или вертикально — на всех страницах.
4. На каждой странице должны отображаться логотип и контактная информация.
5. Интерфейс модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использования одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.
Требования к ссылкам:
Все ссылки на сайте должны быть относительными, кроме внешних.
Язык интерфейса: русский.
Требования к размеру страницы:
Все элементы дизайна должны быть сжаты таким образом, чтобы размер страницы не превышал 50кб.
Требования к серверной части:
Системные требования:
— процессор — 2 ядра, не менее 512МБ ОЗУ, жесткий диск не менее 250 ГБ.
— операционная система: Linux, Windows.
— версия Apache: 1.3.41+,
— версия MySQL: 5.0+,
— версия PHP: 5.1+.
Требования к пользовательской части:
Веб-система должна корректно отображаться в следующих браузерах — Internet Explorer 6.0+, Оpеra 9.2+, Firefox 2.0+, Safari 2.0+, Chrome 2+.
Требования к функциям
1. Определение положения поездов Описание: диспетчер вводит данные о маршруте в форму и отправляет данные контент-менеджеру.
Входные данные: времена хода поездов по перегонам, нормы времени на разгон и замедление, нормативы продолжительности стоянок поездов на промежуточных станциях для выполнения технических и коммерческих операций, нормативы оборота локомотивов в депо для выполнения технического обслуживания и расчетные минимальные интервалы между поездами при приеме, отправлении и проследовании их через станции (станционные интервалы), а также интервалы между поездами, следующими в пакете (межпоездные интервалы), названия участка, где производятся работы, вид работ и время работы (от 1 часа до 6 часов), сходы составов, неисправности пути, задержка поездов более часа, отказы технических средств.
Выходные данные: данные в виде массива.
2. Анализ движения поездов. Описание: контент-менеджер анализирует данные, полученные от диспетчеров в виде массива сортирует их по станциям хода следования поезда Входные данные: массив данных.
Выходные данные: графическое отображение маршрута поезда с указанными временными интервалами в декартовой системе координат, где ось Х — ось времени, ось У — ось расстояния с учетом всех неисправностей.
3. Ведение информации о расположении поездов. Диспетчер ставит задачи машинистам и трудовым бригадам.
Входные данные: график движения поездов.
Выходные данные: постановка задач, координация работы, отслеживание движения поезда на больших расстояниях.
4. Статистика отказа по перегонам.
Входная информация: номер и название перегона, состав, тип отказа.
Выходная информация: круговая диаграмма простоя поездов.
Требования к программному обеспечению Требования к программному обеспечению серверной части.
Для функционирования ВБС, на сервере должно быть следующее программное обеспечение:
СУБД — MySQL;
Web Server — Denver;
CMS — Drupal.
Требования к клиентскому программному обеспечению.
ВБС должна быть доступна для полнофункционального пользования и просмотра с помощью следующих браузеров:
Chrome 2.0 и в их более поздние версии;
ВБС Должна быть дееспособна, то есть информация, размещенная на ней, должна быть доступна, при отключенной в браузере поддержки flash і JavaScript.
Требования к техническому обеспечению Техническое обеспечение системы должно максимально и наиболее эффективным образом использовать существующие технические средства. В состав системы должны входить следующие технические средства:
процессор с тактовой частотой не менее: 1,4 ГГц или выше;
2 ГБ или более оперативной памяти (ОЗУ);
жесткий диск 120 Гб или более;
графический адаптер;
DVD-дисковод;
клавиатура и мышь;
сетевой интерфейс 100 мб/сек или более;
Требования к приему-сдаче проекта.
Сдача-приём работы производится поэтапно, в соответствии с рабочей программой и календарным планом.
Сдача-прием осуществляется комиссией, в состав которой входят руководитель курсовой работы и студент-исполнитель. По результатам приема подписывается пояснительная записка и студент получает зачет.
Все создаваемые в рамках настоящей работы программные продукты передаются руководителю, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске).
Требования к представлению системы Администратор, который в нашей системе имеет имя Nina, может управлять сайтом и имеет права и менеджера, и диспетчера.
Менеджер может создавать маршруты и управлять ими, создавать перегоны и управлять ими, создавать рейсы и управлять ими, создавать составы и управлять ими и проводить анализ положения составов и предоставлять статистику отказов поездов.
Диспетчер может создавать задачи и управлять ими, регистрировать отказ технических средств и управлять ими, создавать технические работы и управлять ими.
Есть возможность просмотра списка задач для технических бригад на каждой станции.
Макеты страниц для работы диспетчера разработанной системы приведены ниже.
Рисунок 1.1 — Создание технической работы Рисунок 1.2 — Просмотр всех технических работ Рисунок 1.3 — Создание отказа технических средств Рисунок 1.4 — Просмотр всех отказов технических средств Рисунок 1.5 — Создание задачи трудовой бригаде Рисунок 1.6 — Просмотр всех задач Макеты страниц для работы менеджера разработанной системы приведены ниже.
Рисунок 1.7 — Создание маршрута Рисунок 1.8 — Просмотр всех маршрутов Рисунок 1.9 — Создание перегона Рисунок 1.10 — Просмотр всех перегонов Рисунок 1.11 — Создание рейса Рисунок 1.12 — Просмотр рейсов Рисунок 1.13 — Создание состава Рисунок 1.14 — Просмотр всех составов Рисунок 1.15 — Анализ движения состава Рисунок 1.16 — Статистика отказа по перегонам Макет страницы для работы рабочей бригады разработанной системы приведен ниже.
Рисунок 1.17 — Просмотр задач, поставленных бригадам
2. РАЗРАБОТКА ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ
2.1 Разработка логической модели данных
Была разработана база данных «railway», которая содержит информацию, необходимую для учета передвижения поездов. База данных содержит 8 таблиц: тЗадача, тЗадержка, тМаршрут, тПерегон, тРейс, тСостав, тТехработа, тПользователи.
Стуктура БД и таблиц приведена ниже в таблицах 2.2−2.11.
БД должна помочь диспетчеру и менеджеру ускорить работу и облегчить ведение учета передвижения поездов и постановки задач рабочим бригадам. Для разработки БД была выбрана СУБД phpMyAdmin, а диаграмма разработана в Microsoft SQL Server 2008 Managment Studio.
В таблице 2.1 представлены сущности логической модели данных, а также их описание.
Таблица 2.1 — Сущности логической МД базы данных «railway»
№ пп | Имя таблицы | Назначение | |
тЗадача | Определяет задачу, которую диспетчер может поставить рабочей бригаде | ||
т Задержка | Определяет задержку состава на перегоне, вызванной неисправностью либо другими причинами | ||
тМаршрут | Описывает маршрут следования состава | ||
тПерегон | Определяет часть железнодорожной линии между смежными раздельными пунктами | ||
тРейс | Описывает поезд на заданном маршруте, который отправляется в заданное время | ||
тСостав | Определяет новый состав (поезд) | ||
тТехработа | Определяет работу, связанную с обслуживанием путей | ||
тПользователи | Профили пользователей | ||
Определим типы связей между сущностями и индексы обеспечивающие целостность данных. Описание характера связей в БД и условия целостности приведены в табл. 2.2.
Таблица 2.3 — Связи между сущностями
Родительская таблица | Дочерняя таблица | Тип связи | |||
Имя | Индекс | Имя | Индекс | ||
Состав | PK_состав | Рейс | FK_состав | 1:? | |
Состав | PK_состав | Задержка | FK_состав | 1:? | |
Маршрут | PK_маршрут | Рейс | FK_маршрут | 1:? | |
Перегон | PK_перегон | Маршрут | FK_перегон | 1:? | |
Перегон | PK_перегон | Техработа | FK_перегон | 1:? | |
Перегон | UQ_начальная_станция | Пользователи | FK_начальная_станция | 1:? | |
Пользователи | FK_рабочая бригада | Задача | UQ_рабочая бригада | 1:? | |
Перегон | UQ_конечная_станция | Пользователи | FK_начальная_станция | 1:? | |
Перегон | PK_перегон | Задержка | FK_перегон | 1:? | |
Определим свойства таблиц и полей так, чтобы обеспечить максимальный контроль данных.
Таблица 2.4 — Структура таблицы тЗадача (task)
№ | Заголовок | Название | Тип | |
Тип задачи | field_task_type_id | Целое число | ||
Рабочая бригада | field_team_id | Ссылка на пользователя | ||
Таблица 2.5 — Структура таблицы тМаршрут (route)
№ | Заголовок | Название | Тип | |
Перегон | field_stage_id | Ссылка на материал | ||
Станция отправления | field_start_station_id | Ссылка на пользователя | ||
Станция прибытия | field_end_station_id | Ссылка на пользователя | ||
Таблица 2.6 — Структура таблицы тПерегон (stage)
№ | Заголовок | Название | Тип | |
Начальная станция | field_stage_start_station_id | Ссылка на пользователя | ||
Конечная станция | field_stage_end_station_id | Ссылка на пользователя | ||
Длина перегона | field_stage_distance | Число с плавающей точкой | ||
Таблица 2.7 — Структура таблицы тРейс (trip)
№ | Заголовок | Название | Тип | |
Маршрут | field_route_id | Ссылка на материал | ||
Состав | field_train_id | Ссылка на материал | ||
Время отправления | field_departure_time | Дата | ||
Таблица 2.8 — Структура таблицы тТехработа (work)
№ | Заголовок | Название | Тип | |
Перегон | field_stage_id | Ссылка на материал | ||
Вид работ | field_work_type_id | Целое число | ||
Время работ | field_work_time | Целое число | ||
Таблица 2.9 — Структура таблицы тСостав (train)
№ | Заголовок | Название | Тип | |
Тип перевозок | field_transport_type_id | Целое число | ||
Количество вагонов | field_wagon_qty | Целое число | ||
Время разгона | field_acceleration_time | Целое число | ||
Время торможения | field_braking_time | Целое число | ||
Скорость | field_speed | Целое число | ||
Таблица 2.10 — Структура таблицы тЗадержка (delay)
№ | Заголовок | Название | Тип | |
Тип отказа | field_failure_type_id | Целое число | ||
Перегон | field_stage_id | Ссылка на материал | ||
Состав | field_train_id | Ссылка на материал | ||
Таблица 2.11 — Структура таблицы тПользователи (users)
№ | Заголовок | Название | Тип | |
Название станции | Profile_station_name | Textfield | ||
Межпоездной интервал | Profile_train_interval | Textfield | ||
Технические операции | Profile_technical_operations | Textfield | ||
Коммерческие операции | Profile_commercial_operations | Textfield | ||
2.2 Разработка физической модели данных
Физическая модель данных приведена на рисунке. 2.1.
Рисунок 2.1 — Физическая модель данных
3. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1 Разработка диаграммы классов
Разработка диаграммы классов для диспетчера.
Таблица 3.1 — Классы системы для диспетчера
Класс | Стереотип | Назначение | |
index.php | Server Page | Построение главной страницы | |
index.html | Client Page | Отображение главной страницы | |
stationinfo.php | Server Page | Построение страницы информации о станциях | |
stationinfo.html | Client Page | Отображение страницы информации о станциях | |
stationinfo | Form | Форма для ввода информации о станциях | |
delaystat.php | Server Page | Построение страницы статистики отказов | |
delaystat.html | Client Page | Отображение страницы статистики отказов | |
taskmanage.php | Server Page | Построение страницы управления задачами | |
taskmanage.html | Client Page | Отображение страницы управления задачами | |
taskaction.php | Server Page | Построение страницы создания задач | |
taskcreateedit.html | Client Page | Отображение страницы создания задач | |
task | Form | Форма для ввода задач | |
delaymanage.php | Server Page | Построение страницы управления отказами | |
delaymanage.html | Client Page | Отображение страницы управления отказами | |
delayaction.php | Server Page | Построение страницы создания отказов | |
delaycreateedit.html | Client Page | Отображение страницы создания отказов | |
delay | Form | Форма для ввода информации об отказах | |
workmanage.php | Server Page | Построение страницы управления техработами | |
workmanage.html | Client Page | Отображение страницы управления техработами | |
workaction.php | Server Page | Построение страницы создания техработ | |
workcreateedit.html | Client Page | Отображение страницы создания техработ | |
work | Form | Форма для ввода данных о техработах | |
Диаграмма классов приведена в приложении А.
Разработка диаграммы классов для менеджера.
Таблица 3.2 — Классы системы для менеджера
Класс | Стереотип | Назначение | |
index.php | Server Page | Построение главной страницы | |
index.html | Client Page | Отображение главной страницы | |
stagemanage.php | Server Page | Построение страницы управления перегонами | |
stagemanage.html | Client Page | Отображение страницы управления перегонами | |
stageaction.php | Server Page | Построение страницы создания перегона | |
stagecreateedit.html | Client Page | Отображение страницы создания перегона | |
stage | Form | Форма для создания перегона | |
analyzeposition.php | Server Page | Построение страницы анализа положения поездов | |
analyzeposition.html | Client Page | Отображение страницы анализа положения поездов | |
trainmanage.php | Server Page | Построение страницы управления составами | |
trainmanage.html | Client Page | Отображение страницы управления составами | |
trainaction.php | Server Page | Построение страницы создания составов | |
traincreateedit.html | Client Page | Отображение страницы создания составов | |
train | Form | Форма для ввода данных о составе | |
tripmanage.php | Server Page | Построение страницы управления рейсами | |
tripmanage.html | Client Page | Отображение страницы управления рейсами | |
tripaction.php | Server Page | Построение страницы создания рейса | |
tripcreateedit.html | Client Page | Отображение страницы создания рейса | |
trip | Form | Форма для ввода данных о рейсе | |
routeaction.php | Server Page | Построение страницы создания маршрута | |
routecreateedit.html | Client Page | Отображение страницы создания маршрута | |
route | Form | Форма для ввода данных о маршруте | |
routemanage.php | Server Page | Построение страницы управления маршрутами | |
routemanage.html | Client Page | Отображение страницы управления маршрутами | |
Диаграмма классов приведена в приложении А.
3.2 Разработка схемы взаимодействия объектов системы
Схема иерархии пользователей приведена на рисунке 3.1
Рисунок 3.1 — Иерархия пользователей Диаграмма вариантов использования приведена на рисунке 3.2.
Рисунок 3.2 — Диаграмма вариантов использования
3.3 Описание программных модулей системы
Рассмотрим наиболее важные модули, которые использовались при проектировании системы:
1) сck — система создания контента. Позволяет очень гибко управлять материалами на сайте, создавать различные типы полей контента, а также задавать способ отображения этих полей.
2) devel — предоставляет различные инструменты (блоки, страницы и функции) для разработчиков. В частности используется возможность быстрого переключения пользователей.
3) dhtml_menu — динамически открывает меню, чтобы уменьшить количество переходов по страницам.
4) date — предоставляет поля даты для CCK и Views.
5) l10n_update — предоставляет возможность автоматической загрузки и обновления переводов.
6) potx — обеспечивает web-интерфейс и API-интерфейс, чтобы извлечь переводимый текст из строк установленных модулей.
7) views — обеспечивает гибкое управление для разработчиков тем, какие списки составлять, что в них выводить, как по ним искать, в какой форме выводить. Можно сделать галереи изображений и т. д. В Drupal жёстко определены такие списки как термины таксономии и последние изменения на сайте. Модуль позволяет менять их и составлять новые.
8) views_customfield — предоставляет дополнительные типы столбцов для модуля views. В частности используется тип столбца phpcode, который позволяет встраивать во views исполняемый код.
9) open_flash_chart_api — предоставляет программный интерфейс к функциям обработки графиков.
10) railway — наш модуль, предоставляет функции анализа движения и статистки отказов.
4. ТЕСТИРОВАНИЕ ВЕБ-БАЗИРОВАННОЙ СИСТЕМЫ
Зайдем в систему с правами диспетчера и создадим Задачу для локомотивной бригады. Для этого выберем пункт меню «Задачи» и подменю «Создать задачу», после создания сохраним ее и просмотрим внесенные данные, выбрав пункт подменю «Управлять задачами». Созданные задачи можно изменить либо удалить.
Рисунок 4.1 — Создание задачи Рисунок 4.2 — Просмотр созданной задачи Теперь создадим отказ технических средств, выбрав пункт меню «Отказы техсредств» и подпункт меню «Регистрировать отказ техсредств», выбрав пункт «Управлять отказами техсредств».
Рисунок 4.3 — Создание задержки Рисунок 4.4 — Просмотр созданной задержки Еще в данном режиме можно задать дополнительные критерии отбора.
Рисунок 4.5 — Вывод информации по заданным критериям
Теперь создадим техническую работу, выбрав пункт меню «Техработы» и подпункт меню «Создать техработу» и просмотрим введенные данные, выбрав пункт «Управлять техработами».
Рисунок 4.6 — Создание технической работы Рисунок 4.7 — Просмотр созданных технических работ Рисунок 4.8 — Выбор технической работы по заданным критериям Зайдем в систему с правами менеджера и создадим маршрут. Для этого выберем пункт меню «Маршруты» и подменю «Создать маршрут», после создания сохраним ее и просмотрим внесенные данные, выбрав пункт подменю «Управлять маршрутами».
Рисунок 4.9 — Создание маршрута Рисунок 4.10 -Просмотр созданных маршрутов Зайдем в систему с правами менеджера и создадим перегон. Для этого выберем пункт меню «Перегоны» и подменю «Создать перегон», после создания сохраним ее и просмотрим внесенные данные, выбрав пункт подменю «Управлять перегонами».
Рисунок 4.11 -Создание перегона Рисунок 4.12 — Просмотр созданных перегонов Зайдем в систему с правами менеджера и создадим рейс. Для этого выберем пункт меню «Рейсы» и подменю «Создать рейс», после создания сохраним ее и просмотрим внесенные данные, выбрав пункт подменю «Управлять рейсами».
Рисунок 4.13 — Создание рейса Рисунок 4.14 — Просмотр созданных рейсов Зайдем в систему с правами менеджера и создадим состав. Для этого выберем пункт меню «Составы» и подменю «Создать состав», после создания сохраним ее и просмотрим внесенные данные, выбрав пункт подменю «Управлять составами».
Рисунок 4.15 — Создание состава Рисунок 4.16 — Просмотр созданных сайтов Статистическая функция и анализ движения поездов доступны пользователю с правами менеджера. Функция анализа движения поездов реализована подпунктом меню «Анализ движения поездов» пункта меню «Анализ».
На шаге 1 выбираем маршрут и переходи к шагу 2.
Рисунок 4.17 — Выбор маршрута для анализа положения поездов На шаге 2 выбираем рейс.
Рисунок 4.18 — Выбор рейса для анализа положения поездов
На шаге 3 строится график, по которому производится анализ движения поездов. При передвижении курсора мышки по графику отображаются комментарии о том эффективное или неэффективное движение у поезда. В комментарии выводится информация о том, какой километр, станция, перегон, скорость, операция и подробности. По оси Х откладывается время, по оси У — положение поезда. График приведен на рисунке 4.19.
Рисунок 4.19 — График анализа положения поезда При выборе пункта меню «Анализ» подменю «Статистика отказов составов» выводится круговая диаграмма с названиями составов и процентами отказов. Диаграмма приведена на рисунке 4.20.
Рисунок 4.20 — Статистика отказов диспетчер веб данные система Еще можно зайти в систему с правами рабочей бригады и просмотреть поставленные задачи.
Рисунок 4.21 — Просмотр поставленных задач
ЗАКЛЮЧЕНИЕ
В данном курсовом проекте была разработана веб-базированная система «Железная дорога Мариуполь — Донецк». Были описаны функции, задачи и цель создания системы. Была разработана схема базы данных для качественного управления движением поездов.
Были автоматизированы функции определения положения поездов, анализ движения поездов, ведение информации о расположении поездов, статистика отказа по перегонам В ходе разработки ВБС мною были применены знания с курса «веб программирование» и «СУБД», а именно — html, css, javascript, php и sql.
1. Э. Гутманс, С. Баккен, Д. Ретанс, «PHP 5 Профессиональное программирование», Символ, 2006 г., 351 с.
2. Джек Д. Харрингтон, «PHP. Трюки», Питер, 2008 г., 448 с.
3. Крис Дейт. «Введение в базы данных», 6-е изд. Киев, Диалектика, 1998.
4. Влад Мержевич, «HTML и CSS на примерах», Петербург, 2005 г., 448 с.
ПРИЛОЖЕНИЕ А
Рисунок А.1 — Диаграмма классов для диспетчера Рисунок А.2 — Диаграмма классов для менеджера
ПРИЛОЖЕНИЕ Б
railway.info
name = railway
description = «Railway»
core = 6. x
railway.module