UML 2: модель деятельности и модель действий

Данная публикация журнала Journal of Object Technology (www.jot.fm) открывает серию статей, посвященных модели деятельности (activity model) во второй версии унифицированного языка моделирования Unified Modeling Language, а также тому, как она сочетается с моделью действий (action model). Статью можно рассматривать как дополнение к стандарту; в ней представлены сведения общего характера, логические обоснования, примеры, а также концепции, выстроенные в логическом порядке. Речь также идет о причинах, побуждающих переходить на новые модели, об их архитектуре, об основных аспектах понятий деятельности и действий в UML 2 и об общей концепции поведения (behavior) в этом языке [1].

К истории вопроса

В последнее время специалисты, занятые развитием UML, сосредоточивают свое внимание, прежде всего, на процедурах и процессах. Так, в версии UML 1.5 реализована определяемая потоком управления и потоком данных модель параметризованных процедур, которая дополняет существующие модель состояний (state model) и модель взаимодействий (interaction model) [2]. В UML появилась поддержка процедур, которые можно использовать и в качестве методов объектов, и независимо от объектов, как это бывает, к примеру, при моделировании библиотек функций популярных языков программирования. Кроме того, эта модель облегчает работу с UML для тех создателей моделей, которые работают с объектно-ориентированными технологиями лишь от случая к случаю — скажем, для инженеров-системщиков или для разработчиков моделей внутри предприятий, — и дают им возможность шаг за шагом изучать упомянутые технологии [3]. Такая способность гибко сочетать объектно-ориентированные технологии с функциональным подходом существенно расширяет сферу потенциальных приложений UML и обеспечивает их интеграцию.

Кроме того, язык UML 1.5 унаследовал от более ранних версий конечные автоматы в нотационной форме диаграмм потоков (flow diagram), именуемые теперь диаграммами деятельности (activity diagram). К сожалению, семантика, лежащая в основе конечного автомата, ограничивает выразительность и запутывает пользователей. В особенности это относится к пользователям, не имеющим опыта работы в объектно-ориентированной среде, у которых возникает ощущение, что модели деятельности UML 1.x не способствуют решению их задач. Внушает опасение и то, что в UML 1.5 имеется несколько моделей для потоков управления и данных.

С учетом этого опыта, в UML 2.0 модель деятельности была переопределена с тем, чтобы наделить ее ролью интуитивного моделирования потоков и интегрировать ее с моделью действий UML 1.5. В этой новой модели деятельности поддерживаются потоки управления и данных процедур UML 1.5, а также некоторые более общие возможности, такие как циклы и очереди. Тем самым, диаграммы деятельности UML 2 обеспечивают моделирование потоков в большом числе прикладных областей, от вычислительных до физических. Это делает UML идеальным средством спецификации систем вне зависимости от того, как они реализуются — аппаратно или программно, и вне зависимости от того, где проводится граница между системой и средой. Наконец, поскольку комбинация деятельности и действий сохраняет присущую UML 1.x способность реагировать на события, язык можно использовать, например, при работе с встроенными системами и системами на основе агентов.

Различные прикладные области

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

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

Средства, общие для различных приложений, такие, как абстрактная концепция действия, поток управления/данных и ввод/вывод, находятся в корне (базовая деятельность). Отсюда отношения зависимости разводятся по двум направлениям: одно направление используется, в первую очередь, для моделирования программного обеспечения (структурированная деятельность), а второе — для моделирования общих процессов (промежуточная и завершенная деятельность). В диаграммах структурированной деятельности вводятся правильно вложенные (well-nested) конструкции, предназначенные для моделирования условных значений, переменных, блоков try/catch и т.д. В диаграммах промежуточной и завершенной деятельности вводятся явный параллелизм, разделы, основанные на потоках формы для обработки исключительных ситуаций и ряд конструкций для избирательного управления потоками. Эти ветви являются ортогональными, так что их конструкции можно комбинировать. Так, структурная деятельность может перемежаться с промежуточной деятельностью, что позволяет в одно и то же время использовать и явный параллелизм, и структурированные условные выражения¹.

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

Модели потоков и семантика

Вообще говоря, модели поведения определяют, когда следует начать те или иные работы, и каковы их входные данные [3]. В частности, модели деятельности языка UML 2 строятся в соответствии с традиционным подходом потоков управления и данных: вложенные работы инициируются, когда завершаются другие работы, и становятся доступными входные данные. При использовании диаграмм потоков управления и данных визуализация эффекта времени выполнения обычно достигается путем следования по линиям диаграммы от более ранних конечных точек к более поздним, и изображения того, что управляющие воздействия и данные движутся вдоль этих линий. Поэтому для таких пользователей удобнее всего семантика потока маркеров, инспирированная сетями Петри, где «маркер» — это всего лишь общий термин для управляющих воздействий и значений данных.

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

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

