Это то что происходит в течение бизнес процесса и оказывает влияние на его ход

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

Не менее важной целью BPMN было создание внутренней модели, связывающей поколение языков XML с реализацией бизнес-процессов, как например BPEL4WS

(Business Process Execution Language for Web Services) и BPML (Business Processing Modeling Language). Тем самым, BPMN создает важное звено в виде стандарта между проектированием и внедрением бизнес-процесса. Разработка BPMN осуществлялась на твердой математической основе, чтобы язык реализации был максимально точен.

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

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

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

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

Список некоторых программных продуктов, поддерживающих нотацию

1) Oracle BPM Suite (Oracle Corp.)

2) Unify NXJ (Unify Corp.)

3) IBM Web Sphere Business Modeler Advanced (IBM)

4) Lombardi Teamworks (Lombardi Software → с недавних пор IBM, IBM WebSphere Lombardi)

5) SAP Netweaver BPM (SAP)

6) TIBCO iProcess Suite (TIBCO Software Inc.)

7) Intalio (Intalio)

8) Active Modeler Avantage (KAISHA Tec. Company)

9) Runa WFE (Консалтинговая группа «Руна»)

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

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

Выделяют четыре основные категории элементов:

• Объекты потока управления (Flow Objects): события, действия и логические операторы

• Соединяющие объекты (Connecting Objects): поток управления, поток сообщений

• Роли или зоны ответственности (Swimlanes): пулы и дорожки

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

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

1. Объекты потока управления

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

События (Events);

Шлюзы (Gateways).

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

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

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

Рис.1 – Графическое представление события

Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа:

— Стартовое событие (Start),

— Промежуточное событие (Intermediate),

— Конечное событие (End).

1.1.1. Стартовое событие (Start Event)

Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной бизнес-процесс.

В контексте потока операций Стартовое событие является начальной точкой в

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

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

Рис.2 – Графическое представление начального события

Стартовое событие имеет следующие особенности:

Стартовое событие является НЕОБЯЗАТЕЛЬНЫМ. Процессы верхнего уровня, а также Развернутые Подпроцессы МОГУТ начинаться со Стартового события, однако, данное условие не является обязательным.

В случае если Процесс является комплексным и/или исходные условия – не очевидны, то РЕКОМЕНДУЕТСЯ использовать Стартовое событие.

В случае, если диаграмма содержит Конечное событие, то ДОЛЖНО БЫТЬ по меньшей мере одно Стартовое событие.

1.1.2. Конечное событие (End Event)

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

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

Конечное событие представляет собой круг, выполненный одиночной, жирной, черной линией (см. рис.3). Толщина линии должна быть жирной настолько, чтобы без труда можно было отличить Конечное событие от Стартового и Промежуточного.

Рис.3 – Графическое представление конечного события

Конечное событие имеет следующие особенности: Процессы МОГУТ содержать несколько Конечных событий.

Значок Конечного события является ОПЦИОНАЛЬНЫМ. Процесс определенного уровня — Процесс верхнего уровня или Развернутый Подпроцесс – МОЖЕТ удовлетворять данному требованию, однако, это не является необходимым условием.

В случае, если диаграмма содержит Стартовое событие, то ДОЛЖНО БЫТЬ по меньшей мере одно Конечное событие.

1.1.3. Промежуточное событие (Intermediate Event)

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

Промежуточное событие может быть задействовано для того, чтобы:

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

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

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

Рис.4 – Графическое представление промежуточного события Промежуточное событие может соединяться с любой точкой границы действия,

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

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

1.1.4. Триггеры событий (маркеры событий)

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

Рис 5. Типы событий в BPMN 1.1

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

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

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

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

• События-ошибки (error events) позволяют смоделировать генерацию

и обработку ошибок в процессе. Ошибки могут иметь различные типы.

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

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

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

• События-сигналы (signal events) рассылают и принимают сигналы между несколькими процессами. Один сигнал может обрабатываться несколькими

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

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

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

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

Здесь хорошо бы примеры

1.2. Действие (Activity)

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

1. Процесс (Process),

2. Подпроцесс (Sub-Process),

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

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

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

Подпроцесс представляет собой составное действие, заключающее в себе поток операций.

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

Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты. В этом случае его графическое представление дополняется маркером, что позволяет отличить подпроцесс от задачи (рис. 6). Также подпроцесс может быть представлен в развернутом виде (рис. 7).

Стандартное представление подпроцесса Подпроцесс в WebSphere Business Modeler

Рис. 6 – Свернутый подпроцесс

Рис. 7 – Развернутый подпроцесс

BPMN различает пять типов стандартных маркеров Свернутого Подпроцесса. Маркер Подпроцесса, изображенный на рис.6, может сочетаться с оставшимися четырьмя маркерами: Маркером Цикла (Loop Marker), Параллельным Маркером

(Многоэкземплярным) (Parallel/Multiple Instance Marker), Маркером Компенсации (Compensation Marker) и Маркером Ad Hoc (Ad-Hoc Marker). Помимо Маркера Подпроцесса, Свернутый Подпроцесс может содержать от одного до трех вышеуказанных Маркеров. Комбинации Маркеров могут быть любыми, кроме сочетания Маркера Цикличности и Многоэкземплярного, — эти Маркеры не могут изображаться одновременно

