Extracting Features From Process Variants in Case Management

05/30/2020 ∙ by Rik Eshuis, et al. ∙ TU Eindhoven 0

Case Management supports knowledge workers in performing knowledge-intensive processes in a flexible way. An essential ingredient of Case Management are template processes that are modified for a specific case to suit the context of that case. Modifying templates results in many different yet related process variants. However, modifying a template is time consuming and may lead to errors. This paper defines an approach to extract fragments, called features, from artifact-centric process variants in case management. By composing the extracted features, the input variants and other process variants can be derived. This way, complex artifact-centric process variants can be designed more efficiently and their quality improves, since well-known modifications are applied.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Many business processes in modern organizations rely on knowledge workers that have to make informed decisions about specific cases. The available data and knowledge drives the decision making and processes in such knowledge-intensive processes (KiPs) [10]. Case management is a key paradigm in BPM to support KiPs [30]. A key notion in case management is that of a template: a representation of a “baseline” process. The template is modified to suit the needs of the particular case being processed. Common modifications are adding and deleting elements of the template [13]. Such modifications result in a case management process model variant, or a process variant for short.

Modifying a case management template is labor intensive, since the exact changes need to be explicitly specified. Moreover, the changes may have undesirable side effects, for instance a deadlock or a task that is done twice. This paper develops support for reuse of modifications to case management templates. By applying a modification that already was applied before to the template for another variant, the design time for new variants is reduced. Moreover, the quality of new process variants is improved, since well-proven modifications are applied.

More concretely, this paper defines an approach to extract fragments from a case management template and a set of process variants that are based on the template. Each fragment represents work done for a case that was incorporated in an input process variant by modifying the template. We view these extracted fragments as features. The notion of feature comes from the field of Software Product Line Engineering [3], where they are used to distinguish common and variable parts in software artifacts and this way support reuse of software artifacts. Composing different but related features yields different variants of a software product [4, 6].

As host modeling language, we use Guard-Stage-Milestone (GSM) schemas, a technique to declaratively model life cycles of key business entities, called business artifacts [16, 9]. In previous work, we defined a feature composition operator for GSM schemas [12], which defines how a GSM fragment viewed as feature is applied to a base GSM schema (template). Using feature composition, extracted GSM fragments can be composed into variants in a declarative way. GSM schemas are one of the predecessors of CMMN [8, 22]. Thus, the results in this paper provide a basis for applying feature extraction to CMMN models.

The remainder of this paper is organized as follows. Section 2 introduces GSM schemas, feature composition and the problem of extracting features from GSM variants. Section 3 defines GSM schemas and feature composition. Section 4 defines the approach for templates and variants that all refine the template. Section 6 discussed related work. Finally, Section 7 concludes the paper.

2 Overview

We introduce GSM schemas, feature-based composition of GSM fragments, and the problem of extracting features from a set of GSM schema variants.

GSM schemas.

A Guard-Stage-Milestone (GSM) schema defines the life cycle of a business artifact [9, 16]. A business artifact is a key business entity that is changed during a business process, for instance an order or a claim request [26]. Key modeling constructs in GSM schemas are stages and milestones. A stage represents a cluster of business activity performed for the artifact. Stages are organized into a hierarchy. Each atomic stage contains exactly one task, an atomic piece of work. A milestone represents a business objective, usually achieved by completing an attached stage. Stages and milestones change status if certain conditions, called sentries, are met. There are two kinds of sentries. Plus sentries ensure that a stage is opened or a milestone achieved, while minus sentries ensure that a stage is closed or milestone invalidated. Guards are plus sentries of stages.

Figure 1: Base GSM schema Business Criteria Assessment ()
(a) Variant of
(b) Variant of
Figure 2: Variant GSM schemas

Example.

Fig. 2 shows sample GSM schemas. Rounded rectangles denote stages, circles denote milestones, and each diamond denotes the presence of a guard. Other sentries are not visualized. In the base process (Fig. 1), business criteria for a partner contract are assessed: first data about the partner is gathered and prechecked, and next a detailed check is performed to decide whether the criteria should be changed or not. If new information arrives before the business criteria have been assessed, the data is gathered anew and the business criteria check is restarted, if applicable. Sentries for the base process are listed in Table 1 and 2.

Stage Plus sentries (guards) Minus sentries (closing) Initial Data Gathering E:StartAssessment ; E:AdditionalInfo IDGS Preliminary Check IDGS PCS PCU ; E:AdditionalInfo Business Performance Evaluation Check +Preliminary Check BPECS BPECU ; -Preliminary Check Detailed Check PCS DCS DCU

