Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Содержательная часть содержит в себе описание основных стадий проектирования разрабатываемого приложения. В ней представлены схематичная модель интерфейса Web-приложения и описание содержания Web-страниц.

Практическая часть дипломного проекта является описанием решений, принятых по всем стадиям проектирования. Глава содержит обоснование по выбору технологии для создания Web-приложения, описание экспертной системы поддержки принятия решения, а также руководства пользователя и администратора.

1. Содержательная часть

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

1. разграничение доступа к различным разделам Web-приложения:

1. доступ к административному разделу системы осуществляется только авторизованными пользователями (администратором) через Web-интерфейс;

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

3. разграничение уровней доступа к системе осуществляется через структуру логинов и паролей;

1. предоставление справочной информации (данные, добавляемые администратором и доступные для всех пользователей без авторизации);

2. предоставление информации о персонале на основе информации из базы данных АСУТ:

1. возможность просмотра и анализа основной информации о сотрудниках;

2. возможность поиска сотрудников по различным параметрам;

3. наличие сортировки (для удобства пользователя)

4. возможность просмотра подробной информации по медкомиссиям;

5. возможность просмотра подробной информации об инструктажах;

6. доступ к списку отвлечений каждого сотрудника;

1. предоставление информации о поездках на основе информации из базы данных АСУТ (журнал явок):

1. возможность просмотра основной информации о поездках;

2. возможность поиска поездки по различным параметрам;

3. наличие сортировки данных;

1. возможность обратной связи с единой службой поддержи через отправку сообщения по электронной почте;

2. возможность добавления/удаления администратором текстовых документов и их последующего скачивания пользователями;

3. возможность подбора локомотивных бригад на явку:

1. анализ ограничений и правил постановки локомотивной бригады на явку;

2. подбор бригад, отвечающих поставленным требованиям;

3. отображение списка бригад, подходящих для постановки на явку.

2.1 Разработка функциональной модели

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

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

Контекстная диаграмма вариантов использования для Web-приложения на базе АСУТ представлена на рисунке 2.1

Рисунок 2.1 – Контекстная диаграмма

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

• ввод основной информации: заполнение информационных разделов, контактной информации компании;

• проверка взаимодействия системы с базой данных АСУТ – проверка актуальности запросов при обновлении АСУТ, проверка корректности отображения информации;

• загрузка документов на сайт – возможность загрузить оперативные инструкции, регламенты и т п., а также возможность удаления документации, утратившей актуальность;

• администрирование пользователей – создание учетных записей пользователей для возможности просмотра информации базы данных АСУТ на основании согласованных заявок, а также блокировка учетных записей при истечении срока действия заявки.

Посетители сайта смогут выполнять следующие действия на сайте:

• работа с базой данных АСУТ – просмотр необходимой информации через Web-интерфейс (декомпозиция данной функции приведена на рисунке 2.2);

• просмотр справочной информации (контакты, полезные ссылки и т.п.);

• скачивание документов (документы и регламенты);

• просмотр справочной информации по работе с системой.

Рисунок 2.2 – Диаграмма декомпозиции

Работа с базой данных АСУТ осуществляется через вкладку Персонал. Данная вкладка позволяет не только просматривать основные сведения о сотрудниках, но и осуществлять поиск и фильтрацию по некоторым полям: фамилия, табельный номер, номер депо, что значительно упрощает работу со списком сотрудников. Функционал позволяет просматривать подробную информацию об отвлечениях каждого сотрудника, а также включает в себя список всех медкомиссий и инструктажей сотрудника.

Рисунок 2.3 – Диаграмма декомпозиции

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

• проверка наличия инструктажа (не более шести месяцев до поездки);

• проверка достаточности отдыха;

• проверка заключения на серию;

• проверка заключения на места и виды работ;

• анализ явок – проверка отсутствия постановки на другую явку в рамках выбранной поездки;

• проверка наличия медкомиссии (не более 12 месяцев до поездки);

• проверка времени переработки (выбор локомотивных бригад, подходящих по всем параметрам, с отсутствием переработки или наименьшим временем переработки).

2.2 Разработка поведенческой модели

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

Реализация отдельного варианта использования требует участия и взаимодействия определенных экземпляров актеров и классов. Одним из инструментов для описания такого взаимодействия является диаграмма последовательности.

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

Рисунок 2.4 – Диаграмма последовательности

Диаграмма последовательности для варианта использования «Администрирование пользователей» (создание нового пользователя) представлена на рисунке 2.5.

Рисунок 2.5 – Диаграмма последовательности

При переходе на страницу «Пользователя» происходит загрузка списка всех имеющихся учетных записей пользователей. Для добавления нового пользователя администратор создает логин и пароль, соответствующие правилам валидации. В случае если администратор ввел все данные корректно, новая учетная запись будет добавлена в базу данных. Если данные введены некорректно или не все (например, не заполнено поле «Пароль»), пользователь увидит сообщение об ошибке с просьбой исправить некорректные данные.

2.3 Разработка информационной модели (модель базы данных)

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

Создание информационной модели осуществлялась с помощью CASE-средства для проектирования и документирования баз данных ERwin Data Modeler.

Для разрабатываемой системы логическая модель базы данных представлена на рисунке 2.6, физическая модель базы данных – на рисунке 2.7.

Основными объектами информационной модели являются следующие:

• «Журнал явок»;

• «Полигоны»;

• «Сотрудники»;

• «Инструктажи»;

• «Отвлечения»;

• «Медкомиссии»;

• «ОТ и ТБ»;

• «Документы»;

• «Пользователи».

Остальные объекты информационной модели представляют собой словари или являются связующими для осуществления связи «многие-ко-многим».

Рисунок 2.6 – Логическая модель базы данных

Рисунок 2.7 – Физическая модель базы данных

Таким образом, в базу данных, разработанную для Web-приложения, входит 21 таблица.

Таблица JYs (таблица 2.4) предназначена для хранения информации о поездках, занесенных через журнал явок. Связь таблицы осуществляется по ключевым полям SeriesID, VidID, BrigID, PolygonID с таблицами Series, Vids, Brigades, Polygons соответственно.

Таблица 2.1 – JYs – журнал явок

Таблица Depots (таблица 2.2) содержит список всех депо.

Таблица 2.2 – Depots – депо

Таблица Posts (таблица 2.3) содержит список всех должностей.

Таблица 2.3 – Posts – должности

Таблица Persons (таблица 2.4) – это хранилище для основной информации о сотрудниках. Каждый сотрудник имеет приписку к конкретному депо, поэтому данная таблица связана с таблицей Depots по ключевому полю DepoID. Также таблица имеет связь с таблицей Post по ключевому полю PostID для определения должности каждого внесенного сотрудника. Связь с таблицей Brigades, осуществляемая по ключевому полю BrigID, необходима для включения сотрудников в состав локомотивной бригады.

Таблица 2.4 – Persons – сотрудники (персонал)

Таблица Series (таблица 2.5) содержит список серий локомотивов, используемых в поездках (в таблице JYs).

Таблица 2.5 – Series – серии локомотивов

Для связи таблицы Series с таблицей Persons создана таблица SeriesOfPerson (таблица 2.6), которая содержит информацию о наличии заключения на серии для каждого сотрудника.

Характеристики

Список файлов ВКР