Нотация бизнес процесса это

Самоучитель UML 9 стр.

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

Рис. 2.11. Диаграмма «сущность-связь» для примера сотрудников, участвующих в работе над проектами

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

Рис. 2.12. Диаграмма «сущность-связь» для общего примера компании

Нотации описания бизнес-процессов. Часть 3. Нотация EPC | Naked BPM

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

Диаграммы функционального моделирования

Начало разработки диаграмм функционального моделирования относится к середине 1960-х годов, когда Дуглас Т. Росс предложил специальную технику моделирования, получившую название SADT (Structured Analysis https://sharlib.com/read_345549-9″ target=»_blank»]sharlib.com[/mask_link]

Нотации основных методологий моделирования

Нотация моделирования бизнес-процессов BPMN (Business Process Modeling Notation) была впервые представлена публике еще в 2004 г. и описана консорциумом Object Management Group. В основе управления процессами в BPMN лежит идея, что сама стратегия управления опирается на три основные методологии: моделирования бизнес-процессов, анализа и оптимизации. В свою очередь, их поддерживает ряд инструментальных средств, служащих:

• • для разработки стратегии, описания, анализа, документирования;
• • информационной поддержки бизнес-процессов;
• • поддержки потока работ (Workflow management).

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

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

• • диаграммы активности UML;
• • диаграмма потоков активностей и принятия решений ADF (activity decision flow);
• • диаграмма событийных цепочек процесса ЕРС (event-driven process chain);
• • нотация функционального моделирования IDEF (Icam DEFinition for functional modeling);
• • другие модели (UMLEDOC Business Processes, RosettaNet, LOVeM).

В 2010 г. была опубликована версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в том числе консорциума OMG, Института Хассо Платтнера (Hasso Plattner Institut, Потсдам, Германия), университета Гумбольдта (Берлин, Германия), университетской инициативы Signavio.

Нотации описания бизнес-процессов — IDEF0 | Naked BPM

В 2013 г. версия BPMN 2.0.1 была принята как международный стандарт IS0/1 ЕС 19510:2013 Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.

Основные понятия и группы объектов в BPMN приведены в табл. 4.6.

Основные понятия и группы объектов в BPMN

При помощи объектов Действия описываются задачи (бизнес-правила, сценарии, задачи-сервисы, задачи отправки сообщений и др.). Задачи затем детализируются, в том числе за счет маркеров действий (сценариев действий) и определения потоков (порядка и условий выполнения действий)

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

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

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

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

Диалоги и взаимодействия

Определение характера информационных взаимодействий: один-к- одному либо один-ко-многим. Отличие от хореографии — в выделении нескольких пулов действий (swimlanes) и детальном описании каждого из них (пример таких пулов приведен на рис. 4.17)

Благодаря группе объектов Роли определяются:

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

Нотация еЕРС (Extended Event-driven Process Chain, расширенная событийная цепочка процессов) предполагает описание алгоритма действий, выполняемых отдельными организационными единицами, что позволяет сформировать общий сценарий процесса как последовательность отдельных шагов.

Рис. 4.17. Пример BPMN-диаграммы

Основными объектами диаграммы еЕРС являются элементы, приведенные в табл. 4.7.

Объекты и нотация диаграмм еЕРС

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

Правила выполнения функции (если наступает только одно из событий или обязательно оба события) и правила наступления событий при выполнении функций (по сути, правила слияния и разделения ветвей процесса)

Описание элемента работы, который представляет собой один этап процесса

Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов (как для логической последовательности «следу- ющий/предыдущий процесс», так и для обозначения направления передачи объекта)

Объекты организационной схемы

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

еЕРС нс случайна названа «расширенной» диаграммой — на практике в модели такого вида могут также включаться другие объекты, например:

• • товарно-материальные ценности;
• • бумажные и электронные документы;
• • продукты (используемые и производимые);
• • объекты информации;
• • информационные системы и их отдельные модули и функции;
• • базы данных;
• • цели (которые поддерживаются конкретной функцией);
• • места выполнения (например, производственный цех № 4);
• • другие элементы описания.

Между всеми объектами в обязательном порядке определяются связи, например, «создает» (документ), «распределяет» (задание между сотрудниками), «использует» (информационную систему 1C), «выполняет» (функцию выполняет менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие другие.

Текстовое описание

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

Графическое описание

Рис. 4.18. Графическое описание алгоритма

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

Архитектура интегрированных программных систем ARIS — инструментальная система моделирования бизнеса, разработанная компанией IDS Scheer AG и ныне принадлежащая Software AG.

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

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

Рис. 4.19. Структура ARIS

Таким образом, ARIS как методология позволяет моделировать такие подсистемы предприятия, как организационная, функциональная, информационная, процессная и подсистема входов/выходов. Они формируются на трех уровнях описания, иерархически идущих от анализа проблем бизнеса к конкретной реализации при помощи ИТ:

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

Для каждого из представлений программный продукт ARIS предусматривает различные виды диаграмм:

• • организационная диаграмма;
• • диаграмма данных ERM;
• • диаграммы BPMN 2.0;
• • процессный ландшафт (цепочка добавленной стоимости VACD);
• • системный ландшафт (диаграмма компонентов);
• • иерархическая диаграмма активностей (whiteboard);
• • диаграмма бизнес-процессов ЕРС;
• • диаграмма ИТ-инфраструктуры (сети);
• • диаграмма общего вида.

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

Расширения ARIS

Визуализация проблем производительности

Получение отчетов/оповещений о достижении критических отметок показателей процессов

Мониторинг данных, процессов и их ключевых индикаторов (например, функционально-стоимостной анализ затрат)

Управление бизнес-операциями, рисками и требованиями, контроль исключений

Управление политиками и соответствием требованиям регуляторов

Формирование карт политик в бизнес-контексте с разграничением зон ответственности

Сочетание политик управления требованиями, рисками и процессами

Ведение журнала аудита с возможностью формирования сложных отчетов (в том числе по контрольным панелям)

Управление взаимодействием: создание рабо- чей платформы коллаборации

Организация общих обсуждений процессов/приложений/данных

Представление моделей процессов в формате web-страниц

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

Возможность для специалистов компании предложить свои улучшения в процессах

Возможность «прогона» (симуляции) моделей BPMN 2.0 и ЕРС для выявления различий моделей As-Is и То-Ве

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

Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов

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

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

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

it-diver

BPMN — это графическая нотация для моделирования бизнес-процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group. Привожу выдержки из статьи в Wikipedia и сайта bpmn.org.

Элементы

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

• Объекты потока управления : события, действия и логические операторы
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли : пулы и дорожки
• Артефакты : данные, группы и текстовые аннотации.

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

Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).

События

изображаются окружностью и означают какое-либо происшествие в мире. События инициируют действия или являются их результатами. Согласно расположению в процессе события могут быть классифицированы на начальные (start), промежуточные (intermediate) и завершающие (end). Начиная с 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) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).

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