Table 1: Stages and sentries for in Fig. 2. ‘;’ separates different sentries

Milestone Full Name Plus sentries Minus sentries IDGS Initial Data Gathering Successful C:Initial Data Gathering E:AdditionalInfo BPECS Business Performance Evaluation Check Successful C:Business Performance Evaluation Check BP_good E:AdditionalInfo BPECU Business Performance Evaluation Check Unsuccessful C:Business Performance Evaluation Check BP_good E:AdditionalInfo PCS Pre-checks Successful BPECS false PCU Pre-checks Unsuccessful BPECU false DCS Detailed Check Successful C:Detailed Check false DCU Detailed Check Unsuccessful C:Detailed Check false

Table 2: Milestones and sentries for in Fig. 2

GSM variants and feature composition.

A GSM schema can be modified into another GSM schema. This way, from a base GSM schema a set of variant GSM schemas can be derived. To derive a variant, several change operations can be applied to a GSM schema [13]. For instance, Fig. 2LABEL:sub@fig:ex3 and Fig. 2LABEL:sub@fig:ex4 show two variants that are modifications of the base GSM schema in Fig. 1. They have been derived by inserting stages and milestones for an additional checks on the credit level and the addressable market. Also sentries need to be modified for these variants: Table 3 shows as an example the modified sentries for PCS and PCU. Space limitations prevent a completing listing of the sentries for the other stages and milestones of the variants.

To enable reuse of shared parts between GSM variants, we proposed in earlier work [12] to view GSM fragments as features and to use feature composition, well-known from the field of Software Product Line Engineering [4, 6], to compose GSM fragments into GSM schemas.

Variant Milestone Plus sentries (achieving) Minus sentries (invalidating) PCS BPECS CCS false PCU BPECU CCU false PCS BPECS CCS AMCS false PCU BPECU CCU AMCU false

Table 3: Sentries for milestones PCS and PCU in variants of in Fig. 2.

Extracting features.

Though the feature composition approach [12] allows to generate different variants from a common base GSM schema (template), it assumes that the composed features already exist. But defining features manually can be time consuming and costly, as it depends on domain knowledge from domain experts.

We define an approach to extract features from a set of variant GSM schemas derived from the same base GSM schema. The approach is efficient, since it can be automated and does not rely on domain knowledge, because that knowledge is already encoded in the different variants. Moreover, extracting features enables the reuse of modifications among different GSM variants, each feature representing one set of related modifications.

In essence, the approach decomposes a base GSM schema and set of GSM schema variants into features. For example, for the base schema and its two variants and , two features can be extracted, one related to Credit Checking, one related to Addressable Market Check. Each feature represents the insertion of a stage and two milestones and the modification of sentries. Each input GSM schema variant can be derived by composing one or more of the extracted features with the base schema, using feature composition [12]. However, also other variants can be derived by composing the extracted features. For instance, another variant for can be composed that contains Addressable Market Check and its connected milestones, but not Credit Check.

3 GSM Schemas

In this section, we define GSM schemas. A GSM schema [9] of a business artifact consists of data attributes and status attributes. Data attributes model the information state of the business artifact. A status attribute is a Boolean variable that denotes the status of a stage or milestone. For a status attribute of a stage, value true denotes that the stage is open, value false that the stage is closed. For a status attribute of a milestone, value true denotes that the milestone is achieved, value false that the milestone is invalid.

Event-Condition-Action rules define for which event under which condition a status attribute changes value (action). The event-condition part of a rule is called a sentry. The event of a sentry is optional. We distinguish between external and internal events. An external event signifies a change in the environment. It is either a task completion event , where is a task, as defined below, or a named external event , where is an event name. An internal event signifies a change in value of a status attribute : internal event denotes that becomes true, that becomes false. For instance, +Preliminary Check in Table 1 is an internal event that signifies that stage Preliminary Check gets opened. The condition of a sentry is a Boolean expression that can refer to data attributes or status attributes. The action of each rule is that a status attribute becomes true or false, which leads to two types of sentries. A plus sentry defines when a stage becomes open or a milestone gets achieved. A minus sentry defines when a stage is closed or a milestone gets invalid.

Stages and milestones can be nested inside other stages. A milestone cannot contain any other milestone or stage. We require that the nesting relation induces a forest, i.e., the nesting relation is acyclic and if a stage or milestone is nested in two other stages , , then either is nested in or in . The most nested stages, which are called atomic, launch tasks. To ease the presentation, we assume for this paper that stages launch tasks having the same label, so for instance stage Detailed Check launches a task with the same name.

