Автоматизация процесса управления использованием автотранспорта АО "ХК Сибирский Цемент"

«PutLists» и «Zaks» имеют связь один ко многим, так как идентификатор каждого id в отношении «PutLists» может иметь несколько значений атрибута в отношении «Zaks».

Рисунок 31. Отношение "PutLists-Zaks"

«Transports» и «PutLists» имеют связь один ко многим, так как один транспорт может работать по многим путевым листам.

«Drivers» и «PutLists» имеют связь один ко многим, так как один водитель может работать по многим путевым листам.

«PutLists» и «DopOs» имеют связь один ко многим, так как один путевой лист может содержать множество особенностей сервиса.



Рисунок 32. Отношение "PutLists-Transports"

Рисунок 33. Отношение "PutLists - Drivers"

Рисунок 34. Отношение "DopOs - PutLists"



Рисунок 35 Результирующая ER-диаграмма, отображающая сущности и их святи

3.4 Даталогическое проектирование

1) Сущность «Водители» представлена таблицей Drivers.

Рисунок 36. Таблица "Drivers"

Id - числовой тип int, является ключевым атрибутом. Введен для идентификации водителя, а также для связи с путевыми листами.

FIO - символьный тип nvarchar(max), содержит фамилию, имя и отчество водителя.

BirthDay - тип datetime, содержит дату рождения водителя.

Passport - символьный тип nvarchar(max), содержит паспортные данные водителя.

Phone - символьный тип nvarchar(max), содержит номер телефона водителя.

Kategory - символьный тип nvarchar(max), содержит категории вождения водителя.

2) Сущность «Транспортные средства» представлена таблицей Transports.

Рисунок 37. Таблица "Transports"

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

GosNum - символьный тип nvarchar(max), содержит государственный номер транспортного средства.

TypeOfTrans - символьный тип nvarchar(max), содержит тип транспортного средства.

TypeOfShin - символьный тип nvarchar(max), содержит тип используемых шин на транспортном средстве.

Put - числовой тип float, содержит количество пройденных км транспортным средством.

Bensin - числовой тип float, содержит количество потраченного бензина в транспортном средстве, в литрах.

Isnos - числовой тип float, содержит степень износа транспортного средства.

3) Сущность «Заказы» представлена таблицей Zaks.

Рисунок 38. Таблица "Zaks"

Id - числовой тип int, является ключевым атрибутом. Введен для идентификации заказа.

Name - символьный тип nvarchar(max), содержит формулировку заказа.

TypeG - символьный тип nvarchar(max), содержит тип заказа.

Adress - символьный тип nvarchar(max), содержит адрес доставки груза.

Ves - числовой тип float, содержит вес груза.

DataFormZak - тип datetime, содержит дату формирования заказа.

DataDos - тип datetime, содержит дату доставки груза.

4) Сущность «Дополнительные особенности путевого листа» представлена таблицей DopOs.

Рисунок 39. Таблица "DopOs"

Id - числовой тип int, является ключевым атрибутом. Введен для идентификации сервиса.

TypeOfDopOs - символьный тип nvarchar(max), содержит тип используемого сервиса.

Znach - символьный тип nvarchar(max), содержит значение используемого сервиса.

5) Сущность «Путевые листы» представлена таблицей PutLists.

Рисунок 40. Таблица "PutLists"

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

DateFormPutList - тип datetime, содержит дату формирования путевого листа.

Odometr - числовой тип float, содержит количество пройденных км транспортным средством.

Benz - числовой тип float, содержит количество потраченного бензина в транспортном средстве, в литрах.

3.5 Разработка сценариев работы с данными

Добавление данных:

Добавление ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.17). При добавлении нового ТС в таблицу Transport, необходимо вводить его ГосНомер- Gosnum, Тип транспорта - Type, Тип шин - TypeSh, Объем топливного бака - EmkostBak, показатель одометра - Put, уровень бензина в топливном баке - BenValue. Код ТС - Id, генерировать автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Transport создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Добавление водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.21). При добавлении нового водителя в таблицу Driver, необходимо вводить его ФИО- FIO, Дата рождения - Birthday, Паспортные данные - Passport, Номер телефона - Phone, категория вождения - Kateg. Код водителя - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Driver создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Добавление заказа. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.13.). При добавлении нового заказа в таблицу Zakaz, выбирается документ xml для выгрузки данных. В документе хранятся по заказам, а именно его Наименование- Name, Дата формирвоания - date, Тип заказа - Type, параметры груза(вес, количество людей) - Param, Адрес доставки - Adress. Код заказа - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Zakas создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Формирование путевого листа. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.24.). При добавлении нового путевого листа в таблицу PutList, выбирается водитель, заказы и ТС. Вводится дата формирования путевого листа. Код путевого листа - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении формирования путевого листа, в таблице PutList создается новая запись, содержащая идентификатор, дату формирования путевого листа, идентификатор транспортного средства и идентификатор водителя. Обработку необходимо реализовать через хранимую процедуру.

