Файл: Автоматизированная информационная система управления пассажирскими перевозками (на примере муниципального предприятия городского округа Самара Пассажирский автомобильный транспорт).pdf

27
Таблица 1.2 – Матрица сравнений на основе общей оценки
Функ. полнота
Доработка
Техноло- гичность
Перспективы развития
Стоимость
Функ. полнота
1 5
3 9
7
Доработка
0,2 1
0,25 5
0,333
Технологичность
0,333 4
1 9
5
Перспективы развития
0,111 0,2 0,111 1
0,143
Стоимость
0,143 3
0,2 7
1
Рисунок 1.15 – Результаты расчетов
В результате получили что наиболее приемлемый результат в зависимости от заданных приоритетов возможен при выборе программного продукта «1С: Управление автотранспортом».
Выводы по главе 1
Рассмотрев вопросы учета заказов клиентов на примере автотранспортного предприятия соответствии с вышеизложенным можно сделать следующие выводы:
– Существующая технология работы автотранспортного предприятия подразумевает необходимость информационного обмена между подразделениями в рамках учета перевозок.

28
– Существующий уровень автоматизации предприятия является недостаточным, что приводит к временным задержкам при обработке заявок на осуществление перевозок, расчета ожидаемых бюджетных расходов на ГСМ.
– Возможность автоматизации учета транспортных перевозок, а также оперативной передачи данных о поступающих заявках исполнителям позволит сократить время исполнения заявок на осуществление перевозок, провести оптимизацию штатной численности.
– Используемый в настоящее время программный продукт АСУ
«Навигация», решающий задачи диспетчеризации перевозок, не позволяет проводить учет перевозок в части мониторинга состояния автопарка и расхода ГСМ.
– Архитектура существующей автоматизированной системы автотранспортного предприятия позволяет произвести внедрение автоматизированной системы учета перевозок в части мониторинга состояния автопарка и расхода ГСМ.
Требования предприятия наиболее полно удовлетворяет программный продукт «1С: Управление автотранспортом».
Этапы решения задачи:
– изучение бизнес-процессов, постановка задачи автоматизации;
– определение способа приобретения программного продукта;
– внедрение автоматизированной информационной системы;
– расчет экономической эффективности внедрения АИС.

29

30
Подробное описание представлено далее, в проектировании базы данных.
Как показано на Рисунок 2.2, в информационной системе по учету заявок на осуществление пассажирских перевозок, предусматриваются сценарии
Администратора, Диспетчера и Экономиста.
Диспетчер
Администратор
Экономист
Учет транспортных средств
Учет пробега
Учет ГСМ
Учет заявок на перевозки
Оценка эффективности
Ведение классификаторов
Установка прав доступа
Рисунок 2.2 – Диаграмма вариантов использования информационной системы в части учета перевозок
В функционал экономиста входят вопросы учета поступающих заявок на перевозки, формирование аналитической отчётности в рамках процесса оказания услуг пассажирских перевозок, а также учета затрат на ГСМ.
Функционал диспетчера предполагает учет параметров автопарка, пробега автотранспорта, а также данные о фактическом использовании ГСМ.

31
Функционал Администратора включает ведение внутренних классификаторов, а также установку прав доступа к системе.
2.1.1. Разработка базы данных
На основании определенных сущностей информационной системы по учету перевозок построим диаграмму «Сущность - Связь» (приведена на
Рисунок 2.3). Далее согласно данным Рисунок 2.3 определим типы связей между сущностями АИС по учету перевозок. На базе построенной модели создадим схему базы данных.
Оператор
Путевой лист
Клиент
Водитель
Модель ТС
Вид топлива
ТС
Пункты назначения
Заявка
Вводит
1
N
Входит в
1
N
Соответствует
1
N
Делает
N
1
Заполняет
1
N
Соответствует
1
N
Соответствует
1
N
Код
ФИО
Код
ФИО
Должность
Код
Наименов ание
Стоимость
Код
Наименован ие
Растояние
Код
ФИО
Адрес
Телефон
Код
Дата
Клиент
Адрес
Стоимость
Входит в
1
N
Код
Наименов ание
Тип ГСМ
Код
Наименование
Модель
ГосНомер
Заводской номер
Код
Дата
Код заявки
КодТС
Расход ГСМ
Рисунок 2.3 – Диаграмма «Сущность – связь»
Каждый оператор вводит множество заявок. Связь 1:N. Каждой модели
ТС соответствует множество автомобилей в автопарке. Связь 1:N. Каждому

