Software & Systems

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

Информация об ИсС может поступать в систему мониторинга автоматически или вводиться вручную (полностью или частично) оператором. Выдавать информацию система мониторинга также может либо автоматически, либо при частичном участии оператора. Участие оператора в работе системы мониторинга превращает ее в интерактивную.

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

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

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

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

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

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

При разработке системы мониторинга делаются следующие предположения:

–    сообщения об эволюции ТИсС могут поступать с задержками и в произвольном порядке;

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

–    непредусмотренные переходы ТИсС совершаются только между разрешенными состояниями исходного ТП;

–    сообщения не теряются, и после завершения эволюции ТИсС по прошествии разумного времени в систему мониторинга поступят все сообщения о данном ТИсС;

–    нарушения хронологии сообщений и технологической дисциплины со стороны ТИсС редки.

Архитектура и режимы работы системы мониторинга. Каналы получения информации об эволюции ТИсС не всегда позволяют автоматизировать мониторинг (например, информация может поступать в виде бумажных писем по почте). Отсюда происходит интерактивность системы мониторинга.

Будем строить систему мониторинга на основе управления ТП. Каждому ТИсС поставим в соответствие парный ему следящий токен в системе мониторинга. Эволюция следящего токена определяется тем потоком информации о ТИсС, который поступает в систему мониторинга.

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

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

–      ТП для следящего токена должен включать в себя ТП для ТИсС (чтобы в штатном режиме подсказывать оператору, в какие состояния может перейти ТИсС из текущего состояния);

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

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

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

Для администратора системы мониторинга дополнительно ведется история следящего токена, которая может не совпадать с историей ТИсС.

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

Гибкие переходы выполняются в специальном гибком режиме. Переход в этот режим оправдан в следующих ситуациях:

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

–      при поступлении ранее отсутствовавших сведений о предыдущих переходах ТИсС для указания этих сведений, а затем для перевода следящего токена обратно в актуальное состояние;

–      при фактических нарушениях исходного ТП в исходной системе.

В системе мониторинга необходимо иметь две разновидности гибких переходов следящего токена (разновидность перехода выбирается оператором непосредственно перед совершением перехода):

–      с регистрацией перехода в истории (при этом переход отражается в отчетах);

–      без регистрации перехода (такой переход не попадает в историю и отчеты).

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

Рассмотрим пример эволюции ТИсС и следящего токена, показывающий, как после получения последнего сообщения восстанавливается полная история ТИсС. На рисунке (а) представлена траектория некого ТИсС, который создается в стартовом состоянии S, а заканчивает свою эволюцию в финишном состоянии F.

Допустим, что следящий токен создается в системе мониторинга с опозданием, в тот момент, когда ТИсС уже находится в состоянии 1 (см. рис.), а сведения о предшествующей истории ТИсС у оператора отсутствуют. Затем оператору поступает сообщение о переходе ТИсС из 1 в 2. Оператор совершает служебный переход из S в 1, а затем вводит данные о переходе из 1 в 2, тем самым совершая перевод следящего токена из 1 в 2. После этого оператор получает запоздавшее сообщение о переходе ТИсС из S в 1. Оператор совершает служебный переход из 2 в S, а затем вводит данные о переходе из S в 1, тем самым совершая перевод следящего токена из S в 1, после чего возвращает следящий токен в актуальное состояние 2 с помощью служебного перехода из 1 в 2. Данные о переходах из 2 в 3, из 3 в 4, о возвращении из 4 в 2, а также о переходе в F поступают без задержек и нарушений хронологического порядка. Здесь следящий токен движется по графу почти синхронно с ТИсС.

Необычен переход из 3 в 4: он не предусмотрен исходным ТП. Для его отслеживания оператор переключил систему в гибкий режим и выполнил гибкий (но не служебный) перевод СТ из 3 в 4, сопроводив его вводом данных о переходе.

Изложенная эволюция следящего токена представлена на рисунке (б).

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

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

Чтобы избежать квадратичного (по числу состояний) роста числа дополнительных переходов, можно применить схему «звезда». При этом каждый гибкий переход совершается обязательно через специальное дополнительное состояние «звезда» в два прыжка. Транзитный переход через «звезду» происходит автоматически, оператору он представляется как гибкий одинарный переход между двумя разрешенными состояниями.

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

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

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

Предложенный метод построения интерактивных систем мониторинга на основе гибких ТП позволяет разрабатывать гибкие системы мониторинга в основном за счет описаний дополнительных ТП на языке высокого уровня. Эти дополнительные ТП строятся на основе описания ТП исходной системы по простым правилам. Гибкостью предложенная система похожа на чрезмерно гибкую систему [3]. Однако в предложенной системе сохраняется основная идея подхода управления ТП – предоставление оператору контекстно-ориентированных автоматизированных средств поддержки принятия решений и автоматическое ведение истории. При этом от оператора предложенной системы мониторинга не требуется знаний о существе ТП в ИсС, как и в жесткой системе [2].

Литература

1.     Workflow management coalition. URL: http://www.wfmc. org (дата обращения: 20.09.2012).

2.     Калабин А.Л., Пакшвер Э.А., Козлов А.В. Универсальная программа мониторинга технологических процессов // Программные продукты и системы. 2012. № 1. С. 95–99.

3.     Will M.P. van der Aalst, Weske M., Grünbauer D. Case handling: a new paradigm for business process support. Data & Knowledge Engineering. 2005. Vol. 53, pp. 129–162.

4.     Business activity monitoring from Perceptive Software. URL: http://www.perceptivesoftware.com/products/business-pro­cess-management.psi (дата обращения: 20.09.2012).

5.     Ellis C.A. and Keddara K. A Workflow Change Is a Work­flow, Business Process Management: Models, Techniques, and Em­pirical Studies, LNCS, Berlin, Springer-Verlag, 2000. Vol. 1806, pp. 218–234.

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