Из всего многообразия диаграмм, которые используются при моделировании и разработке ПО, главными я считаю всего три.
Все они вам хорошо знакомы, хотя часто маскируются под разными названиями.
Это:
диаграмма последовательности действий;
диаграмма смены состояний;
диаграмма взаимодействия объектов.
Почему они главные?
Во-первых, они отражают принципы устройства современных цифровых машин. И поэтому будут жить, пока не исчезнут машины.
Во-вторых (которое проистекает из «во-первых»), они представляют набор, достаточный для моделирования любых процессов, причём на любом уровне детализации.
Давайте посмотрим на них поближе.
Эта диаграмма известна, наверное, любому человеку с техническим образованием в образе старой доброй блок-схемы алгоритма. Состоит она из трёх основных элементов:
описание действия;
однонаправленная стрелка, показывающая последовательность действий во времени;
точка ветвления, из которой можно пойти разными путями, в зависимости от выполнения какого-то условия.
У этой диаграммы бесчисленное множество разновидностей и потомков — пожалуй, больше, чем у других диаграмм. К ним относятся Activity Diagram в UML, диаграммы бизнес-процессов BPMN, eEPC, IDEF3 и т. п.
Каждый разработчик новой мутации нотации добавляет к базовым трём элементам что-то своё. Обычно это что-то важное только в области применения именно этой нотации. Блок-схемы алгоритмов содержали отдельные элементы для ввода, печати и сохранения данных в БД. Нотации для бизнес-процессов включают особые элементы для обозначения событий, сигналов и ролей участников.
Каждое такое добавление сужает область применения диаграммы, и тем самым сокращает время жизни производной нотации. Но основа остаётся неизменной: действия, их последовательность и точки принятия решений.
Именно так работают центральные (и не только центральные) процессоры цифровых машин. Именно так мы пишем для них программы на высокоуровневых языках программирования. И именно так мы используем машины для автоматизации разнообразной деятельности.
Описание последовательности действий — это универсальный шаблон для представления процессов на любом уровне детализации. И поэтому эта диаграмма входит в число самых главных.
Эта диаграмма тоже знакома каждому «технарю». Её называют ещё диаграммой конечного автомата, диаграммой переходов или просто диаграммой состояний. В UML она называется State Machine Diagram.
Диаграмма включает всего два элемента:
описание состояния;
стрелка, указывающая возможный переход из одного состояния в другое.
Диаграмма тоже тесно связана с устройством вычислительных машин. Теоретически любую программу для цифровой машины можно полностью описать как последовательность смены состояний её памяти. На практике, конечно, такое описание в виде диаграммы имеет смысл только для самых простых учебных алгоритмов: у любой программы, имеющей практическое применение, общее число состояний слишком велико.
Диаграмма получила особенно широкое распространение с развитием объектно-ориентированного подхода к программированию. В ООП программа создаётся в виде набора взаимодействующих объектов, которые при взаимодействии изменяют определённым образом своё состояние. Можно смело сказать, что описание этих состояний и возможных переходов между ними составляет суть объектного моделирования. Разрабатывая класс, программист должен ясно представлять себе эту картину, и диаграмма смены состояний оказывается здесь бесценным помощником для разработки и анализа.
Применение диаграммы смены состояний, конечно, не ограничивается моделированием при разработке отдельных классов. С помощью картины состояний оказалось очень удобно моделировать объекты и процессы на разных уровнях абстракции — от самых детальных (состояния отдельно взятой переменной) до самых высоких (например, состояние переработки ядерного топлива, как показано на картинке).
Благодаря этой универсальности диаграмма тоже относится к числу самых главных.
Диаграмма взаимодействия объектов получила широкое распространение сравнительно недавно. Её популярность тоже связана с широким применением объектно-ориентированного подхода. Если диаграмма смены состояний подходит для моделирования отдельных объектов, то эта диаграмма описывает способы и порядок их взаимодействия.
Эта диаграмма несколько сложнее, чем две предыдущие. Её основными элементами являются:
участвующие во взаимодействии объекты с «линиями жизни» (их ещё иногда называют плавательными дорожками);
стрелки, показывающие взаимодействие между объектами;
ось времени, обозначающая последовательность взаимодействий. Даже если вы её не видите, она там есть. :) Обычно в качестве оси времени используется направление сверху вниз, поэтому её не рисуют.
Хотя основных элементов всего три, они могут обозначать разные виды взаимодействия: обмен сообщениями, вызовы методов, пересылку целых объектов и т. п. Кроме того, бывает удобно добавлять на эту диаграмму элементы других диаграмм, показывая на линиях жизни объектов действия или состояния.
Конечно, диаграмма взаимодействия объектов использовалась и до появления ООП. В частности, её активно использовали при описании сетевых протоколов взаимодействия.
В UML разновидность этой диаграммы называется диаграммой последовательности (Sequence Diagram). Это не самое удачное название. Видимо, его выбрали только потому, что к моменту включения диаграммы в стандарт UML все подходящие слова, обозначающие взаимодействие (сollaboration, сooperation, interaction), были уже заняты.
Вообще, в UML этой диаграмме не повезло. В попытке сделать её универсальной разработчики стандарта переусложнили диаграмму визуально трудноразличимыми и не всегда понятными интуитивно элементами — «столбиками» временной активности и разными типами стрелок. Возможно, поэтому некоторые аналитики её до сих пор недолюбливают.
Как и предыдущие две, эта диаграмма может использоваться для моделирования процессов на всех уровнях абстракции. С её помощью можно описывать и пересылку сообщений между объектами элементарных классов, и порядок взаимодействия целых подсистем.
Эти три диаграммы представляют собой основу для моделирования устройства и поведения программных (и не только) систем. Во многих случаях этого набора достаточно для анализа и описания требований. Если вы ещё не используете визуальное моделирование при разработке требований, но хотите его освоить, то начните с этих трёх диаграмм.
Введение в профессию аналитика 2 900 руб. | |
Введение в профессию аналитика (демо) Бесплатно | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 999 руб. | |
SQL для непрограммистов Бесплатно |