32 виду топлива соответствует множество моделей ТС. Связь 1:N. Каждому пункту назначения соответствует множество путевых листов. Связь 1:N.
Каждому автомобилю соответствует множество путевых листов. Связь 1:N.
Каждый водитель вводит множество путевых листов. Связь 1:N. Каждый сотрудник использует транспортные средства множество раз. Связь 1:N.
Каждый сотрудник делает множество заявок на перевозки. Связь 1:N.
+
Добавить()
+
Изменить()
+
Удалить()
-code_top : int
-nam
-stm : float
vid_top
+
Добавить()
+
Изменить()
+
Удалить()
-code_model : int
-nam : char
-code_top : int
-volume : int
model
+
Добавить()
+
Изменить()
+
Удалить()
-code_ts : int
-gosnum : char
-year : int
-code_model : int
park
+
Добавить()
+
Изменить()
+
Удалить()
-code_vod : int
-fio : char
-tel : char
vodit
+
Добавить()
+
Изменить()
+
Удалить()
-code_ots : int
-code_ts : int
-code_vod : int
obs_ts
+
Добавить()
+
Изменить()
+
Удалить()
-code_per : int
-day : Date
-gsm : int
-prim : char
-code_vod : int
-code_ts : int
-code_zay : int
gur_per
+
Добавить()
+
Изменить()
+
Удалить()
-code_dtp : int
-day : Date
-sod : char
-code_per : int
dtp
+
Добавить()
+
Изменить()
+
Удалить()
-code_zay : int
-day : Date
-sod : char
-code_cli : int
gur_zay
+
Добавить()
+
Изменить()
+
Удалить()
-code_cli : int
-adr : char
-rasst : int
-tel : char
clients
Рисунок 2.4 – Диаграмма классов информационной системы
На Рисунок 2.5. представлена логическая модель базы данных информационной системы.

33
Рисунок 2.5 – БД информационной системы учета перевозок
В результате работы системы учета перевозок, формируются несколько таблиц, отражающих процесс работы транспортного отдела. Данные для построения этих таблиц берутся из справочников, а также журнала работы с заявками. Структура нескольких таблиц приведена ниже, в Приложении представлено описание остальных таблиц.
Таблица 2.1 – Таблица «Операторы»
Наименование
Идентификатор Тип поля Длина
Прочее
Идентификатор оператора code_oper число
10
Первичный ключ
ФИО
Fio cтрока
50
Роль в системе
Rol число
1
Пароль passw cтрока
50
Таблица «oper» служит для хранения информации об операторах системы и разграничения доступа. Средний объем записей – 20.
ВидыТоплива
КодВТ
Наименование
Стоимость
Модели ТС
КодМоделиТС
Наименование
Объем двигателя
КодВТ (FK)
Водители
КодВодителя
ФИО
НомерТел
ОбслТС
КодОТС
КодТС (FK)
КодВодителя (FK)
Автопарк
КодТС
Госномер
ГодВыпу ска
КодМоделиТС (FK)
Перевоз ки
КодПеревоз ки
Дата
РасходГСм
Примечание
КодВодителя (FK)
КодТС (FK)
Код з аявки (FK)
ДТП
КодДТП
Дата
Содержание
КодПеревоз ки (FK)
Заявки клиентов
Код з аявки
Дата
Содержание
КодКлиента (FK)
Клиенты
КодКлиента
Адрес
Расстояние
Телефон

34
Таблица 2.2 – Таблица «Перевозки»
Наименование поля Идентификатор Тип поля Длина
Прочее
Идентификатор путевого листа
Code_vt число
10
Первичный ключ
Идентификатор водителя
Code_v число
10
Вторичный ключ
Идентификатор автомобиля code_sotr число
10
Вторичный ключ
Дата
Day
Дата
Фактический пробег Prob число
10
Затраты
Stm
Денежный
Расход ГСМ
Rash число
10
Идентификатор места назначения
Code_pn число
10
Вторичный ключ
Примечание prim строка
200
Идентификатор клиента
Code_с число
10
Вторичный ключ
Идентификатор заявки
Code_z число
10
Первичный ключ
Таблица «plist» служит для хранения информации о путевых листах.
Средний объем записей – 100000.
Далее приведем описание кодирования ключевых сущностей проектируемой ИС и их свойств.
Таблица 2.3 – Описание систем классификации и кодирования
№ п/
п
Наименование кодируемого множества объектов
Значность кода
Система кодирован ия
Вид классификато ра
1 2
3 4
5 1
Код вида услуги перевозки
ХХ порядковая локальный
2
Код клиента
ХХХ ХХХХХ серийно – порядковая локальный
3
Код ТС
ХХХ порядковая локальный
4
Код перевозки
ХХХХ ХХХХХ серийно- порядковая локальный
5
Код ГСМ
ХХХХХ ХХХХ порядковая локальный
•
Код вида услуги перевозки. Длина кода ХХ, где ХХ – порядковый номер вида услуги перевозки в картотеке транспортной компании.

