Что находится между идеей и кодом? Обзор 14 диаграмм UML

Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?

Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.

UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.

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

UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.

Происхождение UML

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

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

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.

В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».

На UML также повлияли другие объектно-ориентированные нотации:

Почему UML?

По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.

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

Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.

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

Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.

Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.

Основные цели дизайна UML:

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

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.

Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Диаграмма компонентов

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

Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.

Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.

Диаграмма развертывания

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

Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.

Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.

Диаграмма объектов

Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.

Диаграмма пакетов

Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.

Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.

Диаграмма составной структуры

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

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

Диаграмма профилей

Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.

Диаграмма прецедентов

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

Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.

Диаграмма деятельности

Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.

Диаграмма состояний

Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.

Диаграмма последовательности

Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.

Диаграмма Коммуникации

Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.

Диаграмма обзора взаимодействия

Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Временная диаграмма

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

Зачем в UML столько диаграмм?

Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.

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

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

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

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

Источник

UML — Диаграммы взаимодействия

Из термина «Взаимодействие» ясно, что диаграмма используется для описания некоторого типа взаимодействий между различными элементами в модели. Это взаимодействие является частью динамического поведения системы.

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

Назначение диаграмм взаимодействия

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

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

Целью диаграммы взаимодействия является —

Чтобы зафиксировать динамическое поведение системы.

Для описания потока сообщений в системе.

Для описания структурной организации объектов.

Для описания взаимодействия между объектами.

Чтобы зафиксировать динамическое поведение системы.

Для описания потока сообщений в системе.

Для описания структурной организации объектов.

Для описания взаимодействия между объектами.

Как нарисовать диаграмму взаимодействия?

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

У нас есть два типа диаграмм взаимодействия в UML. Одна — это диаграмма последовательности, а другая — диаграмма сотрудничества. Диаграмма последовательности фиксирует временную последовательность потока сообщений от одного объекта к другому, а диаграмма сотрудничества описывает организацию объектов в системе, участвующих в потоке сообщений.

Следующие вещи должны быть четко определены, прежде чем рисовать диаграмму взаимодействия

Объекты, принимающие участие во взаимодействии.

Потоки сообщений среди объектов.

Последовательность, в которой сообщения передаются.

Объекты, принимающие участие во взаимодействии.

Потоки сообщений среди объектов.

Последовательность, в которой сообщения передаются.

Ниже приведены две диаграммы взаимодействия, моделирующие систему управления заказами. Первая диаграмма — это диаграмма последовательности, а вторая — диаграмма сотрудничества.

Диаграмма последовательности

Диаграмма последовательности имеет четыре объекта (Customer, Order, SpecialOrder и NormalOrder).

Диаграмма сотрудничества

Вторая диаграмма взаимодействия — это диаграмма сотрудничества. Он показывает организацию объекта, как показано на следующей диаграмме. На диаграмме сотрудничества последовательность вызова метода указана с помощью некоторой техники нумерации. Число указывает, как методы вызываются один за другим. Мы взяли ту же систему управления заказами, чтобы описать диаграмму сотрудничества.

Вызовы методов аналогичны вызовам диаграмм последовательности. Однако различие в том, что диаграмма последовательности не описывает организацию объекта, тогда как диаграмма сотрудничества показывает организацию объекта.

Чтобы выбрать между этими двумя диаграммами, акцент делается на тип требования. Если временная последовательность важна, тогда используется диаграмма последовательности. Если требуется организация, используется диаграмма сотрудничества.

Где использовать диаграммы взаимодействия?

Мы уже обсуждали, что диаграммы взаимодействия используются для описания динамической природы системы. Теперь мы рассмотрим практические сценарии, в которых используются эти диаграммы. Чтобы понять практическое применение, нам нужно понять основную природу последовательности и диаграмму сотрудничества.

Основное назначение обеих диаграмм схожи, поскольку они используются для захвата динамического поведения системы. Тем не менее, конкретная цель важнее уточнить и понять.

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

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

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

Для моделирования потока управления по временной последовательности.

Моделировать поток управления структурными организациями.

Источник

10) Взаимодействие, Сотрудничество, Диаграммы последовательности

Что такое диаграмма взаимодействия?

ДИАГРАММА ВЗАИМОДЕЙСТВИЯ используется в UML для установления связи между объектами. Он не манипулирует данными, связанными с конкретным каналом связи. Диаграммы взаимодействия в основном сосредоточены на передаче сообщений и на том, как эти сообщения составляют одну функциональность системы. Диаграммы взаимодействия предназначены для отображения того, как объекты будут реализовывать определенные требования системы. Критическим компонентом в диаграмме взаимодействия является линия жизни и сообщения.

Различные элементы UML обычно имеют собственные диаграммы взаимодействия. Детали взаимодействия могут быть показаны с использованием нескольких обозначений, таких как диаграмма последовательности, временная диаграмма, диаграмма связи / сотрудничества. Диаграммы взаимодействия отражают динамическое поведение любой системы.

Обозначение диаграммы взаимодействия

