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 Requirements Goal 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 Goal Create a simple BPMN Diagram Interchange (DI) Schema Align BPMN DI schema with the DI Metamodel Explore 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 BPMNDiagram has a BPMNPlane as root A BPMNShape that is referring a semantic element A BPMNEdge referring a semantic element A BPMNShape that is a BPMNPlane A BPMNPlane contains BPMNShapes and BPMNEdges

Schema Baseline One page long XSLT friendly The Schema Baseline was posted as a proposal to http://www.osoa.org/jira/browse/BPMNFTF-280

Showcase Example (from Maged) Examples Showcase Example (from Maged)

Process Diagram from Maged

Progress Diagram from Maged BPMNShape bounded containing a BPMNPlane BPMNDiagram With a BPMNPlane as root 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 Pool Using a Pool creates an incomplete Collaboration of one Participant depicted in one diagram

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

Figure 7-6 Collaboration with Black Box Pools

Sub Processes and Call Activity 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 Choices Containment 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