ПОСТРОЕНИЕ UML-ДИАГРАММ НА ПРИМЕРЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПРОПУСКА ТРАНСПОРТНЫХ СРЕДСТВ НА ТЕРРИТОРИИ ПРЕДПРИЯТИЯ ООО «САХ»

Работа над моделями начинается с общего анализа системы. Система пропуска транспортных средств предприятия представляет из себя КПП с заграждением и датчиками распознавания RFID.

Задачи системы:

• распознавание транспортного средства;
• осмотр транспортного средства (производит механик ОТК (отдел технического контроля));
• выписка ремонтного листа, в случае необходимости;
• выписка путевого листа;
• выписка временного пропуска.

Рассмотрим диаграмму вариантов использования, отражающую функциональное назначение проектируемой программной системы (рисунок 1) [1].

Рисунок 1. Диаграмма вариантов использования.

Как видно из рисунка 1, диаграмма предполагает только проход через КПП, как вариант использования. Действие «Пропуск транспорта» обязательно включает в себя «Запись в путевой лист», что отражено стрелкой со стереотипом «include». При проверке идентификатора, транспорт обязательно регистрируется, что также отмечено на диаграмме. В случае необходимости, выписывается временный пропуск, отмеченный на рисунке стрелкой «extend», которая означает обработку исключений. Так же возможна выписка ремонтного листа.

Напомним, что эта диаграмма является высокоуровневым концептуальным представлением модели, следовательно, она не должна содержать слишком много вариантов использования и актеров. В последующем данная диаграмма может быть изменена путем добавления новых элементов, например, вариантов использования и актеров, или их удаления [2].

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

Рисунок 2. Диаграмма классов СКУД.

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

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

Система контроля реализует управление заграждением и экраном АРМ. Так же этот класс обеспечивает передачу данных из и в базу данных. С экрана АРМ «Механик ОТК» контролирует информацию о машине и с помощью класса «Клавиатура и мышь АРМ» может создать или заполнить, путевой или ремонтный лист.

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

Перейдем к диаграмме кооперации (рисунок 3). Диаграмма кооперации является разновидностью диаграммы взаимодействия, и, в контексте языка UML, описывает динамический аспект кооперации объектов, при реализации различных вариантов использования. Обычно такие диаграммы описывают реализацию типичного хода событий при работе системы [5].

Рисунок 3. Диаграмма кооперации.

Как видно из рисунка 3, типичная схема работы системы достаточно проста. С устройства считывания идентификатор передается на центральный класс – «Система контроля транспорта». После чего этот класс запрашивает данные о машине в классе «База данных», с помощью связей «Получить данные о машине» и «Передать путевой лист».

После получения этих данных на «Экран АРМ» передается информация о машине и путевой лист. Механик ОТМ принимает решение о пропуске, в случае необходимости заполняется ремонтный лист и передается сигнал на заграждение.

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

Рассмотрим также диаграмму последовательности (рисунок 4). Диаграмма последовательности является другим способом визуализации взаимодействия в модели и, как и диаграмма кооперации, оперирует объектами и сообщениями.

Рисунок 4. Диаграмма последовательности.

Диаграмма последовательности, изображенная на рисунке 4, изображает процесс типичного хода работы системы более наглядно, чем диаграмма кооперации. Диаграмма состоит из так называемых «дорожек», которые обозначают жизненный цикл классов системы. На этих дорожках изображены действия этих классов. Чем ниже действие – тем позже оно в хронологии проходит.

Продолжим построение UML-диаграмм с диаграммой состояний.

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

• Круг, обозначающий начальное состояние.
• Круг обведенный, обозначающая конечное состояние (если есть).
• Скруглённый прямоугольник, обозначающий состояние. Верхняя часть   прямоугольника содержит название состояния. В середине может быть линия, под которой записываются действия, происходящие в данном состоянии.
• Стрелка, обозначающая переход. Название события, вызывающего переход, отмечается рядом со стрелкой. Охраняющее выражение может быть добавлено перед «/» и заключено в квадратные скобки (название_события[охраняющее_выражение]), что означает возможность перехода в случае истинности выражения. Если существует какое-то действие, то оно добавляется после «/» (название_события[охраняющее_выражение]/действие).
• Толстая горизонтальная линия с либо множеством входящих линий и одной выходящей, либо одной входящей линией и множеством выходящих. Это обозначает объединение и разветвление соответственно.

Рассмотрим такую диаграмму применительно к нашей системе. Она расположена на рисунке 5.

Рисунок 5. Диаграмма состояний.

На рисунке 5 изображена диаграмма состояний. Начальное и конечное состояние системы замкнуто на состоянии «Ожидание ввода идентификатора», что означает, что система всегда ожидает ввода. Стрелки на диаграмме представляют из себя произошедшие события, прямоугольники – состояния системы.

Следует заметить, что в разрабатываемой модели диаграмма состояний является единственной и описывает поведение системы в целом. Главное достоинство данной диаграммы – возможность моделировать условный характер реализации всех вариантов использования в форме изменения отдельных состояний разрабатываемой системы [3].

Перейдем к построению финальной диаграммы – диаграммы компонентов. Эта диаграмма показывает отношения между компонентами системы (рисунок 6).

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

Как видно из рисунка 6, система состоит из компонентов программной логики – «MainProgram» который, как следует из названия, реализует программный компонент системы и «Controller», который отвечает за работу физических устройств. Так же видна связь между программой и базой данных.

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

Список литературы:

1. Грекул В. Проектирование информационных систем. // ИНТУИТ.ру.  – 2007.  [электронный ресурс] – Режим доступа. – URL:www.intuit.ru/studies/courses/1178/330/info (дата обращения: 16.06.2016).
2. Данилин А., Слюсаренко А. Архитектура и стратегия. "Инь" и "янь" информационных технологий. М.: Интернет-университет информационных технологий, 2009.
3. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление. - М.: ИНФРА-М, 2004
4. Леоненков А.В. Самоучитель UML. – СПб.: БХВ-Петербург, 2001. – 304 с.: ил.
5. Маклаков С.В. Моделирование бизнес-процессов с AIIFusion Process Modeler. М.: Диалог-МИФИ, 2003. – 240 с.