Хабрахабр

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.

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

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

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»