UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы02.05.2019 08:18

Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

«Рассказ о моделировании именно сложных систем»

Предыстория

К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:

«Было бы здорово увидеть рассказ о моделировании именно сложных систем».

И я пообещала подобрать что-то из реальной жизни.

Несколько слов о языке моделирования, среде моделирования, методологии и соглашении по моделированию

Язык моделирования
Для моделирования применяется UML — Unified Modeling Language, унифицированный язык моделирования [1].

Среда моделирования
В качестве инструмента моделирования используется Enterprise Architect от австралийской компании Sparx Systems [2].

Методология и соглашение по моделированию
До начала проектирования необходимо установить определенные правила и подходы, которым мы будем следовать при разработке диаграмм, эти же правила будут использоваться при «чтении» диаграмм. Подробно основные подходы описаны в [3, 4].

Этап 1. Разрабатываем карту процессов с помощью Use-case диаграммы, на нее помещаем все выявленные целевые процессы — элементы Use-case, а также участников процессов — элементы Actor, стараемся процессы сразу сгруппировать по смыслу (по возможности, конечно).

Этап 2. Описываем каждый процесс в виде диаграммы Activity. Для процесса, в котором выделено более 10 шагов, имеет смысл применить принцип декомпозиции шагов процесса, чтобы повысить читабельность диаграммы. Для диаграмм Activity нижнего уровня применяем структурирование поля диаграммы с помощью «плавательных» дорожек — Swim lanes. Имя дорожки будет соответствовать типу элементов диаграммы, которые будут размещены на этой дорожке. «Вх./вых. объекты»: на этой дорожке будут располагаться элементы Objects — объекты, которые используются или являются результатом выполнения некоторого шага процесса. «Деятельность»: сюда поместим элементы Activity — действия участников процесса. «Роль»: дорожка для элементов, которые будут обозначать роли исполнителей действий в нашем процессе, для них мы будем использовать все тот же моделирующий элемент Object — объект, но добавим ему стереотип «Actor». Следующая дорожка называется «Правила» и на этой дорожке разместим в текстовом виде правила выполнения шагов процесса, а использовать для этого будем моделирующий элемент Note — примечание. Дорожку «Инструменты» будем использовать для сбора сведений об уровне автоматизации процесса.

Этап 3. Выделяем то, что можно автоматизировать. У нас будет три типа шагов: ручное выполнение, автоматизированное и полностью автоматическое.

Этап 4. Автоматизируемому шагу нужно поставить в соответствие функцию или функции системы (отношение может быть многие-ко-многим), рисуем Use-case диаграмму. Это функции нашей системы.

Этап 5. Опишем внутреннюю организацию системы с помощью диаграммы классов — Class. Плавательная дорожа «Вх./вых. объекты» на диаграмме Activity — это основа для построения объектной модели и модели сущность-связь.

Этап 6. Проанализируем заметки на дорожке «Правила», они дают различного рода ограничения и условия, которые постепенно трансформируется в нефункциональные требования.

Этап 7. Элементы на дорожке «Инструменты» говорят нам об уровне автоматизации процесса.
Полученная совокупность диаграмм дает формализованное описание в достаточно строгой нотации, т.е. имеет однозначное прочтение. Теперь можно разрабатывать техническое задание, уточнять спецификацию требований и т.д.

Моделирующие элементы диаграммы Use-case для карты процессов

Моделирующие элементы диаграммы Activity

Краткие сведения об объекте автоматизации

Объектом автоматизации являются процессы обеспечения качества производства медицинских изделий.

Процесс изготовления медицинских изделий характеризуется наличием большого количества ручных операций. Управление качеством регламентировано в соответствии со стандартом ГОСТ ISO 13485–2011. Изделия медицинские. Системы менеджмента качества. Системные требования для целей регулирования.

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

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

Разрабатываемая автоматизированная система (АС) контроля изготовления медицинских изделий предназначена для:

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

Карта процессов — диаграмма Use-case

На Рисунке 1 представлена карта процессов АС контроля изготовления медицинских изделий. Зеленым цветом выделены процессы, для которых далее будут приведены сценарии выполнения.

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

Примеры сценариев выполнения процессов — диаграммы Activity

На Рисунках 2–5 представлены примеры сценариев выполнения процессов АС контроля изготовления медицинских изделий.

Рисунок 2. Подготовка к работе (начало смены)

Рисунок 3. Изготовление мед. изделия (макрошаги)

Рисунок 4. Начало изготовления мед.изделия

Рисунок 5. Изготовление мед.изделия

Жизненный цикл объекта — диаграмма State Chart

На диаграммах Activity состояния обозначены в квадратных скобках до или после имен объектов.

Полный жизненный цикл изготовления медицинского изделия представлен на диаграмме состояний — State Chart (Рисунок 6).

Рисунок 6. Диаграмма состояний изготовления мед.изделия

Структура системы

Система логически разделена на подсистемы по функциональному признаку:

Подсистема «Изготовление мед.изделий»;
Подсистема «Справочники и реестры (НСИ)»;
Подсистема «Мониторинг и контроль» (включая модули «Мониторинг технологических операций» и «Отчетность»);
Подсистема «Безопасность»;
Подсистема «Администрирование».

Автоматизируемые процессы в разрезе подсистем и модулей представлены на рисунке ниже (Рисунок 7).

Рисунок 7. Автоматизируемые процессы в разрезе подсистем и модулей

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

Вместо заключения

Когда приступали к разработке системы, знания о предметной области основывались только на упомянутом в начале ГОСТ ISO 13485–2011 про медицинские изделия и описании потребностей заказчика на полстраницы. Модели обсуждали с заказчиком, особых трудностей в «чтении» моделей не наблюдалось.

АС разработана в 2016–2017 гг. под SQL Server 2014 Express, на C#, платформа ASP.NET MVC 5, для front-end — Javascript и JQuery. В качестве дистанционных считывателей штрих-кодов применялись беспроводные сканеры Mercury CL600R.

Список источников

OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Электронный ресурс] Режим доступа: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF
Сайт Sparx Systems. [Электронный ресурс] Режим доступа: Интернет: https://sparxsystems.com
Свидетельство № 18249 о регистрации и депонировании произведения результата интеллектуальной деятельности. Алфимов Р.В., Золотухина Е.Б., Красникова С.А. Рукопись учебно-методического пособия под названием «Моделирование предметной области с использованием Enterprise Architect» // 2011 г.
Золотухина Е.Б., Вишня А.С., Красникова С.А. Моделирование бизнес-процессов. — М.: КУРС, НИЦ ИНФРА-М, ЭБС Znanium.com. — 2017.