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

В UML взаимодействие объектов понимается как обмен информацией между ними. При этом информация принимает вид сообщений. Кроме того, что сообщение несет какую-то информацию, оно некоторым образом также влияет на получателя. Как видим, в этом плане UML полностью соответствует основным принципам ООП, в соответствии с которыми информационное взаимодействие между объектами сводится к отправке и приему сообщений.

Диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Диаграмма последовательностей показывает последовательность, в которой объекты в процессе взаимодействия обмениваются сообщениями.

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

Диаграмма последовательности имеет два измерения (рис. 30). Одно – слева направо в виде последовательности объектов. Второе измерение – вертикальная временная ось, направленная сверху вниз. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим.

Рис. 30. Графические примитивы диаграммы последовательности

Объект - это просто прямоугольник, внутри которого указаны подчеркнутые имя объекта и название класса (не обязательно), разделенные двоеточием. Объекты располагаются в верхней части диаграммы друг за другом. А вниз от каждого объекта тянется пунктирная линия, которую называют линией жизни объекта. Линия жизни объекта - это линия, которая изображает существование объекта на протяжении некоторого промежутка времени, и чем длиннее линия, тем дольше существует объект.

Объект является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретные значения атрибутов. Для обозначения роли классификатора небходимо указать либо имя класса (вместе с двоеточием), либо имя роли (вместе с наклонной чертой).

<собственное имя объекта> '/'<Имя роли классификатора> :<Имя классификатора> [','<Имя классификатора>].

Здесь элементы Имя роли классификатора и Имя классификатора аналогичны рассмотренным выше, а вся запись имени объекта подчеркивается. Если указано собственное имя объекта, то оно должно начинаться со строчной буквы. В этом формате, как правило, имя роли классификатора записывается только при наличии собственного имени объекта на уровне примеров.В отдельных случаях собственное имя объекта может отсутствовать. Такой объект принято называть анонимным, при этом обязательно записывается двоеточие перед именем соответствующего класса. Отсутствовать может и имя класса – такой объект называется сиротой. Для него записывается только собственное имя объекта, а двоеточие и имя класса не указываются. Если для объектов указываются атрибуты, то в большинстве случаев они принимают конкретные значения. Для объектов дополнительно указаны роли, которые они играют в кооперации.Таким образом, на диаграммах кооперации уровня примеров могут встретиться следующие варианты возможных записей имен объектов:

о : С – объект с собственным именем о, образуемый на основе класса С;

: С – анонимный объект, образуемый на основе класса С;

о : (или просто о) – объект-сирота с собственным именем о;

о / R : С – объект с собственным именем о, образуемый на основе класса С и играющий роль R;

/ R : С – анонимный объект, образуемый на основе класса С и играющий роль R;

о / R – объект-сирота с собственным именем о, играющий роль R;

/ R – анонимный объект и одновременно объект-сирота, играющий роль R.

Рис. 35. Примеры графических изображений объектов на диаграммах кооперации уровня примеров

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

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то его линия жизни должна начинаться в верхней части диаграммы и заканчиваться в нижней части (объекты 1 и 2 на рис. 30). Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы “X” (объект 3 на рис. 30). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность (объект 6 на рис. 31).

Рис. 31. Варианты линий жизни и фокусов управления объектов

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

Сообщения, которыми обмениваются объекты, изображаются в виде стрелок с именем сообщения, направленных от линии жизни одного объекта к линии жизни другого. Линии жизни объектов, тянущиеся вниз, играют роль шкалы времени, так что сообщения, отправленные ранее, расположены выше, чем отправленные позже. Таким образом, последовательность сообщений легко читается "сверху вниз". Мы рассматриваем сообщение как спецификацию передачи информации от одного объекта к другому. Объект отправляет сообщение в расчете на то, что оно вызовет некую реакцию и за этим последует некоторая деятельность.

У каждого сообщения должно быть имя, соответствующее его цели. Существует несколько видов сообщений. (рис. 32).

Рис. 32. Примеры сообщений

Простое(call) сообщение используется по умолчанию. Означает, что все сообщения выполняются в одном потоке управления (рис. 32, 1).

Синхронное (synchronous) применяется, когда клиент посылает сообщение и ждет ответа пользователя (рис. 32, 2).

Сообщение с отказом становиться в очередь (waitили balking): клиент посылает сообщение серверу и, если сервер не может немедленно принять сообщение, оно отменяется (рис. 32, 3).

Сообщение с лимитированным временем ожидания (nowait илиtimeout): клиент посылает сообщение серверу, а затем ждет указанное время; если в течение этого времени сервер не принимает сообщение, оно отменяется (рис. 32, 4).

Асинхронное сообщение (asynchronous): клиент посылает сообщение серверу и продолжает свою работу, не ожидая подтверждения о получении (рис. 32, 5).

И еще одно - мы легко можем представить ситуацию посылки сообщения в зависимости от истинности некоторого условия. Например, если цена приглянувшейся нам в магазине вещи меньше ста условных единиц, мы вполне можем приобрести ее за наличные. Покупку на сумму от 100 до 1000 долларов можно оплатить кредитной картой, а чтобы купить нечто, стоящее дороже 1000 у. е., придется брать кредит. А как изобразить такие ситуации (ветвления) на диаграмме последовательностей? Да легко (рис. 5.5)!

Рис. 5.5.

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

Ранее мы говорили, что сообщение посылается объектом в расчете на определенную реакцию, на то, что за этим последует некоторая деятельность. Например, посылка ответного сообщения. А как на диаграммах последовательностей изображаются ответные сообщения? Обычно их изображают пунктирной линией со стрелкой, хотя часто они имеют точно такой же вид, как и обычные сообщения, только направлены в противоположную сторону. Как именно их рисовать - пунктирной линией или сплошной - решать вам. Это абсолютно не принципиально (рис. 5.6).

Рис. 5.6.

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

Рис. 5.4.

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

Примеры диаграмм последовательности

Пример сценария снятия 20$ со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. 33.

Эта диаграмма последовательности отображает поток событий в рамках варианта использования “Снять деньги”. В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования “Снять деньги”. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме Последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме Последовательности представлен конкретный клиент Джо.

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения – этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект “счет” (account) и инициализирует экран ATM. Экран запрашивает у клиента его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта “счет” и обнаруживает, что он правильный. Затем экран предоставляет клиенту меню для выбора, и тот выбирает пункт “Снять деньги”. Экран запрашивает, сколько он хочет снять, и клиент указывает 20$. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом “счет”. Во-первых, осуществляется проверка, что на этом счету лежат, по крайней мере, 20$. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать чек и $20 наличными. Наконец все тот же объект “счет ” дает устройству для чтения карточек инструкцию вернуть карточку.

Рис. 33. Диаграмма последовательности для снятия клиентом 20$

Таким образом, диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования “Снять деньги со счета” на примере снятия клиентом 20$. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики – объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

Пример модели процесса телефонного разговора между двумя абонентами изображен на рисунке 34.

Рис. 34. Модель процесса телефонного разговора