Добавление сервиса. При добавлении сервиса необходимо указать его наименование - Name, значение - Znach. Код сервиса - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении добавления сервиса в таблице DopOs появляется запись с данными по сервису и путевому листу, при заполнении которого был добавлен сервис. Обработку необходимо реализовать с помощью хранимых процедур.

Изменение данных:

Изменение данных ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.18). При изменении данных выбирается ТС из таблицы на форме, ТС вводится его ГосНомер- Gosnum, Тип транспорта - Type, Тип шин - TypeSh, Объем топливного бака - EmkostBak, показатель одометра - Put, уровень бензина в топливном баке - BenValue. Код ТС - Id, генерируемый автоматически, не изменяется. При подтверждении изменения данных, в таблице Transport изменяются данные по ТС. Обработку необходимо реализовать через хранимую процедуру.

Изменение данных водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.22). При изменении данных необходимо выбрать водителя, ввести его ФИО- FIO, Дату рождения - Birthday, Паспортные данные - Passport, Номер телефона - Phone, категория вождения - Kateg. Код водителя - Id, генерируемый автоматически, не изменяется. При подтверждении изменения данных, в таблице Driver изменяются данные по водителя с выбранным ID. Обработку необходимо реализовать через хранимую процедуру.

Изменение данных по заказу. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.14). При изменении данных необходимо выбрать заказ, ввести его Наименование- Name, Дату формирования - date, Тип заказа - Type, параметры груза(вес, количество людей) - Param, Адрес доставки - Adress. Код заказа - Id, генерируемый автоматически, не должен изменяться. При подтверждении изменения данных, в таблице Zakas изменяется запись по заказу с выбранным Id. Обработку необходимо реализовать через хранимую процедуру.

Изменение времени выполнения заказа. При выполнении данного сценария необходимо выбрать заказ и ввести время выполнение. При подтверждение ввода в записи о заказе появляется запись о времени выполнения. Обработку следует реализовать через хранимую процедуру.

Удалениие данных:

Удаление ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.19). При удалении данных выбирается ТС из таблицы на форме. При подтверждении удаления данных, из таблицы Transport удаляется запись с данными по выбранному ТС. Обработку необходимо реализовать через хранимую процедуру.

Удаление водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.23). При удалении данных выбирается водитель из таблицы на форме. При подтверждении удаления данных, из таблицы Driver удаляется запись с данными по выбранному водителю. Обработку необходимо реализовать через хранимую процедуру.

При удалении данных по ТС необходимо реализовать удаление данных в путевом листе по ТС. Сценарий следует реализовать через триггер.

При удалении данных по водителю необходимо удалять данный в ПЛ по этому водителю. Сценарий следует реализовать через триггер.

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

Удаление заказа. Сценарий соответствует одноименному сценарию, рассмотренному в процессе проектирования (рис.15). При удалении данных по заказу необходимо выбрать заказ на форме. При подтверждении удаления запись из таблицы удаляется. Обработку необходимо реализовать через хранимую процедуру.

Выбор данных:

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

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

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

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

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

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

Сценарий поиска данных о ПЛ по ФИО водителя. Сценарий необходим для вывода данных в соответствующий элемент формы. Для поиска данных необходимо выбирать водителя. При подтверждении поиска информация по ПЛ выводится в соответствующий элемент формы. Сценарий следует реализовать через хранимую процедуру

3.6 Разработка механизмов реализации серверной компоненты

1. Добавление данных

Реализуется с помощью хранимых процедур.

Процедура AddTrans для вставки кортежа в таблицу Транспортные средства(Transport) представлена ниже:

Рисунок 41. Хранимая процедура "AddTrans" для добавления кортежа в таблицу Transport

Аналогично описываются и следующие процедуры, для соответствующих таблиц:

Рисунок 42. Список хранимых процедур для добавления данных в таблицы.

Изменение данных

Реализуется с помощью хранимых процедур.

Процедура AddTrans для вставки кортежа в таблицу Транспортные средства(Transport) представлена ниже:

Рисунок 43 Хранимая процедура "UpTrans" для изменения данных кортежа в таблице Transport

Аналогично описываются и следующие процедуры, для соответствующих таблиц:

Рисунок 44. Список хранимых процедур для изменения данных в таблице.

3. Удаление данных

Реализуется с помощью хранимых процедур.

Процедура DelTrans для удаления кортежа из таблицы Транспортные средства(Transport) представлена ниже:

Рисунок 45. Хранимая процедура "DelTrans" для удаления кортежа из таблицы Transport

Аналогично описываются и следующие процедуры, для соответствующих таблиц:

Рисунок 46. Список хранимых процедур для удаления данных из таблиц.

Добавление даты выполнения заказа

Реализуется с помощью хранимых процедур.

Рисунок 47. Процедура заполнения даты выполнения заказа

Добавление заказа в путевой лист

Реализуется с помощью хранимых процедур.