We next formally define GSM schemas [9, 13].

Definition 1 (GSM schema)

A GSM schema is a tuple , where

  • is a set of attributes, partitioned by the following three subsets:

    • is a finite set of data attributes;

    • is a finite set of stage attributes;

    • is a finite set of milestone attributes;

  • is a finite set of named external events;

  • is the set of stage completion events;

  • is a partial order on stages and milestones, where means that is child of . Relation induces a forest, i.e., if and , then or . We let denote the set of stages that have no children;

  • , are functions assigning to each status attribute non-empty sets of sentries (see Definition 2). For , is the set of plus sentries that define the conditions when to open stage or achieve milestone , while is the set of minus sentries that define the conditions when to close stage or invalidate milestone .

Relation is visualized using nesting. For instance, Business Performance Evaluation Check Preliminary Check and BPECS Preliminary Check in Fig. 2LABEL:sub@fig:ex1.

Each sentry in set , where , maps into an Event-Condition-Action rule “”, where sentry is the Event-Condition part and action denotes for that stage gets opened and for that milestone gets achieved. Each sentry in set maps into a rule “”, where action denotes for that stage gets closed and for that milestone gets invalid. Each sentry in set or is sufficient for triggering a status change in the stage or milestone .

For the definition of sentries, we assume a condition language that includes predicates over integers and Boolean connectives. The condition formulas may refer to stage, milestone and data attributes from the universe of attributes . Keyword orig denotes the original condition formula defined in another GSM schema for the same status attribute [12].

Definition 2 (Sentry)

A sentry has the form , where is the event-part and the condition-part. The event-part is either empty (trivially true), a named external event , a task completion event , where is a task, or is an internal event or , where is a stage or milestone attribute. The condition is a Boolean formula in CNF in the condition language that refers to , so data attributes in and status attributes in and the keyword orig can be used in . The condition-part can be omitted if it is equivalent to .

The condition part of a sentry is a boolean formula in conjunctive normal form (CNF) in order to ease the presentation. However, this is not a severe restriction: if the condition part of a formula in is not in CNF, it can be rewritten using Boolean laws into an equivalent set (disjunction) of sentries. For instance, formula is equivalent to set of sentries .

In earlier work we proposed a declarative composition operator for GSM schemas [12]. Given a GSM schema fragment and a GSM schema , the GSM schema results by merging the GSM schemas by taking the union of the different components of a GSM schema tuple, except for sentries (rules). For shared stages and milestones the definition of sentries in override those in .

If the sentries of a shared stage or milestone should be merged rather than overridden, keyword orig can be used in the sentries of , which in the evaluation of is replaced with the sentries of the shared stage or milestone in . For instance, if and share milestone , the sentry of in is and in is , then the sentry of in is .

GSM schema fragments contain orig in their sentries, while base schemas and variants do not contain sentries with orig, i.e., they can be executed.

4 Extracting Features

We next define a method that extracts a set of features from a template (base) GSM schema and a set of GSM schema variants that refine the template. Each extracted feature is specified as a GSM schema fragment.

4.1 Requirements

First, we list requirements on the set of features that the method extracts:

  • The feature set must be minimal: there is no feature in the set that itself is a combination of other features in the set.

  • The feature set must be complete: each variant can be derived by composing one or more features with the template.

Requirement R1 states that features are not overlapping, so orthogonal. For instance, variant can be derived by applying two features, one of which is defined for generating variant . Introducing a third feature that derives directly from is therefore redundant. Requirement R2 ensures that each variant that is input can in fact be derived by a combination of features.

4.2 Method

The input, output and different steps of the method are shown in Fig. 3. We next explain and define the different steps in detail.

Figure 3: Method to extract features from a set of GSM schemas that all refine the same base GSM schema

Step 1

Figure 4: Variant graph for GSM schemas in Fig. 1 and 2

creates a variant graph that shows the refinement relations between the different GSM schema variants. Nodes are and the variant GSM schemas. An edge in this variant graph denotes that refines (extends) , written . Fig. 4 shows the variant graph for the GSM schema variants in Fig. 2, which all refine . Moreover, refines .

The refines relation, , is defined as follows.

Definition 3 (Refinement)

