Моделирование и проектирование программного обеспечения Лекция 8 Реализация

Моделирование и проектирование программного обеспечения Лекция 8. Реализация вариантов использования Диаграммы коммуникаций

Диаграммы коммуникаций

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

Диаграммы коммуникации • Диаграммы коммуникационные (ДК) основное внимание уделяют структуре взаимодействия, тому, как передаются сообщения между участниками. • В UML 2 ДК имеют меньше возможностей описания логики взаимодействия чем диаграммы последовательностей.

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

Пример варианта использования • Вариант использования Add. Course (добавить курс)

• Простая коммуникационная диаграмма для прецедента Add. Courses, в котором : Registrar добавляет два новых объекта Course. • Следует обратить внимание на нумерацию сообщений, обозначающую их последовательность и вложенность в другие сообщения.

Пошаговая интерпретация диаграммы коммуникации 1. add. Course("UML") – сообщение add. Course(. . . ), которое отправляется линии жизни объекта : Registration. Manager с параметром "UML". • Экземпляр : Registration. Manager инициирует операцию add. Course( … ) и передает в нее параметр "UML", фокус управления переходит в эту операцию.

1. 1. «create» – порядковый номер 1. 1 говорит о том, что фокус управления по-прежнему находится в операции add. Course(. . . ). • : Registration. Manager посылает анонимное сообщение, помеченное стереотипом «create» . • Такие сообщения «create» создают новые объекты, и это конкретное сообщение создает новый объект uml: Course. • Позже при анализе или проектировании этому анонимному сообщению будет дано имя и, возможно, параметры, но пока достаточно показать, что создается новый объект uml: Course. • После создания объекта из операции add. Course( … ) больше не посылается никаких сообщений, и этот поток возвращается.

2. add. Course( "MDA" ) – в : Registration. Manager посылается сообщение add. Course(…) с параметром "MDA". • Фокус управления переходит к операции add. Course( … ). 2. 1. «create» – порядковый номер 2. 1 говорит о том, что фокус управления по-прежнему находится в операции add. Course(…). • : Registration. Manager посылает анонимное сообщение, помеченное стереотипом «create» ; это создает новый объект, mda: Course. • После создания объекта фокус управления add. Course(…) возвращается и итерация завершается.

• При чтении коммуникационных диаграмм необходимо понимать, что – в результате отправления сообщения вызывается некоторая операция экземпляра и – сложная нумерация сообщений указывает на вложенность вызовов операций (т. е. вложенный фокус управления).

Описание итераций • Выражение, описывающее итерацию включает – спецификатор итерации (*) и – (необязательный) блок итерации, в скобках […. ]. • Выражение итерации задает, сколько раз должно быть отправлено сообщение. • UML 2 не определяет никакого конкретного синтаксиса для блоков итераций, поэтому может использоваться все, что имеет смысл. • Обычно хорошим вариантом являются код или псевдокод.

Блок итерации • Однако в спецификации UML ничего не говорится, о том, что ДК могут по умолчанию использовать синтаксис итерации диаграммы последовательностей. • Если применить синтаксис итерации из Диаграммы Последовательностей, то описывающее итерацию сообщение могло бы выглядеть следующим образом: [ loop min, max [ условие ] ] – Преимущество такой записи - единообразия, – Но есть некоторая синтаксическая избыточность, поскольку и loop, и символ * являются спецификаторами итерации.

Пример описания цикла в ДК • В данном примере для обозначения повторения блока итерации при увеличении i от 1 до n применяется псевдокод. • Затем i используется как селектор для выбора определенного экземпляра Course, которому отправляется сообщение print(). • В результате этого происходит распечатка всех экземпляров Course. • Однако такой подход предполагает, что экземпляры Course хранятся в индексированной коллекции.

Другой подход • Если не нужно делать предположение, о том, что экземпляры Course хранятся в индексированной коллекции, то можно воспользоваться альтернативным подходом. 1. На связи между : Registration. Manager и : Course указано имя роли во множественном числе (courses) и кратность. Все это свидетельствует о том, что : Registration. Manager соединен с коллекцией объектов : Course. 2. К сообщению print() добавлен спецификатор итерации. Это указывает на то, что сообщение print() посылается каждому объекту коллекции.

Параллельные операции • Стандартный спецификатор итерации (*) означает, что сообщения будут выполняться последовательно. • Если необходимо показать, что все сообщения выполняются параллельно, используется спецификатор параллельной итерации *//. – Например: 1. 1: *// print()

Ветвление в диаграммах коммуникации • Ветвление можно смоделировать, добавив в сообщения сторожевые условия. • Такие сообщения посылаются только тогда, когда сторожевое условие становится истинным. • Ветвление – сообщение посылается, только если условие истинно.

Пример ветвления в системе регистрации курсов • Пример ветвления в системе регистрации курсов. • Эта коммуникационная диаграмма реализует прецедент Register. Student. For. Course (зарегистрировать студента на курс). • В этой системе регистрация является трехэтапным процессом: – найти запись студента – нельзя зарегистрировать студента на курс, если его нет в системе; – найти необходимый курс; – зарегистрировать студента на курс.

• На рис. широко показаны условия, чтобы продемонстрировать варианты их применения в коммуникационных диаграммах.

• Условия не имеют формального синтаксиса, но обычно являются выражениями, в которых используются временные переменные области действия текущего фокуса управления или атрибуты классов, участвующих во взаимодействии. • Результаты операций find. Student(…) и find. Course(…) записываются в две временные переменные: student (студент) и course (курс). • Затем значения этих переменных используются для вычисления значения временной булевой переменной found (найден). – found применяется для образования ветви в шаге 1. 3. – found также используется для принятия решения о формировании ошибки для : Registrar на шаге 1. 4.

1. Пошаговая интерпретация 1. register. Student( "Jim", "UML" ) – актер : Registrar посылает сообщение register. Student( "Jim", "UML" ) объекту : Registration. Manager.

2. Пошаговая интерпретация 1. 1. find. Student( "Jim" ) – : Registration. Manager сам себе посылает сообщение find. Student( “Jim” ). • Возвращаемое в результате этой операции значение сохраняется в переменной student. • В случае неудачного поиска значение равно null.

3. Пошаговая интерпретация 1. 2. find. Course( "UML" ) – : Registration. Manager сам себе посылает сообщение find. Course("UML"). • Возвращаемое в результате этой операции значение сохраняется в переменной course. • В случае неудачного поиска значение равно null.

4. Пошаговая интерпретация 1. 3. [found] register( student ) – : Registration. Manager посылает сообщение register( student ) объекту course. • Это сообщение защищено условием и будет послано, если и student, и course не null. • Иначе говоря, попытка зарегистрировать student на course делается только в случае успешного обнаружения обоих объектов, student и course.

5. Пошаговая интерпретация 1. 4. [!found] : error() – если found имеет значение false, вызывается операция error() объекта : Registrar.

• На коммуникационных диаграммах достаточно сложно понятно показать ветвления – создается впечатление, что условия разбросаны по всей диаграмме; – В связи с этим данная диаграмма очень быстро становится достаточно сложной. • Основная рекомендация: показывайте на этих диаграммах только очень простое ветвление. – Для представления сложных ветвлений больше подходят диаграммы последовательностей.