Рисунок 48. Хранимая процедура добавления заказа в путевой лист

Сценарии вывода необходимых данных:

Реализуется с помощью хранимых процедур.

Хранимая процедура вывода данных о водителях:



Рисунок 49. Хранимая процедура "SelectDriv" для вывода данных по водителям

Хранимая процедура вывода данных о ТС:

Рисунок 50. Хранимая процедура "SelectTrans" для вывода данных по ТС

Хранимая процедура вывода данных о заказах:

Рисунок 51. Хранимая процедура "SelectZak" для вывода информации по заказам

Хранимая процедура вывода данных о путевых листах:

Рисунок 52. Хранимая процедура "SelectPutList" для вывода данных по ПЛ

Хранимая процедура вывода данных о заказах одного дня:

Рисунок 53. Хранимая процедура "SelectZakOneDay" для вывода заказов одного дня

Хранимая процедура вывода данных о водителях по типу заказа:

Рисунок 54. Хранимая процедура "SelectDrinTypZak"для вывода данных о водителях по типу заказа

Хранимая процедура вывода данных о ТС по типу заказа:

Рисунок 55. Хранимая процедура "SelectTransTypZak" для вывода ТС по типу заказа

Хранимая процедура для вывода данных о ПЛ по ФИО водителя:

Рисунок 56. Хранимая процедура для вывода данных о ПЛ по ФИО водителя

5. Сценарий удаления данных:

Реализовано в виде триггера.

Удаление данных в ПЛ по водителю при удалении водителя:

Рисунок 57. Триггер для удаления данных в ПЛ по водителю при удалении водителя

Удаление данных в ПЛ по ТС при удалении ТС:

Рисунок 58. Триггер для удаления данных по ТС в ПЛ при удалении ТС

Удаление данных в заказе по ПЛ при удалении ПЛ:

Рисунок 59. Триггер для удаления данных о ПЛ в заказе при удалении ПЛ

4. Специальная часть. Использование технологии Xamarin.Forms для организации заполнения путевых листов

4.1 Выбор технологии

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

Мир мобильных платформ сильно фрагментирован, выделяются две основные операционные системы - Android и iOS, а также платформа Windows Phone/Windows 10 Mobile, при этом для каждой ОС имеются свои языки для разработки и соответственно среды.

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

В связи с тем, что среда разработки системы - это Visual Studio, которая поддерживает разработку кроссплатформенных мобильных приложений посредством работы с Xamarin, для рассмотрения выбрана именно эта платформа.

Функционально платформа Xamarin состоит из трех субплатформ:

*Xamarin.Android - библиотеки для создания приложений на ОС Android

*Xamarin.Mac - библиотеки для создания приложений на Mac OS X

*Xamarin.iOS - библиотеки для создания приложений для iOS

Возможность создавать кроссплатформенные приложения означает, что мы один раз можем определить визуальный интерфейс, один раз к нему привязать какую-то логику на C#, и все это будет работать на Android, iOS и Windows Phone. Данная возможность представлена технологией Xamarin.Forms. И именно эту технологию мы и будем использовать для создания мобильного приложения для водителей цеха.

Для работы с Xamarin.Forms установим пакет для разработки мобильных приложений Xamarin в нашу среду VS:

Рисунок 60

4.2 Область применения в разрабатываемой информационной системе

Данная технология применяется для разработки приложения для водителей. Приложение должно включать:

1.Возможность заполнения путевого листа;

2.Возможность передачи данных на компьютер диспетчера АТЦ.

Определим интерфейс приложения (соответствует форме Заполнение путевого листа Пункта Формирование требований к пользовательскому интерфейсу):



Рисунок 61. Форма "Заполнение путевых листов"

При нажатии на кнопку «Загрузить данные по ПЛ» производится поиск интернет соединения на планшете. В случае наличия соединения данные по путевому листу водителя загружаются в ListView «Заказы:», куда возможен дальнейший ввод информации по времени выполнения заказа.

В используемый сервис вводятся данные по АЗС, СТО и т.д.

При нажатии на кнопку «Заполнить ПЛ» данные заполняются в БД.

Связь между android приложением водителя и приложением диспетчера WFA осуществляется путем интернет соединения меду этими приложениями. Во время работы диспетчера производится прослушивание порта, настроенного в программе. При получении сигнала производится принятие сообщения, и данные вносятся в базу данных.

5. Технологии разработки и программная реализация

5.1 Выбор технологии

5.1.1 Выбор операционной системы

В качестве операционной системы для разработки и развертывания информационной системы выбрана ОС Microsoft Windows. Выбор данной операционной системы обусловлен тем, что на машинах предприятия, для которого предназначена разрабатываемая ИС, установлена операционная система Windows 7 и комплект необходимых для работы программ, смена операционной системы будет нецелесообразной.

5.1.2 Выбор взаимодействия пользователя с операционной системой

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

5.1.3 Выбор языка и среды программирования

