Содержание к диссертации
Введение
Глава 1 Опыт разработки систем управления потоками работ в других организациях 14
1.1 Тенденции в развитии информационных систем 14
1.2 Эволюция систем управления потоками работ 16
1.2.1 Технология офисной автоматизации 17
1.2.2 Системы управления документами 20
1.2.3 Электронная почта 20
1.2.4 Управление базами данных 21
1.3 Эталонная модель архитектуры системы управления потоками работ 21
1.3.1 Определения 22
1.3.2 Модель реализации продукта 25
1.3.3 Описание эталонной модели 27
1.4 Способы моделирования потоков работ 31
1.5 Сети Петри - краткое напоминание 35
Глава 2. Структурные шаблоны в сетях потоков работ 37
2.1 Введение 37
2.2 Шаблоны потоков работ в коммерческих продуктах 38
2.3 Применение сетей Петри для моделирования шаблонов 42
2.4 Каталог шаблонов 43
2.4.1 Шаблон 1. Последовательность (последовательная маршрутизация) 44
2.4.2 Шаблон 2. Параллельное расщепление (разветвитель, параллельная маршрутизация, И-расщепление) 44
2.4.3 Шаблон 3. Синхронизация (И-объединение, рандеву, синхронизатор) 44
2.4.4 Шаблон 4. Эксклюзивный выбор (XOR-расщепление, условная маршрутизация, выбор, решение) 45
2.4.5 Шаблон 5. Простое соединение (XOR-объединение, асинхронное объединение, соединение) 45
2.4.6 Шаблон 6. Множественный выбор (условная маршрутизация, ИЛИ-выбор)... 46
2.4.7 Шаблон 7. Синхронизирующее соединение 47
2.4.8 Шаблон 8. Множественное соединение 48
2.4.9 Шаблон 9. Дискриминатор 49
2.4.10 Шаблон 10. Произвольные циклы (петли, итерация, цикл) 50
2.4.11 Шаблон 11. Явное завершение 51
2.4.12 Шаблон 12. Множественные экземпляры без синхронизации 53
2.4.13 Шаблон 13. Множественные экземпляры с априорным знанием во время разработки 54
2.4.14 Шаблон 14. Множественные экземпляры с априорным знанием во время выполнения 54
2.4.15 Шаблон 15. Множественные экземпляры без априорного знания во время выполнения 56
2.4.16 Шаблон 16. Отложенный выбор (внешний выбор, неявный выбор) 56
2.4.17 Шаблон 17. Чередующаяся параллельная маршрутизация (неупорядоченное выполнение) 57
2.4.18 Шаблон 18. Веха (этап, тестовая дуга, условное состояние, предельный срок) ...57
2.4.19 Шаблон 19. Отмена активности 58
2.4.20 Шаблон 20. Отмена экземпляра 58
2.5 Выводы 58
Глава 3. Поиск структурных конфликтов в графах потоков работ 60
3.1 Введение 60
3.2 Постановка задачи 60
3.3 Известные решения 65
3.4 Экземплярный подход 67
3.5 Доказательство корректности и полноты 77
3.6 Анализ сложности 80
3.7 Случай с простыми циклами 81
Глава 4 Архитектура и описание реализации модуля управления потоками работ в платформе Competentum 84
4.1 Общая архитектура платформы Competentum 84
4.1.1 Уровень серверного представления и библиотека Maverick 85
4.1.2 Уровень бизнес-логики 88
4.1.3 Уровень бизнес-объектов 89
4.2 Архитектура модуля потоков работ 90
4.2.1 Общее описание 90
4.2.2 Объектная модель схемы процесса 92
4.2.3 Ролевая модель и организационная структура 95
4.2.4 Интерпретатор схем 97
4.2.5 Данные процесса: пространства и измерения 99
4.2.6 Модель экземпляра процесса 103
4.2.7 Подсистема действий потоков работ 105
4.2.8 Блок выполнения экземпляров процесса 113
4.3 Пользовательский интерфейс 114
4.3.1 Интерфейс администратора 114
4.3.2 Обработчик списка работ - папка «Входящие» 119
4.3.3 Обработка задания 120
4.3.4 Визуальный редактор 123
4.4 Практическое применение модуля потоков работ 125
4.4.1 Система Protrac для компании Thomson Learning (США) 126
4.4.2 Система РМ Tool для компании Pearson Education (США) 127
4.4.3 Система консолидации финансовой отчетности для компании ГЕК (Россия) 128
4.4.4 Корпоративная информационная система для мебельной компании А&А (Россия) 128
4.4.5 Автоматизация бизнес процессов компании ФИЗИКОН в рамках сертификации на соответствие стандарту ISO 9001:2000 128
Заключение 131
Список использованных источников
- Эволюция систем управления потоками работ
- Применение сетей Петри для моделирования шаблонов
- Доказательство корректности и полноты
- Ролевая модель и организационная структура
Введение к работе
В последнее время в организациях практически любого масштаба значительно возрос интерес к корпоративным информационным системам. Эти системы используются для автоматизации деятельности предприятия и управления различными аспектами его работы. Одной из важных областей применения таких систем является моделирование процессов, протекающих внутри этих организаций. Процессный подход в последнее время приобретает все большую популярность в связи с задачами в области обеспечения качества. Бизнес-процессом можно назвать упорядоченный во времени набор работ, выполняемьк людьми, устройствами и информационными системами, направленный на достижение определенной заранее цели за определенное заранее время. Именно организация деятельности предприятия в виде бизнес-процессов, детальный анализ их выполнения и постоянное усовершенствование позволяет говорить об управлении качеством работы этого предприятия.
В отсутствии информационных систем сотрудник выполнял элементарную работу и передавал результаты другому сотруднику, который должен был выполнить следующий этап в общем процессе, пользуясь формальным, или чаще неформальным описанием процедуры. В области информационных технологий было приложено немало усилий для автоматизации этого процесса, заключающейся в координации работ, выполняемых сотрудниками на их рабочих местах. Автоматизация позволяет выполнять работы и процесс в целом наиболее эффективным с точки зрения времени способом. . Одним из главных направлений развития современных информационных систем, является разработка инструментов, которые позволяют координировать сами работы, их порядок выполнения. Среди ранних подходов, применяющихся при построении корпоративных информационных систем для организации потока скоординированных работ, заключался в непосредственном кодировании самих процессов. Другими словами, последовательность действий при этом задавалась жестко. Как показала практика, такой подход лишь в редких случаях давал положительный результат. На то есть несколько причин. Каждое успешное бизнес-окружение должно уметь быстро подстраиваться под изменения внешних условий (изменения на рынке, в законодательстве, и т.д.), равно как и внутренних (оптимизация использования ресурсов, более гибкое управление персоналом и т.д.). Это означает, что организации должны иметь возможность быстро настраивать и изменять свою информационную систему, как только произошли такие изменения и процесс требует модификации.
Этот подход вполне допустим для крупных организаций, в состав которых входит отдел информационных технологий, занимающийся созданием и технической поддержкой внутренних информационных систем. Однако, если подобное программное обеспечение разрабатывается на заказ, то ситуация значительно усложняется, особенно на российском рынке. За рубежом большое распространение получили гибкие методологии производства программного обеспечения, которые обеспечивают разработку продукта при непосредственном постоянном участии заказчика без заранее определенной детальной спецификации. Разработка ведется короткими итерациями, что позволяет корректировать предварительную спецификацию в зависимости от возникающих обстоятельств непосредственно в момент разработки. Таким образом, конечный продукт наиболее полно соответствует тому, что хочет заказчик и то какие процессы протекают в организации. Как можно заметить, этот подход подразумевает отсутствие информации о сложности продукта, а значит и его стоимости до самого конца разработки. Для российского рынка такой подход зачастую неприемлем. Российский заказчик предпочитает оговорить заранее полностью технической задание, установить стоимость и только после этого начать разработку. Создание подобно й системы и написание технического задания- процесс весьма длительный и сложный. Российский бизнес же достаточно динамичен и еще только развивается. В результате заказчик может получить систему, которая автоматизирует устаревшие процессы, протекавшие в компании несколько месяцев назад. Это относится и к зарубежным компаниям, которые не желают содержать ИТ отдел. После окончания разработки и внедрения продукта в рабочее окружение будет сложно изменять процессы, если они жестко закодированы в системе.
Но даже если компания согласна модифицировать код системы для поддержки новых (модифицированных) процессов компании, то это может породить новую проблему, а именно внесение изменений во внедренную систему, которой уже пользуется несколько десятков или даже сотен человек. Необходимо провести изменения безболезненно, без потери данных, а при модификации функционального кода это всегда тяжело гарантировать.
Выходом из этой ситуации может служить активно развивающаяся технология workflow (WF) или технология потоков работ. Она зародилась еще во времена отсутствия информационных систем. На бумаге рисовались схемы производственных процессов и фиксировались этапы выполнения. Одно время проводились активные исследования в этой области. Затем интерес к технологии потоков работ заметно ослаб. В полную силу она начала развиваться в связи со стремительным ростом информационных распределенных систем, развитием вычислительных глобальных сетей. Одно из
определений термина workflow, данное в одной из первых работ по данной тематике [GHS95] следующее: «набор заданий, организованных таким образом, чтобы выполнить определенный бизнес-процесс».
Workflow Management Coalition (WfMC), международная организация по стандартизации технологии потоков работ дает следующее определение термину workflow [WMFC]: «workflow - это автоматизация бизнес-процесса, полностью или частично, во время которой документы, информация или задания переходят от одного участника к другому, в соответствии с набором процедурных правил».
Технология позволяет задавать бизнес-процессы описательным, очень часто графическим путем, без привлечения программистов, что значительно снижает затраты на техническую поддержку корпоративных информационных систем, а также во много раз увеличивает их гибкость.
За последние десять лет на свет появилось очень большое количество систем управления потоками работ (Workflow Management Systems - WfM системы). Это свидетельствует о высокой потребности в таких системах, позволяющих моделировать, координировать бизнес-процессы, а также управлять потоками информации или документов и последовательной обработкой частей документов, таких как изображения. Совсем недавно появилась новая и ставшая уже популярной парадигма построения распределенных информационных систем СОА (сервисно-ориентированная архитектура). Она позволяет интегрировать множество распределенных систем посредством web-служб. Для организации сложных взаимодействий между системами применяются системы автоматизации потоков работ. Поток работ в данном случае распределяется между несколькими системами.
Системы управления потоками работ обычно реализованы в виде отдельного решения для автоматизации именно бизнес-процессов, но также они могут быть представлены в виде отдельных подключаемых библиотек для того, чтобы разработчики могли включать эти модули в свои системы и задавать процессы описательным путем. Многие технологические платформы, которые служат для автоматизации деятельности предприятия и интеграции всех аспектов его работы в одно информационное пространство, дополнились таким модулем. Этот модуль становится неотъемлемой частью любой подобной системы.
Количество произведенных на свет коммерческих систем управления потоками работ приближается к трем сотням. Однако технологию потоков работ можно назвать молодой и незрелой. Не смотря на усилия международной коалиции WfMC по стандартизации разработок в области систем управления бизнес-процессами, им удалось создать только
высокоуровневые спецификации, не касающиеся деталей и тонкостей реализации. До сих пор не решены многие проблемы, возникающие при создании или использовании подобных систем. Эта работа посвящена решению некоторых таких проблем, теоретических и практических.
Эволюция систем управления потоками работ
Одно из распространенных заблуждений, которое бытует в мире систем управления потоками работ, это то, что такие системы появились совсем недавно. На самом деле разработкой систем, способных поддерживать выполнение корпоративных процессов, занялись уже в конце 60х.
В то время на предприятиях росли объемы данных, которые были интересны многим сотрудникам предприятия. Однако доступ в реальном времени к компьютерным технологиям с рабочих столов пользователей был экономически невозможным даже в очень крупных корпорациях. Идея разделяемого во времени доступа к данным была предложена сотрудником Стэндфордского Университета Дугласом Энгелбартом, который разработал прототип офисной системы NLS (oNLine System) [NLS]. Впервые она была представлена в 1968 году. Первой коммерческим усилием в этой области стала попытка создания компанией IBM совместно с American Airlines национальной системы продажи и резервирования билетов. Разработка системы SABRE [SABRE] (Semi-Automatic Business Research Environment) началась в I960 году, но завершилась лишь в 1976м. В 70е годы происходит бурный рост СУБД, появляется доступ через терминалы к крупным вычислительным машинам. Однако развитие приложений только начинает смещать акценты к модульному подходу, поэтому на ранних стадиях, процессы жестко закодированы и тяжело модифицируемы.
Яблонский и Бусслер определили семь концептуальных предшественников технологии потоков работ [JB96]: офисная автоматизация, управление базами данных, электронная почта, управление документами, управление процессами разработки программного обеспечения, моделирование бизнес-процессов и моделирование и архитектура предприятия. В дополнение к этому, коалиция WfMC [WMFC] выделяет следующие типы систем: обработка изображений, программное обеспечение коллективного пользования (groupware applications), приложения, основанные на транзакциях [Толс04Ь].
Первой в этом списке можно смело назвать технологию офисной автоматизации (office automation technology). В 70-х и 80х годах уже появлялись системы, которые позволяли выполнять ряд часто повторяющихся работ, таких как выписка заказа, что, несомненно, увеличивало производительность. Однако на простом рабочем месте, не смотря на внедрение информационных технологий в офисное окружение, производительность простых сотрудников не увеличилась. Вдохновленные постоянным развитием вычислительной техники и растущей доступностью к информационным технологиям, большое число разработчиков начали прикладывать свои усилия для создания систем офисной автоматизации [Bur77]. Они придерживались следующих целей: «уменьшение сложности пользовательского интерфейса к системе, управление потоком информации и улучшение общей эффективности офиса» [EN80]. Работа Эллиса и Ната над прототипами офисной автоматизации в компании Xerox в конце 70х имела значительное влияние на технологию в целом. Их системы, названные Officetalk [EN80], Backtalk [NE79] в различных версиях использовали формы для структурирования бизнес процессов. Их процессы представлялись как Сети Информационного Управления (Information Control Nets) - формализм, наследованный от сетей Петри. Прототип представлял собой взаимодействие пользователя с графическим интерфейсом, который уже в то время начал использовать такие распространенные сегодня понятия как входящие (inbox), исходящие (outbox) докменты и формы (forms).
Одним из первых прототипов, поддерживающих организационные процессы, стала система SCOOP (System for Computerization of Office Processes). SCOOP являлась системой офисной автоматизации, которая также использовала сети Петри для представления бизнес-процессов [Zis77],[Zis78]. Другой язык моделирования процессов был предложен Крейфелтсом в 1983 году. Он предсказал что: «[Будущие офисные системы] редко будут представлять одноместные или двухместные текстовые системы. Вместо этого, они будут представлены как набор интеллектуальных рабочих станций, соединенных через локальную сеть.[...]»
Работа Крейфелтса и его коллег привела к созданию системы DOMINO [Krei91], которая позже использовалась в качестве основы коммерческой системы X_Workflow [WK93] компанией Olivetti. В то время как большинство прототипов систем офисной автоматизации использовали сети Петри в качестве модели для представления офисных процедур (благодаря тому, что прототипы создавались в научных сообществах), компания IBM разработала высокоуровневый язык описания процессов Business Definition Language (BDL), чтобы офисные сотрудники могли задавать процессы на лету. К сожалению он не пользовался большим успехом на практике и не получил большого распространения. На рис. 2 (из книги [Mueh04]) показана историческая перспектива развития офисных систем автоматизации и технологии потоков работ. Исследования в области офисной автоматизации (1975 - 1985), заложили основу для развития промышленных приложений потоков работ. В период с 1983 по 1985 началась коммерческая эксплуатация технологии потоков работ. Появились системы маршрутизации и обработки документов (изображений), развитие систем электронных писем. С того времени всего лишь несколько производителей продолжают работу в этом направлении и по сей день. В то время на системы офисной автоматизации возлагали большие надежды, однако очень небольшому количеству систем удалось выжить
Применение сетей Петри для моделирования шаблонов
В работе [AH02b] показывается, что при помощи данного формализма не удается смоделировать все шаблоны. На самом деле это не совсем так (реализация шаблонов будет показана в следующем разделе). Сети Петри не поддерживают явной реализации той или иной конструкции, однако при моделировании, разработчик схемы процесса может искусственно реализовать все бизнес-случаи.
Для решения этой проблемы в работе [АН02с] вводится язык, расширяющий сети Петри, который позволяет реализовать все шаблоны (разве что за исключением одного). Этот язык назван YAWL (Yet Another Workflow Language - еще один язык моделирования потоков работ) [АН02с], созданный специально с целью покрыть все шаблоны и позволить тем самым реализовать сложные случаи потоков работ.
Языки, основанные на высокоуровневых сетях Петри, а также и YAWL являются все же достаточно низкоуровневыми и неудобными для конечного пользователя. Именно поэтому они не получили широкого распространения и не используются в коммерческих системах. В нашей работе применяется комбинированный подход. Язык описания бизнес-процессов, использующийся в модуле управления потоками работ платформы Competentum, является более высокоуровневым и удобным, но внутренняя реализация модели построена на основе формализма сетей Петри. В этом языке возможна реализация всех шаблонов (за исключением некорректных с точки зрения дизайна) за счет применения именно сетей Петри. Покажем, каким образом осуществляется поддержка шаблонов.
При моделировании процесса потоков работ сетями Петри активность в процессе моделируется переходом. Текущее состояние процесса моделируется состоянием сети Петри (маркировкой). Будем использовать следующую нотацию на рисунках, описывающих реализацию шаблонов: темным переходом будет моделироваться реальная активность (за выполнение такой активности отвечает какой-либо ресурс в процессе -человек или устройство), светлым переходом будем отмечать переход, который используется во вспомогательных целях и срабатывает автоматически, когда становится активным (enabled) - без участия ресурса.
Для каждого шаблона будет приведено название, в скобках перечислены синонимы, какими эти шаблоны могут называться в коммерческих реализациях. Далее приводится краткое описание шаблона (его определение), и путь реализации сетями Петри (с краткими комментариями).
Базовые шаблоны потока управления
Эти шаблоны покрывают элементарные аспекты управления процессами. Они тесно связаны с элементарными концепциями потоков управления, определенными коалицией WfMC [WFMC]. Для них практически не требуется пояснения, так как такие конструкции реализованы во всех системах управления потоками работ.
Описание: Активность в процессе потоков работ становится активной (то есть доступной дл выполнения ресурсом) после завершения работы другой активности в том же процессе. Реализация: Это самый простой шаблон, который определяет последовательное выполнение работ. На рис. 9,а приведена его реализация. Активность В, обозначенная на рисунке переходом В становится активной, после того как сработает переход А (выполнится активность А).
Описание: Точка в процессе потоков работ, в которой один поток управления расщепляется на несколько потоков управления, которые выполняются параллельно, таким образом, позволяя активностям выполняться одновременно или в любом порядке. Реализация: Можно выделить два основных подхода к реализации данного шаблона: явное (explicit) и неявное (implicit) расщепление. В языках поддерживающих явное расщепление, исходящие переходы у активности, являющейся И-расщеплением, становятся активными, как только активность выполнится. При неявном расщеплении не существует специальных конструкций, которые реализуют данный шаблон. Для каждой активности могут быть определены несколько исходящих переходов, которые могут выполняться при выполнении набора условий. Разработчику процесса необходимо смоделировать такие условия, чтобы данная активность вела себя как И-расщепление. Для этого в простейшем случае достаточно поставить истинное условие на каждый исходящий переход. На рис. 9,6 показано параллельное расщепление, а именно его явная реализация. После срабатывания перехода А становятся активными переходы В и С одновременно. Следовательно, они могут сработать одновременно либо в любом, не зависящем друг от друга, порядке.
Описание: Точка в процессе потоков работ, в которой несколько параллельных подпроцессов/активностей сходятся в единый поток управления, синхронизируя несколько потоков. В данном шаблоне полагается, что входящие ветви синхронизатора выполнятся только один раз.
Реализация: Рис. 9,в показывает переход С, который становится активным (enabled) после того, как сработают переходы А и В. Точка в сети, обозначенная переходом С является синхронизатором. Подобно параллельному расщеплению, синхронизатор может быть явным (вводится специальная конструкция) или неявным (накладываются условия на переходы). В рамках сетей Петри можно реализовать явную версию.
Описание: Точка в процессе потоков работ, в которой, в зависимости от решения или данных процесса, выбирается одна из нескольких альтернативных веток. Реализация: Аналогично шаблону 2 (параллельное расщепление) существует несколько стратегий для реализации данного шаблона. Некоторые языки поддерживают явную конструкцию (Staffware, Visual WorkFlo), в то время как в других необходима помощь дизайнера (он должен расставить условия на исходящих переходах таким образом, чтобы эти условия были взаимно исключающими). На рис. 9,г представлена явная реализация данного шаблона. После выполнения активности А на основании решения, которое принимает участник процесса (человек или устройство), будет выбрана ветвь, ведущая через активность В или С.
Доказательство корректности и полноты
Покажем, что данный алгоритм является необходимым и достаточным для проверки того, является ли граф корректным. Для этого докажем две теоремы. Теорема 1. Если граф является корректным (не содержит структурных конфликтов), тогда алгоритм всегда завершается на последнем шаге.
Доказательство. В случае корректного графа, это утверждение следует из построения шагов алгоритма. Покажем это.
Первый и второй обходы находят атрибуты а и Л каждого перехода. Покажем, какой смысл имеют эти атрибуты. Рассмотрим произвольный переход / Количество экземпляров, которые содержат переход /(другими словами его кратность), определяется следующими конструкциями: координаторы слияния, которые находятся на путях от начального узла к данному переходу, координаторы выбора, которые расположены на путях от данного перехода к конечному узлу, а также количество экземпляров, которые порождаются в параллельных ветках. Именно эти конструкции влияют на количество экземплярных подграфов. Допустим, что после данного перехода f, на путях к конечной задаче teTE, не встретится ни одного координатора выбора (и нет параллельных данному переходу веток). Следовательно, все переходы и узлы, лежащие на этих путях, входят во все экземпляры, которые содержат и переход / Допустим, таких экземпляров п. Такая ситуация может получиться только в случае, если на путях от начальной задачи / є Ts к данному переходу f, встречается несколько координаторов слияния, объединяющих п альтернативных путей. Действительно, каждый координатор слияния, объединяющий т путей, каждый из которых несет а/, а ,..., ат разных экземпляров, на выходе дает переход, содержащийся в i + 02 + ...+ ат разных экземплярах. Очевидно, что если координаторов слияния на путях от начальной задаче к f нет, то / содержится только в одном экземпляре. Эти числа а представляют собой кратности переходов, в предположении, что после этого перехода нет ветвлений (координаторов выбора) и нет параллельных путей. Именно эти кратности получаются в первом обходе.
Действительно, в шаге 3 устанавливается атрибут а начального перехода, равный единице. В предположении, что далее не встретится ни одного координатора выбора, это утверждение очевидно. Далее, последовательное выполнение (шаг 3,а) и разветвлители (шаг 3,Ь) не меняют этого числа (то есть и этой «условной» кратности). Координаторы выбора (шаг 3,с), также не меняют кратности. Координаторы слияния (шаг 3,d) как показано чуть выше меняют кратность, суммируя входящие кратности. Синхронизаторы (шаг 3,е) объединяют параллельные потоки. Так как каждый такой поток предварительно может порождать несколько разных экземпляров, то общее количество экземпляров после обработки синхронизатора должно содержать все возможные комбинации экземпляров, порожденных в каждом параллельном потоке. Очевидно, это число будет кратно произведению всех кратностей входящих переходов. Таким образом, после обработки синхронизатора получим либо точную кратность (в предположении, что далее отсутствуют координаторы выбора), либо число, кратное точной кратности (в п є N раз большее, чем точная кратность).
Теперь предположим следующее. Допустим, что на путях от начальной задачи к переходу / нет координаторов слияния. Аналогичные рассуждения показывают, что числа Ь, найденные в шаге 5 алгоритма, представляют собой кратности переходов, если используется данное допущение. Этот обход симметричен предыдущему обходу, поэтому доказательство корректности поиска таких чисел аналогичное.
Получив для перехода / числа а/ и Ь/, можно получить полную кратность, в предположении, что нет параллельных веток. Экземпляры, которые содержат /включают в себя экземпляры, которые получаются в предположении, что после/нет координаторов выбора, и экземпляры, которые получены в предположении, что перед / нет координаторов слияния. Следовательно, полная кратность перехода/включает в себя все возможные сочетания экземпляров и представляет собой произведение ajbf (опять же, вспомним, что это число может быть не точной кратностью, а в и є N раз большее, чем точная кратность). Так как у начального и конечного перехода не существует параллельных путей, тогда это произведение атрибутов будет кратно точной кратности начального и конечного перехода.
Произведение атрибутов на начальном переходе будет равно aobo=\bo=bo, а на конечном переходе ajbf=a/[=a/. Оба эти числа должны быть кратны точной кратности. Выбрав наименьшее из этих чисел (шаг 6), обойдем граф (шаг 7) еще раз. Так как граф является корректным, то этот обход завершится успешно (на последнем шаге), исходя из утверждений 1-3 и лемм 1, 2. Найденные числа будут являться точными кратностями переходов, либо в п є N раз большими, чем точные кратности (сама точная кратность в данном случае не имеет значения).
Шаг 8 очевидно выполняется для корректного графа. Действительно, пусть точная кратность начального перехода к. Это число равно количеству разных экземпляров, которые порождаются данным графом. Действительно, в случае непротиворечивого графа, каждый экземпляр должен содержать начальный переход, равно как и конечный переход. То есть, кратность конечного перехода должна быть равна к. Покажем, что и последний обход в случае непротиворечивого графа завершится успешно. Это означает, что на шаге 10е не произойдет выхода из алгоритма по «тупику». Такой выход может произойти, если в разных входящих переходах будут содержаться разные элементы (входящие множества не будут совпадать), порожденные одним и тем же координатором выбора. Это означает, что будут существовать экземпляры, у которых в данном синхронизаторе сходящиеся параллельные потоки будут проходить через разные альтернативные пути одного и того же координатора выбора, но это невозможно, так как граф является корректным. Следовательно, шаг 10 завершится успешно, и алгоритм завершится на последнем шаге.
Ролевая модель и организационная структура
Основной класс, который является корневым в иерархии объектной модели схемы, называется WorkflowModel. Для каждой схемы процесса существует ровно один объект данного класса. Этот класс определяет название процесса (name), перечень моделей данных (modelList), для которых разработан данный процесс, ссылку на пиктограмму, с которой будет ассоциирован данный процесс (iconName), полную XML конфигурациию процесса (configuration), а так же название начальной позиции (startState). Начальная позиция определяет позицию в сети Петри, в которую помещается метка при запуске экземпляра процесса. По историческим причинам позиции (places) в модели называются состояниями (states), хотя состояниями в сетях Петри называется маркировка сети, то есть совокупность позиций, в которых находятся метки. Это связано с тем, что на ранних этапах модуль управления потоками работ не поддерживал параллельного выполнения. Соответственно, метки могли находиться только в одной позиции (для отдельно взятого экземпляра). Поэтому ошибочно позицию называли состоянием. После введения параллельности переименовывать модели не стали с целью обратной совместимости с существующими системами.
Сеть Петри моделируется двумя объектами-узлами: StateModel и TransitionModel. Как уже было сказано, StateModel представляет собой вершину типа позиция (place). Позиции в рамках одного процесса должны иметь уникальные имена (поле name модели WorkflowPartModel). Уникальность проверяется интерпретатором схем. Помимо этого, для позиции может быть определено отображаемое имя (которое будет видно пользователю), рекомендуемое время нахождения в данной позиции (duration), то есть, время, через которое рекомендуется выполнить один из активных переходов, а также время автоматического срабатывания перехода через определенный интервал времени. Для этого в объектной модели будет сформирован автоматический переход, который сработает по истечении заданного времени.
Другой тип вершин - переходы, задается моделью TransitionModel. Данная модель содержит информацию о ребрах сети, так как именно в этой модели задаются правила инцидентности: начальные (startState) и конечные (endState) позиции для данного перехода. Атрибут userSelection определяет, какая роль (или набор ролей) отвечает за данный переход (более подробно о ролях в процессе будет сказано в соответствующем разделе). Если такой атрибут не определен и переход не является автоматическим, тогда этот переход является «мертвым» - он никогда не сработает, хотя и может быть активным (enabled). Атрибут isForAll служит для того, чтобы разрешить выполнять переход любому пользователю системы. Это иногда бывает полезно, особенно при запуске процессов. Также с переходом проассоциирован набор действий (actions), которые должны быть выполнены при срабатывании данного перехода. Этот набор содержит экземпляры объектов, унаследованных от абстрактного класса WorkflowAction. Этот класс имеет статический метод registerQ, который вызывается при инициализации системы и регистрирует действия, доступные для модуля потоков работ. Стандартные действия будут более подробно описаны далее.
Также в описание схемы может входить несколько объектов класса LocalRoleModel. Данная модель данных определяет набор локальных ролей (см. раздел «Роли в процессе»), которые будут присутствовать в каждом экземпляре данного процесса. Аналогично, для схемы можно определить несколько объектов LocalUnitModel. Их назначение также описано дальше.
Модуль потоков работ тесно связан с моделью организационной структурой, заложенной в информационной системе. В ядре платформы Competentum для этих целей предусмотрена абстрактная модель данных UnitModel, которая определяет элемент организационной структуре. По сути дела, наследниками этой модели могут быть любые другие объекты, в рамках которых возможны задания ролей. Такими объектами могут быть объекты присущие организационной структуре, такие как организация, департамент, группа, отдел, но также, ими могут быть такой объект как проект. И хотя проект не является частью организационной структуры, в его рамках возможно задание ролей. Наследование его от UnitModel обеспечит стандартную работу с ролевой моделью. На рис. 34 в качестве примера показаны два наследника модели UnitModel -OrganizationModel (организация) и ProjectModel (проект).
В классе UnitModel есть атрибут parent_unit, который хранит ссылку на родительский элемент, либо null в случае отсутствия такового. Таким образом, возможно задание иерархии этих объектов, в том числе и задание структуры организации. Другая модель, относящаяся к ролевой модели и находящаяся в ядре Competentum, называется UserModel. Эта модель данных хранит информацию о пользователях системы. Эта простая модель хранит такие данные о пользователе, как логин в систему, пароль, е-mail, а также личные данные. В ядре дополнительно предусмотрена система «прозрачной» аутентификации в доменах Active Directory, для того чтобы пользователь не вводил пароль и для обеспечения большей безопасности. Так как от системы к системе могут потребоваться различные дополнительные поля о пользователях системы, такие как телефон, адрес и т.д., то модель UserModel также является абстрактной и разработчик должен определить обязательного наследника этого класса. Например, на рис. 34 показан наследник UserModellmpl, вводящий дополнительный атрибут phone (телефон). Роли в системе хранятся в объектах модели RoleModel. Роль содержит такие атрибуты, как название (name), а также название модели данных (model), в которой может существовать данная роль. Например, роли менеджера в проекте и в организации являются, по сути, разными ролями, хотя и носят одно название «Менеджер». Также, система должна понимать, что некоторые роли неприменимы к определенным объектам. Например, роль вахтер вряд ли применима к проекту, но применима к организации. Необходимо отметить, что поле model может быть пустым. Такие роли называются глобальными, и они относятся к целой системе, а не к конкретному подразделению. Примером может служить роль «администратор системы».
