Software & Systems

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

Существует большое количество промышленных платформ, ориентированных на поддержку управления процессами (IBM, BEA/Oracle, Micro­soft, Fujitsu, jBoss). Эти платформы функционируют на базе своих собственных методов представления потоков работ и процессов. Методы могут опираться на стандарты и языки описания процессов и процессных взаимодействий, зачастую расширяя и изменяя их, а могут основываться на уникальных для платформы подходах. Поэтому одной из задач является определение возможностей применения результатов теоретических модельных исследований к реальным промышленным платформам и стандартам. В данной работе делается попытка предложить методы построения автоматизированных информационных систем, основанных на управлении потоками работ и поддерживающих механизмы адаптации исполняемых процессов на базе промышленной платформы Windows Workflow Foundation (WF).

Структурный аспект проблемы обеспечения гибкого исполнения процессов

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

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

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

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

Ограничения при реализации потоков работ на базе WF

Рассмотрим принципы, на которых основывается модель исполнения потоков работ платформы WF. Модель или схема процесса WF может быть представлена в виде дерева (рис. 1), узлами которого являются составные действия (Composite Activity – CA), а листьями – атомарные действия (Activity – A). Модель состояний каждого узла описывается конечным автоматом.

Основное назначение составных действий в WF – организация потока управления выполнением действий в процессе. Каждое составное действие запускает на выполнение дочерние действия, ждет их завершения, после чего заканчивает свою работу, сигнализируя об этом родительскому составному действию, если оно имеется. Составные действия различаются по типу реализуемого потока управления. Каждому типу составного действия можно поставить в однозначное соответствие некоторую функцию планирования F(A, P), отвечающую за то, в каком порядке дочерние действия A={A1, A2, …, An} будут спланированы и запущены на исполнение при соответствующих исходных условиях (значениях параметров составного действия P={P1, …, Pn}). Результатом работы такой функции является последовательность событий E={E1, E2, …, En} типа «начать выполнение действия Ai». Таким образом, процедурная составляющая функции планирования непосредственно влияет на историю выполнения потока работ.

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

Однако остается возможной выработка критерия корректности при условии использования потока управления в рамках одного формализма. Для этого необходимо выбрать базовый метод моделирования потока управления действиями и на его основе разработать собственный тип составных действий для платформы WF. При этом выбранный формальный метод должен позволять реализовать механизм внесения изменений в исполняемые процессы.

Выбор базового метода моделирования

Платформа исполнения процессов WF инвариантна к модели, на основе которой задаются процессы [3]. Поэтому целесообразно в первую очередь выделить класс моделей, к которым будут применяться процедуры изменения схем. По причине наибольшей наглядности для пользователя наиболее предпочтительными для решения поставленных задач являются графовые модели. Основными элементами рассматриваемых моделей процессов являются узлы-действия, переходы между узлами, условия срабатывания переходов, а также маркировка узлов и переходов. За основу определения схемы процесса взят формализм маркированных WSM-сетей (Well-structured marking nets) [4], с помощью которых можно формально определять схему потока работ.

Множество S, где S=(N, D, NT, CtrlEdges, Da­taEdges, EC), называется схемой процесса (потока работ), где N – множество действий; D – множество элементов данных; NT: N→{StartFlow, EndFlow, Activity, AndSplit, AndJoin, XorSplit, XorJoin, StartLoop, AndLoop} соотносит каждый узел сети с соответствующим типом узла; CtrlEdgesÌN´N – отношения приоритета (последовательность), множество ребер (дуг) управления; LoopEdgesÌN´N – множество ребер (дуг) возврата цикла; DataEdgesÍN´D´{read, write} – множество операций чтения/записи данных меж- ду элементами данных и элементами-действия- ми; EC: CtrlEdgesÈLoopEdges→Conds(D), где Conds(D) – множество всех справедливых условий перехода, базирующихся на элементах данных из D.

На основе схемы создаются экземпляры потока работ.

Экземпляр потока работ I определяется кортежем (T, V,  DI, MS(T,V), ValS(T,V), H), где T – тип потока работ I; V – версия схемы S:=S(T, V), согласно которой I выполняется; DI включает специфичные для экземпляра I изменения (op1I, …, opmI), примененные к I; MS(T,V) и ValS(T,V) – текущая маркировка и значения элементов данных соответственно; H= – история исполнения I; это протокол информации о начале/завершении действий, чтении/записи элементов данных; Hred – редуцированная история выполнения потока (проекция множества событий на схему процесса, включающая только последнюю или текущую итерацию для каждого цикла в потоке управления).

Для данного формализма существует следующий критерий корректности структурных изменений: I согласован с S'=S+DI тогда и только тогда, когда HISred может быть воспроизведена для S' так же, как и для S.

Применение описанных формальных подходов к моделированию возможности адаптации исполняемых потоков работ при изменении схемы потоков работ описано в [4, 5]. Для реализации подобной модели в WF создадим библиотеку классов, позволяющих описывать процесс, используя рассмотренный подход и базируясь при этом на компонентной модели платформы WF.

Реализация метода на базе WF

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

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

Алгоритм функционирования базового составного действия основан на принципах, описанных в [5]. Особенность реализации в том, что любому дочернему действию может добавляться функциональность влияния на поток управления через дополнительную маркировку, реализованную на базе расширяющих свойств (Attached Dependency Property). Действие может быть помечено как расщепляющее поток управления (AND_SPLIT, XOR_SPLIT) или действие-слияние (AND_JOIN, XOR_JOIN), а также начинающее и заканчивающее цикл (BEGIN_LOOP, END_LOOP).

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

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

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

Обеспечение корректной работы с данными в процессе изменений основано на контроле механизма связывания свойств (ActivityBind) разных действий в потоке работ. Разработаны критерии корректности потока данных с учетом взаимного расположения действий в потоке управления и модификаторов доступа их связываемых свойств.

Таким образом, в работе рассмотрена возможность построения гибких потоков работ, структу-

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

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

Литература

1.   Workflow Reference Model // Workflow Management Coalition. URL: http://wfmc.org/reference-model.html (дата обращения: 20.05.2009).

2.   Rinderle S., Reichert M., Dadam P. Evaluation of correctness criteria for dynamic workflow changes. Business Process Management, LNCS 2678, Eindhoven, The Netherlands, 2003.

3.   Shukla D., Schmidt B. Essential Windows Workflow Foundation. Addison Wesley Professional. 2006.

4.   Reichert M., Dadam P. ADEPTflex – Supporting Dynamic Changes of Workflows Without Loosing Control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow Management Systems, Vol. 10, No. 2, March/April 1998.

5.   Reichert M., Rinderle S., Dadam P. On the common support of workflow type and instance changes under correctness constraints, in: CoopIS '03, LNCS, vol. 2888, Catania, Italy, 2003.