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

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

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

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 выступает в роли визуального языка программирования.

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

• Какие еще виды диаграмм (кроме диаграмм активностей) можно использовать для моделирования динамики системы?
• Чем диаграммы деятельности отличаются от блок-схем? Какие преимущества это сулит разработчикам?
• Что такое траектория объекта?
• Чем конечное состояние потока отличается от конечного состояния деятельности?
• Чем моделирование процессов отличается от моделирования операций?
• Применимы ли диаграммы деятельности безотносительно к ООП?