Подходы к семантическому аннотированию спецификаций бизнес-процессов

Часть 2

Л.Бабенко

ОСНОВНЫЕ ПОНЯТИЯ BPMN

Процесс есть любая деятельность, осуществляемая внутри компании или организации.

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

.

Внутри процесса могут выделяться подпроцессы. Действия могут состоять , в свою очередь, из более мелких действий. Элементарное действие называется задачей. Задача имеет одного исполнителя (человека или программу).

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

Основные категории элементов диаграмм BPMN :•Объекты потока управления: события, действия и

логические операторы. Представлены на диаграммах специальными знаками.

•Соединяющие объекты: поток управления, поток сообщений и ассоциации. Представлены на диаграммах специальными линиями.

•Участники процесса (конкретные или их роли). Представлены на диаграммах вертикальными или горизонтальными прямоугольниками, называемыми пулами, внутри которых могут детализироваться потоки управления, называемые дорожками (line), за которые отвечают участники (каждый имеет свою зону ответственности).

•Артефакты: данные, группы и текстовые аннотации

Объекты потока связываются в единый процесс с помощью т.н. объектов связи:

Поток управления,Поток сообщений,АссоциацияАссоциации используются для ассоциирования артефактов

(данных или текстовых аннотаций) с объектами потока управления.

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

Другие события:

Подпроцесс транзакции – пример бронирования

Типы логических операторов в BPMNЛогические операторы изображаются ромбами и представляют

точки принятия решений в процессе. С помощью логических операторов организуется ветвление и синхронизация потоков управления в модели процесса.

Соединяющие объекты (объекты связи)

Цель семантических аннотаций к BPMN

1.снабдить смыслом каждый из элементов процесса и сделать их машиночитаемыми, то есть машиннопонимаемыми.

2. сделать возможным рассуждения над описаниями процессов,

3. сделать возможным автоматическую реализацию диаграмм BPMN как композицию семантических веб-сервисов (SWS), для этого:

•предоставить возможность автоматически привязывать к каждой задаче реализующие ее веб-сервисы (или их композиции)

• генерировать представление процессов в BPEL, развернуть механизм исполнения и затем выполнить процесс

Таким образом расширения BPMN превращают ее в Semantic Business Process Modeling Notation (sBPMN).

Изучены публикации по разработкам sBPMN, их много, но большинство содержит “декларации о намерениях’’. Наиболее продвинутые разработки относятся к проекту под названием SUPER, авторы из Познани, Германии (SAP), Болгарии.

.

Выявлены такие направления исследований:1)Декларируются требования к среде

семантического моделирования бизнес-процессов и его жизненный цикл.

2)Предлагается обогатить описания процессов, действий и задач в BPMN дополнительными знаниями относительно смысла указанных действий.

3)Все проекты базируют свои усилия по разработке sBPMN на использовании соответствующих онтологий, в том числе онтологий ПрО. В обозреваемых источниках обсуждаются:

•состав этих онтологий,• структура таких онтологий,•обогащение онтологий ПрО и BPMN• пути отображения элементов диаграмм

на реализующие из семантические веб-сервисы.

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

• повторно использовать части модели процессов при создании новых моделей;

•сделать модели процессов исполняемыми; •обнаруживать отношения между

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

для передачи знаний.

Требования к среде семантического моделирования

Она (среда) должна оказывать следующую помощь конечному пользователю:

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

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

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

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

Обогащение онтологий ПрО и BPMNВопросы компетенции при построении

онтологии домена

1.Каковы характерные для домена объекты, состояния и действия и каковы их имена?

2. Каковы возможные состояния определенного объекта?

3. Каковы возможные предшествующие и последующие состояния определенного состояния?

4. Какие действия, возможно, релевантны для определенного объекта?

5. Какие объекты какими действиями изменяют свое состояние?

6. Какие изменения состояния (переходы) для каких объектов могут быть вызваны какими действими?

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

Вводится следующая дополнительная семантическая информация для модели бизнес-процессов:

•Могут быть указаны объекты, релевантные каждому действию модели процесса, и, если таковые имеются, они должны быть непосредственно связаны с соответствующими объектами онтологии домена (ПрО).

•Могут быть указаны состояния этих объектов до и после выполнения связанного с ними действия

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