Узлы и ребра деятельности

Диаграммы деятельности UML 2 содержат узлы, связанные ребрами; в результате чего образуется полный граф потоков. Управление и значения данных двигаются вдоль ребер и обрабатываются узлами, направляются на другие узлы или временно сохраняются. Более точно, в моделях деятельности имеются три вида узлов.

• Узлы действия оперируют получаемыми управляющими воздействиями и значениями данных и предоставляют управление и данные другим действиям.
• Узлы управления маршрутизируют перемещение маркеров по графу. Эти узлы содержат конструкции для выбора между альтернативными потоками (точки принятия решения — decision points), для параллельного движения по нескольким потокам (разветвления — forks) и т.д.
• Объектные узлы временно удерживают маркеры данных, которые ожидают продолжения движения по графу.

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

Узлы деятельности связываются направленными ребрами двух типов.

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

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

В следующих разделах действия и ребра обсуждаются на небольшом примере.

Действия

Модели деятельности координируют действия, некоторые из них могут вызывать работы, определяемые пользователями, включая другую деятельность. Все действия являются предопределенными. Например, в UML 2 имеются действия по созданию объектов, установке значений атрибутов, связыванию объектов и вызову работ, определенных пользователями. Действия могут иметь входы и выходы, называемые «контактами» (pins), которые связываются ребрами потоков объектов и показывают, как значения, предоставляемые одними действиями и получаемые другими, проходят через данную деятельность. В простых случаях для начала выполнения действия требуется наличие всех его входных данных.

На рис. 5 представлен пример действия по созданию нового экземпляра класса ORDER («заказ»), и другого действия, вызывающего определяемую пользователем работу по заполнению заказа. Действие по созданию объекта создает незаполненный заказ, который заполняется с помощью действия FILLORDER. Узлы действий представлены в виде прямоугольников с закругленными углами^{4, 5}. Маленькие прямоугольники, присоединенные к действиям в верхней части рис. 5, представляют собой входные и выходные контакты действий. Тип объекта, принимаемого в качестве входного или предоставляемого в качестве выходного, указывается в виде текста под прямоугольником контакта. Нотацию, представленную в нижней части рис. 5, можно использовать в тех случаях, когда типы входа и выхода совпадают. Контакты — разновидность узлов объектов, поэтому они, кроме прочего, временно сохраняют значения данных в потоке.

Как уже говорилось, не обязательно нужно использовать именно ту нотацию, которая показана на рис. 5. Программисты, скорее всего, предпочтут текстуальную нотацию [4], скажем, такую:

Order o;
o = new Order;
FillOrder(o);

Как показано на рис. 6, для обеих нотаций средствами UML 2 можно определить единую модель репозитария, если моделировать переменные текстуального языка в виде потока данных⁶. Каждый элемент репозитария является экземпляром метакласса, определенного в спецификации UML; имя метакласса располагается справа от двоеточия. Имя самого экземпляра репозитария помещается слева от двоеточия; в случае анонимного элемента это место остается пустым. В модели показано действие CREATEOBJECTACTION, выходной контакт которого передает свое значение входному контакту действия CALLBEHAVIORACTION. Действие CREATEOBJECTACTION связано с пользовательским классом (ORDER), экземпляр которого оно создает, а действие CALLBEHAVIORACTION — с определяемой пользователем работой (FILLORDER), которую оно вызывает.

Примитивные действия по созданию объектов, по вызову определяемых пользователями работ и т.д. сами по себе не являются работами с точки зрения техники, но это не концептуальное различие, а скорее артефакт метамоделирования. Фундаментальным является различие между спецификацией динамического эффекта и его использованием: возможны различные использования одной и той же спецификации. Например, одна и та же работа FILLORDER может вызываться во многих диаграммах деятельности или вызываться много раз в одной и той же диаграмме деятельности, но в репозитарии каждый вызов будет представлен отдельным экземпляром действия CALLBEHAVIORACTION, и все эти экземпляры будут ссылаться на одну и ту же работу FILLORDER. Дело в том, что каждое использование FILLORDER будет происходить в отдельном потоке или в разных точках одного и того же потока, и при каждом использовании эта работа может предваряться и завершаться разными действиями. К примеру, на рис. 6 FILLORDER предваряется действием CREATEOBJECTACTION, а в другом потоке это действие может отсутствовать⁷.

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

Деятельность

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

