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

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

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

Действия используются на переходах и в состояниях машины состояний UML и играют там ключевую роль.

Действие в UML (версий 1.1—1.4) может быть одного из следующих типов:

• присваивание значения;

• вызов операции;

• создание объекта;

• уничтожение объекта;

• возврат значения;

• посылка сигнала;

• останов;

• не интерпретируемое действие.

Приведенный список очень похож на список основных выполняемых операторов в обычном языке программирования. Именно на этот "эффект узнавания" и рассчитывали авторы UML. Действительно, подразумевается, что действие — это примитивная исполняемая конструкция языка программирования. Но UML не является языком программирования, поэтому семантика действий до конца в UML не определяется. Можно было бы взять один из распространенных языков программирования (или придумать еще один) и задать семантику выполнения действий UML через примитивы выбранного языка. UML стал бы визуальным языком программирования. Но именно этого и хотели избежать авторы — оказать предпочтение одному языку в ущерб остальным.

В табл. 11 приведены основные сведения о действиях в UML.

 

Таблица 11 Действия

Тип действия	Ключевое слово	Описание
присваивание значения	:=	Присваивание значения атрибуту объекта. После выполнения присваивания значение атрибута равно значению выражения в правой части
вызов операции	call	Вызов операции заданного объекта с заданными аргументами. Можно вызывать операцию сразу у нескольких объектов. В этом случае все они выполняются параллельно, а операция не должна возвращать значение. Операции вызываются синхронно: вызывающий объект ждет, когда выполнение операции закончится и ему вернут управление и, возможно, значение
создание объекта	create	Создание и инициализация нового объекта заданного класса. Аргументы используются для инициализации атрибутов
уничтожение объекта	destroy	Уничтожение заданного объекта и всех его составляющих, включенных отношением композиции
возврат значения	return	Возврат значения в точку вызова операции. Это действие может применяться только внутри вызванной операции, например, на переходе, возбужденным событием вызова. Возвращаемых значений может быть несколько
посылка сигнала	send	Создание нового экземпляра сигнала и отправка созданного сигнала заданному целевому множеству объектов. Целевое множество может не содержать элементов, содержать один элемент или несколько элементов. Сигналы посылаются асинхронно: посылающий объект не ждет, когда объекты целевого множества получат сигналы, а сохраняет свой поток управления и продолжает работу
останов	terminate	Прекращение работы (принудительная остановка) машины состояний объекта и уничтожение этого объекта
не интерпретируемое действие	любой текст	Любое действие, не определенное в UML. Например, исполняемая конструкция целевого языка программирования, поддерживаемого инструментом или же текст на естественном языке

 

Еще одно средство, относящееся к действиям UML, называется повторитель.

Повторитель — это выражение, предписывающее выполнить действие несколько раз (может быть, ноль раз).

Синтаксически повторитель записывается подобно сторожевому условию, в квадратных скобках, перед которыми ставится звездочка:

 

* [ повторитель ] действие

 

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

Завершим разговор о действиях нашим вариантом метамодели действий (Рисунок 4.24).

Рисунок 4.24. Метамодель действий

Деятельность в UML — это средство структурной композиции действий.

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

 

Таблица 12 – Сопоставление действия и деятельности.

Характеристика	Действие	Деятельность
Внешнее событие	Не прерывает выполнения	Может прервать и завершить выполнение
Завершаемость	Всегда завершается самостоятельно	Может продолжаться неограниченно долго
Внутренняя структура	Не моделируется в UML	Может быть раскрыта в отдельной диаграмме
Время выполнения	Пренебрежимо мало	Продолжительное

 

Теперь наконец мы может точно и кратко определить основные сущности на диаграмме деятельности UML. Таковых две:

• состояние действия — это состояние, внутренняя активность которого является действием;

• состояние деятельности — это состояние, внутренняя активность которого является деятельностью.