В качестве среды программирования выбираем Visual Studio, а в качестве языка C#. Данный язык и среда являются универсальными инструментами программирования, поэтому они подходят для решения поставленной задачи по созданию ИС.

5.2 Определение физической архитектуры приложения

5.2.1 Определение состава компонент

При формировании компонент рекомендует ориентироваться по трем логическим сервисным уровням:

· пользовательскому;

· прикладному;

· уровню данных.

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

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

Уровень данных -- прикладной уровень не знает, как и где хранится обрабатываемая им информация. В этом вопросе он полагается на сервисы доступа к данным, выполняющие всю работу по получению и передаче данных. Сервисы доступа к данным также реализуются в виде изолированных модулей, «знающих» о месте хранения информации. Таким образом, если хранилище перемещено или изменен его формат, потребуется обновить только сервисы доступа к данным. Каждый модуль доступа к данным, как правило, отвечает и за целостность хранилища (например, реляционной базы данных). Для многоуровневых приложений в качестве хранилища информации подходят простые системы управления базами данных (СУБД), необходимые для обслуживания данных в таблицах и быстрой выборки информации (например, с помощью хранимых процедур).

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

5.2.2 Разработка компонент

В качестве клиента используется «тонкий» клиент, т.е. используется сервер приложений. Вся бизнес-логика перенесена на сторону сервера.

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

Для повышения простоты и удобства использования, все поля, списки и кнопки подписаны без использования сокращений.

Названия программных объектов, для более простого редактирования и изменения в дальнейшем, отражают их суть. Все поля, списки и кнопки имеют имена, также отражающие их суть.

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

Клиентское приложение водителя имеет следующие функции:

· Добавление транспортных средств, водителей и путевых листов. Функция обеспечивает заполнение данных по необходимому водителю, ТС, путевому листу.

· Изменение транспортных средств, водителей и путевых листов. Функция обеспечивает изменение данных по выбранному водителю, ТС, путевому листу.

· Удаление транспортных средств, водителей и путевых листов. Функция обеспечивает Удаление данных по необходимому водителю, ТС, путевому листу.

· Поиск заказов. Обеспечивает поиск заказов по определенной дате.

· Поиск транспортного средства. Обеспечивает поиск ТС по типу заказов.

· Поиск водителя. Обеспечивает поиск водителя по типу ТС.

· Загрузка из XML-файла. Функция обеспечивает загрузку данных по сотрудникам и заказам из XML-файла.

Клиентское приложение водителя имеет следующие функции:

· заполнение данных по транспортному средству в путевые листы.

5.2.3 Уточнение состава экранных форм. Определение конкретных типов управляющих элементов для форм.

Клиентская компонента содержит следующие основные экранные формы:

· Форма «Выбор действия» (Главная форма диспетчерского приложения);

· Форма: «Работа с транспортными средствами»;

· Форма: «Работа с водителями»;

· Форма «Работа с заказами»;

· Форма: «Работа с путевыми листами»;

· Форма: «Формирование путевого листа»;

· Форма «Заполнение данных по путевому листу».

Форма «Выбор действия» служит для выбора функции, с которой диспетчер хотел бы проводить дальнейшие действия.

Рисунок 62. Форма "Выбор действия"

Форма содержит элементы:

· Button1(Работа с водителями) - кнопка для открытия формы «Работа с водителями»;

· Button2(Работа с транспортными средствами) - кнопка для открытия формы «Работа с транспортными средствами»;

· Button3(Работа с путевыми листами) - кнопка для открытия формы «Работа с путевыми листами».

· Button4(Работа с заказами) - кнопка для открытия формы «Работа с заказами».

Форма «Работа с водителями».

Рисунок 63. Форма "Работа с водителями"

Форма содержит элементы:

· DateGridView1(Таблица водителей) - элемент для отображения данных по всем водителям;

· Textbox1(ФИО) - поле для ввода ФИО водителя;

· Textbox2(Паспортные данные) - поле для ввода паспортных данных водителя;

· dateTimePicker1(дата рождения) - поле для выбора даты рождения водителя;

· Textbox4(номер телефона) - поле для ввода номера телефона водителя;

· Combobox1(категория вождения) - поле для выбора категории вождения водителя;

· Button1(Добавить) - кнопка для добавления нового водителя в систему;

· Button2(Изменить) - кнопка для изменения данных по водителю;

· Button3(Удалить) - кнопка для удаления данных по водителю.

Элементы связи с данными:

· DataSet - basaDiplomDataSet.

· BindingSourse - selectDriverBindingSource.

· TableAdapter-selectDriverTableAdapter.

При загрузке формы вызывается процедура selectDriver и в dataGridView выводятся данные по всем водителям предприятия.

Рисунок 64. Форма "Работа с ТС"

При нажатии на кнопку Добавить вызывается процедура AddDriver и в dataGridView добавляется запись с данными по новому водителю, при нажатии на кнопку Изменить вызывается процедура UpDriver и в dataGridView изменяются данные по выбранному водителю, при нажатии на кнопку Удалить вызывается процедура DelDriver и из dataGridView удаляется запись с данными по выбранному водителю.