Let be two GSM schemas. Then refines , written , if

  • ;

  • ;

  • ;

  • ;

  • ;

  • ;

  • for each , if then there is a s.t.  implies ;

  • for each , if then there is a s.t.  implies .

In the definition, most lines are straightforward given the definition of GSM schemas, except the one about the rules. If then for each plus (minus) rule of status attribute in , the same plus (minus) rule or plus (minus) rule for is in . If the rule is of the form in , then a feature can be constructed that extends with conjunct , by defining a sentry . A rule in of the form is not allowed (cf. Def. 2); instead, a set of rules can be specified.

Step 2

removes each transitive edge from the variant graph, i.e., each edge for which there is an alternative path from to . Step 2 is needed to ensure that the feature set is minimal. A refinement relation that is implied by one or more other refinement relations can be safely deleted, since its effect can be obtained from the other refinement relations. For the variant graph in Fig. 4, edge is transitive and removed in step 2.

Step 3

creates for each edge in the variant graph a feature. Since , constructing a feature seems straightforward: simply delete from . However, to ensure that composing the feature with yields , the feature must include some attributes from .

For instance, consider and in Fig. 1 and 2LABEL:sub@fig:ex3. Deleting from gives the GSM schema fragment in Fig. 5(a). But applying this as feature to results in a GSM schema variant in which the result of stage Credit Check, represented by milestones CCS and CCU, is not linked to the sentries of the stages and milestones of . Fig. 5(b) shows the correct feature: the fragment includes milestones PCS and PCU; the sentry of PCS is while the sentries for PCU are CCU and orig. These sentries connect CCS and CCU to .

(a) (b)

Figure 5: (a) Difference between and ; (b) Feature extracted for and

Given a core feature extracted by subtracting from , the next definition characterizes which status attributes from should be added to the core feature, in order to derive . We call these the border attributes, since they are the attributes from that link with the core feature.

Definition 4 (Border attributes)

Let be two GSM schemas such that (e.g., is the template, the variant). Then is the set of status attributes of that indirectly reference attributes in the part of that is not in :

The definition shows that border attributes need to be included for two reasons. First, if there is a sentry for a stage or milestone, such that the sentry references attributes of that are not in . For instance, the sentry of PCS of is and CCS is in but not in . Therefore, PCS is a border attribute for and , to ensure that the extracted feature modifies the sentry of PCS.

Second, if a stage or a milestone that is in but not in , is in a direct hierarchical relation with a status attribute that is in , then that status attribute needs to be a border attribute, to ensure that the hierarchy relation is preserved in the feature. For instance, stage Credit Check is in but not in . Compound stage Preliminary Check is a border attribute, to ensure that hierarchy relation of is included in the extracted feature.

We now define how a feature is extracted.

Definition 5 (Feature extraction)

Let be two GSM schemas such that (e.g., is the template, the variant). Then is the GSM schema where

  • ;

  • ;

  • ;

  • ;

  • ;

  • ;

  • for each ,


Most lines of the definition are straightforward. Above we already explained why border attributes need to be included. For the definition of rules, note that for a status attribute in but not in , the rules of in are incorporated in the feature. However, for a status attribute that is a border attribute, both and have defined rules. In that case, for pairs of rules that are similar, i.e., the rules are equal or the rule in extends the rule in , the feature should contain the rule of but with keyword orig replacing the rule of . For instance, in milestone PCS has sentry BPECS while in the sentry for PCS is . In , the sentry for PCS is .

We state the correctness of the approach with a few lemmas. The first lemma states that feature extraction results in a GSM schema fragment.

Lemma 1

Let be two GSM schemas such that . Then is a GSM schema.

The next lemma ensures that applying a feature that was generated for a template and a variant to the template yields the variant.

Lemma 2

Let be two GSM schemas such that . Then .

The next lemma follows easily from the method defined in Fig. 3.

Lemma 3

Let be a base GSM schema and be the set of variant GSM schemas such for each , . The set of features generated by the method in Figure 3 is minimal and complete.

5 Evaluation

To evaluate the feasibility of the approach, we applied the method to a real-world process of an international high tech company with offices in different regions of the worlds. In the process the expired due diligence qualification of a business partner of the company is renewed. The company has defined a standard due diligence process, but offices in certain regions can use their own process variant.

The standard process and three variants had been modeled before in separate GSM schemas [32]. The method could not be applied directly to these GSM schemas, since in one variant a fragment of the standard process was replaced with another fragment. Therefore, the standard process could not act as base process. We therefore manually created a base process, specified as GSM schema, such that both the standard process and the variant refine the base process. Thus, the standard process becomes another (fourth) variant. The GSM schemas for all these processes are available in the appendix.

