Введение в UML 2.0, Часть I

Типы диаграмм UML

Настала пора познакомиться с одним из визуальных языков - UML (Unified Modeling Language) версии 2.0, который является на данный момент самым распространенным и общеизвестным способом моделирования программного обеспечения.

"Скелетом" представленного здесь UML-экскурса является диаграммная структура UML. Его авторы выделяют следующие типы диаграмм (diagram types) (см. рис. 3.1):

На рис. 3.1 не все узлы обозначают типы диаграмм - некоторые изображают лишь группы диаграмм, например, "Структурные", "Поведенческие", "Взаимодействий".

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

Система "Телефонная служба приема заявок"

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

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

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

Диаграммы случаев использования (use case diagrams)

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

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

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

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

Случай использования (use case) - это независимая часть функциональности системы, обладающая результирующей ценностью для ее пользователей.

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

"Результирующая ценность" случая использования для актера системы подразумевает, что он, данный случай использования, должен приносить актеру некоторый законченный и ценный с точки зрения его бизнеса результат. Будучи реализован системой, этот случай использования действительно делает бизнес актера эффективнее, производительнее. Тем самым разработка системы фокусируется на бизнес-целях, а незначительные случаи использования игнорируются. Строится не абстрактная модель функций системы, а набор самых важных (для заказчика и пользователей) сервисов, чтобы каждый из них правильно понять и не один не упустить. И в дальнейшем контроль разработки системы будет осуществляться именно в терминах этого самого важного - того, что нужно заказчику и пользователям.

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

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

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

Существует два вида принципиально разных диаграмм случаев использования - для ПО и для всей системы в целом. Ведь, как правило, ПО является частью более крупной системы. Последняя может включать другое ПО, а также некоторый бизнес-процесс. Пользователями такой системы будут различные клиенты системы (бизнес-актеры), поскольку система создается именно для них. А сама система будет предоставлять для них бизнес-случаи использования. Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок показан на рис. 3.3.

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

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

Диаграммы активностей (activity diagrams)

С их помощью удобно изображать бизнес-процессы - алгоритмы, по которым работает компания. Именно в эти алгоритмы должна встроиться информационная система, автоматизировав некоторую их часть. В данном случае в компании должен быть создан новый бизнес-процесс по телефонной обработке заявок. Заказчик как-то себе представляет этот будущий процесс. Перед началом разработки системы необходимо уточнить алгоритм работы этой новой службы. На рис. 3.4 показана общая схема работы оператора с клиентом.

Программистам полезно ясно представлять себе все бизнес-процессы компании, которые будут затронуты их новой системой. В данном случае у компании еще есть бизнес-процесс обработки заявок, который уже работает и есть у заказчика, и его также нужно понять. Иначе может оказаться, что упущена какая-то важная деталь, которая не позволяет новой системе полноценно выполнять свои функции. Например, может оказаться, что подсистема обработки заявок, с которой должна интегрироваться создаваемая система, реализована… на макросах к Word/Excel! Очевидно, интегрироваться с такой системой весьма затруднительно. На этот и подобные факты необходимо указать заказчику как можно раньше, так как иначе проект может закончиться неуспешно - заказчик потратит деньги и не получит нужных для своего бизнеса сервисов.

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

На диаграмме должны присутствовать символы начала (start) и конца (finish).

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

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

Диаграммы развертывания (deployment diagrams)

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

На рис. 3.5, а показано, что телефонная служба приема заявок будет состоять из офисной телефонной станции ( PBX - Public Branch Exchange), сервера, телефонных аппаратов и клиентских компьютеров. На этом рисунке представлена диаграмма развертывания в одном из двух возможных в UML видов - в описательном. На ней определены типы аппаратных узлов системы, а между ними - ассоциации с пометками множественности (см. описание диаграмм классов).

На рис. 3.5, б приведена диаграмма развертывания в экземплярном варианте. Показан тестовый вариант системы, который, кроме сервера и PBX, содержит один пользовательский компьютер для тестирования взаимодействия сервера и клиента и один клиентский компьютер вместе с телефонным аппаратом для тестирования связи клиента с сервером и PBX. Два клиентских компьютера нужны, чтобы тестировать работу ПО в случае более чем одного клиента (при переходе от одного к двум начинают появляться многочисленные ситуации, которые не проявлялись ранее). Большее количество клиентов - три, десять и т. д. - не принципиально на первых стадиях тестирования и отладки.

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

Таким образом, на диаграммах развертывания показываются узлы (nodes) - элементы аппаратуры, которые также входят в целевую систему, наравне с программным обеспечением. На части этих узлов и развертывается программное обеспечение системы. В рассматриваемом примере такими узлами являются клиентский компьютер и сервер запросов. Кроме того, на диаграммах развертывания могут быть показаны и другие виды узлов - элементы аппаратуры, с которым ПО лишь взаимодействует, например, PBX или телефонный аппарат. Данный тип диаграмм не предназначен для подробного описания аппаратной части системы, а позволяет моделировать только ту часть оборудования, которая прямо или косвенно связана с ПО системы. Например, в данном случае в целевую систему может входить дополнительное сетевое оборудование - переключатели (так называемые "хабы") и т. д. Для подробной спецификации всего этого целесообразно использовать не UML, а средства классического инженерного проектирования.