Ниже приведены различные типы диаграмм взаимодействия, определенных в UML:

Целью диаграммы последовательности в UML является визуализация последовательности потока сообщений в системе. Диаграмма последовательности показывает взаимодействие между двумя линиями жизни в виде упорядоченной по времени последовательности событий.

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

Временные диаграммы сосредоточены на том моменте, когда сообщение отправляется от одного объекта другому.

Цель диаграммы взаимодействия

Интерактивные диаграммы помогают визуализировать интерактивное поведение системы. Диаграммы взаимодействия используются для представления того, как один или несколько объектов в системе соединяются и взаимодействуют друг с другом.

Диаграммы взаимодействия фокусируются на динамическом поведении системы. Диаграмма взаимодействия предоставляет нам контекст взаимодействия между одной или несколькими линиями жизни в системе.

В UML диаграммы взаимодействия используются для следующих целей:

Важная терминология

Диаграмма взаимодействия содержит линии жизни, сообщения, операторы, инварианты состояния и ограничения.

дорога жизни

Линия жизни представляет единственного участника взаимодействия. Он описывает, как экземпляр конкретного классификатора участвует во взаимодействии.

Линия жизни представляет роль, которую экземпляр классификатора может играть во взаимодействии. Ниже приведены различные атрибуты линии жизни,

Обозначение линии жизни объясняется в разделе обозначений.

Сообщения

Сообщение — это особый тип связи между двумя линиями жизни во взаимодействии. Сообщение включает в себя следующие действия,

Когда спасательный круг получает сообщение о вызове, он действует как запрос для вызова операции, имеющей подпись, аналогичную указанной в сообщении. Когда спасательный круг выполняет сообщение, оно имеет фокус контроля. По мере развития взаимодействия с течением времени центр управления перемещается между различными линиями жизни. Это движение называется потоком контроля.

Ниже приведены сообщения, используемые на диаграмме взаимодействия:

Государственные инварианты и ограничения

Когда экземпляр или спасательный круг получает сообщение, это может привести к изменению его состояния. Состояние — это состояние или ситуация в течение времени жизни объекта, при котором оно удовлетворяет некоторому ограничению, выполняет некоторые операции и ожидает некоторого события.

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

оператор

Оператор определяет операцию о том, как будут выполняться операнды. Операторы в UML поддерживают операции с данными в форме ветвления, а также итерации. Различные операторы могут использоваться для обеспечения использования итерации и ветвления в модели UML. Операторы opt и alt используются для операций ветвления. Оператор цикла используется для обеспечения итерационных операций, в которых условие выполняется многократно, пока не будет получен удовлетворительный результат. Оператор разрыва используется внутри цикла или итерационных операций. Это гарантирует, что цикл завершается всякий раз, когда встречается оператор останова. Если условие останова не указано, то цикл выполняется бесконечное число раз, что приводит к сбою программы.

Источник

Язык UML Руководство пользователя

Глава 18. Диаграммы взаимодействий

Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования.

Введение

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

При моделировании программной системы возникает похожая проблема: как лучше смоделировать ее динамические аспекты (о моделировании структурных аспектов рассказано в частях 2 и 3 данной книги). Вообразите на минуту, что вы способны визуализировать работающую систему. Если бы вы подключили к ней интерактивный отладчик, то могли бы сосредоточить внимание на любом участке памяти и наблюдать, как он изменяется. Можно было бы даже наблюдать за работой нескольких интересующих вас объектов. Вы увидели бы, как с течением времени объекты создаются, изменяют значения атрибутов и уничтожаются.

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

Рис. 18.1 Диаграммы взаимодействий

Термины и понятия

Общие свойства

Содержание

Как правило, диаграммы взаимодействий (см. главу 15) содержат:

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

Подобно прочим диаграммам, диаграммы взаимодействий могут содержать также примечания и ограничения.

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

Рис. 18.2 Диаграмма последовательностей

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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. (Обстоятельства жизненного цикла объекта можно указывать с помощью ограничений new, destroyed и transient, см. главу 15.)

Примечание: Если объект на протяжении своей жизни изменяет значения атрибутов, состояние или роль, это можно показать (см. главу 13), поместив копию его пиктограммы на линии жизни в точке изменения.

Примечание: На диаграммах кооперации линию жизни объекта явным образом не показывают, хотя можно показать сообщения create и destroy. Не показывают там и фокус управления, однако порядковые номера сообщения могут отображать вложенность.

Диаграммы кооперации

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

Рис. 18.3 Диаграмма кооперации

У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей.

UML не определяет никакого особенного формата для выражений в квадратных скобках при описании итераций и ветвлений; можно использовать псевдокод или синтаксис какого-либо конкретного языка программирования.

Примечание: Не показывайте явно связи между объектами на диаграмме последовательностей. Также не указывайте порядковый номер сообщения, поскольку он неявно определяется физическим расположением сообщения относительно верха или низа диаграммы. Итерации и ветвления показывать можно; при этом альтернативные ветви изображают с помощью отдельных сообщений, исходящих из одной точки. Как правило, на диаграммах последовательностей показывают только простые ветвления; более сложные изображаются на диаграмме кооперации.

