Software & Systems

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

Произвольные переходы. Важным частным случаем гибкости ТП на практике является возможность совершать непредусмотренные произвольные переходы между разрешенными состояниями ТП. Такие произвольные переходы будем называть гибкими связями.

Для решения проблемы реализации гибких связей в ТП предложен ряд подходов [2].

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

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

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

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

Дальнейшее изложение ведется на основе программного продукта с открытым кодом perl-work­flow [5] на языке Perl. Этот продукт представляет собой набор строительных блоков, предназначенных для добавления функциональности управления ТП в любую информационную систему. Этот набор особенно удобен для встраивания в интерактивные информационные системы, в частности с веб-интерфейсом. В продукте perl-workflow описание ТП понимается следующим образом.

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

–    множество разрешенных состояний;

–    множество разрешенных переходов между этими состояниями (каждому переходу ставится в соответствие действие, сопровождающее этот переход);

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

ТП должен рассматриваться в совокупности с внешним механизмом принятия решения (внешними событиями). Как правило, в качестве такого механизма выступает человек. Механизм принятия решения позволяет выбрать один из нескольких возможных вариантов перехода токена из данного состояния в какое-то иное.

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

Рассмотрим пример стандартного (негибкого) описания некоторого ТП на языке высокого уровня, применяемого в продукте perl-workflow. Это описание представлено в формате XML и почти совпадает с аналогичными описаниями ТП в других программных продуктах [2, 3].

Пример 1.

 <workflow>  <type>WF</type>  <description>Workflow definition</description>  <state name="STATE_A">   <action name="move_to_b" resulting_state="STATE_B">   </action>   <action name="move_to_c" resulting_state=" STATE_C">   </action>  </state>  <state name="STATE_B">   <action name="move_to_d" resulting_state="STATE_D">   </action>  </state>  <state name="STATE_C"><action name="move_to_d" resulting_state="STATE_D">   </action>  </state>  <state name="STATE_D">  </state> </workflow>                                                                 

Данное описание исходного ТП соответствует прямоугольникам и стрелкам, изображенным на рисунке сплошными линиями.

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

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

Для реализации этого режима предлагается расширить описание ТП, добавив в него еще одно особое состояние, соединенное с каждым из остальных по схеме «звезда». Такое особое состояние будем называть STELLA. Для этого необходимо еще на этапе разработки системы внести следующие изменения в исходное описание ТП:

–      добавить новое состояние STELLA, из которого разрешены переходы в любое другое состояние из числа предусмотренных данным ТП;

–      в описание каждого состояния добавить безусловный (то есть доступный в любой момент времени) переход в состояние STELLA.

На рисунке состояние STELLA и связанные с ним переходы показаны штриховыми линиями.

Приведем расширенный вариант описания ТП, соответствующего примеру 1.

Пример 2.

  <workflow>  <type>WF</type>  <description>Workflow definition</description>  <state name="STATE_A">   <action name="move_to_b"resulting_state="STATE_B">   </action>   <action name="move_to_c" resulting_state=" STATE_C">   </action>   <action name="over_stella" resulting_state="STELLA">   </action>  </state>  <state name="STATE_B">   <action name="move_to_d" resulting_state="STATE_D">   </action>   <action name="over_stella" resulting_state="STELLA">   </action>  </state>  <state name="STATE_C">   <action name="move_to_d" resulting_state="STATE_D">   </action>   <action name="over_stella" resulting_state="STELLA">   </action>  </state>  <state name="STATE_D">   <action name="over_stella" resulting_state="STELLA">   </action>  </state>  <state name="STELLA">   <action name="over_a" resulting_state="STATE_A">   </action>   <action name="over_b" resulting_state="STATE_B">   </action>   <action name="over_c" resulting_state="STATE_C">   </action>   <action name="over_d" resulting_state="STATE_D">   </action>  </state> </workflow>                                                                                                                                                   

Журналирование гибких ТП. Одной из важных особенностей технологии ТП вообще и продукта perl-workflow в частности является автоматическое ведение истории – последовательности всех состояний, переходов и действий для каждого токена. В системе с гибкими связями удобно иметь два типа истории. Первый тип – это история, которая видна оператору. Оператор не обязан знать о существовании состояния STELLA и связанных с ним вспомогательных переходов, ему целесообразно показывать историю в удобной для человека форме. Например, если система выполнила сложный двухшаговый произвольный переход из состояния STATE_A в состояние STELLA, а затем в состояние STATE_D, то оператору следует знать лишь о простом одношаговом переходе из состояния STATE_A в состояние STATE_D. Заметим, что в системе технически отсутствует такой одношаговый переход. Второй тип истории предназначен для администратора системы и содержит все фактически сделанные переходы, включая переходы с участием состояния STELLA.

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

Применение метода. Предложенный способ реализации произвольных переходов в ТП применим, например, в системах мониторинга. Здесь решается задача отслеживания эволюции токена, который движется по графу описания ТП. Информация об эволюции токена может поступать в систему мониторинга нерегулярно: с опозданиями, с опережением (прогнозирование), с перерывами или с нарушением хронологического порядка. Для решения задачи мониторинга каждому токену исходной системы (подчиняющемуся исходному негибкому ТП) сопоставляется парный ему токен системы мониторинга (подчиняющийся расширенному гибкому ТП, включающему состояние STELLA).

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

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

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

Литература

1.     Workflow Management Coalition. URL: http://www. wfmc.org (дата обращения: 10.09.2012).

2.     Will M.P. van der Aalst, K.M. van Hee. Workflow Management: Models, Methods, and Systems. Cambridge Massachusetts USA. MIT Press. 2002.

3.     Mohan R., Cohen M.A., Schiefer J. A state machine based approach for a process driven development of web-applications. 14-th Intern. Conf. on Advanced Information Systems Engineering, CAISE 2002, Lecture Notes in Computer Science. Berlin, Heidelberg. Springer-Verlag. 2002. Vol. 2348, pp. 52–66.

4.     Will M.P. van der Aalst,·Pesic M., Schonenberg H. Declarative workflows: Balancing between flexibility and support. Computer science research and development. Amsterdam. Springer. 2009. Vol. 23, pp. 99–113.

5.     Standalone workflow system Perl-workflow. URL: http:// search. cpan.org/dist/Workflow/ (дата обращения: 10.09.2012).