Коммуникационные диаграммы

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

В UML 1.x эти диаграммы назывались диаграммами кооперации (col­laboration diagrams). Это подходящее название, и я подозреваю, что оно будет существовать, пока люди не привыкнут к новому названию. (Между этим понятием и кооперацией есть различие (стр. 161); отсю­да изменение названия.)

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

Кроме отображения связей, которые представляют собой экземпляры ассоциаций, можно также показать временные связи, возникающие только в контексте взаимодействия. В данном случае связь «local» (ло­кальная) от объекта Order (Заказ) к объекту Product (Продукт) - это ло­кальная переменная, а другими временными связями являются «para­meter» (параметр) и «global» (глобальная). Эти ключевые слова упо­треблялись в UML 1, но пропали из UML 2. Они полезны, поэтому я на­деюсь, что разработчики от них не откажутся.

Стиль нумерации на рис. 12.1 простой и общеупотребительный, но в языке UML он не разрешен. В соответствии с правилами UML необ­ходимо придерживаться вложенной десятичной нумерации, как пока­зано на рис. 12.2.

Вложенная десятичная нумерация нужна, потому что требуется ис­ключить неопределенность при самовызовах. На рис. 4.2 четко пока­зано, что метод getDiscountlnfo вызывается из метода calculateDiscount. Однако в случае применения линейной нумерации, как на рис. 12.1, нельзя будет сказать, вызывается ли метод getDiscountlnfo из метода calculateDiscount или из более общего метода calculatePrice. Схема вло­женной нумерации позволяет обойти эту трудность.

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

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

Кроме чисел в сообщениях можно увидеть и буквы. Эти символы обо­значают различные потоки управления. Так, А5 и В2 могут быть раз­личными потоками; сообщения lal и 1Ь1 могут быть различными по­токами, параллельно вложенными в сообщение 1. Буквы, обозначаю­щие потоки, можно увидеть также и на диаграммах последовательно­сти, хотя это и не дает визуального представления о параллельности.

Коммуникационные диаграммы не имеют точно определенных нота­ций для управляющей логики. Они допускают применение маркеров итерации и защиты (стр. 86), но не позволяют полностью определить алгоритм управления. Не существует также специальных обозначе­ний для создания и удаления объектов, но ключевые слова «create» и «delete» соответствуют общепринятым соглашениям.