Файл: Диплом автоматизации планирования грузоперевозочных рейсов.docx
Добавлен: 25.10.2018
Просмотров: 4862
Скачиваний: 36
Таблица 3.1 — Сравнение сред разработки и соответствующих им языков программирования
Критерий |
Visual Studio (C#) |
Visual Studio (Native C++) |
Eclipse (Java) |
Delphi |
Удобство разработки |
Высокое |
Высокое |
Среднее, трудности в настройке среды |
Среднее |
Простота разработки с точки зрения программиста |
Высокая, обуславливается полностью автоматической работой с памятью |
Низкая, обуславливается низкоуровневым языком и ручной работой с памятью |
Высокая, обуславливается полностью автоматической работой с памятью |
Средняя, обуславливается ручной работой с памятью, не требующей применения указателей |
Надежность разработанных программ |
Высокая |
Низкая |
Высокая |
Средняя |
Ключевые особенности |
Поддержка технологии .NET Framework, огромная библиотека классов |
Позволяет разрабатывать самые производительные программы |
Популярность среди множества разработчиков; множество сторонних компонент; независимость от платформы |
Относительно быстрый компилятор |
Явные недостатки |
Не выявлено |
Отсутствие удобных библиотек готового кода, не годится для разработки ЭИС |
Невысокая скорость работы Eclipse и других программ, написанных на Java |
Разработчики Delphi не успевают за новыми технологиями; Delphi морально устарел |
Таким образом, наиболее оптимальный вариант среды для разработки ЭИС — Microsoft Visual Studio и язык программирования C#.
Для разрабатываемой ЭИС в качестве СУБД была выбрана MySQL. MySQL является относительно небольшой и быстрой реляционной СУБД, оптимальным решением для малых и средних по размеру приложений. MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License или под собственной коммерческой лицензией [3.4].
Основные преимущества СУБД MySQL [3.5]:
-
многопоточность, поддержка нескольких одновременных запросов;
-
оптимизация связей с присоединением многих данных за один проход;
-
гибкая система прав доступа;
-
основанная на потоках, быстрая система памяти;
-
максимальный размер таблицы ограничен 8 миллионами терабайт;
-
легкость управления таблицей, включая добавление и удаление ключей и полей;
-
гибкость, обеспечивающаяся поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей.
Основная причина выбора MySQL в качестве СУБД для разрабатываемой ЭИС заключается в ее бесплатности, так как она распространяется под свободной лицензией с открытым исходным кодом. Так как предполагается, что с ЭИС будет работать одновременно не более 7-10 пользователей, то возможностей и производительности СУБД MySQL будет вполне достаточно. Также стоит отметить, что в разрабатываемой ЭИС код доступа к данным будет вынесен в отдельный модуль, что позволяет с легкостью заменить MySQL на другую СУБД, переписав лишь этот модуль.
Помимо MySQL в качестве СУБД также рассматривались и сравнивались между собой программные продукты других производителей (Таблица 3.2) [3.6].
Таблица 3.2 — Сравнение СУБД
Критерий |
Microsoft SQL Server 2008 |
PostgreSQL 8.4 |
MySQL 5.1 |
Поддерживаемые операционные системы |
Windows |
Windows, Linux, Unix, Mac |
Windows, Linux, Unix, Mac |
Условия лицензирования |
Коммерческий продукт с закрытым исходным кодом |
Лицензия BSD Open Source |
Коммерческая лицензия и GNU GPL |
Наличие драйверов ODBC, ADO.NET |
Да |
Да |
Да |
Использование в коммерческих проектах |
Среднее |
Среднее, но реже, чем MySQL |
Среднее |
Наличие графического ПО для конструирования и оптимизации запросов |
Да (SQL Management Studio и Studio Express) |
Да (PgAdminIII) |
MySQL Workbench, также существует много сторонних средств |
Стоимость |
102700 руб. за версию Standard R2 32-bit/x64, на 10 клиентов |
Бесплатно |
Бесплатно |
Таким образом, MySQL является самым оптимальным вариантом. Также неплох бесплатный PostgreSQL, но под него сложно разрабатывать. А так как скорость разработки ЭИС имеет значение, то самый оптимальный вариант остается без изменений.
На Рисунке 3.2 представлено дерево функций разрабатываемой ЭИС. Диалог с системой реализован с применением «меню» и управляющих элементов (кнопок, полей ввода и других) в окне диалога.
Для разработки структуры сценария диалога помимо выявления состава функций и их иерархии необходимо выбрать язык общения, например, меню. Меню — элемент интерфейса пользователя, позволяющий выбрать одну (в простейшем случае) из нескольких перечисленных опций [3.7].
Элементы диалога, не входящие в меню, но являющиеся важными для системы, выделены пунктирной линией. Все остальные функции системы, представленные на рисунке, реализованы в виде ленточного меню "Ribbon". Ribbon или Microsoft Fluent Interface — тип интерфейса в GUI-приложениях, основанный на панелях инструментов, разделенных вкладками. Последние приложения, выпущенные компанией Microsoft, применяют эту форму интерфейса, главной частью которой является модульная лента как основа интерфейса [3.8].
Типовой сценарий диалога формирования нового рейса (предполагается, что все справочники заполнены и список заявок не пустой) представлен на Рисунке 3.3.
Рисунок 3.3 — Сценарий диалога «формирование нового рейса»
Совокупность программных модулей ЭИС можно разделить на пять групп:
-
служебные модули;
-
модули описания объектов;
-
модули доступа к данным;
-
функциональные модули, реализующие основные алгоритмы ЭИС; модули, связанные с вводом, выводом информации пользователю (реализующие графический интерфейс).
При разработке ЭИС были созданы программные модули, описание которых приведено в Таблице 3.3. В колонке «тип» указана принадлежность модуля к одной из перечисленных выше групп: «С» — служебный; «О» — модуль описания объектов; «Д» — доступ к данным; «Ф» — функциональный; «Г» — модуль вводавывода (графический интерфейс).
Таблица 3.3 — Описание программных модулей
№ п/п |
Идентификатор |
Тип |
Выполняемые функции |
1 |
Car |
О |
Описание класса «автомобиль» |
2 |
Client |
О |
Описание класса «контрагент» |
3 |
CoreObject |
О |
Описание базового класса для основных объектов |
4 |
CostsType |
О |
Описание перечисления типа себестоимости (плановая или фактическая) |
5 |
Driver |
О |
Описание класса «водитель» |
6 |
Fuel |
О |
Описание класса «топливо» |
7 |
GeoPoint |
О |
Описание класса географической координаты |
8 |
Goods |
О |
Описание класса «груз» |
9 |
Request |
О |
Описание класса «заявка» |
10 |
Route |
О |
Описание класса «рейс» |
11 |
CarManager |
Д |
Интерфейс к БД для работы с объектами «автомобиль» |
12 |
ClientManager |
Д |
Интерфейс к БД для работы с объектами «контрагент» |
13 |
DataManager |
Д |
Интерфейс для выполнения запросов к БД |
14 |
DriverManager |
Д |
Интерфейс к БД для работы с объектами «водитель» |
15 |
FuelManager |
Д |
Интерфейс к БД для работы с объектами «топливо» |
16 |
GoodsManager |
Д |
Интерфейс к БД для работы с объектами «груз» |
17 |
ParamManager |
Д |
Интерфейс к БД для управления глобальными параметрами |
18 |
RequestManager |
Д |
Интерфейс к БД для работы с объектами «заявка» |
19 |
RouteManager |
Д |
Интерфейс к БД для работы с объектами «рейс» |
20 |
UserManager |
Д |
Интерфейс к БД для управления пользователями |
21 |
FormAuth |
Г |
Форма для авторизации и входа в систему |
Продолжение Таблицы 3.3
22 |
FormCar |
Г |
Форма для работы с объектами «автомобиль» |
23 |
FormCarList |
Г |
Форма для работы со списком объектов «автомобиль» |
24 |
FormCarSelect |
Г |
Форма для выбора объекта «автомобиль» |
25 |
FormClient |
Г |
Форма для работы с объектами «контрагент» |
26 |
FormClientList |
Г |
Форма для работы со списком объектов «контрагент» |
27 |
FormClientSelect |
Г |
Форма для выбора объекта «контрагент» |
28 |
FormDriver |
Г |
Форма для работы с объектами «водитель» |
29 |
FormDriverList |
Г |
Форма для работы со списком объектов «водитель» |
30 |
FormDriverSelect |
Г |
Форма для выбора объекта «водитель» |
31 |
FormEnterDriverWage |
Г |
Форма для регистрации почасовой оплаты водителя |
32 |
FormEnterFuelCost |
Г |
Форма для регистрации стоимости топлива |
33 |
FormEvents |
Г |
Форма для просмотра событий в системе |
34 |
FormFuel |
Г |
Форма для работы с объектами «топливо» |
35 |
FormFuelList |
Г |
Форма для работы со списком объектов «топливо» |
36 |
FormFuelSelect |
Г |
Форма для выбора объекта «топливо» |
37 |
FormGoods |
Г |
Форма для работы с объектами «груз» |
38 |
FormGoodsList |
Г |
Форма для работы со списком объектов «груз» |
39 |
FormGoodsSelect |
Г |
Форма для выбора объекта «груз» |
40 |
FormInputRealCosts |
Г |
Форма для ввода величин фактических затрат |
41 |
FormLogo |
Г |
Форма, демонстрирующая логотип программы при ее загрузке |
42 |
FormMainRibbon |
Г |
Основная форма программы |
43 |
FormParams |
Г |
Форма для управления глобальными параметрами программы |
44 |
FormPickUpRequest |
Г |
Форма для подбора заявок в рейс |
45 |
FormProgressBar |
Г |
Вспомогательная форма для отображения хода выполнения операции |
46 |
FormReport |
Г |
Форма для построения отчетов по себестоимости |
47 |
FormReportPeriod |
Г |
Форма для построения отчетов с заданным периодом |
48 |
FormRequest |
Г |
Форма для работы с объектами «заявка» |
49 |
FormRequestList |
Г |
Форма для работы со списком объектов «заявка» |
50 |
FormRequestSelect |
Г |
Форма для выбора объекта «заявка» |
51 |
FormRouteDetails |
Г |
Форма для работы с объектами «рейс» |
52 |
FormRoutes |
Г |
Форма для работы со списком объектов «рейс» |
53 |
FormRoutingMap |
Г |
Форма для вывода маршрута движения на карте |
54 |
FormsCommon |
С |
Общий модуль вспомогательных функций для работы с формами |
55 |
FormUsers |
Г |
Форма для управления пользователями |
56 |
MyForm |
Г |
Базовый класс формы, наследуемый большей частью диалоговых форм программы |
57 |
Common |
С |
Общий модуль вспомогательных функций для всей программы |
58 |
CostsCalc |
Ф |
Модуль для вычисления себестоимости заявок и рейсов |
59 |
GeoCoding |
Ф |
Модуль для вычисления географических координат по произвольному адресу |
60 |
GeoNavigation |
Ф |
Модуль для вычисления расстояний и работы с картой |
61 |
IniFile |
С |
Модуль для чтения или записи локальных настроек программы, хранящихся в файле формата Windows INI |
62 |
Program |
Ф |
Основной модуль программы |
Диаграмма классов ЭИС представлена на Рисунке 3.4. Диаграмма разработана в соответствии с принципами UML и содержит только основные классы. UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения.
Методы и атрибуты классов скрыты для сокращения объема занимаемого диаграммой пространства. Большинство классов располагаются в одноименных модулях, изредка в одном модуле располагаются один главный класс и несколько ему подчиненных по смыслу второстепенных классов.
Структура базы данных ЭИС разработана в соответствии с ER-моделью, подробно рассмотренной в пункте 2.2.1.1. Изменения были внесены в состав таблиц (или сущностей для ER-модели), состав атрибутов, а также сущности «клиент» и «пункт» — для удобства их было решено объединить в одну таблицу "Clients". Все названия и идентификаторы заменены эквивалентными английскими словами и сокращениями.
Было добавлено несколько новых таблиц:
-
users — хранит список пользователей системы, атрибут "group" указывает, к какой группе принадлежит пользователь. Таких групп в системе две: диспетчеры и администраторы;
-
events — хранит список произошедших событий в системе (например, удаление или добавление заявки, рейса). В поле "desc" хранится описание события в текстовом виде;
-
cache_distances — используется для хранения ранее вычисленных значений расстояний между контрагентами (в км), чтобы повысить скорость работы программы. Ключевые атрибуты задают контрагентов; param — глобальные настройки системы в виде пары «ключ-значение».
Сущность «накладные расходы рейса» из ER-модели в схеме БД получила название route_costs. Название атрибута «статус» сущности «рейс» из ER-модели в схеме БД заменено на "completed", принимающего значение «1» если рейс завершен и «0» в противном случае.
Для представления дробных чисел используется тип Decimal как наиболее точный с точки зрения влияния округления. Точность в два знака после запятой применяется для значений в денежном выражении, точность в три знака — для значений, выраженных в количественном выражении. Для представления целых чисел используется тип Integer.
Полученная схема базы данных изображена на Рисунке 3.5.
Также стоит пояснить сокращения в названии некоторых атрибутов:
-
routes, cctrl_use — параметр рейса, сообщающий, будет ли использоваться кондиционер или установка климат-контроль;
-
route_costs, request_costs, fuel_winter_al — дополнительный расход топлива в зимний период;
-
route_costs, request_costs, fuel_cctrl_al — дополнительный расход топлива при использовании кондиционера или установки климат-контроль;
-
route_costs, request_costs, fuel_old_al — дополнительный расход топлива на изношенный автомобиль;
-
request_costs, fuel_work_al — расход топлива на транспортную работу;
-
request_costs, fuel_slow_al — расход топлива при движении с пониженной скоростью;
-
request_costs, fuel_refr_al — дополнительный расход топлива при использовании рефрижератора;
-
route_costs, request_costs, fuel_costs — сумма базового расхода топлива (с прицепом) и всех перечисленных ранее показателей расхода топлива.
Предложенная схема БД является наиболее оптимальной, так как сочетает в себе гибкость и минимум дублирования данных. Дублирование таких данных, как например, затраты на страхование (insurance_costs) в таблице с заявками и таблице с их себестоимостью (requests и request_costs) применяется исключительно с целью удобства внесения данных по себестоимости без необходимости модифицировать записи, например, заявок.
Схема функционирования разрабатываемой ЭИС представлена на Рисунке 3.6.
От клиентов заявки поступают диспетчеру, диспетчер вносит информацию о них в ЭИС с помощью графического интерфейса. Графические интерфейс (модули, реализующие диалоговые формы) тесно связан с функциональными модулями, обеспечивающими, например, расчет себестоимости или подбор заявок. Функциональные модули, в свою очередь, связаны с модулями доступа к данным, основная задача которых — извлечение данных из БД. Также вплотную к функциональным модулям примыкают вспомогательные, реализующие отдельные служебные функции.
Главными целями деятельности по обеспечению информационной безопасности являются ликвидация угроз объектам информационной безопасности и минимизация возможного ущерба, который может быть нанесен вследствие реализации данных угроз. Угроза — одно из ключевых понятий в сфере обеспечения информационной безопасности [3.9].
Необходимо выделить два наиболее важных типа угроз:
-
Намерение нанести вред, которое появляется в виде атаки со стороны злоумышленника.
-
Возможность нанесения вреда — существование достаточных для этого условий и факторов. К данному типу угроз можно отнести ошибки пользователей, допускаемые по невнимательности, например, случайное удаление важных данных.
При разработке ЭИС для минимизации вреда от перечисленных выше типов угроз было разработано три подсистемы безопасности:
-
Авторизация пользователя при входе в систему.
-
Разграничение доступа на уровне базы данных.
-
Журнал событий в системе.
Суть авторизации заключается во вводе имени пользователя и пароля в специальном диалоговом окне программы, появляющемся на стадии ее запуска. Авторизация в некоторой степени гарантирует, что никто не сможет войти в систему, не зная указанной комбинации из имени пользователя и пароля (с условием, что пароль является надежным, то есть состоит из беспорядочного набора букв, цифр и специальных знаков и имеет длину от десяти символов и более) [3.10].
Разграничение доступа реализовано в разделении всех пользователей на две группы: администраторы и диспетчеры. Каждая группа наделена определенными правами. Так, администраторы могут производить любые действия, изменять любые параметры системы и добавлять, удалять, изменять любые данные в системе. Диспетчерам позволено добавлять, удалять, изменять данные (элементы справочников, заявки, рейсы), но не разрешено изменять состав пользователей, удалять события из журнала, изменять глобальные параметры (различные нормы надбавок к расходу топлива и другие параметры), так как изменение этих данных повлияет на всех пользователей системы. Доступ к таблицам пользователей, событий и параметров ограничен на уровне базы данных с целью предотвратить возможные случаи, связанные с неправомерным использованием, например, консоли запросов MySQL.