Форма «Работа с транспортными средствами».

Форма содержит элементы:

· DateGridView1(Таблица ТС) - элемент для отображения данных по всем транспортным средствам;

· Textbox1(ГосНомер) - поле для ввода государственного номера ТС;

· Textbox2(Тип шин) - поле для ввода данных по шинам;

· Textbox3(Объем бака) - поле для ввода объема топливного бака;

· Textbox4(показания одометра) - поле для ввода значения показаний одометра;

· Textbox5(Уровень бензина в топливном баке) - поле для ввода уровня бензина в топливном баке;

· Combobox1(тип ТС) - поле для выбора типа ТС;

· Button1(Добавить) - кнопка для добавления нового ТС в систему;

· Button2(Изменить) - кнопка для изменения данных по ТС;

· Button3(Удалить) - кнопка для удаления данных по ТС.

· Button4(Экспорт данных в xml-документ) - кнопка для экспорта данных по ТС в xml документ.

Элементы связи с данными:

· DataSet - basaDiplomDataSet.

· BindingSourse - selectTransBindingSource.

· TableAdapter-selectTransTableAdapter.

При загрузке формы вызывается процедура selectTrans и в dataGridView выводятся данные по всем ТС предприятия.

При нажатии на кнопку Добавить вызывается процедура AddTrans и в dataGridView добавляется запись с данными по новому ТС, при нажатии на кнопку Изменить вызывается процедура UpTrans и в dataGridView изменяются данные по выбранному ТС, при нажатии на кнопку Удалить вызывается процедура DelTrans и из dataGridView удаляется запись с данными по выбранному ТС.

Форма «Работа с заказами».

Рисунок 65. Форма "Работа с заказами"

Форма содержит элементы:

· DateGridView1(Таблица заказов) - элемент для отображения данных по всем заказам;

· Textbox1(путь к файлу) - поле для хранения пути файла для импорта данных;

· Textbox2(Наименование заказа) - поле для ввода наименования заказа;

· Textbox3(Параметры груза) - поле для ввода количества человек для перевозки или же веса груза;

· Textbox4(Адрес доставки) - поле для ввода адреса доставки груза;

· dateTimePicker1(Дата доставки) - поле для выбора даты доставки груза;

· Combobox1(тип заказа) - поле для выбора типа заказа;

· Button1(Выбрать файл)-кнопка для выбора файла для импорта данных;

· Button2(Импорт данных из XML-файла) - кнопка для загрузки данных в таблицу из xml документа;

· Button3(Экспорт данных в XML-файл) - кнопка для загрузки данных из таблицы в xml документ;

· Button4(Добавить) - кнопка для добавления нового заказа в систему;

· Button5(Изменить) - кнопка для изменения данных по заказу;

· Button6(Удалить) - кнопка для удаления данных по заказу.

· Button4(Экспорт данных в xml-документ) - кнопка для экспорта данных по ТС в xml документ.

· openFileDialog1 - элемент для работы с документам xml.

Элементы связи с данными:

· DataSet - basaDiplomDataSet.

· BindingSourse - selectZakBindingSource.

· TableAdapter-selectZakTableAdapter.

При загрузке формы вызывается процедура selectZak и в dataGridView выводятся данные по всем ТС предприятия.

При нажатии на кнопку Добавить вызывается процедура AddZak и в dataGridView добавляется запись с данными по новому заказу, при нажатии на кнопку Изменить вызывается процедура UpZak и в dataGridView изменяются данные по выбранному заказу, при нажатии на кнопку Удалить вызывается процедура DelZak и из dataGridView удаляется запись с данными по выбранному заказу.

Форма «Формирование путевого листа».

Рисунок 66. Форма "Формирование путевого листа"

Форма содержит элементы:

· DateGridView1(Таблица заказов) - элемент для отображения заказов;

· DateGridView2(Таблица ТС) - элемент для отображения ТС;

· DateGridView3(Таблица водителей) - элемент для отображения водителей;

· Combobox1( ПЛ) - поле для выбора ПЛ;

· Button1(Найти) - кнопка для поиска заказов определенной даты;

· Button2(Добавить)-кнопка для добавления заказа в ПЛ;

· Button3(Сформировать путевой лист) - кнопка для формирования путевого листа;

· dateTimePicker1(дата выполнения заказов) - поле для выбора назначенной даты выполнения заказов;

· dateTimePicker2(дата формирования ПЛ) - поле для выбора даты формирования ПЛ.

Элементы связи с данными:

· DataSet - basaDiplomDataSet.

· BindingSourse - selectZakOneDayBindingSource, selectDrivTypZakBindingSource, selectTransTypZakBindingSource, AddPutListBindingSource, FormPutListBindingSource, PutListBindingSource.

· TableAdapte - selectZakOneDayTableAdapter, selectDrivTypZakTableAdapter, selectTransTypZakTableAdapter,AddPutListTableAdapter, FormPutListTableAdapter, PutListTableAdapter.