Источник: studfile.net

Элементы потока

В таблице 6.1 представлены графические элементы BPMN, относящиеся к категории «Элементы потока», которые обозначают различные события.

Таблица 6.1. Графические элементы BPMN «Событие».

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

В таблице 6.2 представлены графические элементы BPMN, относящиеся к категории «Элементы потока», которые обозначают различные действия и операции с потоками.

Таблица 6.2. Графические элементы BPMN «Действие» и «Шлюз».

Воспользуйтесь поиском по сайту:

studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.013 с) .

Источник: studopedia.org

Представление BPMN-диаграммы с помощью УФО-модели

Для обеспечения такого представления используем соответствие между графическими элементами BPMN-нотации и УФО-моделей показанное в таблице З.2.

Таблица З.2. Соответствие графических элементов BPMN и УФО.

Описание элемента	Элементы BPMN	Элементы УФО
Событие (Event) Событие – это то, что происходит в течение бизнес-процесса и оказывает влияние на его ход. Чаще всего событие имеет причину (триггер) или воздействие (результат). Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (Start), Промежуточное событие (Intermediate) и Конечное событие (End).	Маркеры (триггеры) событий: -сообщение, -таймер, -ошибка, -отмена, -компенсация, -условиеправило, -сигнал.
Действие (Activity) Действие – общий термин, обозначающий работу, выполняемую исполнителем. Действия могут быть либо элементарными, либо неэлементарными (составными). Выделяют следующие виды действий, являющихся частью модели Процесса: Процесс (Process), Подпроцесс (Sub-Process) и Задача (Task).
Шлюз (Gateway) Шлюзы используются для контроля расхождений и схождений потока операций. Таким образом, данный термин подразумевает ветвление, раздвоение, слияние и соединение маршрутов. Внутренние маркеры указывают тип контроля развития бизнес-процесса.	Типы шлюзов: -Эксклюзивные ИЛИ (XOR); -ИЛИ (OR); -Комплексные (Complex); -И (AND).
Поток операций (Sequence Flow) Поток операций служит для отображения того порядка, в котором организованы действия Процесса.
Поток сообщений (Message Flow) Поток сообщений служит для отображения обмена сообщениями между двумя участниками, готовыми эти сообщения отсылать и принимать. На диаграмме BPMN два отдельно взятых Пула представляют собой двух участников процесса.
Объект данных (Data Object) Объекты данных рассматриваются как артефакты, так как они не влияют непосредственно на последовательный поток или поток сообщений процесса, но они обеспечивают ввод информации о том, какие действия требуют выполнения и/или что они производят.

Рассмотрим пример модели в нотации BPMN (см. рис. З.11).

Преобразуем представленную на рисунке З.11 BPMN-диаграмму в УФО-модель, используя соответствия между графическими элементами. Результаты представлены на рисунках З.12 – З.14. В результате выполненного преобразования можно утверждать, что УФО-модель будет соответствовать BPMN-диаграмме если в ней:

— в классификацию, в категорию связей «По управлению (С)» введен абстрактный класс связей «Событие», разделенный на подклассы связей, соответствующие маркерам (триггерам) событий (так как элемент «Событие» в нотации BPMN, по сути дела, представляет связи/потоки или поступающие на обработку (на вход процесса), или генерируемые процессом (поступающие на выход));

— УФО-элементы в модели определены на уровне функций;

— введены специальные/служебные УФО-элементы, определенные на уровне узлов, обозначающие логические операции, обеспечивающие схождение и расхождение потоков;

— все потоки в BPMN-модели (операций и сообщений) представляются в УФО-модели связями из классификации (так как действия в процессах не могут просто так переходить одно в другое, они всегда обмениваются материей и информацией);

— элемент BPMN-модели «Объект данных» представляется в УФО-модели определенного вида связью из категории связей «По данным (D)»;

— пулы и дорожки BPMN-диаграммы представляются в УФО-модели УФО-элементами, определенными на функциональном уровне.

Показанное соответствие графических элементов некоторых графоаналитических нотаций (так называемых WF-спецификаций) элементам системно-объектных моделей, а также приведенные примеры преобразования диаграмм в этих нотациях в модели «Узел-Функция-Объект» показывают универсальность УФО-моделей. Таким образом, УФО-подход позволяет моделировать любые процессы и системы без ограничений и способен заменить собой любую существующую нотацию бизнес-моделирования. Учитывая, что возможна формализация УФО-подхода с помощью алгебраических средств (теории паттернов и теории процессов), можно говорить об УФО-моделировании как о едином универсальном способе представления организационных знаний. Данное обстоятельство обосновывает мнение отечественных специалистов по WF-языкам о том, что: «Еще нет WF-спецификации, с которой не было бы связано серьезных проблем, лидеры в этой области пока выглядят неоправданно сложными. Возможно, реальным WF-стандартом станет еще только разрабатываемая спецификация» [116].

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru