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

Лекция 4:

Диаграмма активностей: крупным планом

А ведь это вовсе не блок-схема!

Как мы уже говорили, диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких действий (активностей), выполняющихся в системе. Мы уже знаем, что нотация UML предлагает пять представлений системы:

· Вид системы с точки зрения прецедентов.

· Вид с точки зрения проектирования.

· Вид с точки зрения процессов.

· Вид с точки зрения развертывания.

· Вид с точки зрения реализации.

Рекомендуемые материалы

И при этом каждый из перечисленных способов представления системы может содержать последовательности действий, которые могут быть описаны с помощью алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей. Вообще говоря, любой элемент модели, имеющий динамическое поведение, может быть дополнен диаграммой деятельности - именно для уточнения этой самой динамики. Как хорошо подходящий по контексту пример следует упомянуть возможность применения диаграмм активности для описания бизнес-процессов, существующих в компании (нотации Grapes-BM, BPML/BPMN и др.). Вот уж где самая что ни на есть динамика!

Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри ее. Читатель, конечно же, понял, что, когда мы говорим о динамике, мы подразумеваем поведение системы в целом или ее частей. Говоря более формально, диаграммы активности, в общем-то, не имеют монополии на описание поведенческих особенностей динамических частей системы. Для этой же цели могут использоваться еще диаграммы прецедентов, последовательности, кооперации и состояний. Почему же мы говорим именно о диаграмме активности? Нет, не только потому, что так называется эта лекция.

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

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

Как говорится, лучше один раз увидеть, чем сто раз услышать. Мы достаточно разрекламировали диаграммы деятельностей. Пора взглянуть на пример (рис. 4.1).

Рис. 4.1.

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

Рис. 4.2.

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

Рис. 4.3.

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

Рис. 4.4.

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

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей. Только дорожки это не беговые, а плавательные - они так и называются:swimlanes. Более формально, дорожка - часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект.

Рис. 4.5.

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

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

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

Рис. 4.6.

На этом можно было бы и закончить наш разговор о нотации диаграмм активностей и их отличиях от блок-схем. Если бы не одно НО. Мы говорили, что деятельность - это протяженное по времени составное действие. Составное! То есть составленное из более простых действий. Вот эти-то самые простые (атомарные) действия, а вернее, последовательность их выполнения, частенько изображают внутри деятельности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку - одна (а часто и не одна) диаграмма внутри другой. Мы не будем долго говорить об этом: нашей целью было просто обратить внимание читателя на подобную возможность "вложенных" диаграмм. Мы просто покажем пример, позаимствованный нами из Zicom Mentor (рис. 4.7).

Рис. 4.7.

Диаграмма описывает высадку пассажиров самолета, достигших пункта назначения, и посадку новых пассажиров. Предлагаем читателю самому внимательно рассмотреть эту диаграмму. Из нее, например, можно почерпнуть, что конечных состояний может быть больше одного. Кстати, кроме начального и конечного состояний есть еще конечное состояние потока (Flow final mode). От конечного состояния оно отличается вот чем: конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности. Обозначается конечное состояние потока простым символом, напоминающим лампочку накаливания в схемах электрических цепей (рис. 4.8):

Рис. 4.8.

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

Примеры использования таких диаграмм

На практике диаграммы деятельности применяются в основном двумя способами:

1. Для моделирования процессов

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

2. Для моделирования операций

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

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

Моделируют бизнес-процессы в несколько этапов, первым из которых является разбиение их на подпроцессы. Подпроцессы, являющиеся "участками большого процесса", описать легче. А там, глядишь, и составится целое из частей. Дальше выделяют ключевые объекты (и создают для них дорожки), определяют предусловия и постусловия каждого процесса (т. е. его границы), описывают деятельности и переходы, отображают на диаграммах состояния ключевых объектов, в которые они переходят в ходе процесса. Все это звучит довольно сложно, а на практике происходит еще сложнее: ведь создается не какая-то абстрактнаядиаграмма, а модель реального бизнес-процесса в реальной компании, занимающейся реальным бизнесом, где цена ошибки может быть очень высока. Чтобы окончательно не запугать читателя, приведем просто пример использования диаграммы активностейдля описания процесса разработки ПО в OpenUP (рис. 4.9):

увеличить изображение
Рис. 4.9.

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

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

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

Рис. 4.10.

Ну что, почувствовали себя опять студентом?

Советы по построению диаграмм активностей

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

1. Составление перечня деятельностей в системе

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

2. Принятие решения о необходимости построения диаграммы деятельностей

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

3. Определение зависимостей между деятельностями

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

4. Выделение параллельных потоков деятельностей

Выделите активности, имеющие общих предшественников. Зачем - думаем, и так понятно.

5. Определение условий переходов

Сформулируйте выражения, которые могут принимать только два значения - "истинно" или "ложно", соответствующие альтернативным потокам управления. Теперь вы знаете, что писать рядом с символами принятия решений!

6. Уточните сложные деятельности

Повторите пункты 1-6 для каждой из деятельностей (при необходимости). Помните пример с посадкой/высадкой пассажиров самолета? Присмотритесь внимательно, возможно, в проектируемой вами диаграмме тоже будет нелишним применить "принцип матрешки". А как это работает на практике? Да легко! Рассмотрим, например, моделирование пословицы "После драки кулаками не машут":

1. Выделяем деятельности: драться, махать кулаками.

2. Следует ли строить диаграмму в этом случае? Вообще-то нет. Но ведь это пример!

3. Определяем зависимости между деятельностями: размахивание кулаками не происходит после драки.

4. Определяем параллельные деятельности: вроде бы тут таких не наблюдается...

5. Определяем условия переходов: драка состоялась? Если "нет", то машем кулаками, если "да", то нет.

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

Посмеялись? А теперь попробуйте все это смоделировать. Правда, легко? Ведь все уже разложено по полочкам - только рисуй! А что относительно процесса построения диаграмм активностей говорят классики? Тот же Буч, например, писал:

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

Что ж, напутствия сделаны, цитата классика приведена. На этом можно и заканчивать. И все же хотелось бы еще раз напомнить о том, что UML в целом и диаграммы активностей в частности обладают немалыми выразительными средствами, позволяющими не только моделировать сложные бизнес-системы, но и рассказывать сказки, стихи, шутить. Да, вы догадались правильно: мы хотим привести еще пару примеров с сайта шуток на UML (http://www.umljokes.com). Первый пример - это незабвенный шекспировский монолог Гамлета на UML (рис. 4.11).

Рис. 4.11.

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

увеличить изображение
Рис. 4.12.

Выводы

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

· Диаграммы деятельности являются частным случаем диаграммы состояний.

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

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

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

· Сложные деятельности можно дополнительно детализировать, разбив на действия и изобразив "диаграмму в диаграмме".

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

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

Рекомендуем посмотреть лекцию "6. Язык HTML".

· Какие еще виды диаграмм (кроме диаграмм активностей) можно использовать для моделирования динамики системы?

· Чем диаграммы деятельности отличаются от блок-схем? Какие преимущества это сулит разработчикам?

· Что такое траектория объекта?

· Чем конечное состояние потока отличается от конечного состояния деятельности?

· Чем моделирование процессов отличается от моделирования операций?

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