При загрузке формы вызываются процедуры AddPutList, putList и в comboBox1 выводятся номера всех ПЛ.

При нажатии на кнопку Найти вызывается процедура SelectZakOneDay и в dataGridView1 выводятся все заказы, дата доставки которых выбрана в dateTimePicker1. При нажатии на кнопку Добавить вызываются процедуры SelectTransTypZak и SelectDrivTypZak и в dataGridView2 и dataGridView3 соответственно выводятся данные о водителях и ТС, соответствующих типу добавленного в ПЛ заказа.

При нажатии на кнопку вызывается процедура FormPutList и в таблицу «путевой лист» БД вносятся данные по сформированному ПЛ.

Форма «Работа с путевыми листами».

Форма содержит элементы:

· DateGridView1(Таблица ПЛ) - элемент для отображения данных по всем путевым листам;

· Button1(Сформировать путевой лист) - кнопка для открытия формы Формирование путевого листа;

· Button2(Удалить) - кнопка для удаления путевого листа;

· Button3(Выгрузить данные в xml-Файл) - кнопка экспорта данных по ПЛ в документ XML.

Рисунок 67. Форма "Работа с путевыми листами"

Элементы связи с данными:

· DataSet - basaDiplomDataSet.

· BindingSourse - selectPutListBindingSource.

· TableAdapte r- selectPutList.

При загрузке формы вызывается процедура selectPutList и в элемент dataGridView1 отображаются данные по всем сформированным путевым листам предприятия.

5.2.4 Определение технологии доступа к компоненте данных

Основными компонентами работы с данными являются:

· Клиентская программа для диспетчеров;

· Клиентская программа для водителей;

· Хранилище данных;

· Программное обеспечение SQL Server.

На рис.61 представлена диаграмма компонент.

Рисунок 68. Компоненты работы с данными

Рисунок 69. Диаграмма компонент

5.3 Тестирование

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

Система должна обеспечивать возможность добавления нового транспортного средства.

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

Тип ТС Грузовой, Госномер oy6712e, Тип шин УЕ129-102 p23, Объем топливного бака 170л, Показания одометра 137009,8 м. При нажатии кнопки «Сохранить» в таблице на форме появляется строка со значениями Код 1 Госномер oy6712e Тип ТС Грузовой Тип шин УЕ129-102 p23 Объем топливного бака 170л Показания одометра 137009,8 м.

Если же некоторые поля не заполнены, система выдает сообщение «Заполните все поля!» и возвращается к заполнению полей.

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

Система должна обеспечивать возможность изменения данных выбранного транспортного средства

Для тестирования данного требования система должна иметь выбранное транспортное средство, которому нужно изменить характеристики. На заполненные все поля, система сохраняет изменение в базу данных без ошибок. Если же некоторые поля не заполнены, система выдает сообщение «Заполните все поля!» и возвращается к заполнению полей.

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

Система должна обеспечивать возможность удаления выбранного транспортного средства

Для тестирования данного требования система должна иметь выбранное транспортное средство. Если ТС выбрано, то система удаляет его из базы данных, если не выбрано, то системе удалять нечего, и она выдаст сообщение «Выберете ТС».

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

Система должна обеспечивать поиск заказов по введенной дате.

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

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

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

Система должна обеспечивать поиск водителей по типу транспортного средства.

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

Система должна обеспечивать поиск данных путевого листа по водителю.

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

1. Добавление нового объекта

Рисунок 70

Внесение данных осуществляется с помощью ручного ввода данных (рисунок 70). Главное задачей является отсутствие пустых значений. При нажатии на кнопку «Добавить» в таблицу ТС вносится соответствующая запись (рисунок 71).

Рисунок 71

Рисунок 72

При попытке добавить данные с пустым значением, система выдаст предупреждение рисунок 72.

2. Изменение данных выбранного объекта

При нажатии на кнопку «Изменить» производится изменение данных выбранной записи в таблице (рисунок 73)

Рисунок 73

Рисунок 74

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

Рисунок 75

Рисунок 76

Удаление выбранного объекта

При нажатии на кнопку «Удалить» производится удаление данных выбранной записи в таблице (рисунок 77). Удалить можно любой объект, за исключением отсутствия объектов в системе.

В случае, если объектов в системе нет, система выдаст предупреждение (рисунок 78).

Рисунок 77

Рисунок 78

Поиск заказов

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



Рисунок 79

Рисунок 80

Поиск ТС

При нажатии на кнопку «Добавить» производится выгрузка данных по ТС, соответствующим типу грузов в соответствующий элемент формы (рисунок 81).

Поиск водителей

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



Рисунок 81

Рисунок 82

6. Аппаратная и административная интеграция ИС

6.1 Разработка схемы развертывания

В результате разработки проекта получена компонента «App1.ехе», реализующая работу на стороне клиента (Диспетчера АТЦ), компонента, реализующая работу на стороне клиента (водителя), и база данных «Basa», реализующая компоненту работы с данными в среде Micsosoft SQL Server 2008.

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

