A FUML-based Distributed Execution Machine for Enacting Software Process Models

Ralf Ellner, Samir Al-Hilank, Johannes Drexler, Martin Jung, Detlef Kips, and Michael Philippsen. 2011. A FUML-based distributed execution machine for enacting software process models. In Proceedings of the 7th European conference on Modelling foundations and applications (ECMFA'11), Robert B. France, Jochen M. Kuester, Behzad Bordbar, and Richard F. Paige (Eds.). Springer-Verlag, Berlin, Heidelberg, 19-34.

Процессы разработки программного обеспечения (SDP) являются важной составляющей создания сложных высококачественных систем или ПО. Существует большое количество различных языков моделирования процессов, пригодных для описания SDP. Одним из них является SPEM, использующий графическую нотацию языка UML. Подобный подход удобен, однако позволяет моделировать только статические структуры, в то время как реализуемость моделей могла бы быть полезной для валидации моделируемых процессов. Кроме того машина исполнения (process execution machine PEX) могла бы помогать и направлять разработчиков ПО.

Авторами данной статьи было предложено расширение SPEM: eSPEM, которое кроме стандартных понятий UML предоставляет специфические возможности, необходимые при разработке ПО. Для обеспечения возможности реализации языка eSPEM, необходимо определить его операционную семантику, для чего может быть использован FUML. Однако такой подход не позволяет производить распределенное выполнение процессов, что требуется для работы команды. Для реализации необходимых при разработке ПО возможностей машина исполнения, основанная на FUML, должна:

• отправлять информацию о состоянии запущенного экземпляра процесса различным узлам сети (Т1),
• приостанавливать и возобновлять выполнение на разных узлах (Т2),
• взаимодействовать с персоналом (Т3),
• адаптироваться к требованиям различных команд (Т4).

Причины невозможности реализации распределенного выполнения средствами FUML:

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

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

1.Для управления экземпляром модели выполнения использовался репозиторий моделей CDO (Connected Data Objects). CDO предоставляет прозрачный доступ к модели по сети, транзакции для безопасной распределенной работы с моделью, а также позволяет предоставлять узлам сети информацию о состоянии запущенного экземпляра процесса разработки ПО, что удовлетворяет (Т1).

2.Использование транзакций требует внесения некоторых изменений в семантику FUML. Во-первых, инициирование перехода выделяется в отдельную транзакцию, которая включает перемещение меток от одного узла к другому и выполнение поведения, определенного на узле-цели, что решает проблему (П1). Во-вторых, переходы по сети инициируются с помощью системных событий: в зависимости от типа событий машина исполнения проверяет, какие переходы могут быть инициированы, и запускает их. Транзакции запускаются одновременно, если их начальные и конечные позиции различны. Также гарантируется, что если у нескольких транзакций совпадает один из узлов, хотя бы одна из них будет совершена, другие транзакции не инициируются, что обеспечивает правильное распределение меток. Это решает проблему (П2). Кроме того, подобные изменения соответствуют второму требованию (Т2).

3.Часто процесс разработки ПО моделируется не полностью, вследствие чего при выполнении необходимо вмешательство разработчиков. Для реализации взаимодействия с персоналом (Т3) был добавлен абстрактный класс Request. Если для принятия решения не хватает входных данных, выполнение приостанавливается и создается запрос. Персонал может обработать его посредством графического пользовательского интерфейса PEX, после чего запрос удаляется и возобновляется выполнение. Рассмотрим наследников абстрактного класса Request.

• DecisionRequest используется, если невозможно автоматически определить необходимое входное значение,
• ObtainObjectReferenceRequest используется, если для продолжения выполнения необходимо определить объект,
• ExecutionRequest используется, если WorkDefinition, который должен быть выполнен, не имеет смоделированного поведения.

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

Для тестирования предложенной реализации операционной семантики eSPEM был разработан ряд тестов. Наряду с функциональными тестами была проведена оценка времени выполнения. Для этого на основе фреймворка Scrum был создан пример SDP. Тестирование проводилось на 6 ПК, соединенных локальной сетью. Один ПК использовался как сервер для экземпляра модели выполнения и машины исполнения. Остальные компьютеры являлись клиентами и симулировали взаимодействие с персоналом, отвечая на запросы. На каждом из них одновременно запускались 1, 2, 3, 10 и 20 клиентов машины исполнения. Тесты показали, что время выполнение транзакций менее 100 мс, что является приемлемым временем ответа для взаимодействия с человеком.

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

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

В статье описаны некоторые подходы, основанные на стандартизованных высокоуровневых языках моделирования.

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

Bendraou и др. разработали xSPEM, фокусируясь на валидации SDP с использованием временных сетей Петри. Также это расширение поддерживает события, однако ему недостает возможности моделирования поведения на достаточно низком уровне. Кроме того, не обеспечена возможность прямого выполнения разработанных моделей.

Seidita и др. расширили SPEM для поддержки моделирования агентно-ориентированных методологий, но не уделили внимание реализуемости.

UML4SPM расширяет SPEM с помощью концепций моделирования поведения UML 2.0. Существует два способа сделать модели, основанные на UML4SPM, выполнимыми. Во-первых, для этого можно использовать WS-BPEL, но он обладает рядом недостатков, описанных выше. Во-вторых, операционная семантика UML4SPM может быть определена на основе FUML. Было предложено несколько реализаций, ни одна из которых не предоставляет распределенное выполнение.

Di Nitto и др. моделируют SDP посредством фреймворка, основанного на UML 1.3. Для определения языка они использовали только UML. Остается непонятным, каким образом с помощью данного фреймворка проводить моделирование некоторых естественных аспектов процессов разработки ПО (например, предшествование действий).

Chou использует набор диаграмм классов и деятельности (UML 1.4) для графического моделирования SDP. Он предложил низкоуровневый объектно-ориентированный язык программирования процессов для выполнения SDP, однако код на основе диаграмм необходимо создавать вручную.

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

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

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

Benyahia и др. предложили расширение FUML для моделирования систем реального времени (составление графика работ, параллельное их выполнение), но они не предоставили возможности распределенного выполнения.

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

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

Atkinson and Kühne предложили так называемый метод глубокой инстанциации, который позволяет помечать элементы моделей типов положительными числами (мощностью). На каждом шаге инстанциации мощность уменьшается на1. Если мощность элемента равна единице, то он ведет себя как объект. Это достаточно универсальный подход, но его применения к UML или SPEM проблематично.