* Задание (task) это единица работы, элементарное действие в процессе.
* Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
* Циклическое действие (loop activity) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.
* Свёрнутый подпроцесс (collapsed subprocess) является сложным действием и содержит внутри себя правильную ДБП.
* Развёрнутый подпроцесс (expanded subprocess) также является составным действием, но скрывает детали реализации процесса.
* Ad-hoc подпроцесс (ad-hoc subprocess) содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

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

* Оператор исключающего ИЛИ управляемый данными (data-based exclusive gateway) Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.
* Оператор исключающего ИЛИ управляемый событиями (event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.
* Оператор И (parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.
* Оператор включающего ИЛИ (inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор синхронизирует потоки, то он ожидает завершения выполнения всех активированных ветвей и затем активирует выходной поток.
* Сложный оператор (complex gateway) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.

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

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

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

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

Роли

Роли — визуальный механизм организации различных действий в категории со сходной функциональностью. Существует два типа ролей:
Типы ролей в BPMN 1.1

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

Артефакты

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

показывают читателю какие данные необходимы действиям для выполнения и какие данные действия производят.

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

используются для уточнения значения элементов диаграммы и повышения её информативности.

Источник: itdiver.blogspot.com

Модель и нотация бизнес-процесса

Графическое представление для определения бизнес-процессов Пример модели бизнес-процесса и нотации для процесса с нормальным потоком.

Модель и нотация бизнес-процессов (BPMN ) — это графическое представление для определения бизнес-процессов в модели бизнес-процессов.

Первоначально разработанная Business Process Management Initiative (BPMI), BPMN поддерживалась Object Management Group (OMG) с момента объединения двух организаций в 2005 году. Версия 2.0 BPMN был выпущен в январе 2011 года, после чего название было изменено на Модель бизнес-процесса и нотация, чтобы отразить введение семантики выполнения, которая была введена наряду с существующими элементами нотации и диаграмм. Хотя это спецификация OMG, BPMN также ратифицирована как ISO 19510. Последняя версия — BPMN 2.0.2, опубликованная в январе 2014 года.

Обзор

Модель и обозначение бизнес-процесса (BPMN) — это стандарт для моделирования бизнес-процессов, который предоставляет графическое представление для указания бизнес-процессов в диаграмме бизнес-процессов (BPD) на основе блок-схемы методика очень похожа на диаграммы действий из Unified Modeling Language (UML). Цель BPMN — поддерживать управление бизнес-процессами как для технических пользователей, так и для бизнес-пользователей, предоставляя нотацию, которая интуитивно понятна бизнес-пользователям, но способна представить сложную семантику процесса. Спецификация BPMN также обеспечивает соответствие между графикой нотации и базовыми конструкциями языков исполнения, в частности языка выполнения бизнес-процессов (BPEL).

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

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

Были разработаны два новых стандарта, использующих подход, аналогичный BPMN: моделирование управления делами (Модель управления делами и нотация ) и моделирование решений, (Модель решения и обозначение ).

Темы

Объем

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

• Организационные структуры
• Функциональная разбивка
• Модели данных

Кроме того, в то время как BPMN показывает поток данных (сообщений) и связь артефакты данных для действий, это не диаграмма потока данных.

Элементы

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

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

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

Объекты потока и соединяющие объекты

Объекты потока являются основными описывающими элементами в BPMN и состоят из трех основных элементов: событий, действий, и шлюзы.

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

События также классифицируются как Catching (например, если захват входящего сообщения запускает процесс) или Throwing (например, выдача сообщения о завершении при завершении процесса). Начальное событие Действует как триггер процесса; обозначается единственной узкой рамкой и может быть только Catch, поэтому отображается открытым (контурным) значком.

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

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

Он может быть атомным или составным. Задача Задача представляет собой отдельную единицу работы, которая не может быть разбита на более высокий уровень детализации бизнес-процесса. Это называется атомной активностью. Задача — это деятельность самого низкого уровня, показанная на диаграмме процесса. Набор задач может представлять собой процедуру высокого уровня.

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

Имеет свои собственные автономные начальные и конечные события; потоки последовательности от родительского процесса не должны пересекать границу. Транзакция Форма подпроцесса, в которой все содержащиеся в ней действия должны обрабатываться как единое целое; то есть все они должны быть выполнены для достижения цели, и если какой-либо из них не удается, все они должны быть компенсированы (отменены).

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

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

Parallel Используется для создания параллельных путей без оценки каких-либо условий. Inclusive Используется для создания альтернативных потоков, в которых оцениваются все пути. Exclusive Event Based Событие оценивается для определения того, какой из взаимоисключающих путей будет выбран. Сложный Используется для моделирования сложного поведения синхронизации. Параллельное событие На основе Два параллельных процесса запускаются на основе события, но событие не оценивается. Соединения

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

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

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

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

Дорожки плавания и артефакты

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

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

Е. Скрывая внутренние детали), когда он изображается как пустой прямоугольник, растягивающий ширину или высоту диаграмма. Дорожка Используется для организации и категоризации действий в пуле в соответствии с функцией или ролью и изображается в виде прямоугольника, растягивающегося по ширине или высоте пула. Дорожка содержит объекты потока, соединяющие объекты и артефакты.

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

• Объекты данных: объекты данных показывают читателю, какие данные требуются или создаются в действии.
• Группа: Группа представлена ​​прямоугольником с закругленными углами. и пунктирные линии. Группа используется для группировки различных действий, но не влияет на последовательность операций на диаграмме.
• Аннотация: аннотация используется, чтобы дать читателю модели / диаграммы понятное впечатление.

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

BPMN 2.0.2

Видение BPMN 2.0. 2 состоит в том, чтобы иметь единую спецификацию для новой модели и нотации бизнес-процесса, которая определяет нотацию, метамодель и формат обмена, но с измененным именем, которое по-прежнему сохраняет бренд «BPMN». К функциям относятся:

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

Текущая версия спецификации была выпущена в январе 2014 года.

Сравнение версий BPMN

• Совместные (общедоступные) B2B процессы,
• внутренние (частные) бизнес-процессы.

• Совместные (общедоступные) B2B процессы,
• внутренние (частные) бизнес-процессы,
• a хореография — ожидаемое поведение между двумя или более участниками бизнеса,
• колл. aborations, который представляет собой набор участников и их взаимодействие, и
• диалог — логическая связь обмена сообщениями.

• start (нет, сообщение, таймер, правило, ссылка, несколько)
• промежуточный (нет, сообщение, таймер, ошибка, отмена, компенсация, правило, ссылка, несколько)
• конец (нет, сообщение, ошибка, отмена, компенсация, ссылка, завершение, несколько)

• начало (нет, сообщение, таймер, условное, сигнал, несколько)
• промежуточное (нет, сообщение, таймер, ошибка, отмена, компенсация, условное, ссылка, сигнал, несколько)
• конец (нет, сообщение, ошибка, отмена, компенсация, сигнал, завершение, несколько)

• начало

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

• перехват (сообщение, таймер, условное, ссылка, сигнал, несколько, параллельное множественное)
• прерывание границы (сообщение, таймер, эскалация, условное, ошибка, отмена, компенсация, сигнал, множественный, параллельный множественный)
• граница без прерывания (сообщение, таймер, эскалация, условная, сигнал, множественная, параллельная множественная, завершение)
• выброс (нет, сообщение, эскалация, связь, компенсация, сигнал, несколько, несколько параллелей)

• задача ( атомарный)
• процесс / подпроцесс (неатомарный)

• свернутый подпроцесс
• расширенный подпроцесс

• задача (атомарный)
• хореография задача

• свернутый подпроцесс хореографии
• расширенный подпроцесс хореографии

• свернутый подпроцесс
• расширенный подпроцесс

• XOR — исключительное решение и слияние. как на основе данных, так и на основе событий. на основе данных может отображаться с маркером «x» или без него.
• OR — включающее решение и объединение
• сложное — сложные условия и ситуации
• И — разветвление и объединение

• эксклюзивное решение и слияние. как на основе данных, так и на основе событий. на основе данных может отображаться с маркером «x» или без него.
• включающее решение и объединение.
• комплекс — сложные условия и ситуации.
• параллельное разветвление и объединение.

• эксклюзивное решение и слияние. как на основе данных, так и на основе событий. исключительный может отображаться с маркером «x» или без него.
• включительно решение шлюза и объединение
• сложный шлюз — сложные условия и ситуации
• параллельный шлюз — разветвление и объединение

нормальный поток . неуправляемый поток. условный поток. поток по умолчанию. поток исключений

• объект данных

• сбор
• ввод данных
• вывод данных

• цикл

• цикл активности
• цикл потока последовательности

• цикл

• цикл активности
• цикл потока последовательности

• новая спецификация вводит категоризацию триггеров событий на «захват» и «выброс». Т.е. теперь есть два типа промежуточных сообщений сообщений: один отвечает за прием сообщений («перехват»), а другой — за отправку сообщений («бросание»).
• В дополнение к старым типам он вводит нового типа, сигнальное событие .
• События начала и конца ссылки больше не существуют в BPMN 1.1.
• Старые «события правила» были переименованы в условные события . Семантика и внешний вид не изменились.
• Шлюз на основе событий в BPMN 1.1 выглядит немного иначе, чем в 1.0. Вместо шестиугольной звезды у нее теперь в центре пятиугольник. Такая же форма также используется для нескольких событий (начало, промежуточное, конечное).
• Существует дополнительная линия, отделяющая описание вашей дорожки от ее содержимого.

Внесенные в второстепенную версию BPMN 1.2 изменения состоят из редакционных исправлений. и исправления ошибок реализации. Следовательно, эти незначительные изменения влияют на поставщиков инструментов моделирования больше, чем на разработчиков моделей (пользователей).

• Хореографии

• Хореографии-модели
• Conversation-model

• Вызываемый элемент
• Активность вызова
• Глобальная задача

• Эксклюзивный / Параллельный Шлюз на основе событий (они стоят в начале процесса)

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

• Объекты данных (сбор, ввод данных, вывод данных)

Типы подпрограмм BPMN -model

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

Частные (внутренние) бизнес-процессы Частные бизнес-процессы — это внутренние бизнес-процессы конкретной организации, которые обычно называются бизнес-процессами или процессами BPM. Если используются плавательные дорожки, то частный бизнес-процесс будет содержаться в одном пуле.

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

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

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

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

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

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

• Действия частных процессов высокого уровня (не функциональная разбивка) *
• Подробные частные бизнес-процесс
• Как есть или старый бизнес-процесс *
• Будущий или новый бизнес-процесс
• Подробный частный бизнес-процесс с взаимодействием с одним или несколькими внешними объектами (или « Черный ящик »)
• Два или более подробных частных бизнес-процесса, взаимодействующих
• Подробная связь частного бизнес-процесса с абстрактным процессом
• Подробная взаимосвязь частного бизнес-процесса с процессом совместной работы
• Два или более абстрактных процесса *
• Отношение абстрактного процесса к процессу сотрудничества *
• Только процесс сотрудничества (например, ebXML BPSS или RosettaNet) *
• Два или более подробных частные бизнес-процессы, взаимодействующие через свои абстрактные процессы и / или процесс сотрудничества

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

Сравнение с другими нотациями моделирования процессов

Управляемые событиями цепочки процессов (EPC) и BPMN — две нотации с одинаковой выразительностью, когда речь идет о моделировании процессов. Модель BPMN может быть преобразована в модель EPC. И наоборот, модель EPC может быть преобразована в модель BPMN с небольшой потерей информации.

Исследование показало, что для того же процесса модели BPMN может потребоваться примерно на 40% меньше элементов, чем соответствующей модели EPC, но с немного большим набором символов. Таким образом, модель BPMN будет легче читать. Преобразование между двумя нотациями можно автоматизировать.

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

Слабые стороны

Слабые стороны BPMN могут быть связаны с:

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

BPEL и BPMN

Спецификация BPMN включает неформальное и частичное отображение из BPMN в BPEL 1.1. Более подробное отображение BPMN в BPEL было реализовано в ряде инструментов, включая инструмент с открытым исходным кодом, известный как BPMN2BPEL. Однако разработка этих инструментов выявила фундаментальные различия между BPMN и BPEL, которые делают очень трудным, а в некоторых случаях невозможным создание удобочитаемого кода BPEL из моделей BPMN. Еще более трудной является проблема проектирования двустороннего обмена между BPMN и BPEL: генерация кода BPEL из диаграмм BPMN и поддержание исходной модели BPMN и сгенерированного кода BPEL синхронизированными в том смысле, что любые изменения одной модели распространяются на другую.

См. Также

• DRAKON
• BPEL
• Управление бизнес-процессами
• Моделирование бизнес-процессов
• Сравнение моделей бизнес-процессов и инструментов моделирования нотации
• Модель решения и нотация
• CMMN (Модель управления делами и обозначения)
• Служба обмена сообщениями, управляемая процессами
• Цепочки процессов, управляемые событиями
• Функциональная модель
• Архитектура функционального программного обеспечения
• Рабочий процесс
• Шаблоны рабочих процессов
• Служба Компонентная архитектура
• Модель принятия решения и обозначение (DMN)
• XPDL
• YAWL

Ссылки

Дополнительная литература

• Гросскопф, Декер и Веск. (28 февраля 2009 г.). Процесс: моделирование бизнес-процессов с использованием BPMN. Меган Киффер Пресс. ISBN978-0-929652-26-9. Архивировано из оригинала 30 апреля 2019 г. Получено 9 июля 2020 г.
• Райан К. Л. Ко, Стивен С. Г. Ли, Энг Ва Ли (2009 г.) Стандарты управления бизнес-процессами (BPM): обзор. В: Журнал управления бизнес-процессами, Emerald Group Publishing Limited. Том 15 Выпуск 5. ISSN 1463-7154. PDF
• Стивен А. Уайт; Конрад Бок (2011). Руководство по BPMN 2.0, второе издание: методы, концепции, тематические исследования и стандарты в нотации управления бизнес-процессами. Future Strategies Inc. ISBN978-0-9849764-0-9.

Внешние ссылки

На Викискладе есть материалы, относящиеся к нотации моделирования бизнес-процессов.

• Спецификация OMG BPMN
• Матрица инструментов BPMN
• Домашняя страница информации BPMN Страница информации OMG для BPMN.

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

Принципы использования BPMN

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

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

Рисунок 42 — Пример описания внешнего бизнес-процесса Глобальный бизнес-процесс показывает взаимодействие между двумя или более участниками в виде последовательности действий, включающих обмен сообщениями. BPMN-модель глобального процесса может быть преобразована в форматы различных языков описания бизнес- взаимодействия, например ebXML и RosettaNet. Глобальный процесс может быть представлен в виде двух или нескольких внешних процессов, обменивающихся сообщениями друг с другом, и отражает только «точки соприкосновения» взаимодействующих субъектов, скрывая структуру внутренних процессов каждой из сторон. Пример диаграммы глобального бизнес-процесса показан на рисунке 43.

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

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

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

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

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

Рисунок 44 — Фрагмент описания бизнес-процесса с использованием транзакции и корректировок

Разработчиками BPMN во многом двигало желание преодолеть разрыв между нотациями моделирования бизнес-процессов, ориентированными на бизнес-пользователей, и исполняемыми языками, предназначенными для формального описания процессов при их автоматизации с помощью информационных систем. Каждый графический объект BPMN снабжен стандартизованным набором атрибутов (например, для действий определены такие атрибуты, как ActivityType с множеством значений , Status , InputSets , LoopType и др.). На основе значений своих атрибутов в соответствии со спецификацией объекты BPMN могут быть преобразованы в конструкции языка BPEL (BPEL4WS версии 1.1). Следует заметить, что не любой бизнес-процесс, описанный в BPMN, возможно конвертировать в код BPEL, однако такое преобразование не всегда требуется — нотация BPMN, благодаря своей наглядности и простоте, хорошо подходит для описания бизнес-процессов с целью анализа деятельности организации, не подразумевающего последующей автоматизации в точном соответствии с построенными моделями.

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

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

На сегодняшний день поддержка нотации BPMN реализована в программных средствах моделирования более чем сорока производителей, среди которых IBM, Sun Microsystems, Proforma, IDS Scheer, Casewise и др.

ПРАКТИЧЕСКИЕ ЗАДАНИЯ

• 1. Смоделируйте процесс «Проведение мероприятия» в нотации BPMN.
• 2. Ответьте на вопросы.

Описание процесса «Проведение мероприятия»

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

Координатор мероприятия рассматривает заявку, сверяясь с календарем заказов компании, и принимает решение по мероприятию:

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

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

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

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

Методические указания

BPMN (Business Process Modeling Notation, нотация и модель бизнес- процессов) — нотация для моделирования бизнес-процессов.

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

• 1. Объекты потока управления (Flow Objects): события, действия и логические операторы.
• 2. Соединяющие объекты (Connecting Objects): поток управления, поток сообщений и ассоциации.
• 3. Роли или зоны ответственности (Swimlanes): пулы и дорожки.
• 4. Артефакты (Artifacts): данные, группы и текстовые аннотации.

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

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

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

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

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

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

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

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

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

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

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

о Циклическое действие (loop activity) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия, о Свернутый подпроцесс (collapsed subprocess) является сложным действием и содержит внутри себя правильную диаграмму бизнес-процессов, о Развернутый подпроцесс (expanded subprocess) также является составным действием, но скрывает детали реализации процесса.

о Ad-hoc-подпроцесс (ad-hoc subprocess) содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

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

Логические операторы (шлюзы) — используются для контроля расхождений и схождений потока операций.

Соединяющие объекты

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

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

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

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

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

Данные — показывают, какие данные необходимы действиям для выполнения и какие данные действия производят

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

Текстовые аннотации — используются для уточнения значения элементов диаграммы и повышения ее информативности

Для выполнения задания используйте следующие элементы нотации:

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

• 4. Диаграммы взаимодействия отражаются в виде .
• а) диаграммы деятельности
• б) кооперативной диаграммы
• в) диаграммы последовательности
• г) диаграммы классов
• 5. На диаграммах взаимодействия стрелки являются .
• а) вариантами использования
• б) сообщениями
• в) классами
• г) условиями
• 6. В UML не существует стереотипа (типа класса) .
• а) сущность
• б) управление
• в) пользовательский интерфейс
• г) состояние
• 7. На диаграмме состояний переход от одного состояния к другому вызывает .
• а) определяющее условие
• б) входное действие
• в) событие
• г) выходное действие
• 8. Для описания потоков событий в вариантах использования используют
• а) диаграмму деятельности
• б) диаграмму состояний
• в) диаграмму кооперации
• г) диаграмму взаимодействия
• 9. Исполняемые компоненты и библиотеки кода иллюстрируются на диаграмме .
• а) размещения
• б) классов в) компонентов
• г) состояний
• 10. В методологии RUP фаза Проектирование не включает в себя:

• а) создание базовой версии модели прецедентов
• б) документирование требований
• в) построение исполняемой архитектуры
• г) более точные оценки сроков и стоимости

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