Состояние действия и состояние деятельности

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

Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами, как показано на рис. 5.1. Внутри этой фигуры записывается выражение действия (action expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

Рисунок 5.1. Графическое изображение состояния действия

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

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

В противоположность этому состояния деятельности могут быть подвергнуты дальнейшем декомпозиции, вследствие чего выполняемую деятельность можно представить с помощью других диаграмм деятельности. Состояния деятельности не являются атомарными, то есть могут быть прерваны. Предполагается, что для их завершения требуется заметное время. Можно считать, что состояние дей­ствия - это частный вид состояния деятельности, а конкретнее - такое состояние, которое не может быть подвергнуто дальнейшей декомпозиции. А состояние дея­тельности можно представлять себе как составное состояние, поток управления которого включает только другие состояния деятельности и действий. Состояния деятельности и действий обозначаются одинаково, с тем отличием, что у первого могут быть до­полнительные части, такие как действия входа и выхода (то есть выполняемые со­ответственно при входе в состояние и выходе из него), и оно может сопровождать­ся спецификациями подавтоматов. В этом случае можно использовать специальное обозначение для состояния, содержащего под-деятельности. Такое состояние обозначается специальной пиктограммой в правом нижнем углу символа состояния деятельности, как показано на рис. 5.2.

Рисунок 5.2. Графическое изображение состояния деятельности, содержащего вложенные действия

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний. При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз или слева направо. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное — в ее нижней части.

Переход

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

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

Ветвление

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

В качестве примера рассмотрим фрагмент известного алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + b*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы.

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

Рисунок 5.3. Диаграмма деятельности для алгоритма нахождения корней квадратного уравнения

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

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

Рассмотрим диаграмму, приведенную на рис. 5.4. Моделируется ситуация расчета общей стоимости товаров, покупаемых по кредитной карточке в супермаркете. Если общая стоимость превышает $50, то выполняется аутентификация личности владельца карточки. В случае положительной проверки (карточка действительная) или если стоимость товаров не превышает $50, происходит снятие суммы со счета и оплата стоимости товаров. При отрицательном результате (карточка недействительная) оплаты не происходит, и товар остается у продавца.

Рисунок 5.4. Пример использования ветвлений на диаграмме деятельности

Разделение и слияние

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

Как правило, такая черта изображается отрезком горизонтальной линии, толщина которой несколько шире основных линий диаграммы деятельности. При этом разделение (concurrent fork) имеет один входящий переход и несколько исходящих. Слияние (concurrent join), напротив, имеет несколько входящих переходов и один выходящий, как показано на рис. 5.5.

Рисунок 5.5. Изображение разделения и слияния параллельных потоков

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

Рисунок 5.6. Пример использования разделения и слияния потоков

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

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

Обратите внимание на необходимость поддержания баланса между точками разделения и слия­ния. Число потоков, исходящих из точки разделе­ния, должно быть равно числу потоков, приходящих в соответствую­щую ей точку слияния.

Дорожки

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

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

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

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

 Рисунок 5.7. Фрагмент диаграммы деятельности торговой компании

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

 

Объекты

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

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

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

Рекомендации по построению диаграмм деятельности

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

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

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

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

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

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

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

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

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