Методы и средства описания организационной перспективы в процессно-ориентированных системах управления Текст научной статьи по специальности «Компьютерные и информационные науки»

МЕТОДЫ И СРЕДСТВА ОПИСАНИЯ ОРГАНИЗАЦИОННОЙ ПЕРСПЕКТИВЫ В ПРОЦЕССНО-ОРИЕНТИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ

УДК 007.51

Кирилл Сергеевич Курышев,

аспирант кафедры Прикладной информатики в экономике,

Московский государственный университет экономики, статистики и информатики, Тел.: (495) 442-80-98, Эл. почта: kkurishev@qmail.com

В статье рассматриваются вопросы проектирования процессно-ориентированных систем управления в аспекте отображения сотрудников на операции процесса. Для этого проводится анализ типовых методов отбора и назначения исполнителей на интерактивные задачи. Для каждого метода описаны его преимущества и недостатки. Значительная часть работы посвящена обзору и анализу механизмов описания организационной перспективы процесса средствами нотации BPMN 2.0 и программного языка WS-BPEL. По результатам анализа сформулированы выводы о выборе средств моделирования на разных стадиях ЖЦ разработки процессно-ориентированной системы управления.

Ключевые слова: процессно-ориенти-рованные системы управления, организационная перспектива, BPMN, WS-BPEL, назначение исполнителей.

Kirill S. Kuryshev,

Post-graduate student, the Department of Applied Informatics in Economics, Moscow State University of Economics, Statistics and Informatics (MESI), Tel.: (495) 442-80-98, E-mail: kkurishev@qmail.com

METHODS AND TECHNIQUES OF DESCRIPTION OF ORGANIZATIONAL PROSPECT IN THE PROCESS-ORIENTED MANAGEMENT SYSTEMS

The article deals with the issues of designing process-oriented management systems in the aspect of staff display in the operation process. In order to do this, an analysis of standard methods for the selection and appointment of executors on interactive tasks is carried out. The advantages and disadvantages of each method are described inthearticle. A considerable part of the research work covers the review and analysis of the description mechanisms of organizational perspective of the process by means of BPMN 2.0 notation and programming language WS-BPEL. As a result of the analysis, there were made some conclusions on the choice of modeling tools at different stages of the life cycle development process-oriented management system.

Keywords: process-oriented management systems, organizational prospect, BPMN, WS-BPEL, resource assignment.

1. Введение

В основе процессно-ориентированной системы управления лежит исполняемая модель процесса, которая состоит из четырёх перспектив: поведенческой, функциональной, информационной и организационной [6],[7]. Последняя отвечает на вопрос «Кто» и определяет каким образом сотрудники участвуют в выполнении процесса. Для описания организационной перспективы необходимо отобразить множество сотрудников на множество операций процесса. Существуют различные способы решения этой задачи. Можно указать исполнителя для каждой задачи прямо в схеме процесса. Однако, в этом случае, любое изменение в организационно-штатной структуре приведет к необходимости редактировать исполняемую модель. Можно для каждой операции указать критерии отбора сотрудников, но это повысит сложность сопровождения системы управления. Придется запоминать и вносить правки во все операции, в которых поменялись критерии. Можно воспользоваться процессно-ролевой структурой. Тогда все операции в процессе группируются в роли, которые в последующем назначаются исполнителям. Поскольку правила отображения сотрудников на роли не является частью модели процесса, это резко повышает ее инвариантность по отношению к компании. Таким образом, выбор метода описания организационной перспективы напрямую влияет на эффективность разработки и сопровождения процессно-ориентированной системы управления.

Создание исполняемой модели процесса осуществляется с применением различных средств моделирования. Нотация BPMN 2.0 (Business Process Model and Notation) является стандартом "де-факто" для графического описания поведенческой перспективы процесса [4]. BPMN позволяет формализовать состав и последовательность выполнения операций в процессе, а так же определить семантику их выполнения. Нотация не предназначена для описания организационной перспективы, однако, в ней содержатся механизмы, которые позволяют отобразить сотрудников на процесс [5]. Схема процесса, выполненая в нотации BPMN, может быть интерпретирована в программный код на языке WS-BPEL [13]. Это XML-подобный язык, который позволяет исполнять процессы в виде совокупности веб-сервисов. Он, благодаря расширениям WS-HumanTask [14] и WS-BPEL4People [15], существенно расширяет возможности нотации BPMN в части описания интерактивных задач.

