Соответствие требованиям спецификации

Для обеспечения соответствия Требованиям Моделирования Процессов НЕОБХОДИМА возможность поддержки следующих пакетов BPMN:

• Основные элементы BPMN, включающие элементы пакетов: Инфраструктура (Infrastructure), Фундамент (Foundation), Общий (Common) и Сервис (Service) (см. Главу 8).
• Диаграммы Процессов, в состав которых входят элементы пакетов: Процесс (Process), Действия (Activities), Данные (Data) и Пользовательские действия (Human Interaction) (см. Главу 10).
• Диаграммы Взаимодействий (Collaboration), в состав которых входят Пулы (Pools) и Потоки сообщений (Message Flow) (см. Главу 9).
• Диаграммы Обмена сообщениями (Conversation), в состав которых входят Пулы (Pools), элементы Обмен сообщениями (Conversations) и Соединители элементов Обмен сообщениями (Conversation Links) (см. Главу 9).

Альтернативой полному соответствию Требованиям моделирования Процесса (Process Modeling Conformance) являются три подкласса соответствия:

• Подкласс для Описания (Descriptive)
• Аналитический подкласс (Analytic)
• Подкласс Общего Выполнения (Common Executable)

Подкласс для Описания касается отображаемых элементов и атрибутов, используемых в моделях высокого уровня. Это особенно удобно для аналитиков, привыкших использовать инструменты BPA для составления блок-схем.

Аналитический подкласс содержит все подклассы для описания и в общей сложности половину всех конструкций Класса Соответствия Требованиям Моделирования Процесса (Process Modeling Conformance Class). За основу был взят объединенный опыт использования BPMN, а также анализ ориентированных на пользователя образцов DoDAF (Department of Defense Architecture Framework) и результатов плановой стандартизации данной среды.

Как Подкласс для Описания, так и Аналитический подкласс ориентированы на отображаемые элементы и содержат минимальное количество поддерживающих атрибутов/элементов.

Подкласс Общего Выполнения ориентирован на то, что требуется моделям выполняемых процессов.

Элементы и атрибуты, не относящиеся к вышеописанным подклассам, содержатся в классе Соответствия Требованиям Моделирования Процесса (Process Modeling Conformance сlass)

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

Соответствие Требованиям моделирования Процесса (Process Modeling Conformance) включает элементы, входящие в состав диаграмм Взаимодействия и Процесса, а именно: Задачи всех типов, встроенные Подпроцессы, Действия типа Вызов, Шлюзы всех типов, События всех типов (Стартовые, Промежуточные, Конечные), Дорожки, Участников, Объекты данных (также Входные и Выходные данные), Сообщения, Группы, Текстовые аннотации, Потоки операций (также условные Потоки операций и Потоки операций по умолчанию), Потоки сообщений, Обмен сообщениями (ограниченный до группировки Потоков сообщений, ассоциативных корреляций), Корреляцию, Ассоциацию (также Ассоциацию компенсации). В этот набор также входят маркеры (маркеры Цикла, Многоэкземплярные, Транзакции, Компенсации), используемые для дифферинцировки Задач и встроенных Подпроцессов.

Примечание: Такие элементы моделирования Хореографии, как Задача Хореографии и Подхореография, в этот перечень не входят.

Для того, чтобы инструмент моделирования мог декларировать поддержку подкласса, он ДОЛЖЕН подходить под следующие критерии:

• В нем ДОЛЖНЫ поддерживаться все элементы подкласса.
• В нем ДОЛЖНЫ поддерживаться все перечисленные атрибуты каждого из элементов подкласса.
• В целом, если атрибут не упоминается в подклассе и НЕ является ОБЯЗАТЕЛЬНЫМ для отображения в схеме, то он не входит в данный подкласс. Исключения для этого правила описаны в примечании.

Подкласс соответствия для Описания

Таблица 2.1 содержит информацию о Подклассе соответствия для Описания.

Таблица 2.1 – Элементы и Атрибуты Подкласса Соответствия для Описания