35
•
Код клиента. Длина кода ХХХ ХХХХХ, где ХХХ – порядковый номер категории, ХХХХХ – порядковый номер клиента.
•
Код ТС. Длина кода ХХХ, где ХХХ – порядковый номер транспортного средства, зарегистрированного в системе.
•
Код перевозки. Длина кода ХХ ХХХХХ, где ХХ – порядковый номер ТС, ХХХХХ – порядковый номер услуги перевозки.
•
Код ГСМ. Длина кода Х, где Х – порядковый номер вида ГСМ.
2.2. Физическое моделирование АИС
2.2.1. Архитектура АИС
В качестве архитектуры решения будет применяться многослойная клиент-серверная архитектура, поскольку уже используемые на АТП решения на базе 1С: Предприятия организованы на базе такой архитектуры. Для клиент- серверной архитектуры, характерно отделение процессов представления, обработки и управления данными. Модель клиент-серверной архитектуры помогает создавать гибкое программное обеспечение. Изменения в данной модели осуществляются не во всем приложении сразу, а лишь в конкретных слоях, что позволяет сократить количество потенциальных ошибок и времени на модернизацию. Для клиент-серверных систем характерно наличие самостоятельно взаимодействующих процессов, выполнение которых, в общем случае, может производиться на разных вычислительных системах путем обмена данными по сети.
Слой клиента – это компонент комплекса, реализующий интерфейс конечного пользователя.
Данный слой не имеет возможности взаимодействовать с базой данных напрямую, на него обычно выносится простая бизнес–логика, такая как: интерфейс организации, контроль вводимых значений, сортировка, группировка и другие простые операции. В случае решения 1С может быть как полновесной программой клиентом, так и
«тонким» и даже веб-клиентом.

36
Серверное приложение
Клиентское приложение
(интерфейс)
БД
Слой клиента
Слой логики
Слой данных
Рисунок 2.6 – Модель многослойной архитектуры
Слой логики – реализует большую часть бизнес-логики. Вне этого уровня реализуются элементы логики, экспортируемые на клиента, а также хранимые процедуры в БД. Данный компонент реализуется связующим программным обеспечением, на предприятии это платформа 1С: Предприятие.
Слой данных – как правило представляет собой СУБД, обеспечивающую хранение данных. Взаимодействовать с третьим уровнем может только второй уровень. Слой данных на предприятии уже реализован на базе MS SQL Server
2008.
2.2.2. Функциональная схема проекта
На Рисунок 2.7 приведена структурная схема проекта автоматизации управления заявками на осуществление перевозок с использованием ПО «1С:
Управление автотранспортом».

37
Рисунок 2.7 – Структурная схема системы
Как показано на Рисунок 2.7, функционал информационной системы составляют модули:
– диспетчеризации;
– учета перевозок;
– взаиморасчетов;
– ПТО;
– учета работы водителей;
– учёта ремонтов;
– учёта ГСМ.
2.2.3. Описание программных модулей
Подсистема диспетчеризации реализует логику процессов оформления заказов на перевозку, распределения по экипажам, формирования маршрутных листов, контроля выполнения, формирования и обработки путевых листов.

38
Рисунок 2.8 – Модуль диспетчеризации, выпуск путевого листа
Разнарядка на выпуск автомобилей выписывается с учетом различных графиков работы автомобилей и водителей. Программа автоматически производит проверку пригодности автомобиля к выполнению рейса по состоянию ТС и документов (истекший полис ОСАГО и т.д.).
При закрытии путевого листа выполняются расчеты нормативного и фактического расхода ГСМ, выработки ТС, оборудования и водителя, учет отработанного времени для табеля.
Задание заполняется на вкладке задание, форма представлена на рис. 2.10.
В модуле учета ГСМ реализован расчет нормативного расхода топлива в соответствии с приказом Министерства транспорта России. В справочниках содержатся нормы для многих моделей автомобилей. Для учета отклонений расхода ГСМ от нормы для модели ТС (износ, ремонт и т.д.) можно задать коэффициент для отдельного автомобиля.