Семантическая эквивалентность

Типичные примеры применения

Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Речь идет о взаимодействии экземпляра (см. главу 13) любой разновидности в любом представлении системной архитектуры (см. главу 2), включая экземпляры классов (см. главы 4 и 9), в том числе активных (см. главу 22), интерфейсов (см. главу 11), компонентов (см. главу 25) и узлов (ем. главу 26).

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

При моделировании динамических аспектов системы диаграммы взаимодей ствий обычно используются двояко:

Типичные приемы моделирования

Потоки управления во времени

Моделирование временной упорядоченности потока управления осуществляется следующим образом:

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

Рис. 18.4 Моделирование временной упорядоченности потоков управления

Примечание: На диаграмме последовательностей можно моделировать изменения состояния, роли и значений атрибутов объекта. Для этого есть два способа. Во-первых, можно изобразить объект несколько раз с различными состояниями, ролями и атрибутами, а потом для обозначения изменений воспользоваться переходом со стереотипом become. Во-вторых, для изменения состояния можно прямо на линии жизни объекта поместить соответствующую пиктограмму состояния.

Структура потоков управления

Моделирование структурной организации потоков управления состоит из следующих шагов:

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

В качестве примера на рис. 18.5 показана диаграмма кооперации, которая описывает поток управления, связанный с регистрацией нового студента, причем внимание акцентируется на структурных отношениях между объектами. На диаграмме представлено пять объектов: RegistrarAgent, r (Регистратура), Student, s (Студент), два объекта Course, cl и с2 (Курс) и безымянный объект School (Вуз). Поток управления пронумерован явно. Действие начинается с того, что RegistrarAgent создает объект Student и добавляет его к School (сообщение addStudent), а затем дает ему указание зарегистрироваться. После этого объект Student посылает себе сообщение getschedule, предположительно получив сначала Course, на который он хочет записаться. Затем объект Student добавляет себя к каждому объекту Course. В конце опять показан объект s с об новленным значением атрибута registered.

Рис. 18.5 Моделирование организации потоков управления

Обратите внимание, что на диаграмме показаны связи между объектом School и двумя объектами Course, а также между объектами School и Student, хотя вдоль этих путей не передаются никакие сообщения. Связи просто поясняют, как Student может «видеть» два Course, на которые он записывается. Объекты s cl и с2 связаны с School ассоциацией; следовательно, s может найти cl и с2 во время обращения к операции getSchedule (которая может вернуть набор объек тов Course) косвенно, через объект School.

Прямое и обратное проектирование

Прямое проектирование (создание кода на основе модели) возможно и для диаграмм последовательностей, и для диаграмм кооперации, особенно если их контекстом является операция. Например, используя достаточно развитый инструмент прямого проектирования, для операции register класса student из только что описанной диаграммы можно сгенерировать следующий код на языке Java:

Слова «достаточно развитый» означают следующее: из сигнатуры операции getSchedule инструмент должен понять, что она возвращает объект CourseCollection. Обходя содержимое этого объекта с помощью стандартной идиомы итерации (о которой инструмент должен знать), код может быть обобщен на любое число предлагаемых студенту курсов.

Обратное проектирование (создание модели на основе кода) также возможно для обоих видов диаграмм, особенно если контекстом кода является тело операции. Фрагменты приведенной выше диаграммы можно было бы сгенерировать с помощью соответствующего инструмента на основе прототипного исполнения операции register.

Примечание: Прямое проектирование осуществляется непосредственно, а обратное требует усилий. Простая операция обратного проектирования может привести к избытку информации; проблема состоит в том, чтобы определить детали, которые следует оставить.

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

Советы

Создавая диаграммы взаимодействий в UML, помните, что и диаграммы последовательностей, и диаграммы кооперации являются проекциями динамических аспектов системы на одну и ту же модель. Ни одна диаграмма взаимодействий, взятая в отдельности, не может охватить все динамические аспекты. Для моделирования динамики системы в целом, равно как и ее подсистем, операций, классов, прецедентов и коопераций, лучше использовать сразу несколько диаграмм взаимодействий.

Хорошо структурированная диаграмма взаимодействий обладает следующими свойствами:

При изображении диаграммы взаимодействий следует пользоваться нижеприведенными рекомендациями:

Когда тот или иной физик использует понятие «физический вакуум», он либо не понимает абсурдности этого термина, либо лукавит, являясь скрытым или явным приверженцем релятивистской идеологии.

Понять абсурдность этого понятия легче всего обратившись к истокам его возникновения. Рождено оно было Полем Дираком в 1930-х, когда стало ясно, что отрицание эфира в чистом виде, как это делал великий математик, но посредственный физик Анри Пуанкаре, уже нельзя. Слишком много фактов противоречит этому.

Источник