Элемент	Атрибуты
participant (pool)	id, name, processRef
laneSet	id, lane with name, childLaneSet, flowElementRef
sequenceFlow (unconditional)	id, name, sourceRef, targetRef
messageFlow	id, name, sourceRef, targetRef
exclusiveGateway	id, name
parallelGateway	id, name
task (None)	id, name
userTask	id, name
serviceTask	id, name
subProcess (expanded)	id, name, flowElement
subProcess (collapsed)	id, name, flowElement
CallActivity	id, name, calledElement
DataObject	id, name
TextAnnotation	id, text
association/dataAssociationa	id, name, sourceRef, targetRef, associationDirectionb
dataStoreReference	id, name, dataStoreRef
startEvent (None)	id, name
endEvent (None)	id, name
messageStartEvent	id, name, messageEventDefinition
messageEndEvent	id, name, messageEventDefinition
timerStartEvent	id, name, timerEventDefinition
terminateEndEvent	id, name, terminateEventDefinition
documentationc	text
Group	id, categoryRef

1. Ассоциация данных является АБСТРАКТНОЙ, т.е. Ассоциация с Входными и Выходными данными появляется в сериализации XML. У этих типов Ассоциаций есть ОБЯЗАТЕЛЬНЫЕ атрибуты [sourceRef и targetRef], относящиеся к элементам itemAwareElements. Для согласования с метамоделью возникает необходимость в дополнительных элементах: ioSpecification, inputSet, outputSet, Data Input, Data Output. Когда в редакторе BPMN отображается Ассоциация данных, относящаяся к Действию или Событию, должна сформироваться невидимая подконструкция. Другими словами, было бы необходимо изменять метамодель для того, чтобы сделать атрибуты sourceRef и targetRef опциональными или допустить использование ссылки на элемент, не относящийся к itemAwareElements (например, Действие или Событие).
2. Атрибут associationDirection, не указанный для Ассоциации данных.
3. Documentation не отображается. Он является атрибутом практически всех элементов.

Аналитический подкласс соответствия

Аналитический подкласс соответствия включает в себя все элементы Подкласса соответствия для Описания, а также элементы, приведенные в таблице 2.2.

Таблица 2.2 – Элементы и Атрибуты Аналитического Подкласса Соответствия

Элемент	Атрибуты
sequenceFlow (conditional)	id, name, sourceRef, targetRef, conditionExpressiona
sequenceFlow (default)	id, name, sourceRef, targetRef, defaultb
sendTask	id, name
receiveTask	id, name
Looping Activity	standardLoopCharacteristics
MultiInstance Activity	multiInstanceLoopCharacteristics
exclusiveGateway	Add default attribute
inclusiveGateway	id, name, eventGatewayType
eventBasedGateway	id, name, eventGatewayType
Link catch/throw Intermediate Event	Id, name, linkEventDefinition
signalStartEvent	id, name, signalEventDefinition
signalEndEvent	id, name, signalEventDefinition
Catching message Intermediate Event	id, name, messageEventDefinition
Throwing message Intermediate Event	id, name, messageEventDefinition
Boundary message Intermediate Event	id, name, attachedToRef, messageEventDefinition
Non-interrupting Boundary message Intermediate Event	id, name, attachedToRef, cancelActivity=false, messageEventDefinition
Catching timer Intermediate Event	id, name, timerEventDefinition
Boundary timer Intermediate Event	id, name, attachedToRef, timerEventDefinition
Non-interrupting Boundary timer Intermediate Event	id, name, attachedToRef, cancelActivity=false, timerEventDefinition
Boundary error Intermediate Event	id, name, attachedToRef, errorEventDefinition
errorEndEvent	id, name, errorEventDefinition
Non-interrupting Boundary escalation Intermediate Event	id, name, attachedToRef, cancelActivity=false, escalationEventDefinition
Throwing escalation Intermediate Event	id, name, escalationEventDefinition
escalationEndEvent	id, name, escalationEventDefinition
Catching signal Intermediate Event	id, name, signalEventDefinition
Throwing signal Intermediate Event	id, name, signalEventDefinition
Boundary signal Intermediate Event	id, name, attachedToRef, signalEventDefinition
Non-interrupting Boundary signal Intermediate Event	id, name, attachedToRef, cancelActivity=false, signalEventDefinition
conditionalStartEvent	id, name, conditionalEventDefinition
Catching conditional Intermediate Event	id, name, conditionalEventDefinition
Boundary conditional Intermediate Event	id, name, conditionalEventDefinition
Non-interrupting Boundary conditional Intermediate Event	id, name, cancelActivity=false, conditionalEventDefinition
messagec	id, name, add messageRef attribute to messageFlow

