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

Диаграммы деятельностей (Activity diagram) используются для описания поведения систем.

В отличие от большинства других средств UML диаграммы деятельностей не имеют отношения к работам «троих друзей». Диаграммы деятельностей сочетают в себе идеи различных методов: диаграмм событий Джима Оделла, диаграмм состояний SDL и сетей Петри. Эти диаграммы особенно полезны в сочетании с потоками работ, а также в описании поведения, которое включает параллельные процессы.

Основным элементом диаграммы деятельностей является деятельность. Причем диаграммы деятельностей, как и диаграммы классов, могут строиться с трех различных точек зрения: с концептуальной, с точки зрения спецификации и с точки зрения реализации. В соответствии с точкой зрения деятельность рассматривается по–разному.

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

На диаграмме, построенной с точки зрения спецификации или реализации, деятельность – это некоторый метод над классом.

Рассмотрим пример диаграммы деятельностей (рис. 6.70.).

Рис. 6.70. Диаграмма деятельностей

Мы видим на примере, что за каждой деятельностью может следовать другая деятельность. В этом случае они образуют простую последовательность. Например, за деятельностью «Положить Кофе в Фильтр» следует деятельность «Вставить Фильтр в Автомат». При таком подходе диаграмма деятельностей напоминает блок–схему.

Разницу можно обнаружить, если посмотреть на деятельность «Поискать Напиток». Эта деятельность активизирует два действия: каждое действие содержит условие, которое может принимать одно из двух значений: «истина» или «ложь» (так же, как на диаграмме состояний). У нас Личность осуществляет деятельность «Поискать Напиток», выбирая между кофе и колой.

Предположим, что мы отыскали кофе, то есть идем вниз по «кофейному» маршруту. Этот путь ведет к линейке синхронизации, с которой связана активизация трех деятельностей: «Положить Кофе в Фильтр», «Добавить Воду в Ёмкость» и «Достать Чашки». Диаграмма указывает, что эти три деятельности могут выполняться параллельно. Причем порядок их выполнения не играет роли: их можно выполнять в любой последовательности, а можно и чередовать друг с другом. Например, достать одну чашку, затем добавить немного воды в ёмкость; достать другую чашку, добавить еще немного воды и т.д. А можно делать некоторые вещи одновременно: одной рукой наливать воду, а другой доставать чашки. Любой из этих вариантов допустим. Это и показывает линейка синхронизации, то есть выбор порядка выполнения действий остается за Личностью (за тем, кто выполняет эти действия). В этом заключается главное различие между диаграммой деятельностей и блок–схемой, то есть блок–схемы обычно показывают последовательные процессы, а диаграммы деятельностей могут поддерживать дополнительно параллельные процессы.

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

Итак, если при описании поведения системы выявляются параллельные процессы (деятельности), то их необходимо синхронизировать.

Простая линейка синхронизации (как в примере) показывает, что выходная деятельность («Включать Автомат») активизируется только тогда, когда выполнены обе входные деятельности: «Добавить Воду в Емкость» и «Вставить Фильтр в Автомат». Линейки могут быть и более сложными.

Обратите внимание, что второе решение (первое – «Поискать Напиток») относится к составным. Если кофе нет, то приходим ко второму решению, связанному с колой. При такой последовательности решений второе решение обозначается ромбом. Количество вложенных решений может быть любым.

Далее обратите внимание, что деятельность «Выпить Напиток» имеет два входа. Это означает, что она будет выполнена в любом случае, то есть рассматривается как условие «ИЛИ» (выполняется, если выполняется хотя бы одна из двух входящих деятельностей). Линейку же синхронизации можно рассматривать как условие «И».

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

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

Рис. 6.71. Диаграмма деятельностей, изображающая обработку заказа.

Cледующая диаграмма деятельностей может отражать вариант использования «Получение поставки» (рис. 6.72.).

Здесь введена новая конструкция: деятельность «Проверить Позицию Заказа», которая помечена символом «*». Это, так называемый, маркер множественности. Он показывает, что при "получении заказа" должны выполнить деятельность «Проверить Позицию Заказа» для каждой строки заказа. Это означает, что за деятельностью «Получить Заказ» следует один вызов деятельности «Проверить Платеж» и много вызовов деятельности «Проверить Позицию Заказа». Все эти вызовы производятся параллельно.

Этот случай подчеркивает второй источник параллелизма на диаграмме деятельностей. Параллельные деятельности могут быть связаны не только с линейной синхронизацией, но и с множественной активизацией. Для множественной активизации обязательно показывается ее основа. В нашем примере – «для каждой строки заказов».

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

В нашем примере не сможем выполнить Заказ, пока не пополнится запас на складе (после поставки следующей партии товара). Этой деятельности («Получение Поставки») может соответствовать отдельный вариант использования. Этот вариант использования покажет деятельность, которая связана с ожиданием заказа до получения очередной поставки.

Рис. 6.72. Диаграмма деятельностей, отражающая «Получение поставки»

Если посмотреть две диаграммы деятельностей (рис. 6.71.) и (рис. 6.72.), приведенные выше, то видно, что их можно объединить в одну. У них общая деятельность «выполнить поставку» (рис. 6.73.).

Рис. 6.73. Наложение диаграмм деятельностей

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

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

Другой способ – это, так называемые, «плавательные дорожки» (рис. 6.74.). В этом случае диаграмма деятельностей разделяется на вертикальные зоны с помощью пунктирных линий. Каждая зона представляет собой зону ответственности каждого класса или конкретного подразделения фирмы. Такой способ позволяет совместить логику диаграмм деятельностей с ответственностью классов, которая отражена на диаграммах взаимодействий. Но построить такую диаграмму не всегда легко, так как надо, чтобы все деятельности попали в свои зоны ответственности.

Рис. 6.74. Диаграмма деятельностей, использующая «плавательные дорожки»

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

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

Используя диаграмму деятельности, руководствуйтесь следующими принципами:

– дайте диаграмме имя, соответствующее ее назначению;

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

– располагайте элементы так, чтобы число пересечений было минимальным;

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

Дата добавления: 2014-01-07