Система управления бизнес-процессами

<<предыдущая                                        содержание                                     следующая>>


2.1. Соответствие Требованиям Моделирования Процесса (Process Modeling Conformance)
     2.1.1 Типы Процессов BPMN
     2.1.2. Элементы Процесса BPMN
     2.1.3. Внешний вид
     2.1.4. Соответствие структуры
     2.1.5. Семантика Процесса
     2.1.6. Атрибуты и асоциации
     2.1.7. Расширенные и опциональные элементы
     2.1.8. Перенос визуальной модели
2.2. Соответствие исполнению Процесса
     2.2.1. Семантика исполнения
     2.2.2. Импорт диаграмм Процессов
2.3. Соответствие Требованиям Исполнения Процессов BPEL
2.4 Соответствие Требованиям Моделирования Хореографии
     2.4.1 Типы Хореографий BPMN
     2.4.2 Элементы Хореографии BPMN
     2.4.3 Обший вид
     2.4.4 Семантика Хореографии
     2.4.5 Перенос визуальной модели
2.5 Обзор типов соответствий BPMN

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

Для удовлетворения Требованиям Моделирования Процесса (Process Modeling Conformance) НЕ ОБЯЗАТЕЛЬНО учитывать правила соответствия Требованиям Моделирования Хореографии (Choreography Modeling Conformance), и наоборот. Аналогично, соблюдение правил соответствия Требованиям Исполнения Процесса НЕ является ОБЯЗАТЕЛЬНЫМ условием для соответствия Требованиям Моделирования Процесса или Требованиям Моделирования Хореографии.

Для соответствия Требованиям Моделирования Процесса (Process Modeling Conformance) ДОЛЖНЫ БЫТЬ выполнены все требования, описанные в подразделе 2.1 данного документа. Для Соответствия Требованиям Исполнения Процесса (Process Execution Conformance) ДОЛЖНЫ БЫТЬ удовлетворены все требования, описанные в подразделе 2.2. Для соответствия Требованиям Применения Исполнительной Семантики Процесса BPEL (BPEL Process Execution Semantics Conformance type) ДОЛЖНЫ БЫТЬ удовлетворены все требования, описанные в подразделе 2.3. Для соответствия Требованиям Моделирования Хореографии (Choreography Conformance) ДОЛЖНЫ БЫТЬ удовлетворены все требования, описанные в подразделе 2.4. Таким образом, реализация может считаться выполненной в соответствии со всеми предъявляемыми требованиями в том случае, если она произведена с учетом требований, описанных в подразделах 2.1, 2.2, 2.3, и 2.4 данного документа.

2.1. Соответствие Требованиям Моделирования Процесса (Process Modeling Conformance)

В следующих восьми подразделах описываются правила соответствия Требованиям Моделирования Процесса (Process Modeling Conformance).

2.1.1 Типы Процессов BPMN

Для обеспечения соответствия Требованиям Моделирования Процессов НЕОБХОДИМА возможность поддержки следующих пакетов 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)

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

2.1.2. Элементы Процесса BPMN

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

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

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

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

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

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

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

ЭлементАтрибуты
participant (pool)id, name, processRef
laneSetid, lane with name, childLaneSet, flowElementRef
sequenceFlow (unconditional)id, name, sourceRef, targetRef
messageFlowid, name, sourceRef, targetRef
exclusiveGatewayid, name
parallelGatewayid, name
task (None)id, name
userTaskid, name
serviceTaskid, name
subProcess (expanded)id, name, flowElement
subProcess (collapsed)id, name, flowElement
CallActivityid, name, calledElement
DataObjectid, name
TextAnnotationid, text
association/dataAssociationaid, name, sourceRef, targetRef, associationDirectionb
dataStoreReferenceid, name, dataStoreRef
startEvent (None)id, name
endEvent (None)id, name
messageStartEventid, name, messageEventDefinition
messageEndEventid, name, messageEventDefinition
timerStartEventid, name, timerEventDefinition
terminateEndEventid, name, terminateEventDefinition
documentationctext
Groupid, categoryRef

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

b) Атрибут associationDirection, не указанный для Ассоциации данных.

c) 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

a) Значение ConditionExpression, используемого только для Потока операций, исходящего из Шлюза, МОЖЕТ БЫТЬ равно нулю.

b) Атрибут Default является атрибутом sourceRef Шлюза (эксклюзивного или неэксклюзивного).

c) Обратите внимание, что атрибут 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

a) Множественные исходящие соединения допускаются только для Шлюзов, в которых маршруты сходятся.

b) Множественные исходящие соединения допускаются только для Шлюзов, в которых маршруты расходятся.

