21. Динамические модели объектно-ориентированного представления программных систем: диаграммы взаимодействия и Use Case

Динамические модели обеспечивают представление поведения систем. «Динамизм» этих моделей состоит в том, что в них отражается изменение состояний в процессе работы системы (в зависимости от времени). Средства языка UML для создания динамических моделей многочисленны и разнообразны. Эти средства ориентированы не только на собственно программные системы, но и на отображение требований заказчика к поведению таких систем.

Диаграммы взаимодействия

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

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

Данный подход будет проиллюстрирован на примере простого варианта использования, который описывает следующее поведение:

• «Менеджер» запрашивает текущий «Отчет» «Исполнителя»;

• если «Отчет» устарел, «Менеджер» посылает запрос «Исполнителю» на обновление «Отчета»;

• «Исполнитель» создает новый «Отчет»;

• «Менеджер» делает повторный запрос «Отчета».

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии

Эта вертикальная линия называется линией жизни объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

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

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

взаимодействующими при выполнении определенной задачи, что сложно определить из диаграммы

последовательности. Кроме того, диаграммы сотрудничества помогают определить точность вашей

статической модели (то есть, диаграммы класса). Некоторые разработчики создают статические модели

своих бизнес-объектов, но не подтверждают их построением соответствующих динамических моделей.

Если же рассматривать классы в действии (или взаимодействии), можно сразу увидеть недостатки

статической модели, ранее не обнаруженные.

Линии соединения между объектами в диаграмме сотрудничества – это связи. Они, как раз, и отображают

отличие диаграммы сотрудничества от диаграммы последовательности действий. Связи дают возможность

видеть отношения между объектами. Каждая связь представляет отношения между объектами и

символизирует способность объектов посылать сообщения друг другу. Связь может поддерживать одно

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

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

посланные от одного объекта к другому. Визуальное представление связи - прямая линия между двумя объектами.

Сообщения в диаграммах сотрудничества изображаются стрелками, ведущими от объекта-клиента к

объекту-поставщику. Как правило, сообщения представляют вызов клиентом операции на объекте-

поставщике.

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

Сообщение состоит из текста сообщения и предшествующей последовательности чисел, которая

обозначает порядок следования данного сообщения во времени

Фокус управления. В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.

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

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

Диаграмма Use Case определяет поведение системы с точки зрения пользователя. Она рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку. Диаграммы Use Case часто называют диаграммами прецедентов или вариантов использования.

В состав диаграмм Use Case входят элементы Use Case, актеры, отношения зависимости, обобщения и ассоциации, примечания и ограничения и пакеты.

Актер – это роль объекта вне системы, который прямо взаимодействует с ее частью – конкретным элементом (элементом Use Case). Различают актеров и пользователей.

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

Элемент Use Case – это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат.

Один актер может использовать несколько элементов Use Case, и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы.

Отношения в диаграммах Use Case

Между актером и элементом Use Case возможен только один вид отношения – ассоциация, отображающая их взаимодействие (рис. 2.9)

Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case, что и экземпляр родителя (рис. 2.10).

Рисунок 2.9– Отношение ассоциации Рисунок 2.10– Отношение обобщения между актерами

Между элементами Use Case определены отношение обобщения.

Отношение обобщения (рис. 2.11) фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.

Рисунок 2.11– Отношение обобщения

между элементами Use Case