Applying the feature extraction method to the base process and the four variants gave the following results. In the variant graph created in step 1, each variant refines the base schema, but not any other variant. Consequently, in step 2 no transitive edges were removed. In step 3, four features were created, one for each variant. The GSM schema fragments of the four extracted features are available too in the appendix.

Base schema Feature 1 Feature 2 Feature 3 Feature 4 # Non-border stages 9 1 2 1 1 # Non-border milestones 15 1 2 1 1 # Non-border sentries 60 5 10 4 5 # Border stages 1 1 1 1 # Border milestones 1 1 0 0 # Border sentries 5 5 3 3

Table 4: Descriptive statistics of extracted features for Due Diligence Process and its variants

Table 4 gives descriptive statistics of the base schema and the four features. All extracted features use border attributes to link properly to the base schema. For each border attribute there is at least one sentry that uses the orig construct. Composing each feature with the base schema gives the original variant. However, since three from the four features are complementary, additional variants can be derived [12].

This preliminary evaluation shows that the method can be used to extract features from a base schema and a set of GSM schema variants. However, it also shows that some preprocessing can be needed to ensure that all variants refine the base schema. In future work, we plan to extend the method to variants that do not refine the base schema but are overlapping.

6 Related Work

For artifact-centric process models, there is no directly related work on extraction of model fragments. The general problem of designing artifact-centric process models, either by defining a methodology for specifying business artifacts [7] or by defining an automated synthesis of artifact-centric process models [14, 15, 21, 27] has been addressed, but without considering fragments that are composed.

Alternatives to artifact-centric process models are object-aware [18] and object-centric [28] process models and case management models [1, 24, 29] (though artifact-centric process models can be used for case management too [13, 22]). A few of these alternatives support management of process variants [2] and, related, the use of model fragments [24, 25]; we next discuss these in more detail.

Andrews et al. [2] present concepts for managing variants in object-aware processes. Each object-aware process model is defined by a logged sequence of modeling actions. A process variant is derived from another process variant by copying the log of modeling actions of that other process variant into a new log and then adding new modeling actions to the log. The focus of that paper is on efficiently managing updates for related variants, while this paper focuses on extracting composable fragments from variants.

Meyer et al. [24] define an approach for production case management in which procedural, activity-centric process fragments are composed at run-time by linking them, i.e, a case is executed in a distributed fashion by executing linked process fragments. The fragments are linked via shared data objects. Mukkamala et al. [25] define a commutative composition operator on instances of DCR graphs, a declarative, activity-centric process modeling notation. Each DCR graph instance can be viewed as a process fragment being executed. Both approaches focus on composition of existing process fragments, whereas the approach in this paper focuses on extracting fragments from variants such that the fragments can be composed.

For activity-centric process models, approaches exist to extract shared fragments in process model repositories [11, 31], to discover configurable process fragments from activity-centric process models [5], or to discover variants from events log [17, 19]. All these approaches consider graph-like process models, which differ considerably from declarative, rule-based process models like GSM schemas.

In software engineering, feature extraction has been studied for software artifacts, e.g. [20, 23]. However, those features need to be manually identified, whereas in our method features are derived automatically. Studying how domain knowledge from experts can improve the quality of the generated features is an interesting direction for further work.

In sum, the main contribution of this paper is an approach to extract composable fragments from declarative, artifact-centric process variants.

7 Conclusion

This paper has defined a novel approach to extract model fragments, viewed as features, from declarative, artifact-centric process model variants. Using feature composition [12] the declarative fragments can be composed in a declarative way into the original variants, but also other variants can be composed. The approach can be used to decompose variants of case management templates into reusable fragments, that encode well-known modifications. This way, complex case management variants can be efficiently composed in a declarative way.

There are several directions for future work. An open challenge is to reconcile features, which are additive, with modifications of variants, which are non-additive, since they may be the result of deletions [13]. Next, we plan to realize a tool implementation of the approach geared towards CMMN [8]. In addition, we plan to apply this tool to several case study examples to further evaluate the approach.