c) Значение ConditionExpression, используемого только в направленных от Шлюзов Потоках операций, МОЖЕТ БЫТЬ равно нулю.

d) Атрибут 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

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

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

2.1.3. Внешний вид

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

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

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

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

2.1.4. Соответствие структуры

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

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

2.1.5. Семантика Процесса

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

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

2.1.6. Атрибуты и асоциации

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

2.1.7. Расширенные и опциональные элементы

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

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

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

2.1.8. Перенос визуальной модели

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

2.2. Соответствие исполнению Процесса

В следующих двух подразделах описаны правила Соответствия Требованиям Исполнения Процесса (ProcessExecutionConformance).

2.2.1. Семантика исполнения

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

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

2.2.2. Импорт диаграмм Процессов

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

2.3 Соответствие Требованиям Исполнения Процессов BPEL

Для удовлетворения Требованиям Исполнения Процессов (Process Execution Conformance), определяющим соответствие BPMN языку WS-BPEL (см. подраздел 15.1), может быть необходимо соответствие Требованиям Исполнения Процессов BPEL.

Примечание: Инструмент моделирования, желающий соответствовать Требованиям Исполнения Процессов BPEL (BPELProcessExecutionConformance), ДОЛЖЕН полностью соответствовать Требованиям Исполнения Процессов BPMN (ProcessExecutionConformance). Инструмент моделирования, желающий соответствовать Требованиям Исполнения Процессов BPEL (BPELProcessExecutionConformance), не обязательно должен поддерживать и уметь интепретировать модели Хореографии. Также инструмент моделирования, желающий соответствовать Требованиям Исполнения Процессов BPEL (BPELProcessExecutionConformance), не обязательно должен соответствовать Требованиями Моделирования Процессов (ProcessModelingConformance).

2.4 Соответствие Требованиям Моделирования Хореографии

В следующих пяти подразделах описаны Требования Соответствия Хореографии (Choreography Conformance).

2.4.1 Типы Хореографий BPMN

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

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

2.4.2. Элементы Хореографии BPMN

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

2.4.3. Обший вид

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

2.4.4. Семантика Хореографии

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

2.4.5. Перенос визуальной модели

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

2.5. Обзор типов соответствий BPMN

Таблица 2.5 содержит общую информацию о требованиях соответствия BPMN (BPMN Conformance).

Таблица 2.5 – Типы соответствия BPMN

Соответствие Исполнению Процессов (Process Execution Conformance)

Исполнительная семантика Хореографии.

Категория

Соответствие Моделированию Процессов (Process Modeling Conformance)

Соответствие Исполнению Процессов BPEL (BPEL Process Execution Conformance)

Соответствие Исполнению Процессов BPEL (BPEL Process Execution Conformance)

Соответствие Хореографии (Choreography Conformance)

Визуальное представление типов Диаграмм BPMN

Типы диаграмм Процессов и Хореографий, в которых отображается взаимодействие между типами диаграмм Процессов.

Нет данных

Нет данных

Типы диаграмм Хореографий и Взаимодействия, в которых отображается взаимодействие между типами диаграмм Хореографий.

Элементы Диаграммы BPMN, поддержка которых необходима

Все типы Задач, встроенные Подпроцессы, Действия типа Вызов, все типы Событий, все типы Шлюзов, Пулы, Дорожки, Объекты данных (включая Входные и Выходные данные), Сообщения, Группы, Артефакты, маркеры Задач и Подпроцессов, Потоки операций, Ассоциации, Потоки сообщений.

Нет данных

Нет данных

Сообщения, Задачи Хореографии, Глобальные Задачи Хореографии, Подхореографии (скрытые и развернутые), некоторые типы Стартовых, Промежуточных и Конечных событий, Шлюзы, Пулы,

Message Flow.

Импорт/Экспорт типов диаграмм

Да, для диаграмм Процессов и Взаимодействия, в которых Процесс отображается в рамках Взаимодействия.

Да, для диаграмм Процессов

Да, для диаграмм Процессов

Да, для диаграмм Хореографии и Взаимодействия, в которых Хореография отображается в рамках Взаимодействия.

Поддержка Графического синтаксиса и семантики

Диаграммы Процессов и Взаимодействия, в которых Процесс отображается в рамках Взаимодействия.

Нет данных

Нет данных

Диаграммы Хореографии и Взаимодействия, в которых Хореография отображается в рамках Взаимодействия.

Поддержка Исполнительной Семантики

Нет данных

Да, для диаграмм Процессов

Да, для диаграмм Процессов

Исполнительная семантика Хореографии.

<<предыдущая                                        содержание                                     следующая>>


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