На этом шаге рассмотрим сообщения, как спецификацию взаимодействия объектов в UML.
Предположим, у вас есть набор объектов и ряд ссылок, соединяющих эти объекты. Если это все, чем вы располагаете, то речь идет о полностью статической модели, описываемой диаграммой объектов. Последняя моделирует состояние сообщества объектов в заданный момент времени и применяется в случае, когда нужно визуализировать, специфицировать, конструировать или документировать статическую структуру объектов.
Теперь допустим, что вы хотите смоделировать изменяющееся состояние сообщества объектов за некоторый период времени. Чтобы представить это наглядно, вообразим фильм, каждый кадр которого демонстрирует перемещение набора объектов в следующий момент времени. Если эти объекты не являются статическими, то вы увидите передачу сообщений другим объектам, отправку событий и вызов операций. Вдобавок в каждом кадре можно явно визуализировать текущее состояние и роль индивидуальных экземпляров.
Сообщение – это спецификация взаимодействия объектов, обеспечивающего передачу информации, которая должна инициировать определенные действия. Момент приема экземпляра сообщения может рассматриваться как случай возникновения события; случай (occurrence) – это термин UML, описывающий экземпляр события.
Когда вы передаете сообщение, то в результате его приема обычно происходит некоторое действие. Оно может заключаться в изменении состояния целевого объекта и объектов, доступных ему.
В UML можно моделировать несколько типов сообщений:
- call (вызвать) – вызывает операцию объекта. Объект может посылать сообщение самому себе, в результате происходит локальный вызов операции;
- return (возвратить) – возвращает значение вызывающему объекту;
- send (послать) – посылает сигнал объекту;
- create (создать) – создает объект;
- destroy (уничтожить) – уничтожает объект. Объект может уничтожить сам себя.
В дополнение к пяти основным видам сообщений вы можете производить и более сложные действия над индивидуальными объектами. UML не специфицирует синтаксис или семантику таких действий; предполагается, что инструментальные средства должны использовать разные языки описания действий либо применять синтаксис языков программирования.
В UML эти типы сообщений различаются визуально, как показано на рис. 1.
Рис.1. Сообщения
Из всех видов сообщений наиболее часто вам придется моделировать вызов (когда один объект вызывает операцию другого объекта или свою собственную). Объект не может вызвать любую произвольную операцию. Если объект наподобие c (рис. 1) вызывает операцию setItinerary (указатьНаправление) на экземпляре класса TicketAgent (АгентПоПродажеБилетов) – то есть она должна быть объявлена в классе TicketAgent или в одном из его родителей, – то эта операция должна быть видима для вызывающего объекта c.
Такие языки, как C++, типизированы статически (хотя и полиморфно). Это означает, что корректность вызовов проверяется во время компиляции. А вот языки наподобие SmallTalk являются динамически типизированными – следовательно, до времени исполнения нельзя определить, может ли объект принять конкретное сообщение. В UML хорошо согласованная модель вообще может быть проверена статически с помощью инструментальных средств, поскольку на момент моделирования проектировщик, как правило, представляет себе назначение операций.
Когда объект вызывает операцию или посылает сигнал другому объекту, вы можете снабдить сообщение конкретным параметром. Аналогичным образом, когда один объект возвращает управление другому, вы также можете смоделировать возвращаемое значение.
Сообщения могут иметь отношение и к посылке сигналов. Сигнал (signal) – это значение объекта, передаваемое целевому объекту асинхронно. После отправки сигнала объект, который его отправил, продолжает свою деятельность.
Вы также можете определить операцию по классу или интерфейсу, в котором она объявлена. Например, вызов операции register (зарегистрировать) на экземпляре Student (Студент) может полиморфно вызвать любую операцию с этим именем в иерархии классов Student; вызов Imember::register (Iучастник::зарегистрировать) вызывает операцию, специфицированную в интерфейсе Imember и реализованную неким соответствующим классом, также находящимся в иерархии Student.
Получая сообщение сигнала, целевой объект независимо принимает решение о том, что с ним нужно делать. Обычно сигналы инициируют переход автомата целевого объекта в другое состояние. Инициализация такого перехода заставляет целевой объект выполнить некие действия и изменить свое состояние. В системах с асинхронной передачей событий взаимодействующие объекты исполняются параллельно и независимо. Они разделяют информацию только посредством передачи сообщений, поэтому не возникает опасности конфликта за разделяемую память.
На следующем шаге рассмотрим формирование последовательности сообщений между взаимодействующими объектами в UML.