1. Значение ConditionExpression, используемого только для Потока операций, исходящего из Шлюза, МОЖЕТ БЫТЬ равно нулю.
2. Атрибут Default является атрибутом sourceRef Шлюза (эксклюзивного или неэксклюзивного).
3. Обратите внимание, что атрибут messageRef, являющийся атрибутом различных Событий типа Сообщение, является опциональным и не входит в данный подкласс.

Подкласс Соответствия Общему выполнению

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

• Языком определения типа данных ДОЛЖЕН БЫТЬ XML Schema.
• Языком определения интерфейсов Web-сервисов ДОЛЖЕН БЫТЬ WSDL.
• Языком доступа к данным ДОЛЖЕН БЫТЬ XPath.

Элементы подкласса соответствия Общему выполнения приведены в таблице 2.3, а сопутствующие классы отображены в таблице 2.4.

Таблица 2.3 – Элементы и Атрибуты Подкласса Соответствия Общему Выполнению

Элемент	Атрибуты
sequenceFlow (unconditional)	id, (name), sourceRefa, targetRefb
sequenceFlow (conditional)	id, name, sourceRef, targetRef, conditionExpressionc
sequenceFlow (default)	id, name, sourceRef, targetRef, defaultd
subProcess (expanded)	id, name, flowElement, loopCharacteristics, boundaryEventRefs
exclusiveGateway	id, name, gatewayDirection (только сходящийся и расходящийся), default
parallelGateway	id, name, gatewayDirection (только сходящийся и расходящийся)
startEvent (None)	id, name
endEvent (None)	id, name
eventBasedGateway	id, name, gatewayDirection, eventGatewayType
userTask	id, name, renderings, implementation, resources, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs
sig serviceTask	id, name, implementation, operationRef, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs
callActivity	id, name, calledElement, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs
dataObject	id, name, isCollection, itemSubjectRef
textAnnotation	id, text
dataAssociation	id, name, sourceRef, targetRef, assignment
messageStartEvent	id, name, messageEventDefinition (either ref or contained), dataOutput, dataOutputAssociations
messageEndEvent	id, name, messageEventDefinition, (либо ссылка, либо наличие), dataInput, dataInputAssociations
terminateEndEvent	(Триггер завершения в комбинации с одним из конечных событий)
Catching message Intermediate Event	id, name, messageEventDefinition (либо ссылка, либо наличие), dataOutput, dataOutputAssociations
Throwing message Intermediate Event	id, name, messageEventDefinition (либо ссылка, либо наличие), dataInput, dataInputAssociations
Catching timer Intermediate Event	id, name, timerEventDefinition (наличие)
dary error Intermediate Event	id, name, attachedToRef, errorEventDefinition, (ссылка или наличие), dataOutput, dataOutputAssociations

1. Множественные исходящие соединения допускаются только для Шлюзов, в которых маршруты сходятся.
2. Множественные исходящие соединения допускаются только для Шлюзов, в которых маршруты расходятся.
3. Значение ConditionExpression, используемого только в направленных от Шлюзов Потоках операций, МОЖЕТ БЫТЬ равно нулю.
4. Атрибут Default является атрибутом sourceRef Шлюза (эксклюзивного или неэксклюзивного).

Таблица 2.4 – Сопутствующие Классы Подкласса Соответствия Общему Выполнению

Элемент	Атрибуты
StandardLoopCharacteristics	id, loopCondition
MultiInstanceLoopCharacteristics	id, isSequential, loopDataInput, inputDataItem
Rendering
Resource	id, name
ResourceRole	id, resourceRef, resourceAssignmentExpression
InputOutputSpecification	id, dataInputs, dataOutputs
DataInput	id, name, isCollection, itemSubjectRef
DataOutput	id, name, isCollection, itemSubjectRef
ItemDefinition	id, structure or importa
Operation	id, name, inMessageRef, outMessageRef, errorRefs
Message	id, name, structureRef
Error	id, structureRef
Assignment	id, from, tob
MessageEventDefinition	id, messageRef, operationRef
TerminateEventDefinition	id
TimerEventDefinition	id, timeDate

