Содержание к диссертации
Введение
ГЛАВА 1. Информационные системы в управлении бизнес-процессами организации 11
1.1 Системы управления бизнес-процессами 11
1.2 Определения и основные понятия предметной области управления бизнес-процессами 15
1.3 Классификация систем управления бизнес-процессами 20
1.4 Требования к системам управления бизнес-процессами 23
1.5 Применение принципов сервис-ориентированной архитектуры в системах управления бизнес-процессами... 25
1.6 Стандартизация систем управления бизнес-процессами 29
1.6.1 Языки описания процессов 29
1.6.2 Стандарты графического представления бизнес-процессов 33
1.6.3 Базовая модель системы управления потоками работ 37
1.7 Анализ и сравнительные характеристики систем управления бизнес-процессами 40
Выводы по ГЛАВЕ 1 42
ГЛАВА 2. Поиск структурных конфликтов в графах процессов 43
2.1 Постановка задачи 44
2.2 Известные решения по верификации графов 53
2.2.1 Верификация приведением графа процесса к эквивалентной граф-схеме параллельного алгоритма 53
2.2.2 Алгоритм редукции графа процесса 64
2.2.3 Алгоритм петрификации графа процесса 71
2.3 Алгоритм поиска циклов в графе процесса 76
2.4 Алгоритм верификации структурных конфликтов на основе экземплярного подхода 81
2.5 Испытание алгоритма верификации 89
2.6 Анализ сложности алгоритма верификации 91
Выводы по ГЛАВЕ 2 93
ГЛАВА 3. Анализ доступа к данным в графах процессов 94
3.1 Взаимодействие сервисов с атрибутами рабочих объектов 94
3.2 Правила корректности доступа сервисов к данным 98
3.3 Алгоритм обнаружения исключительных ситуаций, связанных с доступом к данным в графе процесса 103
3.4 Алгоритм поиска информационно-независимых действий 116
Выводы по ГЛАВЕ 3 121
ГЛАВА 4. Реализация компонент системы управления бизнес-процессами 122
4.1 описание и структура ASYSBPM 122
4.2 Процессная модель ASYSBPM 125
4.3 Типы действий в процессе 127
4.4 Конструктор процессов ASYS DESIGNER 128
4.5 Верификация схем процессов в ASYS DESIGNER 132
4.6 Автоматический обработчик экземпляров процессов asys engine 137
4.7 Монитор процессов asys monitor 140
4.8 Выполнение процесса в asys врм 144
Выводы по ГЛАВЕ 4 149
Выводы 150
Список литературы
- Классификация систем управления бизнес-процессами
- Стандартизация систем управления бизнес-процессами
- Верификация приведением графа процесса к эквивалентной граф-схеме параллельного алгоритма
- Правила корректности доступа сервисов к данным
Введение к работе
Современная ситуация в экономике характеризуется большой конкуренцией среди компаний. Особенно это характерно для компаний, занятых в сфере высоких технологий. Рынок требует от них большей гибкости к изменяющимся условиям, таким, например, как потребительский спрос или появление новых технологий. Успех бизнеса в современных условиях напрямую зависит от способности компаний приспосабливаться к внутренним и внешним изменениям, прямо или косвенно затрагивающих их деятельность. В такой ситуации первостепенным становится решение проблемы повышения эффективности корпоративного управления. Эффективность корпоративного управления во многом зависит от используемого подхода к управлению.
Традиционным является функциональный подход к управлению, рассматривающий организацию как совокупность отделов, выполняющих те или иные функции. Управление организацией заключается, при таком подходе, в распределении работ между функциональными отделами. Следствием данного подхода является обособление функциональных подразделений и ограничение межфункциональных связей [17]. Руководители отделов в организации, управляющие функциональными подразделениями, стремятся, прежде всего, оптимизировать деятельность в области своей ответственности, что, в конечном счете, может привести к замещению стратегической цели компании целями ее подразделений. Такая тенденция существенно сказывается на показателях эффективности всей компании.
Стало очевидным, что существует противоречие между организационной структурой и задачами, реализуемыми компанией. Поэтому вместо традиционного подхода во многих компаниях применяется подход, называемый процессным или процессно-ориентированным, который рассматривает компанию как совокупность реализуемых бизнес-процессов. Термин "бизнес-
процесс" в настоящее время не имеет однозначного определения. В стандарте ISO 9001:2000 бизнес-процесс трактуется как "устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя" [16]. Главная идея здесь заключается в том, что любой БП имеет потребителя, внутреннего или внешнего по отношению к организации. Таким образом, можно все действия внутри организации рассматривать либо как БП, либо как его часть. Процессный подход позволяет разделять БП на несколько стадий обработки, назначать ответственных за выполнение данных стадий, а также направлять соответствующие ресурсы для их выполнения. Этот подход дает следующие преимущества по сравнению с традиционным:
управление БП предоставляет условия для лучшего контроля за выполнением внутренних работ и использованием ресурсов;
определение границ БП, а также поставщиков и потребителей, дает возможность улучшить взаимодействие и понимание требований, которые должны быть выполнены компанией перед партнерами;
процессный подход позволяет сфокусировать усилия всех исполнителей БП на задаче, реализуемой в данном БП;
процессный подход позволяет лучше понять взаимосвязи отдельных аспектов деятельности компании и повысить ее эффективность.
В пользу процессного подхода также говорит и то, что он используется во многих методиках системы менеджмента качества, например, таких, как: ISO 9000, Capability Maturity Model (CMM), EFQM, 6sigma и т.д.
Однако сам по себе процессный подход необходим, но недостаточен для повышения эффективности бизнеса. Достаточно сложно контролировать каждую из стадий выполняемых БП вручную. Поэтому для полноценной
реализации процессного подхода необходимы соответствующие информационные системы, называемые системами управления бизнес-процессами (СУБП). Эти системы призваны автоматизировать БП, выполняемые в организации и отслеживать их показатели. В настоящее время множество компаний разрабатывает программное обеспечение для информационной поддержки бизнес-процессов в организации. Методической основой данных разработок являются работы таких зарубежных исследователей, как Вил ван дер Аалст (Wil van der Aalst), Кейс ван Хей (Kees van Нее), Л. Фишер (L. Fischer), M. Папазогло (М. Papazoglou), Д. Чаф (D. Chaffey), Ф. Лейман (F. Leymann), Д. Роллер (D. Roller). Среди отечественных исследователей данного направления необходимо отметить работы Серебрякова В. А., Бездушного А. Н., Шундеева А. С.
Несмотря на активное развитие в области СУБП существуют задачи, которые являются по-прежнему актуальными. Это, прежде всего совершенствование алгоритмического обеспечения, используемого в данных системах. Одной из главных задач является разработка эффективных алгоритмов проверки корректности графов процессов.
Актуальность темы исследования определяется распространением СУБП в организациях, и недостаточным уровнем исследований, касающихся алгоритмического обеспечения в данных системах. В большинстве СУБП отсутствуют возможности по анализу процессов на этапе проектирования, что при выполнении процесса может привести к таким исключительным ситуациям как тупик, недостаток синхронизации или зацикливание в процессе. Также, существующие СУБП не поддерживают проверку процесса на корректность доступа к данным при выполнении действий процесса, что может быть причиной остановки процесса или неэффективного использования ресурсов процесса. Особую важность эта тема приобретает в связи с распространением процессного подхода к управлению во многих организациях и
все большей необходимостью в эффективных программных средствах, способных реализовывать данный подход.
Целью диссертационной работы является разработка и реализация алгоритмического и программного обеспечения СУБП, позволяющего выявлять исключительные ситуации, которые могут возникнуть в процессе при его выполнении в СУБП, а также позволяющего повысить эффективность использования ресурсов процесса и исключить возникновение ошибок, связанных с доступом к данным в действиях процесса. Для достижения поставленной цели в работе решаются следующие задачи:
исследование стандартов в области СУБП и выбор наиболее подходящего стандарта для представления графических объектов в системе проектирования процесса;
исследование существующих методов верификации графов процессов;
создание метода поиска некорректных циклов в графах процессов;
разработка и реализация метода верификации графов процессов;
создание метода анализа корректности доступа к данным в действиях процессов;
создание метода поиска информационно-независимых действий в графах процессов;
разработка и реализация программных компонент СУБП Asys ВРМ, предназначенных для создания описаний процессов, анализа описаний процессов на корректность, поддержки выполнения процессов и анализа результатов выполнения процессов.
Объектом исследования являются системы управления бизнес-процессами организации, обеспечивающие информационную поддержку выполнения бизнес-процессов и позволяющие проводить статистический анализ результатов их выполнения.
Предметом исследования является алгоритмическое и программное обеспечение систем управления бизнес-процессами.
Методы исследования. Методологической основой и общетеоретической базой исследования являются принципы системного анализа и проектирования, теория графов, теория сетей Петри.
Научная новизна заключается в следующем:
1. доказана разрешимость проблемы корректности графов процессов путем сведения данной проблемы к проблеме корректности граф-схем параллельных алгоритмов.
2. предложен метод обнаружения некорректных циклов, что позволяет выявлять такие ситуации при выполнении процесса, как тупиковая ситуация или зацикливание процесса.
3. предложен специализированный алгоритм верификации графа процесса на основе экземплярного подхода, который предназначен для выявления структурных конфликтов вида тупик или недостаток синхронизации в графе процесса.
4. доказана разрешимость проблемы обнаружения конфликтных ситуаций, связанных с доступом к данным процесса, что позволяет исключить возникновение подобных ситуаций во время выполнения процесса.
5. предложен алгоритм распараллеливания процессов в СУБП с участием человека при выполнении действий процесса.
Практическая ценность заключается в создании инструментальных средств, входящих в состав СУБП Asys ВРМ и используемых при проектировании процессов, анализе корректности построенных процессов, поддержке выполнения процессов, мониторинге выполнения процессов и анализе результатов выполнения процессов. Разработанные инструментальные средства позволяют выявлять в спроектированном процессе структурные конфликты, исключить ошибки, связанные с некорректным доступом к данным, а также повысить эффективность выполнения процесса за счет распараллеливания его действий.
Апробация работы. Результаты работы докладывались и обсуждались
при проведении:
XVI международной научно-технической конференции "Информационные средства и технологии" Московского энергетического института (г. Москва, 2008).
XII всероссийской межвузовской научно-технической конференции студентов и аспирантов "Микроэлектроника и информатика - 2005" Московского государственного института электронной техники (технического университета).
XIII социологических чтений Российского государственного социального университета (г. Москва, 2006).
Зимних научных чтений факультета социологии и информационных технологий Российского государственного социального университета (г. Москва, 2006).
научных семинаров кафедры программного обеспечения вычислительной техники Российского государственного социального университета.
собраний в компании "АСис Софт".
Реализация и внедрение. Результаты работы используются при поддержке выполнения бизнес-процессов в Комитете по развитию предпринимательства Московской области, предприятии "СУБМИКРОН" (г. Зеленоград), в компании "АСис Софт",
Публикации. По теме исследования опубликовано 8 печатных работ.
Объем и структура диссертации. Диссертация состоит из введения, четырех глав, заключения, списка литературы и пяти приложений. Основное содержание диссертационной работы изложено на 151 листах машинописного текста, иллюстрированного таблицами и рисунками.
Классификация систем управления бизнес-процессами
Опишем функциональные основные требования, выдвигаемые специалистами аналитической компании "Gartner" [70], которым должны соответствовать СУБП: Поддержка задач, выполняемых как людьми, так и автома тическими обработчиками. В системе должны присутствовать гибкие инструменты по управлению ресурсами, как людскими, так и программными. Простота использования и администрирования. Ключевой фактор успеха СУБП — запуск бизнес-процесса в эксплуатацию минуя продолжительный этап разработки. Обязательное требование — это наличие графических средств разработки схемы бизнес-процесса. Производительность и масштабируемость. СУБП должна иметь возможность обслуживать многочисленные, сложные и продолжительные процессы. Управляемость. В данном случае подразумевается как можно меньшее участие технического персонала в эксплуатации и администрировании. Выполнение административных функций должно быть доступно обычным пользователям через удобный интерфейс, включая управление пользователями и группами, изменение бизнес-процессов. Мониторинг. В СУБП необходимо наличие таких функций, как: извещение о системных событиях, информирование в реальном времени о показателях выполнения процессов. Интероперабельность. Интероперабельность (англ. interoperability) — это способность информационной системы к взаимодействию с другими системами [18]. В СУБП необходимо наличие программных интерфейсов для доступа к функциям данной системы из других программ. Наличие готовых шаблонов процессов. Готовые шаблоны процессов для определенных отраслей (например, финансов, здравоохранения или машиностроения) и определенных управленческих методологий позволяют значительно ускорить реализацию бизнес-процессов в организации.
Наиболее перспективным подходом к интеграции информационных систем является построение данных систем в соответствии с принципами сервис-ориентированной архитектуры. Этот подход рассматривается далее.
СУБП позволяет выполнять и быстро изменять описания БП, реализуемые в системе. Однако часто, помимо изменения описаний БП, возникает необходимость в изменении механизмов работы с данными описаниями. Прежде всего, это касается механизмов поддержки выполнения действий. Как правило, большинство действий, реализуемых в процессах являются полуавтоматическими, т. е. выполняются человеком, использующим программный модуль. С появлением или изменением БП организации становится необходимым реализовывать и автоматизировать новые действия, характерные для данных БП. Автоматизация действий требует создания и включения в информационную структуру программных модулей, поддерживающих работу с данными элементами процесса. Возможность модернизации СУБП за счет программных модулей неизбежно отражается на требованиях к архитектуре данной информационной системы. Таким образом, СУБП должна поддерживать гибкость не только в управлении процессами, но и функциональную гибкость, связанную с изменением и добавлением в систему функций, реализуемых программными модулями.
На сегодняшний день большинство современных СУБП построены в соответствии с принципами сервис-ориентированной архитектуры (СОА — по англ. Service-Oriented Architecture). Согласно определению специалистов корпорации IBM [53]: "СОА — это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовывать тот или иной бизнес-процесс".
Фактически, сервис в СУБП — это программный модуль позволяющий реализовывать выполнение автоматических и полуавтоматических дей ствий. СУБП при этом представляет собой совокупность сервисов и отдельных приложений. При таком подходе, сервисы могут добавляться в систему или изменяться разработчиками, что позволяет расширять технические возможности всей СУБП. Автоматизация отдельных действий с помощью сервисов делает возможным сократить затраты на выполнение экземпляра процесса. Следует отметить, что концепция СОА противоречит превалировавшей до недавнего времени концепции монолитного программного обеспечения, где большинство функций сосредоточено в едином приложении. Появление СОА — это закономерный этап в эволюции программного обеспечения. Данный этап связан с переходом от программирования и перепрограммирования информационных систем, в соответствии с меняющимися требованиями к ним, к сборке данных систем из отдельных программных компонент. В будущем, это позволит интегрировать программные системы, находящиеся не только внутри предприятий, но и системы различных предприятий. Такая интеграция даст возможность сократить издержки на коммуникацию сотрудников предприятия (предприятий), что может сказаться на стоимости поставляемого товара или предоставляемых услуг.
Стандартизация систем управления бизнес-процессами
Различными инициативными группами и организациями по стандартизации был предложен ряд языков для описания процессов в СУБП. Задача данных языков — формальное описание бизнес-процессов: задание его возможных состояний, в которых определены соответствующие действия, определение набора внутренних переменных, связывание действий бизнес-процесса с соответствующими внешними приложениями и ролями пользователей и т. д. Практически все из этих языков основаны на синтаксисе XML. Наиболее известными и распространенными из этих языков являются следующие: XPDL (Workflow Management Coalition) [90]; BPML (Business Process Management Initiative) [65]; . BPEL4WS (коалиция OASIS) [67];
Коммерческие системы управления БП тяготеют к языку BPEL4WS, в то время как программные системы с "открытым" исходным кодом (OpenSource), как правило, реализуют язык XPDL (и другие стандарты коалиции WfMC). Некоторые системы поддерживают экспорт определений бизнес-процессов при помощи нескольких спецификаций.
Приведем основные характеристики данных языков.
Язык XPDL (англ. XML Process Definition Language) описывает рабочий процесс как направленный граф, узлами которого являются активности (Activity), связанные между собой переходами (Transition). Существует три типа элементов Activity: Route, Implementation, BlockActivity. Тип Route определяет узлы, не выполняющие действий, они используются в целях маршрутизации рабочих объектов. Implementation - это активности, с которыми связаны действия в бизнес-процессе. BlockActivity — это узел-контейнер, содержащий в себе не имеющую разветвлений последовательность активностей. Существует три варианта Implementation: узел взаимодействия с пользователем; узел взаимодействия с внешним приложением; узел, запускающий подпроцесс.
Переходы (Transition) между активностями могут быть как условными, так и безусловными. Для условного перехода в описании процесса содержится запись условия прохождения рабочего объекта. Переход может соединять любые два узла, то есть бизнес-процессу может соответствовать граф любой сложности и топологии. В частности, в графе бизнес-процесса допустимы циклы. В начале описания процесса находятся спецификации типов (тег TypeDeclaration). Для описания данных, относящихся к процессу, и параметров, передаваемых и возвращаемых приложениями, используются элементы DataField и DataType. Кроме того, в XPDL существует понятие, как ExtendedAtributes — оно дает возможность расширять язык путем ввода дополнительных типов переменных. Это делает возможным определять набор элементов и атрибутов, специфичных для конкретной сферы его применения.
BPML (англ. Business Process Modeling Language) представляет собой язык, который ориентирован прежде всего на координацию работы веб-сервисов. В отличие от XPDL, он принадлежит к так называемым структурно-ориентированным языкам: бизнес-процесс в BPML соответствует не математическому графу, а иерархическому набору вложенных и последовательных тегов. Архитектура связей в данном языке определяется вложенностью тегов, соответствующих элементам Activity, — в BPML нет понятия Transition. Элементы Activity могут соединяться последовательно или вкладываться один в другой. Соответственно Activity могут быть простыми (не содержащими других Activity) или сложными. В описании языка указано, что бизнес-процесс является специальным типом сложной Activity. Всего существует 17 типов простых Activity. Основной тип простой Activity называется Action. Когда управление бизнес-процессом попадает в Activity этого типа, происходит вызов описанных там веб-сервисов. Сущетсвуют типы Activity, соответствующие ветвлению процесса (ветвление относится только к содержащимся внутри них Activities), — это Switch и All Activities. Также есть ти пы Activities, которые запускают дочерние процессы (как с ожиданием их окончания, так и без), организуют задержки выполнения процесса и т. д. Несколько типов Activities предназначены для реализации разного рода циклов. Для синхронизации рабочих объектов, находящихся в Activities одного уровня вложенности, в языке используются сигналы (Signals). В BPML также введены понятия "исключение" (Exception) и "компенсация" (Compensation). "Исключение" соответствует возникновению нештатной ситуации, когда оказывается, что выполнять некоторый участок бизнес-процесса уже не требуется. "Компенсация" соответствует необходимым действиям по корректному завершению ситуации, возникшей в связи с Exception. BPML имеет ряд недостатков, одним из которых является то, что в языке нет возможностей по определению исполнителей Activity — данные функции возложены на технологию веб-сервисов. Кроме того, в BPML не определен синтаксис конструкций для взаимодействия процесса с внешними приложениями: здесь тоже используется технология веб-сервисов.
Язык BPEL4WS (англ. Business Process Execution Language for Web Services) также ориентирован на организацию работы с веб-сервисами. Данный язык во многом похож на BPML, однако существенно сложнее его. BPEL4WS появился путем слияния языков описания процессов WSFL и XLANG. Эти языки основаны на разных моделях: WSFL базируется на теории графов, XLANG — на иерархии тегов XML. BPEL4WS унаследовал конструкции обоих языков. Например, он допускает реализацию некоторых конструкций в двух вариантах: в стиле WSFL и в стиле XLANG. В некоторых случаях допустим и смешанный стиль. BPEL4WS определяет два вида процессов — абстрактный и исполняемый. Абстрактный процесс определяет протокол обмена сообщениями между различными участниками, не определяя алгоритмы их внутреннего поведения.
Верификация приведением графа процесса к эквивалентной граф-схеме параллельного алгоритма
Группа строк (столбцов) в матрице С, соответствующая оператору А, 1 г р, имеет kr строк (kr" столбцов) по числу точек входа (точек выхода) оператора А. Стоящий на пересечении 1-ой строки оператора Ai и j-ro столбца оператора Aq элемент равен 1 или 0 в зависимости от того, соединяет или нет дуга і-ую точку выхода оператора Ai с j-ой точкой входа оператора Aq.
Определение 6. Граф-схемой ПА называется граф-схема, имеющая один начальный (не имеющий входящих дуг) и один конечный (не имеющий исходящих дуг) операторы, и каждый оператор граф-схемы лежит на некотором пути из начального оператора в конечный.
Каждому оператору при практическом использовании языка граф-схем ПА сопоставляется подпрограмма со многими входами (выходами) на выбранном языке программирования процедурного типа (языке интерпретации). Каждой точке входа в оператор сопоставляется точка входа в подпрограмму, причем, в общем случае, различным точкам входа в оператор может сопоставляться одна и та же точка входа в подпрограмму, а каждой точке выхода из оператора — некоторая точка выхода из подпрограммы. Оператор считается готовым для выполнения по некоторой точке входа (или по КГВх), если выполнены все НП-операторы, относящиеся к этой КГВх, причем дуги КГВых; соответствующие осуществленным выходам из подпрограмм НП-операторов, принадлежат рассматриваемой КГВх. Контроль готовности операторов осуществляется после завершения выполнения каждого оператора ПА. Если оператор имеет несколько КГВых, то при завершении работы данного оператора используется только один КГВых. Выполнение граф-схемы ПА всегда начинается с начального оператора. Процесс выполнения граф-схемы ПА считается оконченным, если исчерпан список готовых для выполнения операторов, либо последний выполненный оператор есть конечный оператор граф-схемы ПА.
Определение 7. Граф-схема ПА называется корректной, если для всякого ее выполнения:
а) ни один из единичных элементов ее матричного представления не может иметь более одной метки для произвольного момента времени выполнения граф-схемы ПА;
б) ни один из операторов граф-схемы ПА не может быть повторно занесен в список готовых для выполнения операторов до окончания его очередного выполнения;
в) ПА всегда завершается выполнением конечного оператора.
Перейдем к строгому определению модели выполнения ПА. Сопоставим произвольной граф-схеме G следующие множества:
1) М (G) — множество операторов G, которые ниже будем обозначать АО, А1 Ак, где через АО и Ак обозначаются начальный и конечный операторы G соответственно;
2) М (G) — множество элементов вида AI(lli) для всяких I, i, j, таких, что І є {1, 2, ...,k }, і є {1, 2, ..., Пі}, j є {1, 2, ..., тіиі }, где Пі - количество КГВх опе ратора АІ, ті);і - количество входов в і-ой КГВх оператора АІ;
3) M (G) — множество элементов вида AI для всяких I, j, таких, что І є {1, 2..., k}, j є {1,2,..., pi}, где pj— количество КГВых оператора AI;
4) М (G) — множество всевозможных пар наборов элементов, принадлежа щих множествам М (G) и М (G). Элементы М (G) ниже обозначаются (М P(G) / Mq(G)), где MP(G) и Mq(G) - произвольные наборы элементов мно жеств М (G) и М (G) соответственно, р и q — элементы натурального ряда чисел N, относительно которого задана нумерация наборов элементов мно жеств М (G) и М (G). Пустые наборы элементов множеств M(G) и M(G) обо значаются символом X.
Каждое состояние Si, і є N, процесса выполнения граф-схемы ПА G идентифицируется парой (Mj(G) / Mi(G)), являющейся элементом множества
М (G) и обозначаемой ниже M;(G). В наборе M;(G) перечислены одновременно выполняемые операторы G в состоянии S;. В наборе М ;(G) перечислены ассоциированные с S, операторы, имеющие КГВх, не для всех входов которых вычислены фактические параметры, причем для всякого АІ к) є М ;(G) индексы j и к задают соответственно номер КГВх оператора AI и номер входа в этой КГВх, для которой вычислены фактические параметры. Начальному состоянию So соответствует элемент М o(G) = (АО/А,).
Всякий переход из Si в Sj, і, j є N, осуществляется по завершении выполнения одного или нескольких операторов, выполняемых в S;. Этот переход определяется некоторым набором М у элементов множества М (G), в котором перечислены операторы, завершившие выполнение в S;. При этом для всякого Alk индекс к задает номер КГВых, по которой осуществлен выход из состояния Sj после завершения выполнения оператора AI.
Правила корректности доступа сервисов к данным
Введем математическое описание правил корректности доступа к данным, которым должен соответствовать граф процесса с назначенными сервисами, для избежания возникновения исключительных ситуаций.
Пусть: А= {0, 1,..., п} — это множество действий определенного процесса, А — это подмножество множества А, содержащее номера действий, выполняемых сервисами, A zA. В процессе изменяется рабочий объект одного типа, обработка которого ведется от начального действия к конечному. Каждый рабочий объект характеризуется множеством атрибутов Р={0,1,...,к}. Для каждого действия A .(l j m) существует сервис Sj, кото рый входит во множество всех сервисов S={ Si, S2, .-., Sm}, используемых в
Процессе. КаЖДЫЙ СерВИС Sj (\ j m) ЯВЛЯеТСЯ МНОЖеСТВОМ Sj={Sij, S2j,---, Skj}, где Sy (! / )— это тип обращения к 1-му атрибуту рабочего объекта: s, e{w,r,n), где w — изменение атрибута, г — чтение атрибута, an — отсутствие действий с атрибутом. Также, существует множество всех определений масок доступа в процессе D={Di, D2, ..., Dm}, где маска доступа с индексом і (1 / т) является множеством Dj={dn, d2i,..., dkj}, где dzi (і z k) — это ограничение на обращение со стороны сервиса Sj к z-му атрибуту рабочего объекта: dzi s{w,r,n}, где w — ограничение на изменение атрибута, г — ограничение на чтение атрибута, an — полный запрет на доступ к атрибуту. Таким образом, каждое действие, выполняемое сервисом, характеризуется множеством доступа к атрибутам рабочего объекта и множеством ограничений на данный доступ.
Для корректного выполнения процесса должны удовлетворяться следующие правила, касающиеся последовательности состояний рабочего объекта с доступом к атрибутам:
1. Ограничение масок доступа для всех действий должны совпадать с типами обращений к атрибутам рабочего объекта сервисов этих действий: V/(l j т),V/(l і к) должно быть d-. = s..;
2. Для всякого действия, сервис которого читает атрибут /, должно существовать предшествующее ему действие, в котором данный атрибут определяется: V/(l j т),V/(l і к), таких, что07 = dH = r)3t(l t j) и и ,такое, что sit=djt=w;
Рассмотренные правила по доступу к атрибутам рабочего объекта характеризуют исключительные ситуации при последовательном выполнении автоматических и полуавтоматических действий. Однако при параллельном выполнении действии также могут возникать исключительные ситуации, связанные с доступом к атрибутам рабочего объекта. Покажем это на примере процесса рассмотрения коммерческого предложения, представленного на рис. 37.
Следует отметить, что все действия данного процесса выполняются с помощью полуавтоматических сервисов. В рамках данного процесса действие генерального директора "Рассмотреть предложение" параллельно таким действиям секретаря, как "Сканирование документа" и "Распознавание изображения". При этом сервис полуавтоматического действия "Рассмотреть предложение" читает атрибут рабочего объекта "Ссылка на распознанный документ", который определяется с помощью сервиса действия "Распознавание изображения". Следует отметить, что при обработке в параллельных действиях рабочий объект с атрибутами не дублируется. Таким образом, действия могут получать доступ к атрибутам, которые определяются в других действиях, параллельных данным. Если документ не был распознан до запуска сервиса действия "Рассмотреть предложение", то это вызовет ошибку данного сервиса, поскольку атрибут, читаемый им не будет иметь определенного значения. Такая ситуация может быть причиной остановки выполнения процесса.
В том случае, если сервис генерального директора получил корректное значение атрибута, то он позволит определить атрибут "Резолюция генерального директора". Далее рабочий объект отсылается на рассмотрение финансовому и техническому директорам. Сервисы обоих должностных лиц позволяют определять такой атрибут рабочего объекта, как "Дополнительная резолюция". Возможны ситуации, когда и финансовый директор и технический директор с помощью сервисов будут определять атрибут "Дополнительная резолюция". Одна из резолюций в данном атрибуте будет затерта другой, более поздней. Таким образом, наличие доступа на редактирование к одному атрибуту в параллельных действиях может быть причиной потери данных. Такая неопределенность при изменении атрибута не всегда может быть причиной ошибки при выполнении процесса, однако наверняка увеличивает затраты процесса, связанные с подготовкой неиспользуемых значений атрибутов.
Поскольку рабочий объект при выполнении процесса всегда передается в рамках одного экземплярного подграфа, то его параллельная обработка возможна только в действиях, принадлежащих одному экземплярному подграфу. Действительно, граф процесса на рис. 37 состоит из одного экземплярного подграфа, поскольку не содержит узлов с типом исключающее ИЛИ-разветвление. В случае наличия подобных узлов, следует отметить, что любой экземплярный подграф может содержать только один дочерний узел для узла с типом исключающее ИЛИ-разветвление. Следовательно, параллельное ветвление в экземплярном подграфе может создаваться только узлами типа И-разветвление. Необходимо проверять корректность доступа к атрибутам рабочего объекта в параллельных действиях, которые принадлежат определенному экземплярному подграфу. Действия, которые взаимно параллельны друг другу могут быть выявлены по матрице достижимости экземплярного подграфа. Матрица достижимости экземплярного подграфа используется для хранения информации о существовании путей между его узлами. Если существует путь из узла / в узел у, то это означает, что у достижим из і, следовательно, значение в z -ой строке у-го столбца матрицы достижимости будет больше 0. Матрица достижимости может быть получена как с помощью булевых, так и с помощью алгебраических операций. Наиболее быстро (за 0(N3) операций) матрица достижимости может быть получена с помощью алгоритма Флойда-Уоршелла [51] путем преобразования матрицы смежности. Этот алгоритм предназначен для нахождения кратчайших расстояний между вершинами взвешенного графа.
Похожие диссертации на Исследование и разработка системы управления бизнес-процессами