•Объекты, состояния и действия связываются с описывающими их элементами онтологии домена, и то же для пред- и пост-условий на естественном языке для действий

Для представления смыслов действий , процессов, подпроцессов и задач BPMN в ряде проектов (SUPER) предлагается понятие проекта WSMO goal – цель, которая формулируется в терминах capability-возможность. Эти конструкции являются прямыми аналогами вариантов использования UML (Use case). Модель ПрО обогащается знаниями о целях действий, характерных для нее. Такие же знания включаются в семантические аннотации процессов, подпроцессов, действий и задач в модели бизнес-процессов.

Фактически приемы семантического обогащения онтологий ПрО и моделей бизнес-процессов включением в них характерных состояний объектов, действий, меняющих указанные состояния указанных объектов, целей сближают три типа объектов моделирования – домена или ПрО, бизнес-процессов и семантических веб-сервисов.

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

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

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

Фаза 1. – Аналист составляет модели процесса в виде порядка задач (tasks) на BPMN с комментариями на натуральном языке, описывающими, что делают задачи и кто их исполняет.

Для исполнения такой модели недостает технической информации о связях задач с IT-сервисами и форматов данных. Это задача следующей фазы ЖЦ.

 

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

Фаза 3. Исполнение: механизм делегирует автоматизированные задания веб-сервисам, а ручные – людям. Процесс сам рассматривается как веб-сервис и может быть использован другими.

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

Одна из главных проблем – трансляция из модели бизнес-аналиста в модель workflow IT-инженера – именно тут нужны технологии семантического веба.

Применение семантических технологий не влияет на главные фазы ЖЦ, но повышает степень автоматизации при переходах от фазы к фазе и расширяет функциональности sBPM.

ЖЦ для sBPM тот же, а функциональности следующие:

На фазе 1.строятся семантические аннотации . При этом аналист использует BPMN, но ссылается на элементы диаграмм как на сущности онтологий. Для этого используется ряд релевантных онтологий. Например:

- организационная онтология (задания сущностей организации),

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

- онтология домена, описывающая данные процесса.- онтология элементов процессов BPMN

Бизнес-аналист в ходе моделирования ищет повторно-используемые фрагменты процесса с помощью семантических средств обнаружения. Он описывает требуемую ему функциональность с указанием нужных онтологий, как на шаге аннотирования. Получив альтернативы, выбирает одну из них и вставляет в свою модель процесса. Для незавершенной части модели процесса может быть выполнено автоматическое дополнение (Auto-Completion), если система может найти недостающие фрагменты, запомненные ранее.

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

На фазе 2- реализация путем трансляции в BPEL4WS – семантические онтологии помогают сформулировать запросы к регистрам веб-сервисов в терминах упомянутых онтологий, чтобы найти подходящие для реализации бизнес-процессов семантические веб-сервисы, т.е. те, которые имеют аннотации (или спецификации) в терминах соответствующих онтологий, облегчающие их поиск и композицию.

На всех фазах главное слово - обнаружение

Один из путей построения онтологии sBPMN На первом этапе надо было решить,

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

Поэтому, аннотация процессов в sBPMN означает создание экземпляров ее понятий, например, задача (task) получения лицензии (ObtainLicense) будет экземпляром класса задача, а не его подклассом. Другой вопрос касается ассоциации элементов BPMN с конкретным процессом. Чтобы убедиться, что все элементы модели процесса относятся к нему, специальное свойство было введено (hasProcess) для явной или неявной (через рекурсию) ссылки