1. Структуру ДОЛЖЕН определять составной тип XSD (XSD Complex Type).
2. Структуру ДОЛЖЕН определять составной тип XSD (XSD Complex Type).

Ключевым элементом BPMN является выбор форм и иконок, соответствующих описанным в данной спецификации элементам. Намерением разработчиков спецификации явилось создание стандартного визуального языка, легко распознаваемого и понятного всем разработчикам моделей процессов. Создание и отображение Диаграмм Процессов BPMN подразумевает ОБЯЗАТЕЛЬНОЕ использование графических элементов, форм и маркеров, описанных в данном документе.

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

При моделировании диаграммы BPMN допускаются следующие расширения:

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

Создание и отображение диаграмм BPMN ДОЛЖНО БЫТЬ осуществлено в соответствии с техническими требованиям и ограничениям, при этом следует обращать внимание на соединения и другие взаимодействия между графическими элементами на схеме. Там, где разрешенные или требуемые соединения являются условными и основываются на атрибутах соответствующего элемента, ДОЛЖНО БЫТЬ гарантировано сообщение между соединениями и значениями этих атрибутов.

Примечание: В целом, к таким соединениям и взаимоотношениям применяется особая семантическая интерпретация, которая определяет взаимоотношения между понятиями процесса, представленными графическими элементами. Условные взаимоотношения основываются на атрибутах, которые представляют собой различные типы поведения. Именно поэтому соответствие структуры гарантирует корректную интерпретацию диаграммы как спецификации процесса. На протяжении всего документа в различных параграфах описываются конструктивные характеристики. В тексте они отображаются при помощи маркера абзаца , например: ЗАДАЧА МОЖЕТ являться целью Потока операций и иметь множество входящих Потоков операций. Входящий Поток операций МОЖЕТ поступать по альтернативному и/или параллельному маршрутам.

В данной спецификации приводится несколько понятий семантики, используемых для определения Процесса; при этом они ассоциируются с графическими элементами, маркерами и соединениями. Поскольку при применении диаграмма BPMN интерпретируется как семантическая спецификация данного Процесса, такая интерпретация ДОЛЖНА должна согласовываться с описанной в данном документе семантической интерпретацией. Другими словами, подгонка под требования соответствия моделированию Процесса BPMN (BPMNProcessModelingConformance) означает следование семантикам, окружающим элементы диаграммы и описанным в Главе 10.

Примечание: Моделирование в согласии с требованиями соответствия моделированию Процесса BPMN (BPMNProcessModelingConformance) не подразумевает поддержку исполнительной семантики BPMN, описанной в Главе 13.

Данная спецификация выделяет несколько атрибутов и свойств семантических элементов, представленных посредством графических элементов, маркеров и соединений. Некоторые из них используются лишь для наглядности и обозначены соответствующим образом, другие являются обязательными для отображения. Некоторые атрибуты являются обязательными, однако, могут отображаться по желанию или не отображаются вообще, а некоторые атрибуты являются опциональными. Для адекватного использования каждого обязательного атрибута или свойства ДОЛЖЕН БЫТЬ определен механизм, с помощью которого можно отображать значения атрибутов или свойств. Такой механизм ДОЛЖЕН позволять пользователям создавать или просматривать эти значения для каждого элемента BPMN, имеющего атрибут или свойство. Если способ отображения конкретного атрибута или свойства является ОБЯЗАТЕЛЬНЫМ, ДОЛЖНО использоваться только такое отображение. Если способ отображения конкретного атрибута или свойства является опциональным, то при моделировании МОЖЕТ БЫТЬ использован как графический, так и другой способ отображения. Если атрибут или свойство отображается графически, то ДОЛЖНЫ БЫТЬ определны требования для этого. Если же атрибуту или свойству не соответствует никакое графическое представление, то при моделировании МОЖЕТ БЫТЬ использован как графический, так и другой способ отображения. Если используется какое-либо графическое представление, оно НЕ ДОЛЖНО противоречить установленному графическому представлению какого-либо другого элемента BPMN.

