Для чего нужна диаграмма деятельности
Диаграмма деятельности. Ее назначение, использование. Элементы графической нотации диаграммы деятельности. Состояние действия. Переходы. Дорожки. Объекты
При моделировании поведения проектируемой или анализируемой системы возникает необходимость детализировать особенности алгоритмической и логической реализации выполняемых системой операций.
Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности.
Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычислений или потоков управления в программных системах.
Не менее важная область их применения связана с моделированием бизнес-процессов. Действительно, деятельность любой организации также представляет собой совокупность отдельных действий, направленных на достижение требуемого результата. Однако, применительно к бизнес-процессам, желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию отдельных действий, а сам бизнес-процесс представляется в виде переходов действий из одного подразделения к другому.
Наиболее подходящим типом диаграмм для визуального представления схем выполнения бизнес-процессов являются диаграммы деятельности, на которых дополнительно размещаются так называемые дорожки (Swimlane). Назначение дорожек состоит в том, чтобы указать зоны ответственности за выполнения отдельных деятельностей в рамках моделируемого бизнес-процесса. В качестве имен дорожек используются либо названия подразделений (департаментов) рассматриваемой компании, либо названия отдельных должностей сотрудников тех или иных подразделений.
Проекты по моделированию бизнес-процессов могут выполняться либо с целью реорганизации или реинжиниринга компании, либо с целью собственно документирования бизнес-процессов. Особенности данных проектов заключаются в том, что в обоих случаях необходимо построить модели бизнес-процессов некоторой существующей компании. Чтобы акцентировать внимание на подобных проектах, их часто называют проектами типа «As is» («Как есть»). Соответственно проекты по разработке новых продуктов или моделей новых систем называют проектами типа «To be» («Как должно быть»).
Диаграммы данного типа имеют большое значение для документирования бизнес-процессов и их последующей сертификации по международному стандарту ISO 9000. Поэтому разработка диаграмм этого типа занимает центральное место при выполнении проектов по реинжинирингу и оптимизации бизнес-процессов с использованием нотации UML.
Диаграммы деятельности используются для:
§ спецификации алгоритмов вычислений или потоков управления в программных системах;
В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action).
На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.
Диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия или деятельности, а дугами – переходы от одного состояния действия к другому.
Основные элементы нотации диаграммы деятельности:
Состояния действия
Состояние деятельности (activity state) – состояние в графе деятельности, которое служит для представления процедурной последовательности действий, требующих определенного времени.
Переход из состояния деятельности происходит после выполнения специфицированной в нем ду-деятельности, при этом ключевое слово do в имени деятельности не указывается.
Состояние действия (action state) – специальный случай состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом.
Переход из состояния действия происходит после завершения входного действия. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Обычное использование состояния действия заключается в моделировании шага выполнения алгоритма или процедуры в рамках одного потока управления.
Графически состояния деятельности и действия изображаются одинаковой фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис.). Внутри этой фигуры записывается имя состояния деятельности (рис. а) или действия (рис. б) в форме выражения (expression), которое должно быть уникальным в пределах одной диаграммы деятельности.
Рис. Графическое изображение состояний деятельности и действия
Действие может быть записано на естественном языке, псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами (рис. а). Если же действие может быть представлено в формальном виде, то целесообразно записать его на том языке программирования, на котором предполагается реализовывать разрабатываемый проект (рис. б).
Состояние под-деятельности (subactivity state) – состояние в графе деятельности, которое служит для представления неатомарной последовательности шагов процесса.
Это состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис.). Данная конструкция может применяться к любому элементу языка UML, который поддерживает «вложенность» своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.
Рис. Графическое изображение состояния под-деятельности
Каждая диаграмма деятельности должна иметь единственное начальное и конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний.
При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии.
Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз или слева направо. В этом случае начальное состояние будет изображаться в верхней или левой части диаграммы, а конечное –- в ее нижней или правой части. В интересах удобства визуального представления на диаграмме деятельности допускается изображать несколько конечных состояний. В этом случае все их принято считать эквивалентными друг другу.
Переходы
Переход как элемент языка UML был рассмотрен в диаграммах состояний.
При построении диаграммы деятельности используются только нетриггерные переходы, то есть такие, которые выполняются сразу после завершения деятельности или выполнения соответствующего действия.
Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.
Если из состояния действия выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то выполняться может только один из них.
В этом случае для каждого из таких переходов должно быть явно записано сторожевое условие в прямых скобках.
Условие же истинности должно выполняться только одного из них.
Подобный случай встречается тогда, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. Такая ситуация получила название ветвления, а для ее обозначения применяется специальный символ.
Графически ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста.
В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Принято входящую стрелку присоединять к верхней или левой вершине символа ветвления. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее сторожевое условие в форме булевского выражения.
Для графического объединения альтернативных ветвей на диаграмме деятельности рекомендуется также использовать аналогичный символ в форме ромба, который в этом случае называют соединением (merge).
Наличие этого символа, внутри которого также не записывается никакого текста, упрощает визуальный контроль логики выполнения процедурных действий на диаграмме деятельности (рис. 11.3 внизу).
Входящих стрелок у символа соединения может быть несколько, они исходят от состояний действия, принадлежащих к одной из взаимно исключающих ветвей.
Выходить из ромба соединения может только одна стрелка, при этом ни входящие, ни выходящая стрелки не должны содержать сторожевых условий. Исключением является ситуация, когда с целью сокращения диаграммы объединяют символ решения с символом соединения. Нарушение этих правил делает диаграмму деятельности несостоятельной (ill formed).
Диаграмма деятельности (рис.) моделирует ситуацию, возникающую в супермаркетах при оплате товаров. Как правило, заплатить за покупки можно либо наличными, либо по кредитной карточке. Если покупателем выбран вариант оплаты по кредитной карточке, то проверяется сумма баланса предъявленной к оплате кредитной карточки. При этом оплата происходит только в том случае, если общая стоимость приобретаемых товаров не превышает суммы баланса этой карточки. В противном случае оплаты не происходит, и товар остается у продавца.
Рис. Различные варианты ветвлений на диаграмме деятельности
Один из наиболее значимых недостатков обычных блок-схем или структурных схем алгоритмов связан с проблемой изображения параллельных ветвей отдельных вычислений.
Поскольку распараллеливание вычислений существенно повышает общее быстродействие программных систем, необходимы графические примитивы для представления параллельных процессов.
В диаграммах деятельности с этой целью используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Это прямая черточка, аналогичная обозначению параллельных переходов для диаграмм состояний.
На диаграммах деятельности такая черточка изображается отрезком горизонтальной, реже –вертикальной, линии, толщина которой несколько шире линий простых переходов диаграммы деятельности.
При этом разделение (fork) имеет один входящий переход и несколько выходящих (рис. а), которые изображаются отрезками вертикальных, реже – горизонтальных, линий. Слияние (join), наоборот, имеет несколько входящих переходов и один выходящий (рис. б).
Параллельные переходы на диаграмме деятельности можно изображать в удлиненной форме, а входящие и выходящие переходы вертикальными стрелками.
Рис. Графическое изображение разделения и слияния параллельных потоков управления на диаграмме деятельности
Рассмотренных переходов оказывается достаточно для моделирования различных по сложности ситуаций. Для иллюстрации особенности изображения ветвления и параллельных деятельностей можно рассмотреть пример регистрации пассажиров в аэропорту (рис.). Первоначально выполняется деятельность по проверке билета. В случае если билет не действителен, он возвращается пассажиру, при этом никаких дополнительных действий не выполняется.
Рис. Диаграмма деятельности для примера регистрации пассажиров в аэропорту
Если же билет действителен, то пассажиру выдается посадочный талон. В дополнение к этому проверяется гражданство и наличие багажа у пассажира. Если есть багаж, то его проверка может быть выполнена параллельно, по результатам которой пассажиру выдается талон на багаж. Если пассажир является иностранным гражданином, то дополнительно проверяется наличие у него визы. Если виза действительна, то проверка завершается успешно, и пассажир с возвращенным ему билетом может проследовать на посадку.
Если же виза окажется не действительной, то для этого пассажира посадка на данный рейс оказывается невозможной. В этом случае ему не выдается посадочный талон и талон на багаж, в случае его наличия, поскольку происходит прекращение всех выполняемых сотрудниками аэропорта действий.
Дорожки
Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычислений или потоков управления в программных системах. Не менее важная область их применения связана с моделированием бизнес процессов. Действительно, деятельность любой организации также представляет собой совокупность отдельных действий, направленных на достижение требуемого результата. Однако, применительно к бизнес процессам, желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию отдельных действий, а сам бизнес процесс представляется в виде переходов действий из одного подразделения к другому.
Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes).
Дорожка (swimlane) – графическая область диаграммы деятельности, содержащая элементы модели, ответственность за выполнение которых принадлежит отдельным подсистемам
Все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) организации или сотрудником компании (рис.). В последнем случае принято указывать должность сотрудника, ответственного за выполнение определенных действий.
Названия подразделений явно указываются в верхней части дорожки. Пересекать линию дорожки могут только переходы, которые, в этом случае, обозначают выход или вход потока управления в соответствующее подразделение. Порядок следования дорожек не несет какой-либо семантической информации и определяется соображениями удобства.
Рис. 11.6. Вариант диаграммы деятельности с дорожками
В качестве примера можно рассмотреть фрагмент диаграммы деятельности торговой компании, обслуживающей клиентов в форме заказов. Подразделениями компании обычно являются отдел приема и оформления заказов, отдел продаж и склад. Этим подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая из которых специфицирует зону ответственности подразделения. В этом случае диаграмма деятельности заключает в себе не только информацию о последовательности выполнения рабочих действий, но и о том, какое подразделение торговой компании должно выполнять то или иное действие (рис.).
Рис. 11.7. Фрагмент диаграммы деятельности для торговой компании
Из указанной диаграммы деятельности видно, что после принятия заказа от клиента отделом приема и оформления заказов осуществляется распараллеливание деятельности на два потока (переход-разделение). Первый из них остается в этом же отделе и связан с получением оплаты от клиента за заказанный товар. Второй инициирует выполнение действия по регистрации заказа в отделе продаж (модель товара, размеры, цвет, год выпуска и пр.). Однако выдача товара со склада начинается только после того, как будет получена от клиента оплата за товар (переход-слияние). Затем выполняется подготовка товара к отправке и его отправка клиенту в отделе продаж. После завершения этих деятельностей заказ закрывается в отделе приема и оформления заказов.
Объекты
В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами.
Эти объекты либо инициируют выполнение действий, либо определяют некоторый их результат. Действия специфицируют вызовы, которые передаются от одного объекта графа деятельности к другому. Поскольку в таком ракурсе объекты играют определенную роль в понимании процесса деятельности, иногда возникает необходимость явно указать их на диаграмме.
Для графического представления объектов используется прямоугольник класса, с тем отличием, что имя объекта подчеркивается.
Далее после имени может указываться характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой. Соответствующая зависимость определяет состояние конкретного объекта после выполнения предшествующего действия.
На диаграмме деятельности с дорожками расположение объекта может иметь некоторый дополнительный смысл. А именно, если объект расположен на границе двух дорожек, то это может означать, что переход к следующему состоянию действия в соседней дорожке ассоциирован с готовностью некоторого документа (объект в некотором состоянии). Если же объект целиком расположен внутри дорожки, то и состояние этого объекта целиком определяется действиями данной дорожки.
Для синхронизации отдельных действий на диаграмме деятельности никаких дополнительных обозначений не используется, поскольку синхронизация параллельных процессов может быть реализована с помощью переходов «разделение-слияние».
Рис. Фрагмент диаграммы деятельности торговой компании с объектом-заказом
Достоинством диаграммы деятельности является возможность визуализировать отдельные аспекты поведения рассматриваемой системы или реализации отдельных операций классов в виде процедурной последовательности действий.Таким образом, полная модель системы может содержать одну или несколько диаграмм деятельности, каждая из которых описывает последовательность реализации либо наиболее важных вариантов использования (типичный ход событий и все исключения), либо нетривиальных операций классов.
Дата добавления: 2018-02-15 ; просмотров: 3618 ; Мы поможем в написании вашей работы!
UML — диаграммы деятельности
Диаграмма деятельности — еще одна важная диаграмма в UML, описывающая динамические аспекты системы.
Диаграмма действий — это, по сути, блок-схема, представляющая поток от одного действия к другому. Деятельность может быть описана как работа системы.
Поток управления передается от одной операции к другой. Этот поток может быть последовательным, разветвленным или параллельным. Диаграммы действий касаются всех типов управления потоком с использованием различных элементов, таких как fork, join и т. Д.
Назначение диаграмм деятельности
Основные цели диаграмм деятельности аналогичны четырем другим диаграммам. Он фиксирует динамическое поведение системы. Другие четыре диаграммы используются для отображения потока сообщений от одного объекта к другому, но диаграмма действий используется для отображения потока сообщений от одного действия к другому.
Деятельность — это особая операция системы. Диаграммы действий используются не только для визуализации динамической природы системы, но они также используются для построения исполняемой системы с использованием методов прямого и обратного проектирования. Единственная недостающая вещь на диаграмме активности — это часть сообщения.
Он не показывает поток сообщений от одного действия к другому. Диаграмма деятельности иногда рассматривается как блок-схема. Хотя диаграммы выглядят как блок-схема, это не так. Он показывает разные потоки, такие как параллельный, разветвленный, параллельный и одиночный.
Цель диаграммы деятельности может быть описана как —
Нарисуйте поток активности системы.
Опишите последовательность от одного занятия к другому.
Опишите параллельное, разветвленное и параллельное течение системы.
Нарисуйте поток активности системы.
Опишите последовательность от одного занятия к другому.
Опишите параллельное, разветвленное и параллельное течение системы.
Как нарисовать диаграмму деятельности?
Диаграммы действий в основном используются в качестве блок-схемы, которая состоит из действий, выполняемых системой. Диаграммы действий — это не просто блок-схемы, поскольку они имеют некоторые дополнительные возможности. Эти дополнительные возможности включают ветвление, параллельный поток, дорожку и т. Д.
Прежде чем рисовать диаграмму активности, мы должны иметь четкое представление об элементах, используемых в диаграмме активности. Основным элементом диаграммы деятельности является сама деятельность. Деятельность — это функция, выполняемая системой. После определения видов деятельности нам нужно понять, как они связаны с ограничениями и условиями.
Прежде чем рисовать диаграмму деятельности, мы должны выделить следующие элементы:
После того, как вышеупомянутые параметры определены, нам необходимо составить мысленный план всего потока. Этот ментальный план затем преобразуется в диаграмму деятельности.
Ниже приведен пример диаграммы деятельности для системы управления заказами. На диаграмме определены четыре действия, которые связаны с условиями. Следует четко понимать один важный момент: диаграмма действий не может быть точно согласована с кодом. Диаграмма действий предназначена для понимания последовательности действий и в основном используется бизнес-пользователями.
Следующая диаграмма нарисована с четырьмя основными действиями —
Отправить заказ клиентом
Отправить заказ клиентом
После получения запроса заказа выполняются проверки условий, чтобы проверить, является ли это нормальным или специальным заказом. После определения типа заказа выполняется диспетчерская операция, которая помечается как завершение процесса.
Где использовать диаграммы деятельности?
Основное использование диаграммы активности аналогично другим четырем диаграммам UML. Конкретное использование заключается в моделировании потока управления от одного действия к другому. Этот поток управления не включает сообщения.
Диаграмма активности подходит для моделирования потока активности системы. Приложение может иметь несколько систем. Диаграмма деятельности также охватывает эти системы и описывает поток от одной системы к другой. Это конкретное использование не доступно на других диаграммах. Этими системами могут быть базы данных, внешние очереди или любая другая система.
Теперь мы рассмотрим практическое применение диаграммы деятельности. Из приведенного выше обсуждения ясно, что диаграмма деятельности составлена с очень высокого уровня. Так что это дает высокий уровень обзора системы. Это высокоуровневое представление в основном для бизнес-пользователей или любого другого человека, который не является техническим специалистом.
Эта диаграмма используется для моделирования действий, которые представляют собой не что иное, как бизнес-требования. Диаграмма больше влияет на понимание бизнеса, чем на детали реализации.
Диаграмма деятельности может быть использована для —
Моделирование рабочего процесса с использованием действий.
Высокий уровень понимания функциональных возможностей системы.
Исследование бизнес-требований на более позднем этапе.
Зачем нам UML? Или как сохранить себе нервы и время
Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.
Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.
Что такое UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.
Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.
Плюсы и минусы UML проектирования
Все представленные ниже диаграммы связаны между собой. Комбинируя их, мы можем добиться необходимого уровня декомпозиции отдельно взятых задач.
Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.
Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?
Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.
В чем недостаток данного подхода? Он не нагляден.
Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.
Альтернативой данному подходу является использование диаграммы последовательностей, представленной на рисунке ниже.
Сверху отображены действующие лица, а каждая стрелка это конкретное действие, связанное с ними. Подробнее о данной диаграмме можно узнать здесь
Диаграмма состояний. Настраиваем старые электронные часы
Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Предположим, мы программируем советские электронные часы.
Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.
Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.
Подробнее о диаграмме состояний можно прочитать здесь.
Диаграмма классов, или как рассказать о своем коде без кода
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?
Предположим, вам нужно спроектировать систему. Прежде чем приступить к реализации нескольких классов, вы захотите иметь концептуальное понимание системы, — какие классы мне нужны? Какая функциональность и информация будет у этих классов? Как они взаимодействуют друг с другом? Кто может видеть эти классы? И так далее.
Вот где появляются диаграммы классов. Диаграммы классов — это отличный способ визуализировать классы в вашей системе, прежде чем вы начнете их кодировать. Они представляют собой статическое представление структуры вашей системы.
Именно диаграмма классов дает нам наиболее полное и развернутое представление о структуре и связях в программном коде. Понимание принципов построения данной диаграммы позволяет кратко и прозрачно выражать свои мысли и идеи.
Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».
«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.
Самыми значимыми достоинствами этой диаграммы являются:
Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.
Диаграмма деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельные процессы.
Если говорить кратко, то диаграмма деятельности помогает нам описать логику поведения системы. Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри нее.
Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.
Подробнее о диаграмме деятельности можно прочитать здесь.
Заключение
Надеюсь, что после этой статьи вы по-другому посмотрите на UML. Теперь при прочтении литературы или сайтов, посвященных данной теме, вам будет проще понять, какую цель преследует UML, и найти возможности для его применения. Попробуйте начать применять его и вы почувствуете всю силу и мощь, скрываемую за набором стрелок и квадратиков.
Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.