Нотация BPMN (Business Process Modeling Notation)

Процедуре трансформации модели бизнес-процессов в исполняемый код должна предшествовать процедура моделирования – составления модели.

Среди нотаций моделирования бизнес-процессов в различныхрешениях активно используются средства IDEF0, EPC (Event-drivenProcessChain) и др. В настоящее время наиболее целесообразнымисистемами моделирования становятся такие, которые позволяютсоздавать модели, трансформируемые в исполняемый код бизнес-процесса. Наиболее популярным в настоящее время языком, описывающим исполняемый XML-код бизнес-процессов, является BPEL(BusinessProcessExecutionLanguage). Для этого языка созданы графические редакторы, позволяющие представлять BPEL-программыв виде блок-схем, но эти блок-схемы дают скудное представлениеоб исполняемом бизнес-процессе.

Поэтому для наглядного графического представления процессов используют другое средство – BPMN (BusinessProcessModelandNotation) – нотация и модель бизнес-процессов. BPMN – этосистема условных обозначений, т. е. нотация, предназначенная длямоделирования бизнес-процессов. Она разработана некоммерческойорганизаций BusinessProcessManagementInitiative (BPMI); в настоящее время поддерживается OMG (ObjectManagementGroup) – рабочей группой, занимающейся разработкой и продвижением объектно-ориентированных технологий и стандартов и включающейв себя около 800 производителей и потребителей программногообеспечения.

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

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

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

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

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

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

Элементы BPMN

Моделирование в BPMN осуществляется посредством диаграммс небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

1) объекты потока управления – события, действия и логическиеоператоры;

2) соединяющие объекты – поток управления, поток сообщенийи ассоциации;

3) роли – пулы и дорожки;

4) артефакты – данные, группы и текстовые аннотации.

Элементы этих четырех категорий позволяют строить простейшиедиаграммы бизнес-процессов. Для повышения выразительности модели спецификация BPMN разрешает создавать новые типы объектовпотока управления и артефактов.

Объекты потока управления. Объекты потока управления разделяются на три основных типа:

- события (events);

- действия (activities);

- шлюзы, называемые также логическими операторами (gateways).

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

Типы событий в BPMN показаны на рис. 8.1.

Простые события (plainevents) – это нетипизированные события, использующиеся чаще всего для того, чтобы показать начало или окончание процесса.

События-сообщения (messageevents) показывают получение и отправку сообщений в ходе выполнения процесса.

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

События-ошибки (errorevents) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.

События-отмены (cancelevents) инициируют или реагируют на отмену транзакции.

События-компенсации (compensationevents) инициируют компенсацию или выполняют действия по компенсации.

События-условия (conditionalevents) позволяют интегрировать бизнес-правила в процесс.

Рисунок 8.1. Типы событий в BPMN

 

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

Составные события (multipleevents) моделируют генерацию одного события из множества.

События-ссылки (linkevents) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.

События-остановы (terminateevents) приводят к немедленному завершению всего бизнес-процесса (во всей диаграмме).

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

Типы действий в BPMN показаны на рис. 8.2.

Задание (task) – это единица работы, элементарное действиев процессе.

Множественные экземпляры (multipleinstances) действия показывают, что одно действие выполняется многократно, по одному разудля каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действиямогут выполняться параллельно или последовательно.

Рисунок 8.2. Типы действий в BPMN

 

Циклическое действие (loopactivity) выполняется, пока условиецикла верно. Условие цикла может проверяться до или после выполнения действия.

Ad-hoc-подпроцесс (отлат. ad-hocsubprocess, adhoc– специально для этого) содержит задания. Задания выполняются до тех порпока не будет выполнено условие завершения подпроцесса.

Свернутыйподпроцесс (collapsedsubprocess) является сложнымдействием и содержит внутри себя правильную диаграмму бизнес-процессов.

Развернутыйподпроцесс (expandedsubprocess) также является составным действием, но скрывает детали реализации процесса.

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