Состояние действия не имеет специальной нотации и изображается на диаграмме как простое состояние с действием на входе. Вообще говоря, понятие состояния действия не имеет глубокого смысла: без него вполне можно обойтись. Действительно, при переходе в состояние действия выполняется действие на входе (которое атомарно и мгновенно) и немедленно после этого выполняется переход по завершении. Такую ситуацию можно промоделировать простым переходом, как показано на рисунке 4.25. На этом рисунке на фрагменте диаграммы слева использовано состояние действия, а справа приведен эквивалентный фрагмент без состояния действия.

Рисунок 4.25. Элиминация состояния действия

Пожалуй, единственной причиной, по которой состояние действия оставлено в UML, является стремление угодить вкусам тех, кто привык на блок-схемах операторы присваивания писать внутри прямоугольников, а не над стрелками. Видимо поэтому состояние действия разрешается обозначать в виде фигуры состояния деятельности, внутрь которой вписано действие, а не деятельность. Состояние деятельности, напротив, является существенным элементом диаграммы деятельности и имеет специальное обозначение — прямоугольник со скругленными сторонами. Это обозначение очень похоже на обозначение простого состояния (прямоугольник со скругленными углами), но в тоже время отлично от него. Тем самым подчеркивается родственная связь диаграмм состояний и действий. Внутри фигуры состояния деятельности пишется так называемое выражение деятельности. Никакого специального синтаксиса для данного выражения UML не определяет: это может быть текст на псевдокоде, фрагмент кода на языке программирования и просто название деятельности на естественном языке. Никакой видимой внутренней структуры состояние деятельности не имеет, в противоположность простому состоянию, которое может иметь действия на входе, выходе, внутренние и отложенные переходы. Собственно говоря, то, что написано внутри фигуры состояния деятельности — это и есть его внутренняя активность. Но это отнюдь не означает, что состояние деятельности атомарно и не имеет внутренней структуры. Напротив, оно по определению не атомарно и имеет внутреннюю структуру. Предполагается, что либо эта структура не важна на выбранном уровне абстракции, либо она раскрывается в другом месте^[17] с помощью машины состояний, другой диаграммы деятельности или иным способом.

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

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

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

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

Рассмотрим пример самой обычной блок-схемы (в нотации UML), описывающую последовательность действий при выполнении некоторого сценария. В нашей информационной системе отдела кадров предусмотрен вариант использования DeleteDeparment для удаления подразделения. Удаление подразделения не такая простая операция — нельзя просто взять и удалить подразделение — оно может быть связано отношением композиции с другими подразделениями и должностями, а те, в свою очередь, связаны с другими сущностями и т. д. Мы должны решить, какие элементарные операции и в какой последовательности нужно выполнить, чтобы достичь требуемого не нарушив целостность наших данных. Допустим, что в нашем распоряжении имеются классы и операции, представленные на рисунке 4.26.

Рисунок 4.26. Некоторые классы в информационной системе отдела кадров

 

Операция size класса Department доставляет количество должностей в подразделении, deletePos — удаляет указанную должность, getNextPos — итератор, позволяющий перебирать должности в подразделении. Функция isFree класса Position проверяет вакантность должности. Операция обработки исключения posOccupied и операция deleteDpt определены в службе общего пользования Company. Разумеется, нам должно быть известно, какое именно подразделение следует удалить — пусть этот объект называется dpt. В этой ситуации можно предложить различные варианты поведения — все зависит от кадровой политики организации, которую нужно реализовать. Допустим, что в нашей информационной системе отдела кадров действует такое правило: если в подразделении есть "живые люди", то его нельзя просто так удалить — это ошибка, а если нет никого или только "мертвые души", то можно удалять все не задумываясь. Тогда алгоритм удаления подразделения на псевдокоде можно описать, например, следующим образом.

Это же поведение в нотации диаграммы деятельности UML представлено на рисунке 4.27.

Рисунок 4.27. Диаграмма деятельности по удалению подразделения в информационной системе отдела кадров

 

