Transcript (диаграммы коммуникации)

Моделирование и проектирование
программного обеспечения
Лекция 8.
Реализация вариантов использования
Диаграммы коммуникаций
Диаграммы коммуникаций
Пример диаграммы коммуникации
Диаграммы коммуникации
• Диаграммы коммуникационные (ДК)
основное внимание уделяют структуре
взаимодействия, тому, как передаются
сообщения между участниками.
• В UML 2 ДК имеют меньше возможностей
описания логики взаимодействия чем
диаграммы последовательностей.
• Синтаксис диаграмм коммуникации походит
на синтаксис диаграмм последовательностей,
за исключением того, что у участников нет
линий жизни («хвостов)».
• Участники соединены между собой связями,
образующими коммуникационные каналы
для передачи сообщений.
• Порядок сообщений определяется путем
иерархической нумерации.
Пример варианта использования
• Вариант использования AddCourse (добавить
курс)
• Простая коммуникационная диаграмма для прецедента
AddCourses, в котором :Registrar добавляет два новых
объекта Course.
• Следует обратить внимание на нумерацию сообщений,
обозначающую их последовательность и вложенность в
другие сообщения.
Пошаговая интерпретация
диаграммы коммуникации
1. addCourse("UML") – сообщение addCourse(...),
которое отправляется линии жизни объекта
:RegistrationManager с параметром "UML".
• Экземпляр :RegistrationManager инициирует
операцию addCourse( … ) и передает в нее
параметр "UML", фокус управления переходит
в эту операцию.
1.1. «create» – порядковый номер 1.1 говорит о том, что
фокус управления по-прежнему находится в операции
addCourse(...).
• :RegistrationManager посылает анонимное сообщение,
помеченное стереотипом «create».
• Такие сообщения «create» создают новые объекты, и
это конкретное сообщение создает новый объект
uml:Course.
• Позже при анализе или проектировании этому
анонимному сообщению будет дано имя и, возможно,
параметры, но пока достаточно показать, что создается
новый объект uml:Course.
• После создания объекта из операции addCourse( … )
больше не посылается никаких сообщений, и этот
поток возвращается.
2. addCourse( "MDA" ) – в :RegistrationManager посылается
сообщение addCourse(…) с параметром "MDA".
• Фокус управления переходит к операции addCourse( … ).
2.1. «create» – порядковый номер 2.1 говорит о том, что
фокус управления по-прежнему находится в операции
addCourse(…).
• :RegistrationManager посылает анонимное сообщение,
помеченное стереотипом «create»; это создает новый
объект, mda:Course.
• После создания объекта фокус управления addCourse(…)
возвращается и итерация завершается.
• При чтении коммуникационных диаграмм
необходимо понимать, что
– в результате отправления сообщения вызывается
некоторая операция экземпляра и
– сложная нумерация сообщений указывает на
вложенность вызовов операций (т. е. вложенный
фокус управления).
Описание итераций
• Выражение, описывающее итерацию включает
– спецификатор итерации (*) и
– (необязательный) блок итерации, в скобках [….].
• Выражение итерации задает, сколько раз должно быть отправлено
сообщение.
• UML 2 не определяет никакого конкретного синтаксиса для блоков
итераций, поэтому может использоваться все, что имеет смысл.
• Обычно хорошим вариантом являются код или псевдокод.
Блок итерации
• Однако в спецификации UML ничего не
говорится, о том, что ДК могут по умолчанию
использовать синтаксис итерации диаграммы
последовательностей.
• Если применить синтаксис итерации из
Диаграммы Последовательностей, то
описывающее итерацию сообщение могло бы
выглядеть следующим образом:
[ loop min, max [ условие ] ]
– Преимущество такой записи - единообразия,
– Но есть некоторая синтаксическая избыточность,
поскольку и loop, и символ * являются
спецификаторами итерации.
Пример описания цикла в ДК
• В данном примере для обозначения повторения блока итерации
при увеличении i от 1 до n применяется псевдокод.
• Затем i используется как селектор для выбора определенного
экземпляра Course, которому отправляется сообщение print().
• В результате этого происходит распечатка всех экземпляров Course.
• Однако такой подход предполагает, что экземпляры Course
хранятся в индексированной коллекции.
Другой подход
• Если не нужно делать предположение, о том, что экземпляры
Course хранятся в индексированной коллекции, то можно
воспользоваться альтернативным подходом.
1.На связи между :RegistrationManager и :Course указано имя роли во
множественном числе (courses) и кратность.
Все это свидетельствует о том, что :RegistrationManager соединен с
коллекцией объектов :Course.
2. К сообщению print() добавлен спецификатор итерации.
Это указывает на то, что сообщение print() посылается каждому
объекту коллекции.
Параллельные операции
• Стандартный спецификатор итерации (*)
означает, что сообщения будут выполняться
последовательно.
• Если необходимо показать, что все сообщения
выполняются параллельно, используется
спецификатор параллельной итерации *//.
– Например: 1.1: *// print()
Ветвление в диаграммах коммуникации
• Ветвление можно смоделировать, добавив в
сообщения сторожевые условия.
• Такие сообщения посылаются только тогда,
когда сторожевое условие становится
истинным.
• Ветвление – сообщение посылается, только
если условие истинно.
Пример ветвления в системе регистрации
курсов
• Пример ветвления в системе регистрации курсов.
• Эта коммуникационная диаграмма реализует
прецедент RegisterStudentForCourse
(зарегистрировать студента на курс).
• В этой системе регистрация является
трехэтапным процессом:
– найти запись студента – нельзя зарегистрировать
студента на курс, если его нет в системе;
– найти необходимый курс;
– зарегистрировать студента на курс.
• На рис. широко показаны условия, чтобы
продемонстрировать варианты их
применения в коммуникационных
диаграммах.
• Условия не имеют формального синтаксиса, но обычно
являются выражениями, в которых используются
временные переменные области действия текущего
фокуса управления или атрибуты классов, участвующих
во взаимодействии.
• Результаты операций findStudent(…) и findCourse(…)
записываются в две временные переменные: student
(студент) и course (курс).
• Затем значения этих переменных используются для
вычисления значения временной булевой переменной
found (найден).
– found применяется для образования ветви в шаге 1.3.
– found также используется для принятия решения о
формировании ошибки для :Registrar на шаге 1.4.
1. Пошаговая интерпретация
1.registerStudent( "Jim", "UML" ) – актер :Registrar
посылает сообщение registerStudent( "Jim",
"UML" ) объекту :RegistrationManager.
2. Пошаговая интерпретация
1.1. findStudent( "Jim" ) – :RegistrationManager сам
себе посылает сообщение findStudent( “Jim” ).
• Возвращаемое в результате этой операции
значение сохраняется в переменной student.
• В случае неудачного поиска значение равно
null.
3. Пошаговая интерпретация
1.2. findCourse( "UML" ) – :RegistrationManager сам
себе посылает сообщение findCourse("UML").
• Возвращаемое в результате этой операции
значение сохраняется в переменной course.
• В случае неудачного поиска значение равно
null.
4. Пошаговая интерпретация
1.3. [found] register( student ) – :RegistrationManager
посылает сообщение register( student ) объекту
course.
• Это сообщение защищено условием и будет
послано, если и student, и course не null.
• Иначе говоря, попытка зарегистрировать student
на course делается только в случае успешного
обнаружения обоих объектов, student и course.
5. Пошаговая интерпретация
1.4. [!found] : error() – если found имеет
значение false, вызывается операция error()
объекта :Registrar.
• На коммуникационных диаграммах
достаточно сложно понятно показать
ветвления – создается впечатление, что
условия разбросаны по всей диаграмме;
– В связи с этим данная диаграмма очень быстро
становится достаточно сложной.
• Основная рекомендация: показывайте на
этих диаграммах только очень простое
ветвление.
– Для представления сложных ветвлений больше
подходят диаграммы последовательностей.