Типы логических операторов в BPMN

Если оператор исключающего ИЛИ, управляемый данными (databasedexclusivegateway), используется для ветвления, то поток управления направляется лишь по одной исходящей ветви; если операториспользуется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

Оператор исключающего ИЛИ, управляемый событиями (eventbasedexclusivegateway), направляет поток управления лишь по тойисходящей ветви, на которой первым произошло событие. Послеоператора данного типа могут следовать только события или действия – обработчики сообщений.

Оператор включающего ИЛИ (inclusivegateway) активирует однуили более исходящих ветвей в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидаетзавершения выполнения одной входящей ветви и активирует выходной поток.

Оператор И (parallelgateway), использующийся для ветвленияразделяет один поток управления на несколько параллельных потоков. При этом все исходящие ветви активируются одновременно.

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

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

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

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

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

Поток сообщений показывает, какими сообщениями обмениваются участники.

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

Типы ассоциаций в BPMN:

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

В BPMN средства разделения элементов модели по исполнителям и местам называются ролями. Существуют два типа ролей: дорожки и пулы.

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

Пулы – это совокупности дорожек. Они изображаются прямоугольником, содержащим полосы дорожек. Существует понятие сложенного пула, изображаемого в виде прямоугольника с названием.

Схема организации ролей в BPMN показана на рис. 8.3.

Рисунок8.3. Организация ролей в BPMN

Артефакты. Традиционно в теории моделирования систем артефактами принято называть материальные предметы (документы, программы и базы данных), создаваемые в процессе создания илифункционирования системы. В BPMN артефактами называются немного другие вещи – средства, повышающие наглядность и содержательность диаграммы. Определены три вида артефактов: данные, группы; текстовые аннотации.

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

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

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

Изображения артефактов в диаграммах BPMN показаны на рис. 8.4.

Рисунок8.4. Артефакты в BPMN

 

Применение BPMN

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

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

В сквозной BPMN-модели можно выделить три типа подмоделей:

1) частные (внутренние) бизнес-процессы;

2) абстрактные (открытые) бизнес-процессы;

3) процессы взаимодействия (глобальные).

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

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

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

Рассмотрим пример процесса «Обработка полученного счета», диаграмма которого представлена на рис. 8.5.

Рисунок8.5. Укрупненное представление процесса

«Обработка полученного счета»

 

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

После завершения действия «Проверить счет» управление передается действию «Одобрить платеж», выполняемому финансовымдиректором. Действие одобрения имеет бинарный (с двумя возможными значениями) результат: платеж либо одобряется, либо отклоняется, поэтому далее управление передается на шлюз типа «Исключающее ИЛИ управляемый данными», используемый в качествемеханизма ветвления.

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

Мы рассмотрели укрупненное представление процесса «Обработка полученного счета». Детальное представление того же процессапредставлено на рис. 8.6.

Упрощенный вариант модели, представленный на рис. 8.5, отражает действия одного процесса, локализованного одним пулом «Обработать полученный счет». Более детальное представление (см. рис. 8.6) показывает два взаимодействующих процесса, локализованные пулами «Обработать полученный счет» и «Запланировать платежи». Взаимодействие между процессами осуществляется посредством потоков сообщений.

Рассылкой сообщений занимается специальный элемент – действие типа «Свернутая задача» с пиктограммами . При этом пиктограмма (символические строки текста) означает, что данное действие манипулирует с сообщениями. Пиктограмма символизирует тип действия.

 

Рисунок8.6. Детальное представление процесса

«Обработка полученного счета»

 

На диаграмме представлено два типа потока сообщений:

1) пересылка данных в базу – не человеку;

2) выдача документа для прочтения человеком.

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

6. Прототип системы как механизм поддержки процесса формирования технического задания

В техническом задании (ТЗ) на создание ИС можно выделить двесамостоятельные части:

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

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

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

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

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

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