· Установка на сервер MS SQLServer;

· Развертывание базы данных на сервере;

· Установка разработанного клиентского приложения на компьютеры диспетчеров;

· Установка разработанного клиентского приложения на планшеты водителей.

На рисунке 83 изображена схема развертывания.

Рисунок 83. Начальный вариант схемы развертывания

6.1.1 Формулировка требований к физическим устройствам и сетевому оборудованию, состав рабочих мест

Данная информационная система разработана для последующей установки на ПК с установленной операционной системой Microsoft Windows 7 и выше, а также планшетах водителей с операционной системой Android.

Для функционирования данной ИС необходимо следующее оборудование:

-Сервер СУБД - будет использоваться для размещения и управления базами данных исходя из планируемого объема записей БД. На предприятие имеется сервер, необходимо установить MS SQL Server.

-ПК - будут использоваться как клиенты информационной системы (для диспетчера);

-Планшеты с доступом в интернет - будут использоваться как клиенты информационной системы (для водителя);

-Сетевой кабель, для объединения пк в единую локальную вычислительную сеть (ЛВС);

Для работы с единой базой данных необходимо подключить все рабочие места к сети. В отдел, куда предполагается внедрить ИС, находятся 1 компьютер и 5 планшетов, которые должны быть подключены к сети.

6.2 Выбор состава аппаратных средств

Сервер должен соответствовать системным требованиям серверной ОС и требованиям серверной части ПО.

Клиентские машины должны соответствовать системным требованиям ОС.

ЛВС должна обеспечивать необходимую пропускную способность (скорость соединения) между клиентской машиной и сервером.

Средства коммуникации:

ЛВС на основе Fast Ethernet (100 Mbit/s), либо Gigabit Ethernet (1000 Mbit/s)

В качестве сервера используется ПК со следующими характеристиками:

Таблица 2

Минимальные	Используемые
Pentium IV 1,8GHz , HDD 40Gb, 1 ОЗУ, сетевая карта	Intel core i3 3 GHz , HDD 1ТБ, 4 ОЗУ, сетевая карта

В качестве рабочей станции диспетчера используется ПК со следующими характеристиками:

Таблица 3

Минимальные	Используемые
Pentium IV 2.8GHz , HDD 40Gb, 1 ОЗУ, сетевая карта ОС Windows 7	Intel Core i5 2,93GHz , HDD 500Gb, 4 ОЗУ, сетевая карта, ОС Windows 7

В качестве рабочей станции водителя необходимо использовать планшет со следующими характеристиками:

Таблица 4

Минимальные	Используемые
ОС Android 4.4.2, Wi-fi, 3G-модуль, ОЗУ 1 ГБ	ОС Android 4.4.2, Wi-fi, 3G-модуль, ОЗУ 2 ГБ

Данные компьютеры и планшеты соответствуют требованием для создания сети.

6.2.1 Расчет потребности персонала

Расчет потребности персонала считается с учетом требований, предъявляемым к системе. Для работы с системой и ее внедрения необходим следующий персонал:

- Специалист обеспечения связи

Для обеспечения настройки ЛВС, а также подключения планшетов к сети.

- Ведущий специалист ИС

Для обеспечения возможности внедрения системы на предприятие

- Инженер - программист.

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

-Диспетчер АТЦ.

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

-Водитель АТЦ

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

На предприятие имеются все необходимые специалисты. Вопрос найма новых специалистов, рассматривать не нужно, необходимо обучение уже имеющихся специалистов.

6.3 Разработка среды интеграции

При разработке среды интеграции создание единой информационной среды обмена данными с внешними объектами (технологии, реализация, исполнители, провайдеры) и разработка системы администрирования всей этой средой.

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

Отсутствие ЛВС влечет за собой следующие последствия:

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

· значительные затраты на приобретение различных устройств для каждого компьютера (жесткий диск, принтер, CD-ROM, модем) и дорогостоящего программного обеспечения;

· отсутствие эффективного доступа к глобальным ресурсам всемирной сети Internet и средствам электронной почты (E-mail), которые могли бы значительно повысить эффективность работы предприятия.

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

Именно по этим причинам, чтобы обеспечить доступ различных предприятий одного холдинга, необходимо создание ЛВС, которая во много упростит работу предприятия, а также сделает его деятельность более эффективной.

6.3.1 Выбор сетевой архитектуры и технологии

Выбор архитектуры

На предприятии уже настроена ЛВС, со следующими параметрами, представленными в таблице 11.

Таблица 11. Основные характеристики сети

Компонент/характеристика	Вариант сети
Топология	Звезда
Линия связи	Экранированная витая пара cat 5е.
Сетевые адаптеры	Fast Ethernet
Ретрансляторы (повторители, концентраторы, коммутаторы, мосты, маршрутизаторы, шлюзы)	Коммутаторы (D-Link, telesis), роутеры (D-Link, TP-Link ).
Управление совместным использование ресурсов	Клиент - серверная архитектура построения.
Совместное использование периферийных устройств	Сетевой принтер. Управление очередями к принтеру осуществляет рабочая станция.
Поддерживаемые приложения	Электронная почта, работа с БД.