Здесь следует сделать существенное замечание относительно нотации. Ромбик, который используется на диаграмме деятельности, хотя и является значком, но не является сущностью. Это не более чем связующий символ, позволяющий более экономно изображать сегментированные переходы. В примере на рисунке 4.24 два ромбика в верхней части диаграммы использованы, чтобы показать место ветвления потока управления на альтернативные потоки управления. Но сегментировать в виде дерева можно не только множество исходящих переходов данного состояния, но и множество входящих переходов. В таком случае можно также использовать ромбик, чтобы показать место слияния альтернативных потоков управления (нижний ромбик на Рисунок 4.24). При ветвлении ромбик соединяет один входящий и несколько исходящих сегментов перехода, а при слиянии ромбик соединяет несколько входящих и один исходящий сегмент.

В UML имеется своеобразное графическое средство, которое называется дорожкой.

Дорожка — это графический комментарий, позволяющий классифицировать по некоторому признаку сущности на диаграмме деятельности.

Дорожка не является элементом модели — в метамодели UML нет такого понятия.^[18] Это именно графический комментарий, подобный границам системы на диаграмме использования. Поэтому никаких формальных правил применения дорожек нет.

Дорожки (или подобные им конструкции) часто применяются при моделировании бизнес-процессов в организациях, откуда они и были заимствованы в UML. Рассмотрим бизнес-процесс приема сотрудника на работу в нашей информационной системе отдела кадров. Обсуждая сценарий этого варианта использования, в главе 3 мы сосредоточили свое внимание не на самом бизнес-процессе приема, а на участии моделируемой системы в этом процессе. Давайте допустим, что нас интересует прохождение всего процесса в целом, включая как те шаги, которые выполняются системой, так и те шаги, которые (пока) предполагается выполнять вручную. Польза такого описания очевидна: если мы будем знать необходимые в бизнес-процессе шаги, в том числе выполняемые вручную, мы сможем составить более надежный план его поэтапной автоматизации. Даже в самом простом случае приема на работу этапу оформления документов предшествуют другие этапы: сбор информации о кандидате, проверка и обработка этой информации, принятие решения и наконец собственно прием или отказ в приеме. На рисунке 4.28 представлена диаграмма деятельности, отражающая простейший бизнес-процесс найма на работу. Мы считаем, что наш процесс включает четыре деятельности:

• Interview — сбор информации;

• Approve — анализ собранной информации и принятие решения;

• Fill Forms — заполнение документов;

• Refuse — отказ в найме.

Рисунок 4.28. Диаграмма деятельности процесса найма на работу

На рисунке 4.28 нет никаких дорожек — все деятельности равноправны и однородны. Допустим теперь, что деятельность, в которую нанимаемый вовлечен непосредственно (interview, Fill Forms, Refuse) происходит в одном месте и, так сказать, у него на глазах, а важная деятельность (о которой нанимаемый может не догадываться) по анализу информации и принятию решения осуществляется в другом месте и, может быть, другими действующими лицами (техническими специалистами, руководителями подразделений и т. д.). Эта важная информация не является частью модели, т. к. не имеет отношения к поведению системы, но мы можем отразить ее на диаграмме с помощью дорожек (Рисунок 4.29). В данном случае мы подразумеваем, что дорожка с названием HRDpt содержит деятельности, выполняемые в приемной отдела кадров, а дорожка с названием SomeDpt содержит деятельности, выполняемые в том подразделении, куда предполагается принять кандидата.

Рисунок 4.29. Дорожки

Графически дорожки изображаются в виде прямоугольников с названиями. Как правило, их изображают со смыкающимися боковыми сторонами, хотя это и не обязательно. Авторы UML утверждают, что изображение, подобное приведенному на рисунке 4.29, напоминает плавательные дорожки в бассейне, откуда и произошло название данной графической конструкции.

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

При объектно-ориентированном подходе к моделированию поток данных — это изменение состояний объектов во времени, и описание такого изменения существенным образом характеризует поведение. Для описания данной характеристики поведения в UML используются понятия траектория объекта и объект в состоянии.

Объект в состоянии — это объект некоторого класса, про который известно, что он находится в определенном состоянии в данной точке вычислительного процесса.

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

Траектория объекта — это переход особого рода, исходным и/или целевым состоянием которого является объект в состоянии.

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

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

