Adjustments

In their work, Rossi and Brinkkemper [RB96] used the OPRR modeling language as im- plemented in MetaEdit [Smo+91] to model the methods to be analyzed. However, later studies conducted by Indulska et al. [Ind+09b] and Recker et al. [Rec+09] were based on UML meta-models instead of OPRR meta-models. Therefore, in order to produce results comparable with previous evaluations [Ind+09b; Rec+09; SC02] this study used Rossi and Brinkkemper’s meta-model method complexity metrics, but explicitly identified and followed the approach used by Indulska et al. This allowed the researcher to use the normative CMMN meta-model described using UML class diagrams in the CMMN specification. Additionally, to avoid confusion and to be consistent with Rossi and Brinkkemper’s approach, for the purpose of this study UML meta-model classes are referred to as objects, and attributes are referred to as properties.

There are some differences between the meta-model-based method complexity as defined by Rossi and Brinkkemper [RB96] and how it was applied by Indulska et al. [Ind+09b]. First, as noted above, Rossi and Brinkkemper used OPRR and Indulska et al. used UML. Indulska et al. developed a UML meta-model of BPMN version 1.2 for their research because the BPMN version 1.2 specification did not describe a normative UML meta-model. Secondly, Rossi and Brinkkemper described a set of 17 complexity metrics. Because BPMN version 1.2 contains a single technique (i.e., business process diagrams) Indulska et al. used a smaller subset that focused on the total cumulative method complexity of a method C0_{(M). Thirdly,} Indulska et al. introduced the concept of full and concrete notation for BPMN version 1.2. The full notation consists of the objects, relationships, and properties from the notation

meta-model, and the concrete notation consists of the objects, relationships, and properties derived from the graphical notation. In accordance with Rossi and Brinkkemper, who used a simple, conceptual complexity to compare methods based on the meta-model, the researcher focused on the full notation in this study.

4.2.1.2 Counting Principles

After careful analysis of the meta-model and the approach used by Indulska et al. [Ind+09b], the following counting principles were identified and used for specifications described in UML meta-models:

1. The count of objects includes all of the abstract classes. 2. The count of properties excludes references to other classes.

3. The count of properties includes all objects and relationship properties.

4. The count of properties excludes tool-generated properties. The meta-model used by Indulska et al. was developed for their research, hence it did not include tool-generated properties.

5. Enumerations are not counted.

4.3

CMMN Analysis

Table 4.1 was created using the counting principles described above along with the result- ing objects and their properties for CMMN version 1.0. The data was extracted from the CMMN version 1.0 specification. Figure 4.1 illustrates part of the CMMN class diagram using the counting principles. It includes CMMNElement, Case, Role, Stage, and CaseParameter as objects. It also includes properties name for Case, name for Role, and description for CMMNElement. The Id in CMMNElement is a tool-specific property because it should be gener- ated by the implementing tool. Therefore, it does not appear in Table 4.1. In CMMN 11 tool- generated properties were identified and removed from the count. Examples of tool-generated properties in CMMN include Id, exporter, exporterVersion, and expressionLanguage, which are expected to be populated by the tool implementing the specification.

Table 4.2 provides the resulting relationships and their properties for CMMN version 1.0. The data was extracted from the CMMN version 1.0 specification. As described by the counting principles all of the CMMN meta-model classes are included, but tool-generated properties are excluded from the count.

Table 4.1:CMMN version 1.0 objects and properties Objects OM Properties PM CMMNElement description Definitions name Import location CaseFileItemDefinition definitionType CaseFileItemDefinition name CaseFileItemDefinition structureRef Property name Property type Case name Role name CaseFile CaseFileItem multiplicity CaseFileItem name EventListener Milestone PlanItemDefinition name TimerEventListener timerExpression StartTrigger CaseFileItemStartTrigger standardEvent PlanItemStartTrigger standardEvent UserEventListener PlanFragment PlanItem name Sentry name IfPart Expression body Stage autoComplete TableItem DiscretionaryItem ApplicabilityRule name Task isBlocking ProcessParameter Parameter name ParameterMapping CaseParameter HumanTask ProcessTask process CaseTask PlanItemControl ManualActivationRule name RequiredRule name RepetitionRule name

Figure 4.1: Case class diagram from CMMN version 1.0 specification [OMG14a]

Figure 4.2: Event propagation notation between a case file item and a task