Схема ЛВС, включающая холдинг и предприятие по производству цемента представлена в приложении 2.

Выбор технологии и аппаратных средств. Расчет сети.

На предприятие установлена стандартная сеть на базе технологии Fast Ethernet. Расчет стоимости сетевого оборудования и его монтажа не требуется, так как на предприятии уже установлена и смонтирована ЛВС

В расширение сети включается подключение планшетов к интернету.

Схема сети представлена ниже:

Рисунок 84. Схема сети

7. Общие вопросы администрирования

7.1 Определение стратегии администрирования на уровне руководства и целей предприятия

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

· Определены положения, которые устанавливают права работников;

· Деятельность персонала ограничена;

· Обязанности персонала контролируются сотрудниками управляющей компании;

· Устанавливаются процедуры, которые выполняются работниками;

· внедряются инструкции для водителей и диспетчеров;

· производится обучение пользователей системы.

7.2 Определение объектов администрирования

Объектами администрирования на уровне предприятия:

· рабочие компьютеры;

· сетевые устройства (маршрутизатор);

· база данных и её объекты (таблицы, хранимые процедуры, база выполняется на основе MS SQL Axapta);

· программное обеспечение;

· периферийные устройства (принтеры);

· сервер.

Объекты администрирования на уровне разрабатываемой ИС:

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

· база данных;

· рабочие станции.

7.3 Политика администрирования на уровне предприятия

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

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

В сети допускается использование разных типов приложений: клиент-серверных, на основе эмуляции терминала, WEB приложения и др.

Передача информации осуществляется по сети;

Для адресации сети используется адресное пространство разрешенного частного адресного пространства Интернет.

В целях обеспечения удаленного доступа к информационно-техническим сервисам предприятия допускается наличие канала связи удаленного доступа.

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

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

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

При аварии резервные копии (в основном бэкапы БД), хранящиеся на файл-сервере, используются для восстановления системы.

7.4 Политика администрирования на уровне разрабатываемой системы

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

Требования к аутентификации не были предъявлены, так как пользоваться программой будут только сотрудники АТЦ. Разделение ролей производится на уровне разрабатываемых приложений. Для каждого сотрудника разработано отдельное приложение: для диспетчеров - приложение WFA, для водителей - Android.

Авторизация при работе с рабочими станциями осуществляется средствами Active Directory, установленной в домене.

интерфейс программирование информационный

8. Вопросы информационной безопасности

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

Для обеспечения информационной безопасности на предприятии необходимо предпринять ряд следующих мер:

Обеспечить доступ к информации только сотрудникам предприятия. В пределах предприятия обеспечить доступ сотрудников только к информации, с которой он непосредственно производит работу;

Установить средства защиты от механических повреждений и проникновений в систему, то есть обеспечить физическую безопасность;

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

8.1 Анализ угроз

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

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

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

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

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

Оценка вероятности возникновения угрозы:

· очень вероятна - 9-10 баллов,

· вероятна - 5-8 баллов,

· маловероятна - 3-5 баллов.

· практически невероятна 1-2 балла.

Оценка степени ущерба возникновения угрозы:

· полная потеря данных - 9-10 баллов,

· частичная потеря данных - 3-8 балла,

· возможная потеря данных - 1-2 балла.

Таблица 6. Оценка угроз

Угрозы	Вероятность возникновения	Ущерб	Коэффициент оценки угрозы	Меры предотвращения
Отказы источников питания и скачки напряжения	7	3	21	Использование источников бесперебойного питания
Природные явления (молния, бури и т.д.)	4	2	8	Заземление и установка громоотводов
Угрозы возгорания	1	8	8	Установка систем пожаротушения и экстренной кнопки
Ошибки пользователей	6	5	30	Обучение персонала
Воровство или вандализм	4	8	32	Видеонаблюдение и бдительность охраны
Несанкционированный доступ к ресурсам	4	4	16	Парольная защита
Компьютерные вирусы	8	6	48	Установка антивирусной защиты
Сбои программного обеспечения	3	8	24	Использование качественного и лицензированного ПО
Сбои аппаратного обеспечения	4	8	32	Контроль за состоянием аппаратного обеспечения
Механические повреждения кабеля	2	7	14	Правильный монтаж сети

8.2 Информационная безопасность на уровне предприятия

8.2.1 Контроль доступа в помещение организации

Контроль доступа на объекты регламентируется общими правилами АО « Сибирский Цемент».

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

Кроме того, на входе в помещения организаций, входящих в холдинг, работают сотрудники охраны, наблюдающие за сотрудниками и посетителями организаций.

8.2.2 Обеспечение безопасности с помощью аппаратных средств

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

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