Управление проектами - статьи

         

Роли в моделях взаимодействия


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

Мы будем придерживаться следующего соглашения об использовании синтаксиса именования оси:

<идентификатор_оси> ::= [<имя_элемента>] [: <имя_класса>]


(причем <идентификатор оси> не может быть пустым).

Трактоваться <идентификатор_оси> будет следующим образом: <имя_элемента> обозначает имя роли объекта, которому данная ось ставится в соответствие, а <имя_класса> - тип объекта. В случае, когда опущено имя роли, предполагается, что объект играет некую, так называемую, анонимную роль. Если опущено имя класса, предполагается, что тип объекта может быть произвольным.

В качестве близкого к реальным системам примера рассмотрим модель сети мобильной связи, в которой есть телефоны (Telephone), передатчики (Transmitter) и центральный коммутатор (Switch). Для такой системы можно выделить следующие протоколы:

  • установление соединения;
  • передача данных (разговор);
  • разрыв соединения;
  • регистрация в сети;
  • смена станции в сети.

Мы не будем описывать полную сценарную спецификацию для этой системы, однако приведем ее некоторые возможные сценарии (Рис. 1): запрос на установление соединения (Connection), передача данных (Transmitting), смена станции (Relocation).

Рис. 1. Сценарии системы мобильной связи

По приведенным сценариям видно, что для, например, телефонного аппарата абонента (Telephone) существуют, по крайней мере, такие роли как:

  • Caller - аппарат вызывающего абонента;
  • Calleе - аппарат вызываемого абонента;
  • Sender - аппарат, отправляющий голосовые данные;
  • Receiver - аппарат, принимающий голосовые данные;
  • Migrator - аппарат, сменяющий текущую станцию (передатчик).

Рассматривая эти роли, можно уже указать на важность построения композиции поведения - ясно, например, что роли Sender и Receiver могут выполняться аппаратом после ролей Caller или Callee, причем роли Sender и Receiver могут выполняться аппаратом одновременно.
Поведение, соответствующее роли Migrator, аппарат может выполнять одновременно с любой другой из этих ролей. На этом примере видно, что задание композиции поведения объектов в разных ролях может быть важно для адекватного описания поведения как системы.

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

Итак, рассмотрим систему обмена данными (Рис. 2), состоящую из двух узлов A и B, которые могут по очереди обмениваться сообщениями с данными (data) до тех пор, пока один из них не пошлет сообщение о завершении серии обменов (stop).

Рис. 2. Спецификация модельной системы обмена данными

По существу, в рассматриваемой спецификации имеются только два различных взаимодействия (Рис. 3; здесь опущены конкретные имена типов объектов) - это протокол передачи данных и протокол завершения обмена данными; для данного модельного примера эти протоколы тривиальны.

Рис. 3. Взаимодействия в системе обмена данными.

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

В данной спецификации эти протоколы пришлось продублировать для вариантов разных сочетаний объектов A и B и их возможных ролей.

Теперь рассмотрим следующие два вопроса:



  • Если объекты A и B - различных типов, то как избежать дублирования описания общего для них поведения?
  • Если объекты A и B одинакового типа, то как описать композицию поведения объектов этого типа?


С использованием понятия ролей эти вопросы могут быть переформулированы следующим образом:


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


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


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



Содержание раздела