Relationships in CMMN are challenging in terms of this analysis because there is a single relationship connector (dashed line) in the CMMN notation, and its use is optional. In CMMN, the connector is only used in two situations. First, it is used optionally to indicate event propagation represented in the meta-model by the OnPart of which there are three classes: one abstract class and two concrete classes. Figure 4.2 shows an example of the event propagation notation between a case file item and a task. Secondly, the same connector (dashed line) is used for an expanded planning table in a human task. In this situation the connector is used to connect the human task to the discretionary items contained in the planning table. Figure 4.3 provides an example of an expanded planning table in a human task containing two discretionary tasks. However, planning tables can also be used in stages in which case the connector is never used. CMMN does not have an object in the meta-model to indicate the second situation. There is no object that represents the connection of an expanded table in a human task to its discretionary items. Table 4.2 counts the planning table as a relationship to account for this situation.

Having identified the appropriate set of objects, relationships, and properties using an ap- proach similar to that used by Indulska et al. [Ind+09b] and by using the derived counting principles, Rossi and Brinkkemper’s [RB96] method complexity calculations were applied by counting the cells in the tables. Based on Table 4.1, there are 39 non-duplicated object

Figure 4.3:Planning table in a human task containing two discretionary tasks Table 4.2:CMMN version 1.0 relationships and properties

Relationships RM Properties PM OnPart

CaseFileItemOnPart standardEvent PlanItemOnPart standardEvent PlanningTable

types n(O_M) in the CMMN method. Based on Table 4.2, there are four non-duplicated relationship types n(RM). Based on Tables 4.1 and 4.2, there are 28 properties n(PM). Therefore, the calculated cumulative method complexity C0(M) for CMMN version 1.0 is

C0(M) =pn(O_M)2+ n(R

M)2+ n(PM)2 = √

392+ 42+ 282 = 48.18.

4.4

Findings

Table 4.3 shows the CMMN version 1.0 method complexity in the context of other popular process notations. The table is organized based on the cumulative method complexity C0_(M). The methods included were reported by Siau and Cao [SC02], and Indulska et al. [Ind+09b] using the BPMN version 1.2 subsets identified by zur Muehlen and Ho [zH08], zur Muehlen and Recker [zR08], and zur Muehlen et al. [zur+07]. For illustrative purposes, Figure 2.3 shows a simple insurance claim process described by Korherr [Kor08] using the four process modeling notations evaluated during this study (see Section 2.2.1 for more details).

4.4.1 Implications

A calculated, cumulative complexity of 48.18 for CMMN version 1.0 indicates that it is more complex than EPC, which has a cumulative complexity of 19.26. However, UML version 1.4 Activity Diagrams, which has a cumulative complexity of 11.18 is less complex than BPMN version 1.2, which has a cumulative complexity of 169.07. Table 4.3 clearly shows how BPMN version 1.2 makes extensive use of properties, relationships, and objects: more so than all of the other methods. As stated by Rossi and Brinkkemper [RB96], this may also indicate that

Table 4.3:Method complexity comparison

Objects Relationships Properties Cumulative Complexity

Method n(O_M) n(R_M) n(P_M) C0(M)

BPMN 1.2FULL[Ind+09b] 90 6 143 169.07

BPMN 1.2 DoDFULL[Ind+09b; U.S09] 59 4 112 126.65 BPMN 1.2 Case StudyFULL_{[Ind+09b; zH08] 36 5 81 88.78}

BPMN 1.2 Frequent UseFULL_{[Ind+09b; zR08] 21 4 59 62.75}

CMMN 1.0 [OMG14a] 39 4 28 48.18

EPCFULL_{[Ind+09b] 15 5 11 19.26}

UML 1.4 Activity Diagrams [SC02] 8 5 6 11.18

BPMN version 1.2 is more expressive than CMMN version 1.0, which in turn may be more expressive than EPC and UML version 1.4 Activity Diagrams.

The results are encouraging as they may indicate that CMMN should be easier to learn than BPMN. As suggested by Rossi and Brinkkemper [RB96], these results should be validated via empirical studies. Although empirical validation of the results is needed, practitioners who find BPMN difficult to use may want to explore CMMN as an alternative for Knowledge Intensive Processes (KiP) that follow the use cases identified by di Ciccio et al. [di +14], Işik et al. [I+¸13], Le Clair et al. [Le +09], Reijers et al. [Rei+03], Swenson [Swe10a], and van der Aalst and Berens [vB01].

The reliability and validity of the comparisons may be compromised by the mix of the meta- models and counting principles involved. The researcher was careful to follow the original approach described by Rossi and Brinkkemper [RB96], and adjusted it to compare the results with the work done by Indulska et al. [Ind+09b], Recker et al. [Rec+09], and Siau and Cao [SC02]. In the process, it was noted that Rossi and Brinkkemper [RB96] and Siau and Cao [SC02] used OPRR meta-models to compare their results, while Indulska et al. [Ind+09b] used an UML meta-model; and Recker et al. [Rec+09] used the two meta-models. This study used the normative UML meta-model from the specification was used for CMMN version 1.0.

