Курсовые работы / ПРИС КП_2

8.Фиксация в ИС сведений о выполненных заказах и текущих рейсах;

9.Фиксация требований к транспортировке;

10.Внесение или редактирование информации в БД.

Рассчитаем для примера коэффициенты для первого уровня (А0). Для данного уровня N = 4; L = 1; A1 = 7; A2 = 7; A3 = 10; A3 = 7; Nэл.ф. = 1.

Следовательно коэффициент уровня равняется Ku=4/1=4; коэффициент

сбалансированности равняется Kб=| | ; Кф=1*1/4=0,25.

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

Результаты расчетов представлены в таблице 2.1.

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

уменьшение.

Таблица 2.1 - Результаты количественного анализа модели

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

Также следует отметить, что уровень А21 наиболее сбалансирован. Кроме того коэффициент сбалансированности находится в пределах от 0,5 до 2,25.

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

23

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

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

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

классы сложности маршрута, типы грузов, водители, категории водителей,

категории ТС, транспортные средства, тягачи, полуприцепы - цистерны.

Логическая модель данных представлена на рисунке 2.5, физическая модель данных представлена на рисунке 2.6.

Нормализуем полученную модель данных до третьей нормальной формы.

Для приведения в первую нормальную форму необходимо выполнить условие,

при котором все атрибуты содержат атомарные значения [11]. Как видно из рисунка 1, модель данных находится в первой нормальной форме.

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

«Регламент» можно сделать вывод, модель данных находится во второй нормальной форме.

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

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

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

Физическая модель была построена для СУБД DB-2, так как типы данных идентичны типам данных postgresql.

24

Рисунок 2.5 - Логическая модель данных

Рисунок 2.6 - Физическая модель данных

25

В данной модели можно выделить следующие взаимосвязи между

сущностями:

-На основании информации о маршруте определяется категория сложности маршрута.

-Каждому водителю соответствует определённая категория водительского удостоверения.

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

становится возможным определение подходящего для рейса водителя.

- На основании перевозимого типа груза, перевозимого объема и требованиям к его транспортировке выбирается соответствующий полуприцеп-

цистерна.

- На основании категории сложности маршрута выбираются все подходящие по стажу водители и далее сравниваются их категории с необходимыми для ТС категориями.

Выводы по второй главе

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

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

26

3 РАЗРАБОТКА И ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ ОРГАНИЗАЦИИ ГРУЗОПЕРЕВОЗОК СЖИЖЕННОГО ГАЗА, БЕНЗИНА И НЕФТЕПРОДУКТОВ АВТОТРАНСПОРТНОЙ КОМПАНИЕЙ

3.1 Описание таблиц базы данных

База данных была построена в СУБД PostgreSQL. Для реализации автоматизированной системы были созданы 10 справочников: рейсы, цистерны,

водители, водительские категории, регламент, сложность маршрутов,

возможные маршруты, типы грузов, список тягачей и транспортные средства.

Внешний вид и заполнение справочников представлен на рисунках 3.1 -3.10.

Рисунок 3.1 - Таблица «Рейсы»

Рисунок 3.2 - Таблица «Цистерны»

27

Рисунок 3.3 - Таблица «Оборудование»

Рисунок 3.4 - Таблица «Водительские категории»

Рисунок 3.5 - Таблица «Регламент»

Рисунок 3.6 - Таблица «Сложности маршрутов»

28

Рисунок 3.7 - Таблица «Возможные маршруты»

Рисунок 3.8 - Таблица «Типы грузов»

Рисунок 3.9 - Таблица «Тягачи»

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

29

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

Рисунок 3.10 - Таблица «Транспортные средства» Сочетание экземпляров таблиц тягачи и цистерны задают определённое

транспортное средство, также, на основании данных о категориях транспортных средств, происходит сопоставление полной массы ТС с соответствующей категорией.

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

в последующем на основании регламента для транспортного средства определяется водитель с соответствующей категорией.

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

3.2 Дерево программных модулей

Rails - это полноценный, многоуровневый фреймворк для построения веб-

приложений, использующих базы данных, который основан на архитектуре Модель-Представление-Контроллер (Model-View-Controller, MVC) [12].

Model (далее Модель) является «сутью» приложения и отвечает за непосредственные алгоритмы, расчёты и тому подобное внутреннее устройство приложения. Также предоставляет линк к хранилищу данных.

30

View (Представление, дальше Вид) предназначен для вывода данных,

предоставленных Моделью. Это единственная часть MVC, которая непосредственно контактирует с пользователем.

Controller (Поведение, далее Контроллер) получает данные от пользователя и передаёт их в Модель. Кроме того, он получает сообщения от Модели и передаёт их в Вид.

Взаимодействие перечисленных элементов представлено на рисунке 3.11.

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

Исходя из этого RoR использует три компонента: Active Record; Action View; Action Controller [13].

Рисунок 3.11 - Порядок взаимодействия модели, представления и контроллера

Active Record - это Модель в RoR. Модель хранит данные и предоставляет базу для работы с данными. Кроме этого Active Record также является ORM фрэймворком. ORM значит Object-relational mapping (Объектно-

реляционная проекция). Собственно Active Record делает следующие вещи:

Проекция таблицы на класс. Каждая таблица проецируется на один или несколько классов по принципу convention over configuration (соглашение выше

31

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

Соединение с БД. Вы можете подключиться к базе данных, используя

API, предоставляемый Active Record, который создает необходимый вам запрос непосредственно в движок БД при помощи адаптеров. У Active Record есть адаптеры для MySQL, Postgres, MS SQLServer, DB2, и SQLite. Необходимо лишь записать параметры доступа к БД в файле database.yml.

Операции CRUD. Это операции create (создание), retrieve (получение), update (обновление) и delete (удаление) над таблицей. Так как Active Record -

это ORM фрэймворк, вы всегда работаете с объектами. Чтобы создать новую строку таблицы, вы создаете новый объект класса и заполняете его переменные экземпляра значениями [14]. Данные операции Active Record делает автоматически.

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

Вид включает в себя логику, необходимую для вывода данных Модели.

Роль Вида в RoR играет Action View. Наиболее часто используемые функции

Action View [15]:

Шаблоны (Templates). Шаблоны - это файлы, содержащие заполнители

(placeholders), которые буду заменены на контент. Шаблоны могут содержать

HTML-код и код Ruby, встраиваемый в HTML с использованием синтаксиса встроенного (embedded) Ruby (ERb).

Помощники (helper, далее хелпер) форм и форматирования. Хелперы форм позволяют создавать такие элементы страниц, как чекбоксы, списки,

32