References

  • [1] van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: a new paradigm for business process support. Data Knowl. Eng. 53(2), 129–162 (2005)
  • [2] Andrews, K., Steinau, S., Reichert, M.: Enabling process variants and versions in distributed object-aware process management systems. In: Proc. CAiSE Forum 2018. Lecture Notes in Business Information Processing, vol. 317, pp. 1–15. Springer (2018)
  • [3] Apel, S., Batory, D.S., Kästner, C., Saake, G.: Feature-Oriented Software Product Lines - Concepts and Implementation. Springer (2013)
  • [4] Apel, S., Kästner, C., Lengauer, C.: Language-independent and automated software composition: The featurehouse experience. IEEE Trans. Software Eng. 39(1), 63–79 (2013)
  • [5] Assy, N., Chan, N.N., Gaaloul, W.: An automated approach for assisting the design of configurable process models. IEEE Trans. Services Computing 8(6), 874–888 (2015)
  • [6] Batory, D.S., Sarvela, J.N., Rauschmayer, A.: Scaling step-wise refinement. IEEE Trans. Software Eng. 30(6), 355–371 (2004)
  • [7] Bhattacharya, K., Hull, R., Su, J.: A data-centric design methodology for business processes. In: Handbook of Research on Business Process Modeling, chapter 23. pp. 503–531 (2009)
  • [8] BizAgi and others: Case Management Model and Notation (CMMN), v1.1 (Dec 2016), OMG Document Number formal/16-12-01, Object Management Group
  • [9] Damaggio, E., Hull, R., Vaculín, R.: On the equivalence of incremental and fixpoint semantics for business artifacts with guard-stage-milestone lifecycles. Inf.Syst. 38, 561–584 (2013)
  • [10] Di Ciccio, C., Marrella, A., Russo, A.: Knowledge-intensive processes: Characteristics, requirements and analysis of contemporary approaches. J. Data Semantics 4(1), 29–57 (2015)
  • [11] Ekanayake, C.C., Rosa, M.L., ter Hofstede, A.H.M., Fauvet, M.: Fragment-based version management for repositories of business process models. In: On the Move to Meaningful Internet Systems: OTM 2011, Part I. Lecture Notes in Computer Science, vol. 7044, pp. 20–37. Springer (2011)
  • [12] Eshuis, R.: Feature-oriented composition of declarative artifact-centric process models. In: Weske, M., Montali, M., Weber, I., vom Brocke, J. (eds.) Proc. BPM 2018. Lecture Notes in Computer Science, vol. 11080, pp. 66–82. Springer (2018)
  • [13] Eshuis, R., Hull, R., Yi, M.: Reasoning about property preservation in Adaptive Case Management. ACM Trans. Internet Techn. 19(1), 12:1–12:21 (2019)
  • [14] Eshuis, R., Van Gorp, P.: Synthesizing data-centric models from business process models. Computing 98(4), 345–373 (2016)
  • [15] Fritz, C., Hull, R., Su, J.: Automatic construction of simple artifact-based business processes. In: Proc. ICDT. pp. 225–238 (2009)
  • [16] Hull, R., Damaggio, E., Fournier, F., Gupta, M., III, F.F.T.H., Hobson, S., Linehan, M.H., Maradugu, S., Nigam, A., Sukaviriya, P., Vaculin, R.: Introducing the Guard-Stage-Milestone Approach for Specifying Business Entity Lifecycles. In: Proc. WS-FM. pp. 1–24 (2010)
  • [17] Jansen-Vullers, M.H., van der Aalst, W.M.P., Rosemann, M.: Mining configurable enterprise information systems. Data Knowl. Eng. 56(3), 195–244 (2006)
  • [18] Künzle, V., Reichert, M.: Philharmonicflows: towards a framework for object-aware process management. Journal of Software Maintenance 23(4), 205–244 (2011)
  • [19]

    Li, C., Reichert, M., Wombacher, A.: Mining business process variants: Challenges, scenarios, algorithms. Data & Knowledge Engineering 70(5), 409–434 (May 2011)

  • [20] Linsbauer, L., Lopez-Herrejon, R.E., Egyed, A.: Variability extraction and modeling for product variants. Software and Systems Modeling 16(4), 1179–1199 (2017)
  • [21] Lohmann, N.: Compliance by design for artifact-centric business processes. Inf. Syst. 38(4), 606–618 (2013)
  • [22] Marin, M., Hull, R., Vaculín, R.: Data centric BPM and the emerging case management standard: A short survey. In: Business Process Management Workshops. pp. 24–30. Springer (2013)
  • [23] Martinez, J., Ziadi, T., Bissyandé, T.F., Klein, J., Traon, Y.L.: Automating the extraction of model-based software product lines from model variants (T). In: ASE 2015. pp. 396–406 (2015)
  • [24] Meyer, A., Herzberg, N., Puhlmann, F., Weske, M.: Implementation framework for production case management: Modeling and execution. In: Proc. EDOC 2014. pp. 190–199. IEEE Computer Society (2014)
  • [25] Mukkamala, R.R., Hildebrandt, T.T., Slaats, T.: Towards trustworthy adaptive case management with dynamic condition response graphs. In: Proc. EDOC 2013. pp. 127–136 (2013)
  • [26] Nigam, A., Caswell, N.S.: Business Artifacts: An Approach to Operational Specification. IBM Systems Journal 42(3) (2003)
  • [27] Popova, V., Fahland, D., Dumas, M.: Artifact lifecycle discovery. Int. J. Cooperative Inf. Syst. 24(1) (2015)
  • [28] Redding, G., Dumas, M., ter Hofstede, A.H.M., Iordachescu, A.: A flexible, object-centric approach for business process modelling. Service Oriented Computing and Applications 4(3), 191–201 (2010)
  • [29] Slaats, T., Mukkamala, R.R., Hildebrandt, T.T., Marquard, M.: Exformatics declarative case management workflows as DCR graphs. In: Proc. BPM 2013. pp. 339–354 (2013)
  • [30] Swenson, K.D.: Mastering the Unpredictable: How Adaptive Case Management will Revolutionize the Way that Knowledge Workers Get Things Done. Meghan-Kiffer, FL (2010)
  • [31] Weber, B., Reichert, M., Mendling, J., Reijers, H.A.: Refactoring large process model repositories. Comput. Ind. 62(5), 467–486 (2011)
  • [32] Yi, M.: Managing Business Process Variability in Artifact-centric BPM. Master’s thesis, Eindhoven University of Technology (2015)

