Companion presentation to similar paper at SAICSIT 2015 (Southern African Institute for Computer Scientist and Information Technologists Annual Conference 2015).

1. Metrics for the Case Management Modeling and
Notation (CMMN) Specification
Mike A. Marin Hugo Lotriet John A. Van Der Poll
University of South Africa
September 30, 2015
SAICSIT 2015
Wallenberg Research Centre,
Stellenbosch, South Africa
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

2. Outline
Agenda
Motivation
Case Management Modeling and Notation
Methodology
CMMN Model
Modeling elements and annotators
Size Metric
Length Metric
Complexity Metric
Findings
Future Work
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

3. Motivation
Business Process Management (BPM) is widely used by
businesses to automate business process in the enterprise
Extensive research has been conducted in several aspects of
the technology
Including complexity metrics
Commonly used notations are procedural and graph based
Nodes represents activities
Arcs represent routes
The Business Process Management and Notation (BPMN) is
the main BPM standard
Created by the object management group (OMG)
BPMN version 1.0 released in May 2004
The Case Management Modeling and Notation (CMMN) is a
new process notation
Trying to understand modeling complexity for the CMMN
Identify and validate complexity metrics for CMMN
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

4. Differences between traditional BPM and CMMN
Traditional BPM CMMN
Procedural Declarative
Control flow Event based
Process centric Data centric
Engine control process flow Knowledge workers control the flow
Arcs describe the sequence No predefined sequence
BPMN Example
CMMN Example
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

5. Case Management Modeling and Notation (CMMN)
CMMN is a new process modeling notation
Version 1.0 released in May 2014
Created by the object
management group (OMG)
Notation
Compatible with BPMN
Diamonds represent guards
(pre-conditions)
Rounded rectangles represent
tasks
Declarative
Notation based on business
artifacts with
guard-stage-milestone
CMMN Example
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

6. Methodology
Extensive literature review on complexity software metrics, in
particular for Workflow and BPM.
Formalized the definition of CMMN in order to define metrics
and validate them
Identify three metrics
Size (CS)
Length (CL)
Complexity (CC)
Used the theoretical and empirical validation of software
product measures framework defined by Briand et al. to
validate the three metrics
Used Weyuker's nine properties for evaluating software
complexity measures to further validate the Complexity metric
(CC)
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

7. CMMN Model
Definition (Model)
A CMMN model C is defined as a tuple
C = E, U, V, A
Where
E is a set of modeling elements.
U is a binary relationship in which two elements x and
y in E are related if and only if they are contained in
the same scope.
V is a binary relationship in which two elements x and
y in E are related if and only if an event from one (x)
triggers the other (y).
A is a set of annotators used to indicate characteristics
of elements in E.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

8. Modeling elements E and annotators A
Modeling elements E
Annotators A
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

9. Size Metric
Definition (Size)
The size of a model C denoted by CS(C) is defined as the
cardinality of E,
CS(C) = |E|
Example
CS(C) = 8
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

10. Size metric characteristics
Size CS(C) complies with the Briand et al. framework properties
for size metrics
Size (Non-negativity)
The size of a model S = E, R is non-negative.
Size (Null value)
The size of a model S = E, R is zero if E is empty.
Size (Module additivity)
The size of a module S = E, R is equal to the sum of the sizes
of two of its modules m1 = Em1, Rm1 and m2 = Em2, Rm2
such that any element of S is in either m1 or in m1.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

11. Length Metric
Definition
The length of a model C denoted by CL(C) is defined as the
maximum nesting depth of a model.
The length CL(C) can be calculated by the following algorithm,
Example
CL(C) = 3
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

12. Length metric characteristics
Length CL(C) complies with the Briand et al. framework properties for length metrics
Length (Non-negativity)
The length of a model S = E, R is non-negative.
Length (Null value)
The length of a model S = E, R is zero if E is empty.
Length (Non-increasing monotonicity for connected components)
Adding relationships between elements of a module m does not increases the length of
the model S = E, R .
Length (Non-decreasing monotonicity for non-connected components)
Adding relationships between the elements of two modules m1 and m2 does not decrease
the length of the model S = E, R .
Length (Disjoint modules)
The length of a model S = E, R made up of two disjoint modules m1 and m2 is equal
to the maximum of the lengths of the modules m1 and m2.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

13. Complexity Metric
Definition
The complexity of a model C denoted by CC(C) is defined as,
CC(∅) = 0, otherwise CC(C) =
i∈E∪A
Wi
Where, the weight, Wi is given in by a table of weights.
Example
CC(C) = 11
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

14. Complexity metric characteristics
Complexity CC(C) complies with the Briand et al. framework properties for complexity
metrics
Complexity (Non-negativity)
The complexity of a model S = E, R must be non-negative.
Complexity (Null value)
The complexity of a model S = E, R is zero if R is empty.
Complexity (Symmetry)
The complexity of a model S = E, R does not depend on the convention chosen to
represent the relationships between its elements.
Complexity (Module monotonicity)
The complexity of a model S = E, R is no less than the sum of the complexities of any
two of its modules with no relationships in common.
Complexity (Disjoint module additivity)
The complexity of a model S = E, R composed of two disjoint modules m1 and m2 is
equal to the sum of the complexities of the two modules.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

15. Properties 1/2
Complexity CC(C) complies with the Weyuker’s complexity properties
Property (Non-coarseness)
A metric should not rank all models as equally complex.
Property (Granularity)
A metric should rank only a finite number of models with the same complexity.
Property (Non-uniqueness)
A metric should allow some models to have the same complexity.
Property (Design details are important)
Two distinct but equivalent models that compute the same function need not have
the same complexity.
Property (Monotonicity)
The complexity of two models joined together is greater than or equal to the
complexity of either model considered separate.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

16. Properties 2/2
Complexity CC(C) complies with the Weyuker’s complexity properties
Property (Nonequivalence of interaction)
Two models with the same complexity when each is joined to a third model the
resulting complexity may be different between the two.
Property (Permutation)
Complexity should be responsive to the order of statements.
Property (Renaming)
Complexity should not be affected by renaming.
Property (Interaction may increase complexity)
(∃P)(∃Q)( P + Q < P;Q ).
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

17. Findings
Main findings
The formalization of the CMMN model was sufficient to
define and validate the metrics.
The three proposed metrics comply with the formal framework
for software measurements defined by Briand et al.
The complexity metric also complies with the properties
described by Weyuker.
Both Briand et al., and Weyuker assume that software
systems are build using a procedural style, based on directed
acyclic graphs that may not be totally applicable to CMMN.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

18. Future work
Work is required to understand the applicability of Briand et
al., and Weyuker to declarative systems.
Work is required to conduct the empirical validation for the
proposed metrics.
CMMN claims an approach based on business artifacts,
therefore further work is required to compare the formal
CMMN model described in the paper with a formalization of
business artifacts.
The weights given for the complexity metric CC(C) were
assigned based on the intuition of the authors, and further
empirical work is needed to fine tune the weights.
Empirical work is needed to understand the influence of
CMMN non-visual entities on the complexity metric.
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN

19. Thanks
Mike A. Marin, Hugo Lotriet, John A. Van Der Poll Complexity metrics for CMMN