Цель данной работы заключается в анализе типовых методов и средств описания организационной перспективы. Для этого в первой части рассматриваются основные способы отображения сотрудников на операции процесса. Во второй части проводится описание нотации BPMN и WS-BPEL в аспекте моделирования организационной перспективы.

2. Методы описания организационной перспективы

Центральное место в исполняемой модели занимает схема процесса [6]. Воспользуемся руководящим документом Госстандарта России «Методология Функционального Моделирования IDEF0 [3] для определения понятий предметной области. Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а Операция - как «совокупность последовательно или/и параллельно выполняемых действий». В случае необходимости, операция может быть детализирована на отдельной схеме процесса. Операции, которые не требуют декомпозиции, будем называть задачами.

Любой конкретный случай выполнения процесса в среде процессно-ориентированных систем управления называется экземпляром. По мере выполнения процесса пользователям системы распределяются задания. Под заданием будем понимать реализацию отдельной задачи, изображенной на схеме процесса (рис. 1).

Как следует из рисунка 1, за каждой операций должна быть закреплена группа сотрудников, ответственных за ее выполнение. Под процедурой отбора будем понимать поиск нужных сотрудников. Множество отобранных сотрудников на-

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

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

Существуют различные способы отображения. Разделим их на две категории:!) для каждого сотрудника указывается множество доступных ему операций; 2) для каждой операции указываются критерии отбора потенциальных исполнителей. Рассмотрим каждый способ в отдельности.

2.1. Процессно-ролевая структура

В практике реинжиниринга бизнес-процессов принято создавать про-цессно-ролевую модель, которая закрепляет за каждой операцией соответствующих исполнителей. Ролью принято называть группу операций, формирующих отдельную зону ответственности в процессе [9]. Концепцию применения ролевой структуры в аналитическом моделировании выдвинули Г. Рэмлер и А. Брейч, которые предложили, во-первых, изображать на диаграмме процесса дорожки, группирующие операции в соответствии с функциональными обязанностями сотрудников, во-вторых, давать дорожкам имена, которые позволяют однозначно идентифицировать цель участия в процессе группы сотрудников [8].

Список заданий сотрудника А

Список заданий сотрудника B

>

—V

Задание 1

Задание 2

Задание 3

Задание 2

Задание 1

i

Среда выполнения

задача 1

задача 2

задача 3

ГУ»Г

задача 1

задача 2

Я-»Г

t£)

задача 3

СИ

задача 1

задача 2

bQ

задача 3

Ю

Схемы процессов

Рис. 1. Выполнение заданий в процессно-ориентированной системе

Пользователь 1

Пользователь 2

Операция n Операция n+1

Схема процесса

Информационный объект 1

Информационный Информационный объект m объект m+1

Информационный

объект m+2 Модель данных

Рис. 2. Типовая модель доступа сотрудников к данным в процессно-ориентированной системе управления

Поскольку права доступа не назначаются пользователю индивидуально, а приобретаются им через определенную ему роль, управление доступом сводится к назначению пользователю необходимых ролей [11]. Это упрощает администрирование системы в случае добавления нового пользователя или смены им подразделения. Чтобы множества операций, связанных с различными ролями, не пересекались, вводится иерархическая зависимость между ролями [12]. К примеру, роль «секретарь» может включать в себя роль «регистратор» и, плюс к тому, еще несколько дополнительных операций.

Моделирование участия сотрудников в выполнении процесса реализуется в два этапа: (1) настройка политики безопасности системы; (2) определение прав доступа для субъектов и объектов в системе [1].

Несмотря на все преимущества такого подхода, использование процессно-ролевой структуры связа-

но с набором ограничений.

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

Второе ограничение состоит в том, что роли определяют доступ к операциям процесса, а не к информационным объектам, над которыми эти операции совершаются (рис. 2). Это озна-

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

Третье ограничение связано с моделированием должностных полномочий сотрудников, таких как делегирование и эскалация операций [10]. Концепция роли не учитывает, что сотрудники могут иметь разные полномочия при работе с одними и теми же операциями. Например, начальник отдела может назначить исполнителем операции своего подчиненного, в то время как обычный сотрудник такой привилегией не обладает.

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

Использование процессно-ролевой структуры позволяет, во-первых, повысить информативность схемы процесса, во-вторых, сделать ее инвариантной по отношению к организационной структуре за счёт применения логических групп, вместо действительных сотрудников.

2.2. Использование параметрических запросов для поиска кандидатов

