UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы
Сурьянинов, 1972
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р.
«Рассказ о моделировании именно сложных систем»
Предыстория
К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:
«Было бы здорово увидеть рассказ о моделировании именно сложных систем».
И я пообещала подобрать что-то из реальной жизни.
Несколько слов о языке моделирования, среде моделирования, методологии и соглашении по моделированию
Язык моделирования
Для моделирования применяется UML – Unified Modeling Language, унифицированный язык моделирования [1].
Среда моделирования
В качестве инструмента моделирования используется Enterprise Architect от австралийской компании Sparx Systems [2].
Подробно основные подходы описаны в [3, 4]. Методология и соглашение по моделированию
До начала проектирования необходимо установить определенные правила и подходы, которым мы будем следовать при разработке диаграмм, эти же правила будут использоваться при «чтении» диаграмм.
Этап 1. Разрабатываем карту процессов с помощью Use-case диаграммы, на нее помещаем все выявленные целевые процессы – элементы Use-case, а также участников процессов – элементы Actor, стараемся процессы сразу сгруппировать по смыслу (по возможности, конечно).
Для процесса, в котором выделено более 10 шагов, имеет смысл применить принцип декомпозиции шагов процесса, чтобы повысить читабельность диаграммы. Этап 2. Описываем каждый процесс в виде диаграммы Activity. Имя дорожки будет соответствовать типу элементов диаграммы, которые будут размещены на этой дорожке. Для диаграмм Activity нижнего уровня применяем структурирование поля диаграммы с помощью «плавательных» дорожек – Swim lanes. объекты»: на этой дорожке будут располагаться элементы Objects – объекты, которые используются или являются результатом выполнения некоторого шага процесса. «Вх./вых. «Роль»: дорожка для элементов, которые будут обозначать роли исполнителей действий в нашем процессе, для них мы будем использовать все тот же моделирующий элемент Object – объект, но добавим ему стереотип «Actor». «Деятельность»: сюда поместим элементы Activity – действия участников процесса. Дорожку «Инструменты» будем использовать для сбора сведений об уровне автоматизации процесса. Следующая дорожка называется «Правила» и на этой дорожке разместим в текстовом виде правила выполнения шагов процесса, а использовать для этого будем моделирующий элемент 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 про медицинские изделия и описании потребностей заказчика на полстраницы.
под SQL Server 2014 Express, на C#, платформа ASP. АС разработана в 2016-2017гг. В качестве дистанционных считывателей штрих-кодов применялись беспроводные сканеры Mercury CL600R. NET MVC 5, для front-end – Javascript и JQuery.
Список источников
- 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.