Основы UML. Диаграммы последовательности

Диаграммы последовательности (sequence diagram) являются видом диаграмм взаимодействия языка UML, которые описывают отношения объектов в различных условиях. Условия взаимодействия задаются сценарием, полученным на этапе разработки диаграмм вариантов использования [1]. Существуют различные взгляды на применение этого вида диаграмм:

  • Фаулер предлагает строить диаграммы последовательности для визуализации наиболее сложных отношений на диаграмме классов [2];
  • Буч рассматривает их в качестве альтернативы диаграмм объектов и использует для анализа семантики сценариев на ранних стадиях проектирования (до создания протоколов отдельных классов) [3];
  • Розенберг строит диаграммы последовательности в рамках процесса ICONIX, поэтому они строятся для каждого прецедента (а не только для наиболее интересных отношений, как у Фаулера). В процессе ICONIX разработке этого вида диаграмм предшествует построение диаграмм робастности (пригодности), поэтому уже выделены объекты, участвующие в прецеденте [4].

Рассмотрим этот вид диаграмм на примере главной последовательности сценария добавления ученика в систему:

 

add-student-sequence-diagram

Пример: диаграмма последовательности сценария добавления ученика в систему тестирования

По приведенной диаграмме можно проследить следующие правила построения:

  • текст последовательности действий прецедента наносится в виде комментария;
  • объекты подписываются в формате “объект:класс” и размещаются по горизонтали. Могут изображаться как в виде обычных прямоугольников, так и с использованием обозначений, взятых с диаграммы пригодности (граничный объект, актор,, процесс, сущностный объект);
  • время жизни объектов изображается вертикальными пунктирными линиями, выходящими из объектов снизу;
  • сообщения (отражают взаимодействие, в том числе вызов функций), изображаются горизонтальными стрелками, концы которых располагаются на линиях жизни. Стрелки направлены от отправителя к адресату и упорядоченны по времени с помощью линии жизни;
  • интервалы активности объектов отражают периоды, который методы объектов находится в стеке (обычно между получением фокуса управления и завершением обработки). В ряде случаев интервалы активности позволяют различать на диаграмме с чем связана активность (какой метод инициирует передачу сообщений), в остальных случаях их можно опустить (как у виджета добавления студента), т.к. их рисование довольно трудоемко.
  • вложенные друг в друга интервалы активности отражают самовызов, т.е. объект главного окна в обработчике сигнала от базы данных вызывает метод show. Оба метода в какой-то момент оказываются в стеке, поэтому один интервал активности изображается поверх другого. Часто такие детали опускаются;
  • создание объекта изображается на диаграмме стрелкой, входящей в символ объекта, а уничтожение – крестом на линии жизни (увидеть это можно на объекте addStudentScreen).

Кроме того, на ней показаны три основных вида стрелок (сообщений):

  • синхронные (например вызов функции, вызывающий код получает управление после того, как сообщение будет обработано) изображаются сплошной линией с закрытой стрелкой. Меню добавления студента вызывает функцию проверки логина у объекта базы данных и дожидается ответа;
  • асинхронные (управление возвращается немедленное после передачи сообщения, т.е. сообщение инициирует обработку, но отправитель не дожидается ее завершения) – сплошная линия с открытой стрелкой. В случае успешного добавления студента база данных асинхронно уведомляет подписчиков (см. шаблон проектирования Модель-Вид-Контроллер [5]);
  • ответ на сообщение (результат вычислений) – штриховая линия с открытой стрелкой. В случае если логин не занят, метод базы данных возвращает “login is free“.

При построении диаграммы последовательности обязанности распределяются между объектами (и классами), например мы решили, что база данных будет выступать в роли модели и уведомлять своих подписчиков об изменениях, однако эту же роль мог выполнить объект экрана добавления студента. Внести изменения в диаграмму значительно проще, чем в исходный код. Буч строит этот вид диаграмм сразу после описания вариантов использования, при этом он решает сразу две задачи – выделяет объекты и распределяет между ними ответственность, однако в процессе ICONIX к диаграммам последовательности переходят после построения диаграмм пригодности, т.е. уже выделены объекты, необходимые для реализации прецедента. Процесс построения при этом сводится к четырем шагам:

  1. скопировать текст прецедента на страницу диаграммы;
  2. добавить сущностные объекты с диаграммы пригодности. Каждый из них является экземпляром класса, изображенного на диаграмме классов (модель предметной области). В процессе ICONIX при этом предлагается проверить модель предметной области и добавить в нее пропущенные объекты;
  3. добавить граничные объекты и акторов из диаграммы пригодности (они могут отсутствовать в модели предметной области);
  4. распределить методы по объектам. Контроллеры могут быть преобразованы как в сообщения и методы, реализующие нужное поведение, так и в новые управляющие объекты. Розенберг предлагает вычеркивать контроллеры на диаграмме пригодности после нанесения на диаграмму последовательности чтобы ничего не забыть;
  5. обновить и проверить модель предметной области если при построении были добавлены новые управляющие объекты.

