-
Notifications
You must be signed in to change notification settings - Fork 123
Modeler_audit_rules_R3120
The BPMN Link events help simplifying the BPMN diagramming task by allowing to replace a “hard to route through the diagram” sequence flow by a “goto-like” construction.
In such a construction, the LinkThrowEvent is similar to the “goto” call and the matching LinkCatchEvent is the “label” where the flow is transferred to.
Obviously, a LinkThrowEvent must be paired with a matching LinkCatchEvent for the construction to be valid and make some sense. This is what the R3120 rule verifies, reporting defects where link throw and link catch events are not paired.
Note that, symmetrically, the rule also reports LinkCatchEvent events which are not paired to any LinkThrowEvent.
The fix is quite obvious:
-
either pair the unlinked throw/catch event with a throw/catch event, optionally creating it
-
delete the unlinked throw/catch event that triggers the rule report if this event is no longer useful.
About link events:
Link events are helpful when:
-
a process is laid out on several ‘pages’ of a diagram (process not wholly visible on the screen). In this case, using link events construction can help indicating to the user where to go next.
-
a sequence flow is difficult to route from its source to its target without cluttering the diagram with a long and tortuous path. In such situations a throw/catch pair is usually worth being considered.
The BPMN designer should however keep in mind that, although useful and sometimes unavoidable, the link throw/catch events construction introduces a kind of break in the process flow. So the use of this construction must be limited to cases where it is really justified.
Goodies:
-
link events have a name in Modelio. This name can be displayed in the diagram, greatly helping the identification of the link throw and catch pair as soon as the same name is used for both the throw and the catch event nodes. This is the recommended practice.
-
the rule R3200 reinforces the above recommended best practice by monitoring the names in link throw/ link catch pairs.
-
selecting a link throw (or a link catch) in a diagram will point its corresponding link catch (or link throw) nodes.
About the rule:
-
our recommendation is to keep this rule enabled and to not disable it. The reason is that a non-paired link throw or catch event simply breaks the flow of the process which is unlikely a desired situation.
-
the rule severity may be lowered to ‘warning’ or ‘Tip’ during initial design phases, when the process definition being intensively worked on is highly instable. In such design phases, errors are not always relevant. However, in maintenance phases, our recommendation is to raise the rule severity to ‘Error’ as any break in the sequence flow due to unpaired throw catch events must really be immediately detected and reported as an error that requires fixing.