Виды диаграмм бизнес процессов

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

• Высокоуровневые невыполняемые
• Действия (нефункциональный анализ).
• Детализированный выполняемыйБизнес-процесс.
• Бизнес-процесс «As-is» (устаревший).
• Бизнес-процесс «To-be» (новый).
• Хореография (Choreography). Описание поведения, ожидаемого от двух или более у Участников процесса.
• Детализированный приватныйБизнес-процесс (как выполняемый, так и невыполняемый), включающий взаимоотношения между одним или более внешними участниками (Процесс типа «черный ящик»).
• Два или более детализированных выполняемых взаимодействующих Процесса.
• Детализированный выполняемый Бизнес-процесс, взаимодействующий с Хореографией.
• Два или более публичныхПроцесса.
• Публичный процесс, взаимодействующий с Хореографией.
• Два или более детализированных выполняемыхБизнес-процесса, взаимодействующих посредством Хореографии.

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

7.4. Использование текста, цвета и линий в моделировании диаграмм

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

• Элементы потока и другие элементы диаграммы МОГУТ носить текстовые метки (labels) (например, имя потока и/или названия других его атрибутов). Текстовые метки могут помещаться как внутри фигуры, так и над или под ней. Месторасположение текстовых меток, а также их направление может быть любым в зависимости от задумки разработчика модели или программы моделирования.
• Заливка графического элемента МОЖЕТ БЫТЬ как белого цвета, так и прозрачной.
• Графическая нотация МОЖЕТ допускать использование какого-либо другого цвета заливки для удовлетворения требований разработчика модели или программы моделирования (например, выделение значения атрибута объекта). Однако следует помнить о следующих правилах:
• События, определяющие дальнейший ход потока, ДОЛЖНЫ иметь темную заливку (см. заголовки Конечное события и Промежуточное событие).
• Дорожки Участников в фигуре Хореографии или Подхореографии ДОЛЖНЫ иметь светлую заливку в том случае, если Хореография/Подхореография (Choreography/Sub-choreography) не запускают Действие (см. заголовки Хореография и Подхореография).
• Элементы потока и маркеры МОГУТ БЫТЬ того размера, который удовлетворяет требованиям разработчика модели или программы моделирования.
• Линии, используемые в моделировании диаграмм, МОГУТ БЫТЬ черными.
• Графическая нотация допускает использование других цветов линий для удовлетворения требований разработчика модели или программы моделирования (например, выделение значения атрибута объекта).
• Графическая нотация МОЖЕТ допускать использование разного дизайна линий для удовлетворения требований разработчика модели или программы моделирования (например, выделение значения атрибута объекта), однако, при условии, что выбранный дизайн линий НЕ ДОЛЖЕН противоречить ни одному из вариантов, предложенных языком BPMN. Таким образом, дизайн линий, используемых для изображения Потока операций, Потока сообщений, а также Ассоциаций, изменяться НЕ ДОЛЖЕН.

7.5. Правила соединения элементов потока

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

Язык BPMN может подстраиваться под предъявляемые требования, однако, для соединения Элементов потока разработчикам моделей РЕКОМЕНДУЕТСЯ использовать имеющийся опыт, что облегчит понимание создаваемых диаграмм и сделает ход изображаемого бизнес-процесса прозрачным и доступным для понимания. Это особенно важно в том случае, если в диаграмме присутствуют такие графические элементы, как Поток операций или Поток сообщений. В данном случае оптимальным вариантом является выбор направления Потока операций, располагающегося либо слева направо, либо сверху вниз, а затем и выбор направления Потока сообщений, который необходимо расположить под углом в 90° по отношению к уже выбранному Потоку операций. При выполнении всех вышеперечисленных требований создаются удобные для работы диаграммы.

7.5.1. Правила соединения потоков операций

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

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

Таблица 7.3 – Правила Соединения Потока Операций

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

7.5.2. Правила соединения потоков сообщений

Таблица 7.4 содержит изображения объектов моделирования BPMN, а также показывает, каким образом данные объекты соединяются друг с другом посредством Потока сообщений. Эти правила также применимы к элементам диаграммы Взаимодействия.

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

Таблица 7.4 – Правила Соединения Потока сообщений

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

7.6. Расширяемость BPMN

BPMN 2.0 описывает механизм, позволяющий расширять список атрибутов для стандартных графических элементов диаграммы. При необходимости разработчиком модели или программой моделирования могут быть задействованы нестандартные атрибуты графических элементов или Артефакты, такие, как уникальные требования для вертикальной области. Для того, чтобы не нарушить логику, описываемую в BPMN, такие атрибуты НЕ ДОЛЖНЫ противоречить семантике использования любого их графических элементов BPMN. Необходимо отметить, что, несмотря на возможность добавления новых атрибутов, должны быть сохранены все основные принципы построения и наглядность диаграммы для лучшего её восприятие пользователем любого уровня подготовки. Помните, что фигуры основных элементов потока (События, Действия и Шлюзы) НЕ ДОЛЖНЫ видоизменяться.

Данная спецификация делает различие между обязательными и дополнительными элементами (см. раздел 8.3.2, содержащий описание синтаксиса для создания расширений). Если используются обязательные элементы, то они ДОЛЖНЫ учитываться при внедрении диаграмм. Если используются дополнительные элементы, то при внедрении диаграмм они МОГУТ БЫТЬ опущены.