Второй способ отображения, предусматривает, что процедура отбора сотрудников является частью интерактивной операции, изображённой на схеме процесса. В этом случае, для каждой операции указывается система ограничений - критериев поиска кандидатов. Для этого формируется параметрический запрос к корпоративному справочнику сотрудников. Аргументами этого запроса могут выступать различные свойства, характеризующие одного или группу сотрудников. Значения аргументов подставляются в режиме реального времени, в момент появления задания в среде исполнения. В качестве значений могут быть использованы контекстные данные процесса [13].

Рисунок 3 иллюстрирует типовой сценарий формирования параметрических запросов. Опишем его более под-

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

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

3. Анализ средств описания участия сотрудников в выполнении процессов

Разработка процессно-ориентиро-

ванной системы управления начинается с описания состава и последовательности выполнения операций процесса. Этот этап жизненного цикла разработки системы происходит с использованием нотации BPMN. После этого, схема процесса транслируется в программный язык WS-BPEL, который позволяет на более детальном уровне описать специфику выполнения каждой операции.

3.1. Описание участия сотрудников в процессе средствами нотации BPMN

Предметом нашего анализа станет не вся спецификация BPMN2.0, но ее компоненты, отвечающие за отбор исполнителей. Мы будем анализировать графические элементы нотации и внутреннюю структуру мета-модели, рассмотрим графические элементы Пул (Pool), Дорожка (Lane), Активность (Activity) и атрибуты мета-модели BPMN. Атрибуты не являются графическими элементами и на схеме процесса не отображаются. Их следует рассматривать как свойства графических элементов.

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

Рис. 3. Типовой сценарий отбора сотрудников на операции процесса средствами нотации ВРМК

как «чёрный ящик» - процесс внутри подразумевается, но не изображается. Пул может использоваться для двух целей. Во-первых, для изображения межпроцессного взаимодействия: в этом случае, каждый Пул на схеме состоит из одного процесса. Во-вторых, Пул может использоваться для изображения участника, который является ответственным за выполнение фрагмента сквозного процесса. «Участником» (Participant), с позиции BPMN, может быть как отдельный индивид, так и целая организация. Семантика участника может быть определена двумя способами: путём формирования имени КомпанииУчастника (PartnerEntity) или РолиУчастника (PartnerRole). В первом случае, указывается идентификатор конкретной организации или ее организационной единицы. Во втором случае, на схеме отображается только роль, как цель участия организации в выполнении процесса.

Пул может состоять из одной или нескольких дорожек. Дорожки служат для изображения зон ответственности на схеме процесса. BPMN не определяет критерии формирования дорожек, поэтому аналитик может группировать операции на своё усмотрение. Например, дорожка может объединять активности, выполняемые одним пользователем или сотрудниками одного подразделения. Аналитики, часто ассоциируют Дорожки с названием структурного подразделения, должностью или конкретным исполнителем. В первом случае дорожка может именовать-

ся «Отдел продаж», «Бухгалтерия», во втором - «Торговый представитель» или «Главный бухгалтер», в третьем «Иванов Иван Иванович». Дорожка может состоять из вложенных дорожек. Такой механизм может использоваться для структурной декомпозиции операций процесса по исполнителям.

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

Нотация BPMN 2.0 не предназначена для описания организационной структуры компании. Тем не менее, в спецификации определены два подхода к выбору нужных сотрудников из числа тех, кто работает в организации. Для поиска кандидата можно указать его идентификатор, либо можно определить критерии отбора. Во втором случае, результатом запроса может стать несколько подходящих кандидатур. На рисунке 2 изображена часть метамодели BPMN 2.0, которая определяет семантику отбора сотрудников, ответственных за выполнение задачи либо всего процесса в целом. Диаграмма разработана в нотации UML Class Diagram.

Графический элемент «активность» используется для изображения на диаграмме процесса операций. Активность может быть составной (подпроцесс) и элементарной (задача). Нотация BPMN различает семь типов задач, причём, только два типа используются

для описания взаимодействия пользователя с ИС: пользовательская задача описывает интерактивное взаимодействие пользователя с системой, а ручная - работу, которая выполняется вне системы, так что участник подтверждает в ИС только факт ее исполнения.

Выбор сотрудников на выполнение активностей реализован в нотации ВРМЫ следующим образом (рис. 3). С каждой диаграммой процесса связано множество сотрудников, которые потенциально могут быть выбраны для выполнения одной или нескольких задач процесса. Для этого в метамодели определён класс Ресурс(Р^оигсе) (рис. 4).Он предназначен для хранения в схеме процесса информации о сотрудниках, для их дальнейшей идентификации в справочнике пользователей. Для каждого работника может быть дополнительно указан перечень свойств, ха-растеризующих его.

