Pattern 6 (Explicit Representation)
FLASH animation of Explicit Representation pattern
Description
This pattern denotes the ability to capture process modeling concepts via a dedicated graphical notation. Purpose To visualize and distinguish the various ingredients of a process model.
Purpose
To visualize and distinguish the various ingredients of a process model.
Rationale
Explicit representation can reduce the cognitive overhead of associating syntactic elements to their seman- tics [34].
Realization
The majority of process modeling languages provide graphical notations for a subset of their concepts only. In UML ADs, AddStructuralFeatureValueAction and Apply- FunctionAction are two examples of concepts that are only represented textually. Similarly, in BPMN 1.2 the various task types (e.g. Receive, Service, Manual), and the difference between Embedded and Reusable sub-process, are two examples of concepts that can only be distinguished via a task’s textual attribute. Although these concepts have now been given a graphical notation in BPMN 2.0, still there are numerous element attributes that do not have one. In YAWL [23] none of the concepts related to data and resourcing aspects are visually represented. In Protos joins and splits are always subsumed by an activity’s multiple incoming, respectively, outgoing edges. This is the same in Petri Nets for AND joins and splits. Only a few languages such as eEPCs and Workflow Nets [3], have a graphical notation covering all modeling concepts (i.e., all notions supported are visualized). However, these two languages provide only few concepts. A third class of languages including BPEL, XPDL and languages from the past such as BPML and XLANG, does not have a graphical notation. In the case of BPEL, the majority of BPEL editors provide a proprietary graphical notation (see e.g. JDeveloper or the Eclipse BPEL Editor), while others provide a BPMN skin to a BPEL model (e.g. Intalio|Designer). Such a skin however often imposes restrictions based on the underlying model, e.g., the BPMN models need to be block-structured such that each split has a corresponding join of the same type.
Example
The models in figures 3-6 are all examples of pro- cess models whose modeling concepts (task, gateway, events, sequence flow) are explicitly represented via a dedicated graphical notation.