В нашем случае на диаграмме был оставлен контроллер, т.е. введен новый управляющий объект отображения уведомления о том, что студент был добавлен в базу. Мы, конечно, могли бы добавить этот функционал в виджет главного меню (наиболее простое решение), введение дополнительного объекта не только является более гибким решением, но и позволит снять с меню лишние обязанности, т.е. сделать код более чистым с точки зрения принципа единой обязанности – SRP [6].

Видно, что приведенная диаграмма очень хорошо отражает взаимодействие объектов, однако прецеденты могут содержать предусловия (требования, которые должны быть выполнены для начала выполнения действий прецедента) – они могут быть показаны при помощи механизма использования взаимодействий. Этот механизм позволяет указать что повторно используется какое-либо взаимодействие, определенное в другом месте, изображается с помощью метки ref. Так, можно показать, что до выполнения прецедента учитель должен войти в систему (выполнить прецедент login) и открыть окно главного меню:

sequence-diagram-ref

Механизм использования взаимодействий диаграмм последовательности (метка ref)

Фреймы взаимодействия могут использоваться для изображения параллельных секций, при этом часть сообщений рисуются внутри фрейма par, так например, мы могли бы показать, что база данных уведомляет параллельно всех трех подписчиков и все они параллельно и независимо друг от друга начинают работать:

sequence-diagram-par-section

Пример использования фрейма взаимодействия par

Существуют также фреймы для изображения условных конструкций (alt, opt), циклов (loop) и критических секций (critical). Ветвление при этом использовать не рекомендуется, т.к. для изображения деталей алгоритмов в языке UML есть диаграммы деятельности, а Фаулер в таких случаях даже считает также обоснованным использование псевдокода.

Фаулер рекомендует строить диаграммы последовательностей не только при проектировании, но и на этапе рефакторинга если требуется заменить централизованную обработку децентрализованной (более гибкой), т.к. этот вид диаграмм является лучшим способом распределения обязанностей. Также, они часто используются при объяснении каких-либо деталей проекта другим участникам, т.к. этот вид диаграмм быстро строится с нужной степенью детализации на маркерной доске. На следующем примере показан фрейм взаимодействия loop:

sequence-erlang-process-example

Пример использования фрейма loop

На приведенной диаграмме показано взаимодействие процессов – главный процесс (go) после запуска создает дочерний (loop), затем в цикле посылает ему свой идентификатор (self())и некоторое сообщение (Msg). Дочерний процесс отправляет назад сообщение, но уже со своим идентификатором. Внутри части фрейма loop подписывается условие выхода из цикла – в данном случае пересылка сообщений продолжается до тех пор, пока Msg не станет равно “stop”. После цикла главный процесс отправляет дочернему сообщение stop, которое является сигналом завершения процесса.

Последний пример показывает, что диаграммы последовательностей удобно использовать не только при проектировании архитектуры приложений, но и для описания взаимодействия процессов/потоков. Визуальное представление в таких случаях гораздо проще воспринимается, чем текстовое описание.

Таким образом, диаграммы вариантов использования могут очень широко применяться при разработке программного обеспечения:

  • в процессе ICONIX они используются для анализа диаграмм робастности – при их построении детально исследуется взаимодействие объектов, дополняется модель предметной области. Точно также они строятся в процессе RUP, однако в нем отсутствует диаграмма робастности. Построение этого вида диаграмм сильно облегчает переход к следующему этапу проектирования – построению диаграммы классов, т.к. ее каркас можно получить автоматически – участники преобразуются в классы, а сообщения – в функции;
  • диаграмма является очень наглядной, поэтому может выступать в качестве документации;
  • с использованием нотации диаграммы могут вестись обсуждения деталей проекта в команде, т.к. она является очень простой (разобраться с ней может неподготовленный человек);
  • может применяться не только на этапе проектирования, но и во многих других случаях, выражаемых сценарием использования – например для визуализации сетевого или межпроцессного взаимодействия.

Литература по UML и ICONIX

  1. Основы UML – диаграммы использования (use-case).- URL: https://pro-prof.com/archives/2594
  2. Фаулер М., Скотт К UML. Основы СПб.: Символ, 2006, 184 с.
  3. Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
  4. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
  5. Паттерны MVC и Publish-Subscriber.- URL: https://pro-prof.com/archives/2400
  6. SOLID принципы. Рефакторинг: https://pro-prof.com/archives/1914

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

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

Вы не робот? *