On the BPMN & XPDL Industry Day of the WfMC Thought Leadership Summit one topic of discussion was the current status of BPMN Diagram Exchange.
In the BPMN 2.0 Spec there is a proposal, that builds on a generic OMG proposal, which is not finalized and which will be standardized independent of the BPMN 2.0 standardization.
In this proposal the idea is to have a Diagram Interchange Model independent from the Domain Model, which is in my opinion, a good idea. It is generic, so that other diagram types could be modeled. The diagram validation is done agains a so called Diagram Definition Model, which is also new. The Diagram Definition Model defines, which Attributes a Diagram Interchange node or connector can have, the allowed references and additional (OCL) constraints. Furthermore each Diagram Interchange node or connector is refers to a Domain Model class – in this case a BPMN Task or Gateway or Sequence Flow for example.
Advantages I see:
- Seperation of Model and View – Model maintenance
- Multiple Diagrams for the same underlying BPMN model are possible
- Generic format for different diagram types – tools can use synergies
Disadvantages I see:
- Tools vendors can not use XSD validation. They have to implement the validation against the Diagram Definition.
- The constraints of the Domain model (e.g. Sequence Flows can only be connected to …) must be repeated in the Diagram Definition Model.
- Grafical Attributes (e.g. line thickness) must be repeated as per modeling element.
- Attribute Format (name / value) too generic in my view.
The XPDL Format used to include the Graphics Info into the Elements of the Domain model.
This is simple and straight, and current tools support it, but has the disadvantage, that it is not possible to have one modeling element (e.g. one process) appear in different diagrams. Instead, the modeling elements must be repeated as per diagram, which has many disadvantages in model execution, analysis and model driven development. The Signavio modeler, which was discussed at the meeting, follows the same approach. However it is good as long as only diagrams are drawn for visualization purposes.
Because the BPMN Digram Exchange Proposal was too generic for some, Bruce Silver proposed an BpmnDI.XSD for a concrete XSD validation.
This approach repeats basically all or many BPMN domain modeling elements. This of course is the disadvantage, because it is but a redundant repetition of the already defined domain model. However it is no complete repetition, because the gateway type for example is not included. So a tool must look into the domain model anyway to render the gateway.
Within this discussion it came to my mind, how the GMF (Graphical Modeling Framework) solves this question. I think it is well worth to have a look at this approach, because I think it may be a good compromise.
The GMF defines a Grafical Definition Model, which only defines Shapes. This is simple to understand and straight. Then it defines a Mapping Model. Within the mapping models, nodes and connections are grouped as needed. For example it defines, that there is a node lane which can contain node Activity and Sequence Flow. As a followon the Acitivty node is connected to the Activity domain class and the Shape, that descibes how an activity should look like. The shape can be re-used, which is an advantage of the BPMN Diagram Exchange Approach. The Structures of the Diagram is already contained in the Mapping Model, so it can be serialized to XMI and XSD, which is also an advantage. However still the diagram logic is separated from the Domain Model, which is an advantage over XPDL. And it is a very generic model, which is an advantage over a mere BpmnDI.xsd.
I personally worked with the GMF, and found it quite practical. I am not proposing to use GMF per se, but maybe the approach should be further considered.