ОПИСАНИЕ  БИЗНЕС-ПРОЦЕССОВ  С  ПОМОЩЬЮ  ТЕХНОЛОГИИ  WWF

Cюняков  Сергей  Александрович

магистрант,  Новосибирский  Технический  Государственный  Университет,  г.  Новосибирск

E-mail: 

CREATION  OF  BUSINESS  PROCESSES  USING  TECHNOLOGY  WWF

Syunyakov  Sergey

Graduate  student  of  Novosibirsk  Technical  State  University,  Novosibirsk

АННОТАЦИЯ

Целью  данной  работы  является  рассмотрение  и  анализ  принципов  Windows  Workflow  Foundation  по  созданию  динамических  бизнес-процессов,  описание  процесса  моделирования  и  создания  классов  для  работ  с  ними. 

ABSTRACT

The  purpose  of  this  paper  is  to  review  and  analyze  the  principles  Windows  Workflow  Foundation  to  create  dynamic  business  processes,  a  description  of  the  modeling  process  and  the  creation  of  classes  to  work  with  them.

Ключевые  слова:  бизнес-процесс;  Windows  Workflow  Foundation;  разработка.

Keywords:  business  process;  Windows  Workflow  Foundation;  to  develop.

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

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

Один  из  основных  архитектурных  принципов  Windows  Workflow  Foundation  состоит  в  том,  что  специфическую  семантику  программы  всегда  определяют  отдельные  операции,  а  не  исполняющая  среда  рабочих  процессов.  Архитектура  адаптирована  к  тому,  что  разработчики  и  эксперты  в  предметной  области  будут  определять  собственные  операции,  отвечающие  специфике  этой  области.  Чтобы  специфичная  для  предметной  области  семантика  была  отделена  от  исполняющей  среды,  взаимодействие  между  операциями  и  исполняющей  средой  осуществляется  по  четко  определенному  контракту,  выраженному  в  форме  виртуальных  методов  базового  класса  Activity.

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

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

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

Рассмотрим  принципы,  на  которых  основывается  модель  исполнения  потоков  работ  платформы  WF.  Модель  или  схема  бизнес-процесса  WF  может  быть  представлена  в  виде  дерева,  узлами  которого  являются  составные  действия  (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  инвариантна  к  модели,  на  основе  которой  задаются  процессы  [1].  Поэтому  целесообразно  в  первую  очередь  выделить  класс  моделей,  к  которым  будут  применяться  процедуры  изменения  схем.  По  причине  наибольшей  наглядности  для  пользователя  наиболее  предпочтительными  для  решения  поставленных  задач  являются  графовые  модели.  Основными  элементами  рассматриваемых  моделей  процессов  являются  узлы-действия,  переходы  между  узлами,  условия  срабатывания  переходов,  а  также  маркировка  узлов  и  переходов.  За  основу  определения  схемы  процесса  взят  формализм  маркированных  WSM-сетей  (Well-structuredmarkingnets)  [1],  с  помощью  которых  можно  формально  определять  схему  потока  работ.

Множество  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.

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

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

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

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

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

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

Список  литературы:

1. Дхарма  Шукла,  Основы  Windows  Workflow  Foundation/  2-е  изд.,  перераб.  и  доп.  Издательство  «ДМК-Пресс»,  2008.  —  352  с.
2. Israel  Hilerio  Microsoft  Developer  Network  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://msdn.microsoft.com/en-us/magazine/cc163538.aspx  (дата  обращения  16.04.2013).
3. 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.  Pp.  23—39.
4. 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.  Pp.  23—39.
5. Rinderle  S.,  Reichert  M.,  Dadam  P.  Evaluation  of  correctness  criteria  for  dynamic  workflow  changes.  Business  Process  Management,  LNCS  2678,  Eindhoven,  The  Netherlands,  2003.pp.  41—57.
6. Work  flow  Reference  Model  //  Work  flow  Management  Coalition.  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://wfmc.org/reference-model.html  (дата  обращения:  17.04.2013).