Узлы управления в начале и в конце потока на рис. 7 — это, соответственно, исходный и заключительный узлы. Когда вызывается деятельность ORDERACTIVITY, управляющий маркер помещается в начальный узел, а маркер данных с информацией о заказе — в объектный узел входного параметра. Управляющий маркер двигается от исходного узла к действию CREATEORDER, которое начинает выполняться. Маркер данных передается от соответствующего параметра действию, вызывающему FILLORDER, которому приходится ждать до начала выполнения, пока CREATEORDER не предоставит ему другие входные данные. После завершения действия FILLORDER управляющий маркер передается на конечный узел, деятельность завершается, а управление возвращается элементу, инициировавшему эту деятельность. Частичная модель репозитария для рис. 7 представлена ниже на рис. 8. Она связывается с представленной на рис. 6 модели репозитария с помощью CB1 CALLBEHAVIORACTION. Действие CREATEORDER и его потоки для краткости опускаются.

Поведение в UML 2

В UML 2 поддерживается концепция параметризованного поведения не только для деятельности, а для всех типов работ UML. Это означает, что конечные автоматы, взаимодействия и деятельность могут быть параметризованными и служить методами объектов или вызываться напрямую единообразным способом. В правой верхней части рис. 9 показана модель деятельности для работы DELIVERMAIL (волнистые стрелки не являются частью нотации UML). DELIVERMAIL можно просто вызывать через действие CALLBEHAVIORACTION, или как метод класса POEMPLOYEE через действие CALLOPERATIONACTION. В любом случае эта работа принимает в качестве входных данных экземпляр KEY. Поскольку работы могут вызываться напрямую или как операции, UML 2 предоставляет путь к постепенному усвоению объектно-ориентированного подхода [3].

В UML 2 определяемые пользователями работы тоже являются классами. Всякий раз, когда выполняется работа, создается новый экземпляр времени выполнения класса пользовательской работы. При завершении выполнения работы этот экземпляр уничтожается. Классы работ, как и все другие классы, могут содержать атрибуты, ассоциации, операции и даже другие работы, такие как конечные автоматы. Это является общей практикой в системах, управляющих процессами, скажем, в системах управления потоками работ или операционных системах. В нижней части Рис. 8 представлен класс работ для деятельности DELIVER MAIL с атрибутом, содержащим время выполнения каждого экземпляра DELIVER MAIL, с операцией для прекращения выполнения и с ассоциацией с используемым грузовиком. Приложения могут также помещать в класс работ конечные автоматы, чтобы описывать состояния каждого исполнения, такие как NOT_STARTED, SUSPENDED и т.д. [5, 6].

Рис. 9.Реакция на внешние воздействия в UML 2

Классы работ UML 2 позволяют определять стандартную функциональность управления процессами, хотя в самом языке UML 2 не определяются такие стандартные средства. Свойства классов работ могут быть определяться на основе стандартов прикладных областей силами поставщиков или групп пользователей в качестве повторно используемых библиотек моделей, содержащих абстрактные классы работ с нормативными атрибутами и операциями, такими как ABORT и т.д. Затем эти классы могут быть использованы как супертипы определенных пользователями работ, таких как DELIVER MAIL на рис. 9.

Резюме

Статья посвящена моделям деятельности и действий в UML 2. Рассмотрены достижения в области моделирования потоков средствами UML, структура пакетов, требуемых для создания широкого круга приложений моделирования потоков, используемый в контексте UML подход к проблемам семантики. Также изложены некоторые базовые элементы моделирования деятельности и общие принципы модели работ в UML 2.

Литература

Конрад Бок (conrad.bock@nist.gov) — эксперт в области компьютерных наук Национального института стандартов и технологии (National Institute of Standards and Technology). Руководитель рабочей группы по подготовке к выпуску версии UML 2.

Translated from «UML 2 Activity and Action Models» by Conrad Bock in Journal of Object Technology (JOT), vol.2, No. 4, pages 43-53. Translated into Russian for Open Systems Journal under special permission of the original publisher. Copyright JOT July-August 2003. Original article at http://www.jot.fm/issues/issue_2003_07/ column3.

¹ Для того чтобы модель действия соответствовала деятельности, ее следует строить на основе большего количества блоков; пока же она состоит лишь из INTERMEDIATEACTIONS и COMPLETEACTIONS. В них содержатся заранее заданные действия, такие, как создание объекта, назначение атрибутов и т.д. Абстрактное понятие действия определяется в модуле BASICACTIVITIES, поскольку он является неотъемлемой частью модели потоков.

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

³ В языке UML нет различий между объектами и данными; эти понятия сведены к единой категории — классификаторы (classifiers).

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

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

⁶ При необходимости UML 1.5 и UML 2 обеспечивают возможность работы с переменными.

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

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