Для адекватного моделирования НЕ ТРЕБУЕТСЯ поддержки элементов или атрибутов, которые в данном документе определены как ненормативные (non-normative) и информативные (informative). Для любой характеристики, подходящей под определение «опциональной», в документе указано:

• То, каким образом такая характеристика отображается на диаграмме.
• Отображается ли характеристика вообще.
• Поддерживается ли данная характеристика.

Для адекватного моделирования сопровождение любых характеристик, поддержка которых опциональна, НЕ является ОБЯЗАТЕЛЬНОЙ. Если при моделировании осуществляется поддержка опциональной характеристики, такая поддержка ДОЛЖНА соответствовать указанным в документе требованиям. Для соответствия требованиям ДОЛЖНЫ поддерживаться любые опциональные характеристики, для которых опциональность заключается в том, как они ДОЛЖНЫ отображаться и ДОЛЖНЫ ли они отображаться вообще.

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

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

Примечание: Инструмент моделирования, желающий соответствовать Требованиям Исполнения BPMN (BPMN Execution Conformance), не обязан поддерживать и уметь интерпретировать модели Хореографии или соответствовать Требованиям Моделирования Процесса (Process Modeling Conformance). Точнее, инструмент моделирования не обязан поддерживать графический синтаксис или семантику, описанные в данном документе. В нем МОГУТ быть использованы различные графические элементы, формы и маркеры, а не только те, что указаны в данной спецификации.

Инструмент моделирования, желающий соответствовать требованиям исполнения BPMN (BPMNExecutionConformance), ДОЛЖЕН поддерживать импорт диаграмм Процессов BPMN, включая Взаимодействие (см. таблицу 10.1).

При моделировании, удовлетворяющем требованиям соответствия Хореографии (ChoreographyConformance), ДОЛЖНЫ поддерживаться следующие пакеты BPMN:

• Основные элементы BPMN, включая те, что указаны в Инфраструктуре (Infrastructure), Фундаменте (Foundation), Общем (Common) и Сервисе (Service) (см. Главу 8).
• Диаграммы Хореографии, содержащие элементы Хореографии, и пакеты Хореографии (см. Главу 11).
• Диаграммы Взаимодействия, содержащие Пулы и Потоки сообщений (см. Главу 9).

Список элементов, удовлетворяющих Требованиям Соответствия Хореографии (ChoreographyConformance), включает Сообщения, Задачу Хореографии, Глобальную Задачу Хореографии, Подхореографию (скрытую и развернутую), некоторые типы Стартовых событий (например, Неопределеный, Таймер, Условие, Сигнал и Множественный), некоторые типы Промежуточных событий (например, Неопределеный, присоединенное к границе Действия Сообщение, Условие, Сигнал, Множественный, Связь и т.д.) и некоторые типы Конечных событий (Неопределенный и Завершение), а также Шлюзы. Также, для включения Хореографии в состав Взаимодействия первая должна поддерживать использование Пулов и Потоков сообщений.

При создании и отображении диаграмм Хореографий BPMN ДОЛЖНЫ использоваться графические элементы, формы и маркеры, указанные в спецификации BPMN. Для ознакомления с правилами использования текста, цвета и линий в моделировании диаграмм Хореографий см. раздел 7.4.

Инструмент моделирования, желающий удовлетворять Требованиям Соответствия Хореографии (ChoreographyConformance), должен полностью поддерживать и уметь интерпретировать графическую и исполнительную семантику элементов диаграммы Хореографии, а также типы диаграмм Хореографии.

При моделировании Хореографии должен поддерживаться импорт/экспорт типов диаграмм Хореографии и Взаимодействия, благодаря чему Хореография отображается в рамках Взаимодействия (см. описание в разделе 9.4). Это позволяет сделать диаграммы Хореографий переносимыми, благодаря чему пользователи могут переносить понятия, используемые в среде одного производителя, в среду другого производителя.