Самые главные диаграммы

08.10.2014 12:30

Из всего многообразия диаграмм, которые используются при моделировании и разработке ПО, главными я считаю всего три.

Все они вам хорошо знакомы, хотя часто маскируются под разными названиями.

Это:

  • диаграмма последовательности действий;

  • диаграмма смены состояний;

  • диаграмма взаимодействия объектов.

Почему они главные?

Во-первых, они отражают принципы устройства современных цифровых машин. И поэтому будут жить, пока не исчезнут машины.

Во-вторых (которое проистекает из «во-первых»), они представляют набор, достаточный для моделирования любых процессов, причём на любом уровне детализации.

Давайте посмотрим на них поближе.

Диаграмма последовательности действий

Эта диаграмма известна, наверное, любому человеку с техническим образованием в образе старой доброй блок-схемы алгоритма. Состоит она из трёх основных элементов:

  • описание действия;

  • однонаправленная стрелка, показывающая последовательность действий во времени;

  • точка ветвления, из которой можно пойти разными путями, в зависимости от выполнения какого-то условия.

У этой диаграммы бесчисленное множество разновидностей и потомков — пожалуй, больше, чем у других диаграмм. К ним относятся Activity Diagram в UML, диаграммы бизнес-процессов BPMN, eEPC, IDEF3 и т. п.

Каждый разработчик новой мутации нотации добавляет к базовым трём элементам что-то своё. Обычно это что-то важное только в области применения именно этой нотации. Блок-схемы алгоритмов содержали отдельные элементы для ввода, печати и сохранения данных в БД. Нотации для бизнес-процессов включают особые элементы для обозначения событий, сигналов и ролей участников.

Каждое такое добавление сужает область применения диаграммы, и тем самым сокращает время жизни производной нотации. Но основа остаётся неизменной: действия, их последовательность и точки принятия решений.

Именно так работают центральные (и не только центральные) процессоры цифровых машин. Именно так мы пишем для них программы на высокоуровневых языках программирования. И именно так мы используем машины для автоматизации разнообразной деятельности.

Описание последовательности действий — это универсальный шаблон для представления процессов на любом уровне детализации. И поэтому эта диаграмма входит в число самых главных.

Диаграмма смены состояний

Эта диаграмма тоже знакома каждому «технарю». Её называют ещё диаграммой конечного автомата, диаграммой переходов или просто диаграммой состояний. В UML она называется State Machine Diagram.

Диаграмма включает всего два элемента:

  • описание состояния;

  • стрелка, указывающая возможный переход из одного состояния в другое.

Диаграмма тоже тесно связана с устройством вычислительных машин. Теоретически любую программу для цифровой машины можно полностью описать как последовательность смены состояний её памяти. На практике, конечно, такое описание в виде диаграммы имеет смысл только для самых простых учебных алгоритмов: у любой программы, имеющей практическое применение, общее число состояний слишком велико.

Диаграмма получила особенно широкое распространение с развитием объектно-ориентированного подхода к программированию. В ООП программа создаётся в виде набора взаимодействующих объектов, которые при взаимодействии изменяют определённым образом своё состояние. Можно смело сказать, что описание этих состояний и возможных переходов между ними составляет суть объектного моделирования. Разрабатывая класс, программист должен ясно представлять себе эту картину, и диаграмма смены состояний оказывается здесь бесценным помощником для разработки и анализа.

Применение диаграммы смены состояний, конечно, не ограничивается моделированием при разработке отдельных классов. С помощью картины состояний оказалось очень удобно моделировать объекты и процессы на разных уровнях абстракции — от самых детальных (состояния отдельно взятой переменной) до самых высоких (например, состояние переработки ядерного топлива, как показано на картинке).

Благодаря этой универсальности диаграмма тоже относится к числу самых главных.

Диаграмма взаимодействия объектов

Диаграмма взаимодействия объектов получила широкое распространение сравнительно недавно. Её популярность тоже связана с широким применением объектно-ориентированного подхода. Если диаграмма смены состояний подходит для моделирования отдельных объектов, то эта диаграмма описывает способы и порядок их взаимодействия.

Эта диаграмма несколько сложнее, чем две предыдущие. Её основными элементами являются:

  • участвующие во взаимодействии объекты с «линиями жизни» (их ещё иногда называют плавательными дорожками);

  • стрелки, показывающие взаимодействие между объектами;

  • ось времени, обозначающая последовательность взаимодействий. Даже если вы её не видите, она там есть. :) Обычно в качестве оси времени используется направление сверху вниз, поэтому её не рисуют.

Хотя основных элементов всего три, они могут обозначать разные виды взаимодействия: обмен сообщениями, вызовы методов, пересылку целых объектов и т. п. Кроме того, бывает удобно добавлять на эту диаграмму элементы других диаграмм, показывая на линиях жизни объектов действия или состояния.

Конечно, диаграмма взаимодействия объектов использовалась и до появления ООП. В частности, её активно использовали при описании сетевых протоколов взаимодействия.

В UML разновидность этой диаграммы называется диаграммой последовательности (Sequence Diagram). Это не самое удачное название. Видимо, его выбрали только потому, что к моменту включения диаграммы в стандарт UML все подходящие слова, обозначающие взаимодействие (сollaboration, сooperation, interaction), были уже заняты.

Вообще, в UML этой диаграмме не повезло. В попытке сделать её универсальной разработчики стандарта переусложнили диаграмму визуально трудноразличимыми и не всегда понятными интуитивно элементами — «столбиками» временной активности и разными типами стрелок. Возможно, поэтому некоторые аналитики её до сих пор недолюбливают.

Как и предыдущие две, эта диаграмма может использоваться для моделирования процессов на всех уровнях абстракции. С её помощью можно описывать и пересылку сообщений между объектами элементарных классов, и порядок взаимодействия целых подсистем.

 

Эти три диаграммы представляют собой основу для моделирования устройства и поведения программных (и не только) систем. Во многих случаях этого набора достаточно для анализа и описания требований. Если вы ещё не используете визуальное моделирование при разработке требований, но хотите его освоить, то начните с этих трёх диаграмм.



Автор статьи


Григорий Печёнкин

Партнёры и друзья



Продолжая использовать этот сайт, вы даете согласие на обработку файлов cookie, пользовательских данных (включая сведения о местоположении, тип и версия ОС, тип и версия браузера, тип устройства и разрешение его экрана, источник откуда пришел на сайт пользователь, с какого сайта или по какой рекламе, язык ОС и Браузера, какие страницы открывает и на какие кнопки нажимает пользователь, IP-адрес). Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте сайт. Вы можете узнать, как используются эти данные, ознакомившись с Политикой конфиденциальности.
Ясно, больше не показывать это сообщение