Appendix

This appendix describes features extracted from the variant GSM schemas presented in chapter 5 of Yi [32]. The GSM schemas of Yi have been converted into the notation used in this paper. Each GSM schema models three interacting artifacts. To suit the single artifact framework used in the main text, we have converted the multi-artifact schemas of Yi into single-artifact schemas. Another change is that Yi models a base process that contains a GSM fragment that in one variant is replaced with another GSM fragment. To be able apply the feature extraction method, we have modeled a new base process that contains neither of these fragments. The new base process is refined by the old base process and all the variants.

Base schema

The (new) base schema concerns the process of due diligence qualification of business partners for an international hightech company that has international offices in different countries in Europe, Asia and America. The process starts when a due diligence qualification of a business partner has expired. To renew the qualification, first information needs to be collected about the partner such that the company has a sufficient level of information (milestone Confirmed). Next, based on the collected information, the due diligence qualification is checked. In some cases, mitigation actions need to be taken for the RequestForQuotes that the business partner can receive from the company. Finally, the due diligence qualification is signed off, resulting in either an approved or rejected status. An approved due diligence leads to an activated partner status, a rejected due diligence leads to an inactivated partner status.

Figure 6 shows the GSM schema and Table 5 and 6 the sentries of the stages and milestones, respectively.

Figure 6: Base GSM schema Due Diligence Process ()

Stage Plus sentries (guards) Minus sentries (closing) Drafting E:RegularDDQRenewal +Drafted CompanyConfirming +Drafted +Confirmed; +Drafting Refinement CompanyConfirming +RefinementVersionAchieved ; -CompanyConfirming DeskSearchScreening +Confirmed +MitigationActionNeeded;+Validated ProcessMitigatioAction +MitigationActionNeeded +Responded;-DeskSearchScreening RespondMitigationAction +ProcessMitigationAction +MitigationActionResponsed; -ProcessMitigationAction FillinRFQ MitigationActionNeeded ProcessMitigationAction +RFQassessed; +Respond MitigationAction; -ProcessMitigationAction SigningOff Responded; +Validated +Approved; +Rejected; +ProcessMitigation Authorizing +Approved;+Rejected +Activated; -Inactivated

Table 5: Stages and sentries for . “;" separates different sentries

Milestone Plus sentries (achieving) Minus sentries (invalidating) Drafted C:Drafting +Drafting RefinementVersionAchieved C:PhilipsRefinement CompanyConfirming +Refinement Confirmed +RefinementVersionAchieved +CompanyConfirming MitigationActionNeeded mitigation_needed +Validated; +DeskSearchScreening Validated mitigation_needed +MitigationActionNeeded; +DeskSearchScreening MitigationActionResponded C:RespondMitigationAction ProcessMitigationAction +FillinRFQ RFQassessed C:FillinRFQ ProcessMitigationAction +FillinRFQ Responded +RFQassessed +ProcessMitigationAction Approved signed_off +Rejected; +Signing off Rejected signed_off +Approved; +Signing off Activated partner_status_activated +Inactivated; +Authorizing Inactivated partner_status_activated +Activated; +Authorizing

