CMMN Method and Style – Part 2

Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard.

As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as “style rules” that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler.  As described in that post, CMMN’s event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine.  The problem for most modelers is that the detailed logic depends on case variables and conditional expressions that are typically delegated to programmers and in any case do not appear in the case diagram.  Method and Style conventions make them visible.

In CMMN’s ECA style, the triggering event is a lifecycle state transition of a task or stage (e.g., start, complete, exit), milestone (e.g., occur), or file item (e.g., create, update).  The condition is a Boolean expression of case variables (file items).  The action is enablement or termination of a plan item.  In the diagram, enablement is signified by a white diamond shape, called a sentry, on the boundary of the triggered plan item.  The sentry is connected to the triggering item by a dash-dot connector called an ON-part link, labeled with the triggering event, such as complete.  In similar manner, termination is signified by a black sentry.  The condition is called the sentry’s IF-part, an expression of case variables (file items).  The rules of the spec do not describe how the condition – if there is one – is made visible in the diagram, but Method and Style provides a way.  The ON-part determines when the action occurs; the IF-part determines whether it occurs.

For example, in the diagram below, task b is enabled when task a is complete.  Here there is no IF-part, i.e., the condition is true by default.

BPMN Method and Style has the concept of an activity end state, meaning how did the activity end, successfully or in some exception state?  The end state names, typically Adjective or Noun-Adjective, are the labels of the gates on an XOR gateway following the activity.

For example, the BPMN diagram above means that task a has end states “OK”, leading to task b, and “Exception”, leading to task c.  CMMN Method and Style borrows this idea, with the task end state indicated by the sentry label of an entry condition triggered by the complete event of another plan item.

Here, CMMN task a again has end states “OK”, leading to task b, and “Exception”, leading to task c.  In CMMN Method and Style, the end state of a task is captured in an implicit variable [taskname].end, and here the sentry label represents the entry condition’s IF-part expression, a Boolean.  When the ON-part link – the dash-dot connector – from the triggering plan item is labeled with the complete event, the sentry label is visual shorthand for the full IF-part expression,

[triggering task].end = [sentry label]

The expression syntax depends on the expression language employed.  The syntax I use is FEEL, which is the default in the Trisotech tools.

A milestone is a plan item signifying an achieved state of a stage in the case.  Like task end states, milestones are used in Method and Style to signify the end state of a stage, determining what happens next (or what is possible to happen next).  Unlike task end states, which are exclusive, more than one milestone in a stage may be achieved.  In Method and Style, global variable Milestones contains the list of all case milestones that have been achieved, in the format [stagename].[milestone name].  Similarly to the example above, when completion of a stage determines what happens next, a sentry labeled with the name of a milestone in the triggering stage is visual shorthand for the FEEL IF-part expression,

list contains(Milestones, [stagename].[milestone name])

Let’s take a look at a few of the style rules.  From the above examples you see that labels play a key role.  In the spec, executable CMMN references elements by ids, which are not visible, and pays little attention to labels, which are.  Many style rules require labels on CMMN elements and ascribe particular meaning to them, as we saw above with sentry labels signifying the IF-part condition.  The label of a plan item signifies its name, which must be unique in its context.  For example, style rule 0010 checks for this:

In the diagram on the left, the stage and its enclosed task have the same name, Registration.  This is a style error.  The diagram on the right is correct.

In the spec, dotted line connectors called associations are optional annotations with no operational semantics, but Method and Style may require them, in order to make the case logic visible from the diagram.  For example, the trigger of a timer event listener (similar to a timer intermediate event in BPMN) has no official representation in the diagram, so Method and Style uses a directional association labeled with an event of the triggering item.  Without this connector, the trigger is assumed to be activation of the containing stage.  If the connector is present, style rules require the event label:

The diagram above means that Registration Stage is terminated automatically (black sentry) if it is not completed within 7 days of the actual start of task Registration.  The association labeled manual start defines the trigger of the timer.  The timer label defines its duration.  The diagram on the left is missing the event label, and thus is a style error.  If the timer event listener is missing its duration label, that is also a style error.

Other style rules resolve inconsistencies in the CMMN spec.  Style rule 0100, for example, prohibits ON-link connectors from crossing stage boundaries.  In one part of the spec, it says such links are not allowed; in another part it says they are allowed, and in the wild you often see them.  But such links do not work when a stage is rendered collapsed, and a basic principle is that the semantics should not depend on an element’s graphical rendering.  In Method and Style such links are not allowed.  The top diagram below is thus a style error; the bottom diagram is correct.

The diagram above also illustrates how milestones are used as stage end states.  Task Acceptance is enabled when Registration Stage completes in the end state “Registration OK”.  The sentry label is visual shorthand for the FEEL IF-part expression

list contains(Milestones, "Registration Stage.Registration OK")

And note also that the milestone Registration OK is activated when the task Registration completes in the task end state “OK”.

Still other style rules guard against infinite loops.  The hashtag symbol indicates a plan item is Repeatable,  meaning when it completes a new instance becomes Available immediately if its Repetition Rule is true.  Like IF-part expressions, Repetition Rules are Boolean expressions of case variables (file items) that are normally invisible in the diagram.  Method and Style requires a text annotation to reveal the Repetition Rule; otherwise the rule is assumed to be true by default.  Thus if a Repeatable task or stage is not manually activated, has no entry condition, and does not have a text annotation indicating a Repetition Rule, the new Available instance will become Active as soon as the previous one completes, an infinite loop that prevents completion of its containing stage.

In the left diagram above, task Registration is an infinite loop, a style error.  In the center diagram, Registration is ok, since it is manually activated, and task Acceptance is ok as well, since it has an entry condition.  In the right diagram, Registration is ok as well, since it has a Repetition Rule that prevents an infinite loop.

A final style rule example is intended to eliminate deadlocks caused by zombie states, when a stage is completed manually before its expected end state milestones are set.  The rule says that if a stage has multiple milestones tested by the IF-parts of complete links, it should contain a single Required milestone triggered by all those milestones, in order to ensure proper stage completion.  A stage may not be manually completed unless all of its Required elements are Completed.  The example below illustrates:

In the top diagram, Registration Stage has two milestones tested by complete links, and one leading to exit.  Since no plan items are Required, it is possible for a case worker to manually declare Registration Stage complete without achieving any of the milestones, and in that case there is no next step available.  Style rules flag this with a warning.  The bottom diagram is correct.  Here achieving either milestone New registration or Existing registration sets the Required milestone Registration completed.  The stage may not complete unless the Required milestone is achieved, preventing the zombie state.

If all of this looks wildly unfamiliar, that’s because it is!  But help is on the way.  My book CMMN Method and Style explains it all at length, and it is available on Amazon.  You can play around with CMMN by starting a free trial.

Read part 1