BPMN Diagram Interchange BPMN DI Schema and Meta-model Baseline Proposal

Subgroup Chair:

Robert Shapiro (Global360)

Baseline Proposal:

Denis Gagné (Trisotech)

Maged Elaasar (IBM)

Goal & Requirements

RequirementsThe BPMN DI subgroup was mandated by the general FTF to create a BPMN DI schema that will only contain information that is neither present nor derivable from the semantic model

GoalCreate a simple BPMN Diagram Interchange (DI) Schema

Align BPMN DI schema with the DI MetamodelExplore possible auto-generation of the schema from the MM

Background

OMG Diagram Definition Specification

Seperate OMG Diagram Definition specification effort ongoing

Diagram Definition specification to provide methods to formally define the graphical notation (diagrams) of MOF-based graphical languages, including but not limited to UML, SysML and BPMN.

DI

DI

DI

BPMN DI Meta-Model & Schema

The BPMN DI Meta-model

BPMNDiagram

DI

BPMN DI

BPMNPlane

DI

BPMN DI

BPMNShape

DI

BPMN DI

BPMNEdge

DI

BPMN DI

BPMN DI Concepts

A BPMNDiagramhas a BPMNPlane as root

A BPMNPlane contains BPMNShapes and BPMNEdges

A BPMNEdge referring a semantic element

A BPMNShape that is a BPMNPlane

A BPMNShape that is referring a semantic element

Schema Baseline

One page long XSLT friendly

The Schema Baseline was posted as a proposal to

http://www.osoa.org/jira/browse/BPMNFTF-280

Examples

Showcase Example (from Maged)

Process Diagram from Maged

Progress Diagram from Maged

BPMNDiagramWith a BPMNPlane as root

BPMNShape bounded containing a BPMNPlane

BPMNShape bounded containing a BPMNPlane that contains 4 BPMNShapes one of which is a BPMNPlane

Progress Diagram from Maged

BPMNShape bounded containing a BPMNPlane that contains 3 BPMNShapes and 1 BPMNEdge

Examples

Pools vs Lanesets

Page 182 Example with PoolUsing a Pool creates an incomplete Collaboration of one Participant depicted in one diagram

Page 182 Example with LanesUsing a Lane creates a Process depicted in one diagram

Figure 7-6 Collaboration with Black Box Pools

Customer

Manufacturer

Supplier Bidder

Order Confirmation Shipment Rejection

PartsProvisioning

OpenAuction

Examples

Sub Processes and Call Activity

Sub Process Expanded

One Process with one Diagram

Sub Process Collapsed

One Process with two Diagrams

Details of Embedded Sub Process on a separate Diagram

Call Activity (Re-Use Sub Process)

Two Processes with two Diagrams

Details of Called Process on a separate Diagram

Conclusions

Choices made between orthogonal options will have to be confirmed/infirmed Issues were raised in Jira against the Baseline for that purpose

Comments and Feedback are welcomed

Conclusions

The BPMN DI Baseline Proposal Schema is a simple and easy to read schema One page long XSLT friendly

The BPMN DI Baseline Proposal Schema is completely aligned with OMG’s DI Meta-model We even hope to potentially have the schema auto-generated from the

Meta-model

The BPMN DI Baseline Proposal Schema only contains information that is neither present nor derivable from the semantic model Except for Target and Source as per Issue A

Confirming/Infirming Choices

Confirming/Infirming Choices

Duplication of Source and Target information from the BPMN Semantics to the BPMN DI

Duplication of Source and Target information from the BPMN Semantics to the BPMN DI

The BPMN DI subgroup was mandated by the general FTF to create a BPMN DI schema that will only contain information that is neither present nor derivable from the semantic model.  In preparing the BPMN DI baseline proposal duplication of Source and Target were introduced in the BPMNEdge element to address the following cases:

Visual element without a semantical element to reference (e.g. conversation link).  Given that no semantical element can be referenced the target and source are required as these only exist in the BPMN DI.

This would also apply to visual extensions that are associated to element of the process diagrams but are not in the semantic (e.g. yellow sticky notes)

A semantical element that can be depicted many times (e.g. DataObject). It is possible to depict the same semantical DataObject many time on a diagram. We thus need target and source in DI to link the correct visual instance as they all depict the same semantical element.

 

Possible Remedy: In order to remove this duplication, a semantic element should exist for every depictable element.

 

Option If Source and Target duplication is maintained then maybe they should be made optional and only used in the above particular cases. The fact is that currently the BPMNEdge is of type DI:LabeledEdge, to have the Source and Target as optional would imply making them optional in the generic DI (Non BPMN Domain Specific) and that may not be desirable to the community of other domains.

This choice was reported as an issue for discussion purposes

http://www.osoa.org/jira/browse/BPMNFTF-536

Confirming/Infirming Choices

Sub typing BPMN DI elements vs grab bag attributes

Sub typing BPMN DI elements vs grab bag attributes

In an effort to not duplicate any information that is neither present nor derivable from the semantic model a grab bag approach was taken in the BPMNShape element for 4 visual attributes rather than duplicating the element type information contained in the semantic.

isHorizontal : Applies only to semantic context of type Laneset and Participant

isWhiteBox: Applies only to semantic context of type Participant

isExpended: Applies only to semantic context of type SubProcess and AdhocSubProcess,….

isMarkerVisible: Applies only to semantic context of type Exclusive Gateway

This choice was reported as an issue for discussion purposes

http://www.osoa.org/jira/browse/BPMNFTF-537

Confirming/Infirming ChoicesContainment Structure

+x

Containment structure

The BPMN DI baseline proposal does not capture element specific containment structure.  The BPMN DI has the notions that a BPMNShape can be an “atomic visual shape” or can be a BPMNPlane providing the layout of the “content” (e.g. Pool, Lane, Sub process, etc).  This has the effect that the actual containment relationship is only maintained in the semantic and is not duplicated and thus directly accessible only from the DI.  (For example in the case of matrix layout of lanes an element belonging to both and horizontal lane and a vertical lane in the semantic, the element could find itself at the root plane, the vertical lane plane or the horizontal lane plane.  A best practice of having elements at the root plane could be advised in such case).

An alternative approach could be to have notions of element specific containers such as laneplanes, subprocesplanes, etc.

This would make navigation and awareness of the containment structure possible from only the DI.

This choice was reported as an issue for discussion purposes

http://www.osoa.org/jira/browse/BPMNFTF-538

Stylesheet

The DI and more particularly the BPMN DI introduces the notion of “cascading style sheets”. 

The following precedence rule was favored in BPMN DI: Element, Local or current  Style, Master Style, Default.  The style at the element level on an attribute by attribute base overrides the styles inherited from above.  This means that if a Master Style specifies that all shapes should be blue with a texture gradient, one can only specify the color red for a specific shape at shape level and this particular shape will be red and will inherit the texture gradient from the master style while all other shapes will be blue with the texture gradient.

This choice was reported as an issue for discussion purposes

http://www.osoa.org/jira/browse/BPMNFTF-539