Table 6: Milestones and sentries for .“;" separates different sentries

Variant 1

Variant specifies that a first verification check is performed before stage Refinement; see Table 7 for the new stages and milestones, plus the stages and milestones from the base schema whose sentries have been modified in this variant.

Type Name Plus sentries Minus sentries S FirstVerification +CompanyConfirming +Verified; -CompanyConfirming M Verified C:FirstVerification CompanyConfirming +FirstVerification S Refinement CompanyConfirming Verified +RefinementVersionAchieved ; -CompanyConfirming ; +FirstVerification

Table 7: New and modified sentries for variant . S=Stage; M=Milestone

Feature ; see Table 8.

Type Name Plus sentries Minus sentries S CompanyConfirming orig orig S FirstVerification +CompanyConfirming +Verified; -CompanyConfirming M Verified C:FirstVerification CompanyConfirming +FirstVerification S Refinement Verified orig orig; +FirstVerification

Table 8: Sentries for feature . S=Stage; M=Milestone

Variant 2

Variant specifies that a PreCheck and ExpertReview are performed before stage Refinement; see Table 9 for the new stages and milestones, plus the stages and milestones from the base schema whose sentries have been modified in this variant.

Type Name Plus sentries Minus sentries S PreCheck +CompanyConfirming +Checked; -CompanyConfirming S ExpertReview Checked CompanyConfirming +Reviewed; -CompanyConfirming M Checked C:PreCheck CompanyConfirming +PreCheck M Reviewed C:ExpertReview CompanyConfirming +ExpertReview S Refinement CompanyConfirming Reviewed +RefinementVersionAchieved ; -CompanyConfirming ; +PreCheck

Table 9: New and modified sentries for variant . S=Stage; M=Milestone

Feature ; see Table 10.

Type Name Plus sentries Minus sentries S CompanyConfirming orig orig S PreCheck +CompanyConfirming +Checked; -CompanyConfirming S ExpertReview Checked CompanyConfirming +Reviewed; -CompanyConfirming M Checked C:PreCheck CompanyConfirming +PreCheck M Reviewed C:ExpertReview CompanyConfirming +ExpertReview S Refinement Reviewed orig orig; +PreCheck

Table 10: Sentries for partial feature . S=Stage; M=Milestone

Variant 3

Variant specifies that for a new partner the completion of the profile triggers the due diligence qualification process; see Table 11 for the new stages and milestones, plus the stages and milestones from the base schema whose sentries have been modified in this variant.

Type Name Plus sentries Minus sentries S InitiatePartner E:NewPartnerRequest +ProfileCreated M ProfileCreated C:InitiatePartner +InitiatePartner S Drafting E:RegularDDQRenewal; ProfileCreated +Drafted

Table 11: New and modified sentries for variant . S=Stage; M=Milestone

Feature ; see Table 12.

Type Name Plus sentries Minus sentries S InitiatePartner E:NewPartnerRequest +ProfileCreated M ProfileCreated C:InitiatePartner +InitiatePartner S Drafting orig; ProfileCreated orig

Table 12: Sentries for partial feature . S=Stage; M=Milestone

Variant 4

Variant specifies that the due diligence process can be completed in a fast way; see Table 13 for the new stages and milestones, plus the stages and milestones from the base schema whose sentries have been modified in this variant.

Type Name Plus sentries Minus sentries S ConfirmNoScreening E:FastDDQRenewal +NoScreeningConfirmed M NoScreeningConfirmed no_screen_authorization no_screen_authorization; +ConfirmNoScreening S SigningOff Responded; +Validated; NoScreeningConfirmed +Approved; +Rejected; +ProcessMitigation

Table 13: New and modified sentries for variant . S=Stage; M=Milestone

Feature specifies that the due diligence process can be completed in a fast way; see Table 14.

Type Name Plus sentries Minus sentries S ConfirmNoScreening E:FastDDQRenewal +NoScreeningConfirmed M NoScreeningConfirmed no_screen_authorization no_screen_authorization; +ConfirmNoScreening S SigningOff orig; NoScreeningConfirmed orig

Table 14: Sentries for partial feature . S=Stage; M=Milestone