Спецификация ВРМЫ не разделяет отбор и назначение исполнителей. Сотрудники, прошедшие отбор получат предложение выполнить задание, так что каждый из них может добровольно назначить себя самого исполнителем.

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

Рис. 4. Метамодель BPMN для отбора сотрудников

изображаются на диаграмме в виде пулов и дорожек, но переводит это понятие на уровень аналитического моделирования.

3.2. Описание участия сотрудников в процессе средствами WS-BPEL Спецификация WS-HumanTask, как расширение языка WS-BPEL, добавляет к нотации BPMN 2.0 два важных аспекта в области описания организационной перспективы. Во-первых, это концепция универсальных пользовательских ролей (generic human roles). Во-вторых, это детальная модель жизненного цикла выполнения интерактивной задачи.

Универсальные пользовательские роли используются для описания цели участия сотрудника в выполнении интерактивной задачи процесса. Они определяют набор разрешенных действий, которые сотрудник может инициировать в ходе работы над заданием: назначить себя исполнителем, делегировать, эскалировать задание и т.д. Перечислим основные пользовательские роли, которые есть в спецификации WS-HumanTask:

• инициатор - лицо породившее За-

дание (экземпляр задачи);

• ответственный - несущий полную ответственность за конечный результат выполнения задания, он может контролировать ее исполнение, выполнять административные функции, в том числе назначать и переназначать исполнителей;

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

• исключенный из числа исполнителей - группа сотрудников, которые не соответствуют критериям отбора;

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

• информируемый - участник, кото-

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

Универсальные пользовательские роли «Потенциальный исполнитель», «Исключенный из числа исполнителей» и «Актуальный исполнитель» связаны с этапами выполнения задачи. Для этого, в спецификации WS-HumanTask представлена соответствующая модель жизненного цикла (рис. 5). Опишем основные сценарии выполнения задачи.

Выполнение задания начинается с состояния «Создано», все данные, необходимые для выполнения подготовлены, происходит внутренняя инициализация задания, начинается отбор потенциальных исполнителей. По результатам параметрического запроса, найденные сотрудники отображаются на универсальные пользовательские роли: «Потенциальный исполнитель», «Ответственный» и «Администратор».

В случае если роль «Потенциальный исполнитель» не содержит участников, то задание становится доступным сотрудникам с ролями «Ответ-

исполнителя не требуется

Приостановлено (Suspend)

Предложено (Ready)

Зарезервировано (Reserved)

В работе (In progress)

приостановить

приостановить

(1) Создано (Created)

Отобрать

одного

кандидата

Предложить кандидатам

(2) Предложено (Ready)

Назначить 11 Делегировать

Изменить список кандидатов

Отказаться || Изменить список кандидатов

(3) Зарезервировано (Reserved)

делегировать

Приступить к выполнению

Приступить к выполнению

приостановить

(4) В работе (In progress)

Отказаться || Изменить список кандидатов

Остановить || Делегировать

Задача выполнена

Задача не выполнена

«5

s

о

(5) Выполнено (Completed)

Прервано (Failed)

Ошибка (Error )

Удалена (Exited)

Устарело

(Obsolete)

Рис. 5. Модель жизненного цикла пользовательской задачи

ственный» и «Администратор». Они в ручном режиме выбирают исполнителей задания из справочника пользователей.

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

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

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

В ходе исполнения могут возникнуть нестандартные ситуации, что приводит к изменению состояния задания, например состояние «Ошибка» возникает в случае возникновения неисправимого исключения, состояние «Удалено», соответствует ситуации, когда показатель исполнения процесса (на-

пример, время) вышел за пределы допустимого диапазона, так что необходимо вмешательство сотрудника с ролью «Ответственный».

4. Заключение

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

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

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

Анализ нотации ВРМЫ позволил выявить следующие особенности ее применения. Возможности ВРМЫ выходят за пределы описания только последовательности операций в процессе. Спецификация может и должна использоваться для отображения участников процесса на интерактивные задачи процесса. Тем не менее, следует учитывать следующие ограничения описания организационной перспективы средствами ВРМК Во-первых, она поддерживает ролевую структуру только на уровне аналитического моделирования. Во-вторых, для выполнения параметрических запросов средствами нотации необходимо наличие корпоративного справочника пользователей, в котором представлена исчерпы-

вающая информация о каждом сотруднике организации.

Основное преимущество языка WS-BPEL перед нотацией BPMN заключается в том, что в его расширении WS-HumanTask представлено детальное описание жизненного цикла выполнения интерактивной задачи.

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

Литература

