Upload
genevieve-harris
View
39
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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