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


    Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 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.


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


    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.
    Поделиться публикацией

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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 10

      0
      Спасибо за статью.
      Прочел ваши предыдущие статьи и все равно не понимаю, почему у вас действия Актантов (или Акторов) в диаграмме активности не в виде дорожек, а так как вы представили? Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
      Можно будет еще раз немного поподробнее рассказать по данный выбор и не нарушает ли он нотацию?
        0
        ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?

        Есть разные варианты нотаций. А есть нюансы EA в отображении диаграмм :)
        И есть более удобные способы отображения процессов
          0
          Заметки по поводу использования Swimlanes — «Плавательных дорожек»

          Для начала цитаты из документации UML и EA.

          UML
          Цитата:
          15.6.4.1 Activity Partitions
          An ActivityPartition is notated with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any ActivityNodes and ActivityEdges placed between these lines are considered to be contained within the partition. This notation for an ActivityPartition is colloquially known as a swimlane, as shown in Figure 15.66(a). Swimlanes can express hierarchical partitioning by representing the subpartitions as further partitioning of the superpartition, as illustrated in Figure 15.66(b). Diagrams can also be partitioned multidimensionally, as depicted in Figure 15.66©, where each «swim cell» is an intersection of multiple partitions.

          Перевод цитаты:
          15.6.4.1 Разделы диаграммы Activity
          ActivityPartition обозначается двумя, обычно параллельными линиями, горизонтальными или вертикальными, и именем, обозначающим раздел в поле на одном конце. Любые моделирующие элементы ActivityNodes и ActivityEdges, размещенные между этими линиями, считаются содержащимися в этом разделе. Это обозначение для ActivityPartition, в просторечии известное как swimlane, как показано на рисунке 15.66(a). Плавательные дорожки могут выражать иерархическое разделение, представляя подразделы как дальнейшее разделение, как показано на рис.15.66(b). Диаграммы также могут быть разделены многомерно, как показано на рисунке 15.66 ©, где каждая «swim cell», «плавательная ячейка», является пересечением нескольких разделов.

          И только в одном примечании в документации UML есть довольно явное указание на использование дорожек (п.15.2.5, стр.383):
          Еще одна цитата:
          NOTE. The swimlanes are an important feature for indicating senders and responders.

          И ее перевод
          ПРИМЕЧАНИЕ. Плавательные дорожки являются важной особенностью (возможностью/ характеристикой) [языка] для обозначения отправителей и получателей [сообщений/ информации/ потока управления].


          ЕА
          Цитата:
          Swimlanes are vertical or horizontal bands in a diagram that divide the diagram into logical areas or partitions. You can apply them to all Enterprise Architect diagram types. Activities relating to particular entities within the model (such as the User, or the back end Repository) can be placed within the same Swimlane to indicate their association.

          Перевод цитаты
          «Плавательные дорожки» — это вертикальные или горизонтальные полосы на диаграмме, которые разделяют диаграмму на логические области или разделы. Их можно применить ко всем типам диаграмм Enterprise Architect. Действия, относящиеся к определенной сущности в модели (например, пользователь или серверное хранилище), могут быть помещены на одну и ту же дорожку, чтобы показать их связь с данной сущностью.


          Смотрите, что получается: в документации ЕА приведен пример «специализации» дорожек – «Действия, закрепленные за сущностями». Но это только один из способов структурирования диаграммы! Мы не нарушим нотацию, если закрепим за дорожками другие «специализации», например, такие: «Входные и выходные артефакты», «Шаги процесса», «Участники процесса» и т.д.
          Нет на этот счет запретов ни в языке, ни в инструменте! Попробуйте! А вдруг Вам тоже такой способ структурирования подойдет?
          Диаграммы Activity в моих примерах используются для сбора информации о процессе, который мы будем автоматизировать и о котором мы, когда приступаем к работе, не очень много знаем (т.е. если Вы разрабатываете 1001-ую систему для данной предметной области, оно Вам, может, и не нужно, хотя и в этом случае — не факт). По отношению к процессу мы выступаем в роли сторонних наблюдателей, собираем информацию: кто и что делает, в какой последовательности, что использует для работы, какие документы использует, а какие «порождает», есть ли доп.правила, при этом стараемся сразу структурировать добытую информацию — раскладываем по полочкам — Swimlanes нам в помощь. Такое формализованное описание процесса поможет нам выявить требования к будущей системе.

          Не пытаюсь никого «обратить в свою веру», но призываю не следовать слепо «догме», тем более, что судя по документации ее и нет вовсе:)

          И еще маленький комментарий вот на это замечание:
          Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?

          Ваше замечание как раз перекликается со 2-ой цитатой из документации UML (см.выше).
          И такой подход к структурированию диаграммы Activity: «Действия пользователя», «Действия системы», — мы тоже периодически применяем в своих проектах, но уже на следующих этапах проектирования, когда описываем автоматизированные функции (как правило, это происходит на этапе эскизного или технического проекта).

          P.S. Очень хотелось схулиганить и написать в заметке: «Вы просто поверьте, а поймете потом».:) Но взяла себя в руки и написала более серьезный обоснованный ответ.


          P.P.S. Кажется, набирается материал на самостоятельную статью.:) Спасибо Вам!

          0
          Спасибо за статью! Реальные примеры всегда интереснее вымышленных.
          Не пробовали оценить, насколько моделирование UML вообще необходимо?
          Что проще в данном случае? Написать классическое ТЗ и броситься в бой? Или модели дают реальный выхлоп? Является ли модель заменой ТЗ или по модели затем сочиняется ТЗ?
            0
            Нет, без ТЗ никак, модель не может заменить ТЗ. На мой взгляд, модель позволяет систематизировать собранную информацию о том, что собираемся автоматизировать, и помогает написать адекватное ТЗ. Диаграммы, как правило, в ТЗ тоже приводим, а еще с помощью макросов, например, можно сгенерировать кое-какое дополнительное описание по модели. Можно, конечно, и просто текстовое описание процесса дать, но, по мне, так с помощью диаграмм нагляднее получается. Но это все безусловно дело вкуса и привычки. Если моделирование занимает много времени, ну, значит, или инструмент не тот выбрали, или методика хромает. У меня в статьях: и про «сказки», и про реальную жизнь, — предусматривается переход от шагов процесса к требованиям и функциям системы, при этом трассировка сама собой получается — всегда понятно, та или иная функция с чего вдруг «придумана». Но не могу сказать, что сначала модель, а только потом ТЗ. Модель начинаем разрабатывать до написания ТЗ, а потом продолжаем развивать, добавляя архитектурные аспекты. Резюмирую: модель и классическое ТЗ друг другу не противопоставляем, а стараемся взаимополезно сочетать.
              0
              А есть ли минимальный размер проекта, с которого целесообразно заниматься моделированием? Просто моделирование для простых проектов выглядит моделью ради модели.
                0
                Или модели дают реальный выхлоп?

                Что мешает собрать модель и после сгенерирвать код, сэкономив время

                Является ли модель заменой ТЗ или по модели затем сочиняется ТЗ?

                смотря на какой стадии: «что есть» или «как нужно».
                  0
                  Что мешает собрать модель и после сгенерирвать код, сэкономив время

                  Что такое генерация кода по модели? Каркасы классов накидать и заглушек методов повставлять?
                  0
                  А что значит «простой» проект?
                  Здесь скорее «типовой» — «не типовой». Повторюсь немного: если мы разрабатываем 1001-ую систему для данной предметной области, или переносим систему на 1001-ую платформу, или разрабатываем систему, для которой есть почти 100% аналог, то вряд ли будем отрисовывать весь процесс, скорее только на какие-то нюансы внимание обратим.
                  А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель? В идеале разработка модели и составление текстового описания (продуманного) по трудоемкости не должны сильно отличаться.
                    +1
                    А что значит «простой» проект?

                    Некая выбранная мера сложности. Например, количество сущностей (или классов, юз-кейсов, акторов и т.д.).

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

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое