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

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

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

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

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

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

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

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

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

1. скопировать текст прецедента на страницу диаграммы;

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

3. добавить граничные объекты и акторов из диаграммы пригодности (они могут отсутствовать в модели предметной области);

4. распределить методы по объектам. Контроллеры могут быть преобразованы как в сообщения и методы, реализующие нужное поведение, так и в новые управляющие объекты. Розенберг предлагает вычеркивать контроллеры на диаграмме пригодности после нанесения на диаграмму последовательности чтобы ничего не забыть;

5. обновить и проверить модель предметной области если при построении были добавлены новые управляющие объекты.

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

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

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

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

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

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

На следующем примере показан фрейм взаимодействия loop:

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

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

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

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

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

Познавательные статьи:



Где возникла философия и почему?

Относительная высота сжатой зоны бетона

Сущность проекции Гаусса-Крюгера и использование ее в геодезии

Тарифы на перевозку пассажиров