Проектирование автоматизированной информационной системы автотранспортной компании

2) Процедура  изменения состояния местоположения заказа, периодичность ее решения является постоянной.

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

3) Процедура изменения БД заказчиков и сотрудников решается непрерывно, ежедневно.

Организационно процедура представляет собой внесение изменений в записи БД (добавление, удаление) теми сотрудниками, кому дано разрешение на данные действия (позволяет разграничение прав доступа).

Никакого сбора первичных документов данная процедура не влечет.

Описание  входной информации:

Входной информацией для автотранспортной компании являются следующие потоки данных:

• массив данных заказчиков (Название/ФИО, номер заказа...)
• массив данных сотрудников
• массив данных о состоянии заказов
• массив финансовой информации
• массив данных заказов

Описание  выходной информации:

• финансовые показатели компании
• массив информации заказчиков
• массив информации о состояния заказов
• массив информации путевых листов
• отчетность для руководителя компании
• запросы на предоставление отчетности заказчикам.

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

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

 

Пользователи проектируемой системы и их возможности:

1.  Заказчики:

     - просмотр информации  о заказах;

     - оформление заказа на перевозку грузов.

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

2.  Администратор:

     - просмотр информации, управление учетными данными;

     - составление отчетов.

3.  Диспетчер:

     - просмотр информации;

     - оформление нового  заказа;

     - редактирование информации;

     - оформление путевых листов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Диаграмма вариантов использования (use-case диаграмма)

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

3. Диаграмма активности

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

4. Диаграмма сущность-связь

Диаграмма сущность-связь является самым высоким уровнем в модели данных и определяет набор сущностей  и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для  ее дальнейшей детализации.

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

 

 

 

5. Диаграмма классов 

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

 

 

 

 

 

 

 

6. Диаграмма компонентов.

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

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

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

Диаграмма компонентов  для клиентской части.

Диаграмма компонентов  для серверной части.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7. Диаграмма развертывания.

 

 

 

 

 

 

 

 

 

 

8. Логическая модель системы

Для больших БД с множеством пользователей часто используют технологию клиент-сервер. В этом случае доступ к базе данных для группы клиентов выполняется специальным компьютером — сервером, или дает задание серверу выполнить те или иные операции поиска или обновления базы данных. И мощный сервер, ориентированный на операции с запросами, оптимальным способом, выполняет их и сообщает клиенту результаты своей работы.

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

Проанализировав всю собранную  информацию, выделим сущности:

- заказчик;

- диспетчер;

- администратор;

- груз;

- заказ;

- водитель;

- путевой лист;

- транспортное средство;

- маршрут;

- отчет о заказах;

- список таблиц.

Теперь необходимо определить атрибуты, т. е. список данных о сущностях, которые необходимо хранить в БД:

- Наименование организации-заказчика/ФИО заказчика;

- ФИО диспетчера;

- ФИО администратора;

- стоимость заказа;

- наименование груза;

- количество груза;

- единица измерения груза;

- № путевого листа;

- инвентарный № транспортного  средства;

- наименование транспортного средства;

- тип транспортного средства;

- государственный номер транспортного  средства;

- дата выпуска транспортного  средства;

- пробег транспортного средства;

- грузоподъемность транспортного  средства;

- техническое состояние транспортного  средства;

- табельный № водителя;

- ФИО водителя;

- паспорт;

- класс (категория);

- водительское удостоверение;

- № путевого листа;

- Дата/Время отправления;

- показания спидометра;

- топливо при выезде;

- место отправления;

- место назначения;

- название маршрута;

- протяженность маршрута;

- название пункта;

- стоимость перевозки.

 

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

 

Диспетчер

Атрибут	Тип данных
ФИО	String
Пароль	Integer

 

Груз

Атрибут	Тип данных
Наименование	String
Количество	Integer
Единица измерения	String

 

Заказчик

Атрибут	Тип данных
Наименование/ФИО	String
Пароль	Integer
№ путевого листа	Integer

 

Водитель

Атрибут	Тип данных
Табельный №	Integer
ФИО водителя	String
Паспорт	String
Класс	String
Водительское удостоверение	String

 

Администратор

Атрибут	Тип данных
ФИО	String
Пароль	Integer

 

 

 

Транспортное средство

Атрибут	Тип данных
Инвентарный № транспортного средства	Integer
Наименование	String
Тип средства	String
Государственный номер	String
Дата выпуска	Date/Time
Пробег	String
Грузоподъемность	String
Техническое состояние	String

                                                                  

Путевой лист

Атрибут	Тип данных
№ путевого листа	Integer
Дата/Время	Date/Time
Показания спидометра	String
Топливо при выезде	String

 

Заказы

Атрибут	Тип данных
№ путевого листа	Integer
Дата	Integer
Наименование/ФИО заказчика	String
Стоимость перевозки	Current

 

Маршруты

Атрибут	Тип данных
Название	String
Место отправления	String
Место назначения	String
Протяженность	String

 

Схема базы данных.

Теперь можно отобразить общую  схему. Схема базы данных позволяет просмотреть связи между таблицами.

 

 

 

 

 

 

 

 

 

 

 

 

3. Пример реализации.

Перед входом в систему, пользователю для выполнения необходимых действий нужно авторизоваться.

Форма авторизации.

 

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

Клиентская  форма.

Нажав на кнопку «Оформление нового заказа» заказчик попадает на форму:

 

 

 

 

 

Форма заказа.

 

Нажав на кнопку «Просмотр заказов» заказчик попадает на форму:

 

Выбрав «Просмотр  статусов заказов» открывается окно, показывающее в каком месте находится перевозимый груз (используется система ГЛОНАСС):

Заказчик также может просмотреть  все свои заказы и узнать их общую  стоимость:

 

 

 

 

 

 

 

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

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

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