Диаграммы развертывания могут использоваться, например, как приложение к техническому заданию, а также при обсуждении цен на различные офисные АТС, телефонные аппараты и компьютеры. Такую диаграмму может нарисовать менеджер проекта перед тем, как начать обсуждение архитектуры системы с разработчиками. Эта диаграмма может лежать на столе во время первых таких обсуждений, пока не родилось ничего более конкретного, что также можно нарисовать. Такое "начало от аппаратуры" часто является хорошим стартом проекта, поскольку именно в терминах аппаратуры для многих программно-аппаратных систем формируется существенная часть их функциональных требований: ПО должно уметь управлять таким-то оборудованием в таких-то режимах и т. д. Наконец, диаграмма развертывания может давать хороший обзор всей системы, доступный для непрограммистов (особенно в составе Power-Point презентации с устными пояснениями), поскольку содержит минимум программистских деталей.

Диаграммы компонент (component diagrams)

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

Это - диаграмма компонент UML. На этих диаграммах представляются компоненты (components) - независимые модули ПО, скрывающие свою реализацию и взаимодействующие друг с другом через интерфейсы.

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

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

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

Информация, представленная на диаграмме с рис. 3.6, может со временем меняться: интерфейсы уточняются, добавляются новые компоненты, существующие разбиваются на более мелкие и т. д. Диаграммы компонент проекта целесообразно поддерживать в актуальном состоянии, (имея в виду итеративность разработки и внесение в проект всяких изменений), поскольку компонентное представление системы часто является ядром ее архитектуры. А иметь корректное и компактное описание архитектуры всегда полезно, с помощью такого описания легче следить за изменениями в проекте и удерживать всю картину целиком.

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

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

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

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

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

Диаграммы коммуникаций (communication diagrams)

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

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

Звонок от клиента приходит на офисную АТС, оттуда уходит на телефонный аппарат свободного оператора и на сервер. От сервера через локальную сеть этот звонок приходит на клиентское ПО того же оператора.

Из этой диаграммы становится понятно, что PBX должен передавать серверу вместе с информацией о звонке еще также информацию и об операторе, с которым он прокоммутировал этого клиента. Ведь сервер должен послать информацию о новом звонке на клиентское ПО именно этого оператора. Получая информацию о звонке, клиентское ПО автоматически открывает оператору специальный диалог, в который тот вводит информацию о звонке прямо во время разговора с клиентом. Еще один важный момент, который следует из этой диаграммы: телефонный звонок на аппарате оператора должен прозвенеть одновременно (или почти одновременно) с появлением на его мониторе диалогового окна для внесения информации о звонке. Все эти вопросы удобно обсуждать на фоне этой диаграммы, хоть на ней и нет всей нужной информации.

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

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

Диаграммы последовательностей (sequence diagrams).

Обратимся теперь к временным свойствам алгоритмов работы системы приема телефонных заявок. Для этого в UML есть диаграммы последовательностей (и еще временные диаграммы, рассматриваемые ниже). Пример такой диаграммы представлен на рис. 3.9.

Данная диаграмма сфокусирована на действиях оператора клиентского ПО. Во-первых, на ней явно изображено, что два события - звонок оператору по телефону и появление диалога для внесения информации о звонке на дисплее оператора - должны происходить одновременно. Это "одновременно" может впоследствии доставить много хлопот, поскольку необходимо будет тестировать это требование в условиях, идентичных условиям заказчика, - в его локальной сети, с тем быстродействием, которое она может обеспечивать, с определенным количеством одновременно работающих в сети операторов и т. д. И понятно, что в этой ситуации ПО должно соревноваться по скорости с процессом коммутации в PBX. Вполне возможно, что телефонный аппарат будет звонить существенно раньше, чем соответствующая экранная форма появится на экране оператора, и это может оказаться весьма неудобным. Значит, нужно "убыстрять" обработку звонка сервером ПО. При этом то или иное быстродействие может потребовать существенно разной реализации серверных компонент, поэтому разумно озаботиться этой проблемой заранее. Создание диаграмм последовательностей помогает на этапе проектирования заметить и не забыть о подобных местах в алгоритмах. Программистам рекомендуется преодолеть нетерпеливость и потратить время на прорисовывание различных деталей архитектуры перед началом программирования, а также во время оного, приступая к новому этапу работы. Вроде бы и так все понятно, но предварительное обдумывание с фиксацией решений с помощью диаграмм, обсуждение этих диаграмм с коллегами может предотвратить ошибки, которые, будучи допущенными, потребуют существенных больших усилий на исправление, много превышающих те, что были потрачены на проектирование.

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

Временные диаграммы (timing diagrams)

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

На рис. 3.10 показан фрагмент работы системы AccessControl, которая управляет открытием/блокированием двери в помещение по предъявлению человеком электронного ключа. На рисунке показано три компоненты этой системы. Первая, panel, является устройством, у которого есть дисплей для отображения текущего состояния всей системы и устройство считывания электронного ключа. Исходно panel находится в состоянии locked (соответствующая надпись отображается и на дисплее). После того как человек приложил к этому устройству электронный ключ и устройство считало с него информацию, panel посылает эту информацию в виде сообщения verify второй компоненте - процессору ( access_processor ) - и переходит в состояние waiting. Процессор до получения сообщения verify находится в состоянии idle, а после получения этого сообщения он переходит в состояние verifying. После успешного окончания проверки данных электронного ключа процессор посылает компонентам panel и door сообщения unlock и переходит в состояние enable. Компонента panel переходит в состояние open. Третья компонента, door (собственно, сама дверь), до этого находилась в состоянии locked и, получив сообщение unlock, открывается (переходит в состояние unlock ). Открытой она остается ровно 5 секунд, после чего процессор присылает ей команду lock и она закрывается - снова переходит в состояние locked. Одновременно процессор посылает команду lock также и компоненте panel, которая переходит в свое исходное состояние locked и отображает слово "locked" на дисплее.

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

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

Диаграммы схем взаимодействия (interaction overview diagram)

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

Контрольные вопросы