1. Майоров А.В. Улучшенная ролевая модель управления доступом к объектам // Конференция Software Engineering Russia, 2008.с.32-35.

2. Минцберг Г. Структура в кулаке: создание эффективной организации // Пер. с англ. под ред. Каптуревского.Ю.Н.- СПб.: Питер, 2004.-512 с.

3. Руководящий документ Госстандарта России. Методология Функционального Моделирования IDEF0 // Научно-исследовательский Центр CALS, 2000.- 62 с.

4. Фёдоров И.Г. Сравнительный анализ методов моделирования бизнес-процессов // Открытые системы, №8/ 2011. URL:http://www. osp.ru/ os/2011/08/13011140/ (дата обращения: 05.04.2011) .

5. Business Process Model and Notation 2.0(BPMN) // Object Management Group, 01.2011.

6. Bjоrn Axenath, Ekkart Kindler, Vladimir Rubin. The Aspects of Business Processes: An Open and Formalism Independent Ontology // Computer Science Department of the University of Paderborn, 2005-с.23-39.

7. Curtis, B., Kellner M., Over J., «Process modeling» //Communications of the ACM TOOIS- 1992-с.45-48.

8. Geary A. Rummler, Alan P. Brache:

«Improving Performance: How to Manage the White Space in the Organization Chart», Jossey-Bass Publishers San Francisco, 1995-C.45-49.

9. Ferraiolo D. F., Kuhn D. R. Role Based Access Control // 15th National Computer Security Conference, 1992-c.554—563.

10. N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource Patterns // Working Paper Series, Eindhoven University of Technology, Eindhoven, 2004-C.87-94.

11. Sandhu R., Coyne E. J., Feinstein

H. L., Youman C. E. Role-Based Access Control Models // IEEE Computer (IEEE Press) №29 (2),1999-c.38-47.

12. Osborn, S., Sandhu, R., Nunawer. Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, №3 (2), 2000-C.12-20.

13. Web Services Business Process Execution Language Version 2.0 // Organization for the Advancement of Structured Information Standards, 11.04.2007.

14. Web Services - Human Task (WS-HumanTask) Specification Version

I.1// Organization for the Advancement of Structured Information Standards, 17.08.2010.

15. WS-BPEL Extension for People (BPEL4People) Specification Version 1.1// Organization for the Advancement

of Structured Information Standards, 04.11.2009.

References

1. Mayorov AV Enhanced role model to control access to objects // Conference of Software Engineering Russia, 2008.

2. Mintzberg H. Structure in the fist: the creation of an effective organization // Kap-turevskogo.Yu.N. - St.: Peter, 2004.-512 p.

3. Guidance Document Russian State Standard. Methodology for functional simulation IDEF0 / / Research Center CALS, 2000.-62p.

4. Fedorov IG Comparative analysis of methods for modeling business processes // Open systems, № 8/2011.URL:http:// www.osp.ru/os/ (дата обращения: 05.04.2011).

5. Business Process Model and Notation 2.0(BPMN) // Object Management Group, 01.2011.

6. Björn Axenath, Ekkart Kindler, Vladimir Rubin. The Aspects of Business Processes: An Open and Formalism Independent Ontology // Computer Science Department of the University of Paderborn, 2005-p.23-39.

7. Curtis, B., Kellner M., Over J., «Process modeling» //Communications of the ACM TOOIS- 1992-p.45-48.

8. Geary A. Rummler, Alan P. Brache: «Improving Performance: How to Manage the White Space in the Organization

Chart», Jossey-Bass Publishers San Francisco, 1995-p.45-49.

9. Ferraiolo D. F., Kuhn D. R. Role Based Access Control // 15th National Computer Security Conference, 1992-p.554—563.

10. N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource Patterns // Working Paper Series, Eindhoven University of Technology, Eindhoven, 2004-C.87-94.

11. Sandhu R., Coyne E. J., Feinstein

H. L., Youman C. E. Role-Based Access Control Models // IEEE Computer (IEEE Press) №29 (2),1999-p.38-47.

12. Osborn, S., Sandhu, R., Nunawer. Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, №3(2), 2000-C.12-20.

13. Web Services Business Process Execution Language Version 2.0 // Organization for the Advancement of Structured Information Standards, 11.04.2007.

14. Web Services - Human Task (WS-HumanTask) Specification Version

I.1// Organization for the Advancement of Structured Information Standards, 17.08.2010.

15. WS-BPEL Extension for People (BPEL4People) Specification Version 1.1// Organization for the Advancement of Structured Information Standards, 04.11.2009.