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

Автор:Давиденко Сергей

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

Для чего используется техника креативности

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

План действий

В разделе «Описание» изучите основной набор символов диаграммы деятельности UML, необходимый для того, чтобы уметь читать этот тип диаграмм.

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

Замечания (описание)

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

Термин	Изображение	Описание
Начальный узел		Старт диаграммы
Ветвление		Ветвление (fork), имеет один входной поток и несколько выходных параллельных потоков.
Операция		См. раздел «Пример»
Поток / ребро		В UML 2 параллельно употребляются термины поток (flow) и ребро (edge) для обозначения связи между двумя операциями. Самый про стой вид ребра – это обычная стрелка между двумя операциями.
Решение		Каждый раз при достиже нии решения выбирается только один из выходных потоков, поэтому защиты должны быть взаимно исключающими.
Слияние		Слияние обозначает завершение условного поведения, которое было начато решением.
Объединение		При наличии параллелизма необходима синхронизация. Мы не закры ваем заказ, пока он не оплачен и не доставлен. Это показывается с по мощью объединения
Конец деятельности		Окончание диаграммы
Имя деятельности
Входной параметр
Выходной параметр
«Грабли»		Операции могут быть реализованы или как вложенные деятельности или как методы классов. Вложенную деятельность можно обозначить с помощью символа «граблей».
Вызов метода
Временной сигнал		Временной сигнал (time signal) приходит по прошествии времени. Та кие сигналы могут означать конец месяца в отчетном периоде или приходить каждую секунду в контроллере реального времени.
Принятие сигнала
Посылка сигнала
Прием сигнала
Разъем
Узел объекта
Контакт		Процедуры, как и методы, могут иметь параметры. Показывать на диа грамме деятельности информацию о параметрах не обязательно, но при желании можно отобразить параметры с помощью контактов (pins)
Выражение преобразования		Если требуется нарисовать точную диаграмму деятельности, то необходимо обеспечить соответствие выходных параметров одной процедуры входным параметрам другой. Если они не совпадают, то можно указать преобразование (transformation) (рис. 11.8) для перехода от од ной процедуры к другой.
Ключевое слово
Выходной список контактов
Область расширения		Область расширения (expansion region) отмечает область диаграммы деятельности, где операции выполняются один раз для каждого элемента коллекции.
Окончание потока		Окончание потока (flow final) означает завершение конкретного потока без завершения всей активности.
Описание объединения		Описание объединения (join specification) – это логическое выражение, присоединенное к объединению.

Как применять технику креативности

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

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

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

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

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

Как научиться

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

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

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

Пример использования

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

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

На рис. 11.1 показан пример простой диаграммы деятельности. Мы стартуем с начального узла (initial node), а затем выполняем операцию Receive Order (Принять заказ). Затем идет ветвление (fork), которое имеет один входной поток и несколько выходных параллельных потоков.

Из рис. 11.1 видно, что операции Fill Order (Заполнить заявку), Send Invoice (Послать счет) и следующие за ними выполняются параллельно. По существу, в данном случае это означает, что последовательность операций не имеет значения. Я могу заполнить заявку, послать счет, доставить товар (Delivery), а затем получить оплату (Receive Payment); или я могу послать счет, получить оплату, заполнить заявку, а затем доставить товар. Посмотрите на рисунок.

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

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

При наличии параллелизма необходима синхронизация. Мы не закрываем заказ, пока он не оплачен и не доставлен. Это показывается с помощью объединения (join) перед операцией Close Order (Закрыть заказ). Исходящий из объединения поток выполняется только в том случае, когда все входящие потоки достигли объединения. Поэтому вы можете закрыть заказ, только когда принята оплата и заказ доставлен.

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

Заметьте, что узлы на диаграмме деятельности называются операциями (actions), а не активностями (activities). Строго говоря, деятельность относится к последовательности действий, поэтому диаграмма представляет деятельность, состоящую из операций.

Условное поведение схематически обозначается с помощью решений (decisions) и слияний (merges). Решение, которое в UML 1 называлось ветвью, имеет один входящий поток и несколько защищенных выходных потоков. Каждый выходной поток имеет защиту – условное выражение, помещенное в квадратные скобки. Каждый раз при достижении решения выбирается только один из выходных потоков, поэтому защиты должны быть взаимно исключающими. Применение [else] в качестве защиты означает, что поток [else] используется в том случае, когда другие защиты данного решения принимают ложное значение.

На рис. 11.1 решение располагается после операции заполнения заявки. Если у вас срочный заказ, то он выполняется в течение суток (Overnight Delivery); в противном случае производится обычная доставка (Regular Delivery).

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

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

