Два подхода к структурированию диаграммы Activity

    Сравнение двух подходов структурирования диаграммы Activity (по мотивам "Белки")


    В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.


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


    Подробнее о применяемых подходах к моделированию см. [2].


    Полную спецификацию UML см. здесь [3].


    Повторю вариант диаграммы из прошлой статьи (Рисунок 1) и покажу перерисованную диаграмму со "стандартными" дорожками (Рисунок 2), постараюсь плюсы и минусы обозначить, может быть, и немного субъективно.



    Рисунок 1. Диаграмма Activity – общий вид процесса



    Рисунок 2. Диаграмма Activity – стандартное структурирование диаграммы


    1. Нужно признать, что количество стрелок чуть меньше на 2-ой диаграмме.
    2. Но на 2-ой диаграмме объекты "размазаны" по всему полю диаграммы, что, на мой вкус, не очень удобно.
    3. Та же история с примечаниями — правилами. А еще чтобы правило про назначение дьякона вставить, пришлось все элементы диаграммы в какой-то момент двигать вниз.
    4. Пришлось клонировать шаг "приема/передачи...", чтобы показать, что несколько участников на этом шаге присутствуют.
    5. Во втором варианте пришлось отказаться от одного ветвления и одного слияния процесса, ну совершенно не получалось их "красиво" уложить! По хорошему, нужно было бы тогда повесить комментарий — правило.

    На вкус и цвет, конечно, товарищей нет, но мне первый вариант кажется еще и более удобным для сбора данных о процессе.


    Но не буду лукавить — иногда оба варианта лучше отрисовать, чтобы в процессе разобраться.


    Дополнение. Благодарю за комментарии и привожу немного видоизмененную диаграмму 2-го варианта: можно переставить дорожки (на Рисунке 2 их очередность повторяет очередность появления участников в повествовании), количество пересекающихся стрелок еще немного уменьшится (Рисунок 3).



    Рисунок 3. Диаграмма Activity – стандартное структурирование диаграммы — переставлены дорожки


    Статьи, по мотивам которых, появилась эта статья:
    От моделирования процессов к проектированию автоматизированной системы (Часть 1)
    От моделирования процессов к проектированию автоматизированной системы (Часть 2)


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

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

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

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

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

          0
          Да, мне тоже проще сначала первый вариант построить, а потом можно уже и развернуть, не показываю уже входы и выходы, например, тогда компактнее получится.
          0
          Спасибо! Добавила диаграмму с переставленными дорожками.
          0
          Спасибо, лепота)).
          Трудновато наверное белке петь с орехом в зубах. Можно развить мысль орех разгрызен -> песенки поет(сообщение обработано -> сигнализировать о готовности обработки нового сообщения).
            0
            Супер! Отличная идея! Совершенству нет предела:)
            0
            Спасибо за интересные и полезные статьи. Будет ли продолжение?
            Ещё вопрос — пользуетесь ли вы при проектировании такими концепциями как «Пользовательские истории», «User Story Mapping»?
              0
              Спасибо!
              Да, планирую добавить про StateChart и Sequence диаграммы.
              При проектировании больше ориентированы на применение отечественных ГОСТов, в основном это 34 серия, т.к. речь об автоматизированных системах. Использование ГОСТ продиктовано требованиями Заказчика, но если не придираться к несколько «устаревшей» терминологии и громадному количеству документов (нужно просто выбрать необходимое и достаточное), то практически все рекомендации наших стандартов очень разумны — умные люди составляли (это я про 34-ую серию).
              Пользовательские требования собираются в ходе моделирования бизнес-процесса.
              Про трассировку от функций системы к бизнес процессу чуть-чуть описано во 2-ой части, в планах есть описать подробнее.
                0
                Есть статья про диаграмму Sequence — спасибо Вам!
                  0
                  Спасибо) Таких примеров часто не хватает, когда пытаешься вникнуть в новую область.

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

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