4.5

Summary

This chapter has provided one of the first studies of method complexity of CMMN version 1.0 using the approach proposed by Rossi and Brinkkemper [RB96]. It compared the results against the results obtained by Siau and Cao [SC02], Indulska et al. [Ind+09b], and Recker et al. [Rec+09]. Based on the findings, CMMN compares favorably to other methods. Material from this chapter has been published in Marin et al. [Mar+14b].

Transformations Between GSM and

CMMN

This chapter contributes formal transformations between Case Management Model and No- tation (CMMN) [OMG14a] case types and Guard-Stage-Milestone (GSM) [Hul+11b] artifact types that allow for theoretical results derived from GSM to be applied to CMMN. The transformation from a CMMN case type to a GSM artifact type may also provide CMMN with formal execution semantics. Not surprisingly, the transformation of a GSM artifact type into a CMMN case type is easier to achieve because CMMN is based on GSM [Mar+13; OMG14a]. The transformation from a GSM artifact type into a CMMN case type is relatively straight forward and simple to describe. The resulting case type modeled using CMMN is visually similar to the original artifact type, making it easier for a human being to understand. However, the transformation from a case type into an artifact type is more complex because CMMN has extended GSM by introducing new constructs and defining a life cycle with a set of standard events for those constructs. This transformation allows CMMN to use the formal operational semantics of GSM, and this means that the formal verification work developed for GSM can also be applied to CMMN.

This chapter is organized as follows. Section 5.1 describes the motivation for the transforma- tions. Section 5.2 develops and describes the GSM to CMMN transformation. Section 5.3 develops and describes the CMMN to GSM transformation based on patterns. Two ap- pendices complement the material in this chapter. Appendix D, file 30 (FSM-2-GSM.pdf) describes and formalizes the transformation of a Deterministic Finite State Machine (DFSM) into GSM types that are required to transform CMMN into GSM. Material from Appendix D file 30 (FSM-2-GSM.pdf) has been published in Marin et al. [Mar+16]. Appendix A describes the syntax directed translation grammar [Aho+07] used to transform a CMMN case type into a GSM artifact type.

CMMN GSM DCDS

Figure 5.1: Transformations

5.1

Motivation

The motivation for performing the transformations between CMMN and GSM centers on the possibility of using the theoretical results from GSM [Bel+12; Dam+11; Gon+15; Sol+13b] to provide formal execution semantics for CMMN. This thesis uses an approach similar to that used by Solomakhin et al. [Sol+12] to map GSM to Data-Centric Dynamic Systems (DCDS) [Bag+13; Cal+15]. Both GSM and DCDS are implementations of BAs. Figure 5.1 shows the transformations. The transformation of GSM artifact types to DCDS is described in Solomakhin et al. [Sol+12].

Several researchers of Business Artifact (BA) have done work on transformations. Solomakhin et al. [Sol+13b] have done a transformation of GSM into DCDS which is another BA framework [Bag+13]. Meyer and Weske [MW13] sketched algorithms to transform artifact- centric process models into activity-centric process models. They identified four types of process models, namely artifact-centric, synchronized object life cycles, activity-centric, and activity-centric with attribute definitions. They also sketched five algorithms that allow any of the four types of process models to be transformed into one another. Popova and Dumas [PD13] and Popova et al. [Pop+15] worked on the automatic transformation of Petri Nets into GSM artifact types.

Transformations between process modeling notations particularly between Business Pro- cess Model and Notation (BPMN) [OMG13] and Business Process Execution Language (BPEL) [OAS07] have been described in the work of several researchers [MH11; Shi+16]. Transformations between BPEL and BPMN are important because BPEL does not have a graphical notation, and early BPMN versions did not have clear execution semantics. A transformation can be used to address these two issues. The CMMN specification [OMG14a] and some authors, such as Bruno [Bru16], Eshuis et al. [Esh+16], and Jansen [Jan15], have described CMMN as being based on the GSM type of BA. However, the researcher is not aware of any publication that describes the formal relationship between CMMN and GSM. This chapter addresses this gap by proposing two transformations, one from GSM to CMMN, and the other from CMMN to GSM. These transformations will help clarify the relationship between CMMN and GSM, and provide a way to apply the theoretical work that has been done on GSM to CMMN models.