7.7. Примеры Процессов BPMN

В данном подразделе представлен пример производственного процесса, рассмотренный с разных ракурсов.

Фигура 7.6 – Пример диаграммы Взаимодействия с Пулами в виде «черных ящиков».

Фигура 7.7 – Пример диаграммы автономной Хореографии.

Фигура 7.8 – Пример диаграммы автономного Процесса (Оркестровки).

• Область действия документа
• Соответствие требованиям спецификации
• Нормативные ссылки
• Термины и определения
• Символы
• Дополнительная информация
• Общее представление
• Элементы BPMN
• Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)
• Структура нотации BPMN
• Шлюзы (Gateways)
• Общие элементы (Common Elements)
• Обмен Сообщениями (Conversations)
• Взаимодействие (Collaboration)
• Процесс
• Процесс. Распределение ресурсов
• Процесс. Участие людей
• Процесс. Подпроцесс
• Процесс. Действие Вызов
• Процесс. Представление XML-схемы для Действий
• Процесс.Компоненты и Данные
• Процесс. Семантика исполнения для данных
• Процесс. Событие
• Процесс. Конечное событие
• Процесс. Элементы EventDefinition
• Процесс. Обработка Событий
• Процесс. Представление XML-схемы для пакета События
• Процесс. Шлюзы
• Процесс. Компенсация
• Процесс. Экземпляры Процесса, Немоделируемые Действия и Публичный Процесс

• Главная
• Нотация BPMN 2.0
• Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)

Источник: www.elma-bpm.ru

Введение в BPMN

Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) — это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.

Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:

• Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
• Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
• Возможность автоматизировать бизнес-процессы без необходимости программирования;
• Уменьшение разрыва между моделями «Как есть» и «Как должно быть».

Как пользоваться данным руководством

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

Руководство по BPMN имеет следующие особенности:

• Все содержимое полностью соответствует последней версии спецификации нотации BPMN;
• Статьи сфокусированы на нотации моделирования, без привязки к какому-либо конкретному программному продукту, что дает возможность применять полученные знания в любых программах, которые поддерживают моделирования в BPMN;
• Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;
• Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;
• Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.

Хотите быстро освоить BPMN?
Пройдите обучение в нашем учебном центре!

Источник: www.optimacons.info

Моделирование бизнес-процессов средствами языка моделирования uml Основные сведения

Диаграммы вариантов использования иногда в литературе называют диаграммами прецедентов. Мы будем использовать первый термин. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Варианты использования являются необходимым средством на стадии анализа предприятий и на стадии формирования требований к будущей ИС. Каждый вариант использования — это модель одного бизнес-процесса, реализуемого на предприятии. В проектировании ИС вариант использования является одним потенциальным требованием к системе, и пока оно не выявлено, невозможно запланировать его реализацию. Действующее лицо(actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. Действующие лица делятся на три основных типа:

• пользователи системы,
• другие системы, взаимодействующие с данной,
• время.

Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Для наглядного представления вариантов использования в качестве основных элементов процесса разработки ПО применяются диаграммы вариантов использования. На рис. 1 показан пример такой диаграммы для банковской системы с банкоматами. Эту диаграмму на стадии анализа можно также понимать как модель бизнес процесса по работе с клиентами.Рис. 1. Пример диаграммы вариантов использования На данной диаграмме человеческие фигурки обозначают действующих лиц, овалы — варианты использования, а линии и стрелки — различные связи между действующими лицами и вариантами использования. На этой диаграмме показаны два действующих лица: клиент и внешняя кредитная система. Существуют также шесть основных бизнес-функций, выполняемых банком:

• перевести деньги,
• сделать вклад,
• снять деньги со счета,
• просмотреть баланс,
• изменить PIN-код
• сделать платеж.

На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Один вариант использования отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Данная диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами банковской системы. В сущности, диаграмма вариантов использования иллюстрирует требования к системе. В нашем примере клиент банка инициирует большое количество различных вариантов использования: «Снять деньги со счета», «Перевести деньги», «Сделать вклад», «Просмотреть баланс» и «Изменить PIN-код». От варианта использования «Сделать платеж» стрелка указывает на «Кредитную систему». Действующими лицами могут быть внешние системы, и потому в данном случае «Кредитная система» показана именно как действующее лицо — она внешняя для банковской системы. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом. В данном случае вариант использования «Сделать платеж» предоставляет «Кредитной системе» информацию об оплате по кредитной карточке. Все варианты использования так или иначе связаны с внешними требованиями к функциональности системы. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач. Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи. Конкретная цель диаграмм вариантов использования — это документирование:

• вариантов использования (все, входящее в сферу применения системы),
• действующих лиц (все вне этой сферы),
• связей между ними.

Разрабатывая диаграммы вариантов использования, старайтесь придерживаться следующих правил:

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

• каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда имеется стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает идентифицировать варианты использования. Варианты использования обозначают действия системы. Для того чтобы фактически разработать систему, потребуются более конкретные детали. Эти детали описываются в документе, называемом «поток событий» (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что — сама система. Для моделирования бизнес-процессов организаций и предприятий также средствами UML также можно применять диаграммы деятельности. Ранее при проектировании информационных систем эти диаграммы мы использовали для моделирования динамических аспектов создаваемых ИС. В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности.

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