ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2016 г.)
2-летний импакт-фактор РИНЦ: 0,493
2-летний импакт-фактор РИНЦ без самоцитирования: 0,389
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,732
5-летний импакт-фактор РИНЦ: 0,364
5-летний импакт-фактор РИНЦ без самоцитирования: 0,303
Суммарное число цитирований журнала в РИНЦ: 5022
Пятилетний индекс Херфиндаля по цитирующим журналам: 355
Индекс Херфиндаля по организациям авторов: 499
Десятилетний индекс Хирша: 11
Место в общем рейтинге SCIENCE INDEX за 2016 год: 304
Место в рейтинге SCIENCE INDEX за 2016 год по тематике "Автоматика. Вычислительная техника": 11

Больше данных по публикационной активности нашего журнале за 2008-2016 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2017

Технологические процессы с гибкими связями типа «звезда» для интерактивных программных систем

Workflow with flexible transitions of stellar type
Статья опубликована в выпуске журнала № 4 за 2012 год. [ на стр. 115-118 ][ 14.12.2012 ]
Аннотация:Предложен метод построения интерактивных программных систем, основанных на описании гибких технологических процессов (workflow), в которых допускается нарушение технологической дисциплины в виде непредусмотренных переходов между разрешенными состояниями. В процессе эволюции индивидуального экземпляра процесса (токена) может потребоваться изменить порядок состояний, пропустить какое-либо из них или еще раз вернуться в некоторое состояние, в котором токен уже был. Такие действия могут выполняться в особом режиме работы информационной системы. Для реализации этого режима описание исходного технологического процесса (не допускающего нарушений технологической дисциплины) заранее модифицируется путем добавления в него особых состояний и переходов. Метод в основном реализуется стандартными средствами описания технологических процессов на языке высокого уровня. При этом, с точки зрения оператора, непредусмотренный переход мало отличается от обычного перехода, и оператор может не знать того, что в основе интерактивной системы лежит описание каких-либо технологических процессов. Гибкость системы достигается в процессе ее эксплуатации, а оператор может не иметь квалификацию разработчика или аналитика. Метод изложен на примере использования программного продукта с открытым кодом perl-workflow. Предложенный способ реализации произвольных переходов в технологических процессах применим, например, в системах мониторинга. Полученные результаты расширяют область применимости информационных систем, построенных на основе технологии workflow.
Abstract:A method of building interactive software systems is proposed, which is based on flexible workflow technology. In these systems a violation of the technological discipline is allowed, which comprise unforeseen transitions between the allowed states. During the evolution of the individual workflow instance (token) it may be needed to change the order of the states, to skip some state or to return again to a state in which the token has already been. These actions can be performed in a special operation mode of the information system. To implement this mode an initial description of workflow (which does not allow for violation of the technological discipline) should be in advance modified the addition of special states and transitions. The method is mainly implemented using standard definition of workflow in a high level language. In this case, from the point of view of the operator, unforeseen transition is barely different from the usual transition, and the operator may not be aware of the fact that the interactive system is based on workflow technology. The flexibility of the system is achieved in the course of its operation, and the operator does not need to be a qualified developer or analyst. The method is presented with an example of the open source software called perl-workflow. The proposed method of implementing unforeseen transitions in workflow is applicable, for example, in monitoring systems. These results extend the range of applicability of information systems based on workflow technology.
Авторы: Вышенский С.В. (svysh@pn.sinp.msu.ru) - Научно-исследовательский институт ядерной физики им. Д.В. Скобельцына Московского государственного университета им. М.В. Ломоносова, г. Москва, , , кандидат физико-математических наук, Дубенская Ю.Ю. ( jdubenskaya@pn.sinp.msu.ru) - Научно-исследовательский институт ядерной физики им. Д.В. Скобельцына Московского государственного университета им. М.В. Ломоносова, г. Москва, ,
Ключевые слова: открытый код., мониторинг, переходы, состояния, гибкие связи, граф, информационная система, технологический процесс
Keywords: open source, the automated information system, actions, states, flexible routes, graph, information system, technological process
Количество просмотров: 3928
Версия для печати
Выпуск в формате PDF (9.63Мб)
Скачать обложку в формате PDF (1.26Мб)

Размер шрифта:       Шрифт:

Управление технологическими процессами (ТП) – 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).


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=3322
Версия для печати
Выпуск в формате PDF (9.63Мб)
Скачать обложку в формате PDF (1.26Мб)
Статья опубликована в выпуске журнала № 4 за 2012 год. [ на стр. 115-118 ]

Возможно, Вас заинтересуют следующие статьи схожих тематик: