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

Данная публикация журнала Journal of Object Technology открывает серию статей, посвященных модели деятельности во второй версии унифицированного языка моделирования Unified Modeling Language, а также тому, как она сочетается с моделью действий.

Конрад Бок

Данная публикация журнала 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. Вопреки используемым названиям видов узлов, узлы управления координируют в графе как поток управления, так и поток данных, а узлы объектов могут хранить как объекты, так и данные³.

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

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

25.02.2004г