Поток управления (SequenceFlow) моделируется с помощью правил соединения свойств источник (Source) и назначение (Target) для понятий элементов потока управления, определяющих, какие объекты потока (Flow Objects), например, Tasks, Activities, Events, Gateways) (задачи, действия, события, шлюзы), могут быть связаны друг с другом (в соответствии с правилами соединения потока управления BPMN (Sequence Flow Connection Rules). Правила соединения для потока сообщений были реализованы аналогично.

Основным элементом онтологии sBPMN есть диаграмма бизнес-процесса, представляющая модель процесса. Согласно спецификации BPMN имеется четыре основных категории элементов: Flow Objects, Connecting Objects, Swimlanes and Artefacts. Однако, для ясности и совместимости с другими онтологиями проекта SUPER [3], понятие процесс введено на том же уровне. В остальном основные концепции онтологии sBPMN совпадают с концепциями BPMN.

Текущая онтология sBPMN имеет 95 понятий и более 50 аксиом. Она доступна на веб-сайте проекта SUPER (http://www.ip-super.org - 264,000,000ссылок на проект ).

ВОПРОСЫ КОМПЕТЕНТНОСТИ (COMPETENCY QUESTIONS)

•каковы элементы данного процесса, •каковы правила связывания потока

управления, •каков порядок выполнения действий в

рамках процесса, •какие объекты могут быть источником

ассоциации компенсации, •как может быть запущен определенный тип

действий, и т.д.

BPMO - a Business Process Modelling Ontology –еще одна реализация в рамках проекта SUPER.

Цель - Based Semantic Business Process Modelling Environment.

Ядро стека онтологий SUPER следующее:- Upper Process Ontology (UPO),

определяющая понятия верхнего уровня, такие, как task, goal (цель) и condition (условие),

- BPMO, расширяющая UPO в полную онтологию процессов, абстрагируя различные элементы бизнес-процессов BPMN

– sBPMN and sBPEL – онтологизированные версии подмножеств BPMN и BPEL4WS соответственно. Кроме того, sBPEL дополнительно обогащена элементами Web Services Modelling Ontology (WSMO), ориентированными на цели обнаружения, посредничества и исполнения сервисов.

Пользовательский интерфейс (рис. 1) основан на графической нотации BPMN, расширеной специфическими примитивами моделирования BPMO, интегрированными с существующими средствами WSMO Studio. Таким образом, для создания семантической аннотации модели процесса в BPMO конечный пользователь может просто перетащить и опустить (drag & drop) существующие семантические элементы (например, WSMO-цели, семантические ограничения, концепции и экземпляры из эталонных онтологий) в релевантные элементы модели процесса, действий, потока данных и др.

Проект WSMO націлений на збагачення специфікацій веб-сервіса семантичними елементами, які здатна обробляти машина. Концептуальний каркас специфікації складають наступні головні компонента:

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

•goal - мета клієнта, розв'язувана веб-сервісом;

•webService - функціональні і поведінкові аспекти веб-сервіса

•mediator - так називані посередники, службові компоненти, що забезпечують сумісність неднорідних елементів моделі (наприклад, відображення можливостей веб-сервіса і цілей клієнта, онтологій, використовуваних клієнтом і розроблювачем і ін.).

Одиниця функціональності в проекті називається capability(можливість). Це прямий аналог конструкції Use Case у UML.

Кожна з наданих capability описується використовуваною онтологією, інтерфейсом (див. далі.) і моделлю поведінки, що задається наступними характеристиками:

•shared variables – змінні, значимі для поведінки веб-сервіса, використовувані в логічних формулах нижченаведених характеристик,

•preconditions (перед-умови) визначають простір інформації до виконання веб-сервіса,

•postconditions (пост-умови) визначають простір інформації після виконання веб-сервіса,

•assumptions (припущення) визначають стан (зовнішнього) світу до виконання веб-сервіса,

•effect (ефект) визначає стан (зовнішнього) світу після виконання веб-сервіса.

Всі умови, припущення й ефект виражаються аксіомами, представленими в мові формальної логіки WSML[13], орієнтованій на використання для автоматичного виявлення веб-сервісів при пошуку в регістрах

Специфікації capability входять як складові частини в компоненти специфікації goal і webService, причому можливості, що повідомляються в goal для клієнта, можуть відрізнятися від таких у компоненті webService, у цьому випадку вимагаються відповідні медіатори.

Для полегшення розуміння дій веб-сервіса людиною для кожної з конструкцій WSMO (таких, як класи онтологія, поняття, відношення, екземпляр, веб-сервіс, capability, interface) може бути надана властивість Subject, що (як і в проекті UDDI) рекомендовано представляти множиною пар характеристик, перша з який задає систему класифікації (онтологію), а друга – таксономічне значення в цій системі (вузол онтології). Таким чином, строго формальні характеристики для машинної обробки доповнюються традиційними ключовими словами.

Благодарю за внимание