1 / 38

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

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

genevieve-harris
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BPMN Diagram Interchange BPMN DI Schema and Meta-model Baseline Proposal Subgroup Chair: Robert Shapiro (Global360) Baseline Proposal: Denis Gagné (Trisotech) Maged Elaasar (IBM)

  2. Goal & Requirements Requirements • 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

  3. Background

  4. 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.

  5. DI

  6. DI

  7. DI

  8. BPMN DI Meta-Model & Schema

  9. The BPMN DI Meta-model

  10. BPMNDiagram DI BPMN DI

  11. BPMNPlane DI BPMN DI

  12. BPMNShape DI BPMN DI

  13. BPMNEdge DI BPMN DI

  14. BPMN DI Concepts A BPMNDiagram has a BPMNPlane as root A BPMNShapethat is referring a semantic element A BPMNEdge referring a semantic element ABPMNShapethat is a BPMNPlane A BPMNPlane contains BPMNShapes and BPMNEdges

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

  16. Examples Showcase Example (from Maged)

  17. Process Diagram from Maged

  18. Progress Diagram from Maged BPMNShapebounded containing a BPMNPlane BPMNDiagram With a BPMNPlane as root BPMNShapebounded containing a BPMNPlane that contains 4 BPMNShapes one of which is a BPMNPlane

  19. Progress Diagram from Maged BPMNShape bounded containing a BPMNPlane that contains 3 BPMNShapesand 1 BPMNEdge

  20. Examples Pools vs Lanesets

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

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

  23. Figure 7-6 Collaboration with Black Box Pools

  24. Examples Sub Processes and Call Activity

  25. Sub Process Expanded One Process with one Diagram

  26. Sub Process Collapsed One Process with two Diagrams Details of Embedded Sub Process on a separate Diagram

  27. Call Activity (Re-Use Sub Process) Two Processes with two Diagrams Details of Called Process on a separate Diagram

  28. 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

  29. 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

  30. Confirming/Infirming Choices

  31. Confirming/Infirming Choices • Duplication of Source and Target information from the BPMN Semantics to the BPMN DI

  32. 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

  33. Confirming/Infirming Choices • Sub typing BPMN DI elements vs grab bag attributes

  34. 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

  35. Confirming/Infirming Choices • Containment Structure x +

  36. 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

  37. 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

More Related