Рассмотрим это на примере диаграммы деятельности, описывающей процесс найма сотрудника в информационной системы отдела кадров. Рисунок 4.30 в основном повторяет Рисунок 4.28 и 4.29, но здесь представлена траектория объекта класса Person, хранящего данные о принимаемом сотруднике. На диаграмме хорошо видно, что именно является входными и выходными данными каждого из состояний деятельности: в результате деятельности Interview создается новый объект, который далее обрабатывается, меняя свою состояние.

Рисунок 4.30. Траектория объекта

 

Нетрудно заметить, что в данном случае мы фактически повторяемся, описывая поведение системы. Из диаграммы на рисунке 4.30 следует, что деятельность Approve выполняется после деятельность Interview причем это указано дважды: один раз с помощью перехода по завершении из Interview в Approve и второй раз с помощью траектории объекта, показывающей, что для выполнения деятельности Approve необходим объект, создаваемый деятельностью Interview. Разумеется, UML позволяет не говорить лишнего: диаграмма на Рисунок 4.31 описывает то же самое поведение, что и диаграмма на Рисунок 4.30.

Рисунок 4.31. Использование траекторий объектов вместо переходов по завершении

 

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

Вернемся еще раз к примеру с наймом на работу и допустим, что мы хотим отразить в модели несколько иной вариант поведения. В диаграммах на рисунке 4.8-­4.31 процесс происходящий в приемной отдела кадров приостанавливается на то время, пока не будут завершена деятельность по оценке кандидата и принятию решения, которая фактически происходит в другом месте. Такое вынужденное ожидание может быть психологически неприятно кандидату (равно как и менеджеру по персоналу). Допустим, что в проектируемой информационной системы отдела кадров требуется обеспечить асинхронное проведение процесса приема: после сбора сведений о кандидате менеджер по персоналу отправляет сигнал в соответствующие инстанции и в ожидании ответного сигнала с решением переводит себя и кандидата в состояние ожидания с внутренней активностью — угощает чаем, рассказывает о миссии организации и т. п. В рамках уже рассмотренных обозначений такая ситуация может быть описана диаграммой деятельности (с использованием простого состояния), как показано на рисунке 4.32. Здесь мы предполагаем, что в не отображаемых на диаграмме "инстанциях" принимается сигнал Request с аргументом person и в ответ отправляется сигнал Answer с аргументом decision.

Рисунок 4.32. Асинхронный процесс принятия решения при найме

 

Приведенная на рисунке 4.32 диаграмма точно описывает желаемое поведение, но может показаться не слишком наглядной: читатель должен знать синтаксические детали обозначений UML, чтобы понять описание процесса с первого взгляда. Между тем имеется хорошо знакомая очень многим наглядная система обозначений для передачи и приема сигналов. Эта система обозначений также включена в UML. Суть состоит в том, что действие по отправке и приему сигнала изображаются в виде фигур, сегментирующих соответствующие переходы. Применение данных обозначений приводит нас к диаграмме на рисунке 4.33.

Рисунок 4.33. Специальные обозначения для отправки и приема сигналов

Подводя итоги описания диаграмм деятельности в UML, мы хотим вернуться к обсуждению области применения этих диаграмм.

С одной стороны, диаграммы деятельности — общее и мощное средство описания алгоритмов. Причем не обязательно программно реализованных алгоритмов: диаграммы деятельности с успехом можно применять для моделирования поведения людей, устройств и организаций при выполнении бизнес-процессов. В наших примерах про процесс приема на работу (Рисунок 4.28-4.33) никакой программной реализации, вообще говоря, не подразумевается. Скорее всего, деятельности, обозначенные на этих диаграммах, должны иметь некоторую программную поддержку, но они не могут выполняться полностью автоматически — в них вовлечены люди. Если мы рассматриваем диаграммы деятельности как средство описания бизнес-процессов, то их естественное место в рамках UML — послужить первым шагом при реализации вариантов использования.

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

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

На рисунке 4.34 приведен наш вариант метамоделей элементов диаграммы деятельности в UML. Поскольку диаграмма деятельности является частным случаем машины состояний, метаклассы, соответствующие элементам диаграммы деятельности определяются как подклассы метаклассов машины состояний.

Рисунок 4.34. Метамодель элементов диаграммы деятельности