Диаграммы взаимодействия: крупным планом

Рекомендации по построению диаграмм взаимодействия. Диаграммы взаимодействия и их место среди других диаграмм UML. Смысл диаграмм взаимодействия интуитивно нам, конечно же, понятен. Однако посмотрим, что о таких диаграммах говорили классики, например Буч. А вот что:

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

Несмотря на то величайшее уважение, которое мы питаем к Г. Бучу, это определение не кажется нам уж очень удачным. Хотя суть понятия оно передает. Наиболее важное слово в этом определении - это слово "сообщения". Действительно, как люди программирующие, мы понимаем, что взаимодействие-то как раз и состоит в обмене сообщениями между объектами! И к вопросу о сообщениях мы в этой лекции еще не раз вернемся. А пока же посмотрим, что Буч говорит дальше.

А дальше он объясняет, что такое диаграммы кооперации и последовательностей.

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

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

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

А какое же место диаграммы взаимодействия занимают среди других диаграмм UML? На этот вопрос можно ответить двояко. Можно просто говорить о построении диаграмм взаимодействия как об определенном этапе в процессе моделирования. А можно вспомнить о фазах жизненного цикла разработки ПО и посмотреть, где же диаграммы взаимодействия окажутся в таком случае. Да, кстати, кто помнит, какая диаграмма UML наилучшим образом подходит для описания процессов? Хм, что-то не видно леса рук... Ах да, видим одну руку - девушка, сидящая в дальнем углу зала, за колонной... Правильно! Диаграмма активностей. Что ж, попробуем нарисовать диаграмму активностей, описывающую процесс построения модели системы. Вот вариант такой диаграммы, предложенный одним из наших студентов (рис. 5.1):

Рис. 5.1.

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

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

Рис. 5.2.

И опять все вроде бы логично - мы строим диаграммы взаимодействия во время анализа поведения системы. Кстати, из рисунка (сказать "диаграмма" язык не поворачивается) очень хорошо видно, что диаграмма последовательностей и диаграмма кооперации взаимозаменяемы и являются альтернативными друг другу шагами процесса.

Диаграммы последовательностей и их нотация

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

Еще одна вещь, которую можно увидеть на диаграммах последовательностей - это длинные прерывистые полосы на линиях жизни. Таким образом обозначаются периоды времени, когда объект имеет фокус управления, т. е. выполняет некоторое действие (причем неважно как - непосредственно или путем вызова некоей подчиненной операции). Фокус управления на диаграммах последовательностей часто не изображают: ведь и так понятно, где он должен располагаться, достаточно взглянуть на положение стрелок, изображающих сообщения. Рисовать фокус или нет - дело привычки каждого проектировщика. Впрочем, многие средства UML- моделирования рисуют фокус автоматически, так что человеку не нужно заботиться о его изображении. Если объект в процессе взаимодействия разрушается, этот факт помечают на его линии жизни крестиком, который, собственно, эту линию и заканчивает. Да, все мы смертны. Иногда так и тянется рука написать "R.I.P." рядом с таким крестиком...

Не полагаясь на выразительную силу и образность наших описаний, все же покажем примеры всех этих обозначений (рис. 5.3).

Рис. 5.3.

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

Рис. 5.4.