Операции могут быть разбиты на вложенные деятельности (subactivities). Я могу взять алгоритм доставки, показанный на рис. 11.1, и определить его как самостоятельную деятельность (рис. 11.2), а затем вызвать его как операцию (рис. 11.3).
Операции могут быть реализованы или как вложенные деятельности или как методы классов. Вложенную деятельность можно обозначить с помощью символа «граблей».

Вызов метода отображается с помощью синтаксиса имя-класса::имя-метода. Можно также вставить в символ операции фрагмент кода, если поведение представлено не единственным вызовом метода.

Разделы диаграммы деятельности

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

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

На рис. 11.4 представлено простое одномерное разбиение. Этот способ по понятным причинам часто называют плавательными дорожками (swim lanes), и такая форма была единственной в UML 1. В UML 2 сетка может быть двумерной, поэтому «плавательная» метафора больше не содержит воды. Кроме того, можно взять каждое измерение и разделить строчки на столбцы, создавая тем самым иерархическую структуру.

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

В простом примере на рис. 11.1 диаграммы деятельности имеют четко определенную стартовую точку, соответствующую вызову программы или процедуры. Кроме того, операции могут отвечать на сигналы.

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

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

В случае, показанном на рис. 11.5, до моего отлета остается два часа (Two hours before flight), и мне пора собирать багаж. Если я упакую его раньше времени, то все равно не смогу уехать, пока не прибудет такси. Если такси приходит (Taxi Arrives) до того, как я успею собрать багаж (Pack Bags), то оно должно ждать меня, пока я не закончу.

Мы можем как принимать сигналы, так и посылать их. Это полезно, когда мы посылаем сообщение, а затем должны ожидать ответа, перед тем как продолжить.

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

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

Маркеры диаграммы деятельности

Смельчаки, рискнувшие погрузиться в глубину спецификаций UML, обнаружат, что в разделе, посвященном активности, много говорится о маркерах (tokens), их создании и использовании.

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

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

Потоки и ребра диаграммы деятельности

В UML 2 параллельно употребляются термины поток (flow) и ребро (edge) для обозначения связи между двумя операциями. Самый простой вид ребра – это обычная стрелка между двумя операциями. Если хотите, можете присвоить ей имя, но в большинстве случаев простой стрелки будет достаточно.

При возникновении трудностей с разводкой линий можно воспользоваться разъемами (connectors), которые позволят вам не рисовать линии на всем их протяжении. Разъемы изображаются парами: один для входного и один для выходного потоков, при этом они должны иметь одну и ту же метку. Я предпочитаю без необходимости не применять
разъемы, поскольку они нарушают визуализацию потока управления.

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

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

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

Контакты и преобразования

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

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

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

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

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

Области расширения

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

На рис. 11.9 процедура Choose Topics (Выбрать темы) генерирует список тем. Затем каждый элемент этого списка становится маркером для входа процедуры Write Article (Написать статью). Подобным образом каждая операция Review Article (Рецензировать статью) генерирует единственную статью, которая добавляется к выходному списку области расширения. Когда все маркеры в области расширения диаграммы деятельности достигают выходной коллекции, область расширения генерирует единственный маркер для списка, который передается процедуре Publish Newsletter (Опубликовать информационный бюллетень).

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

На рис. 11.9 все статьи пишутся и рецензируются параллельно, что отмечено ключевым словом «concurrent». Область расширения также может быть итеративной. Итеративные области должны полностью обрабатывать каждый входной элемент за один раз.

Если есть только одна операция, которую надо вызывать несколько раз, то применяется нотация, показанная на рис. 11.10. Такой способ записи предполагает параллельное расширение, поскольку оно наиболее общее. Эта нотация соответствует концепции динамического параллелизма, принятой в UML 1.

Окончание потока

При получении нескольких маркеров, как в случае с областью расширения, поток часто останавливается, даже если вся активность в целом не завершена. Окончание потока (flow final) означает завершение конкретного потока без завершения всей активности.

На рис. 11.11 показана модифицированная версия рис. 11.9, в которой статьи могут быть отвергнуты. Если статья отклонена, то маркер ликвидируется окончанием потока. В отличие от окончания активности, в данном случае остальная активность может продолжаться. Этот подход позволяет областям расширения действовать в качестве фильтров, в результате чего выходная коллекция будет меньше входной.

Описания объединений

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

Описание объединения (join specification) – это логическое выражение, присоединенное к объединению. Каждый раз, когда в объединение прибывает маркер, вычисляется описание объединения, и если его значение истинное, то порождается маркер. Поэтому на рис. 11.12, независимо от того, выбираю ли я напиток (Select Drink) или кидаю монетку (Insert Coin), автомат оценивает определение объединения. Автомат утоляет мою жажду, только если я кинул достаточное количество денег. Если, как в данном случае, вы хотите показать, что вы приняли маркер в каждом входном потоке, то необходимо именовать потоки и включить их в описание объединения.

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».