Modelling Business Process Variants using Graph Transformation Rules

Christine Natschl

ager

, Verena Geist

, Christa Illibauer

and Robert Hutter

Software Competence Center Hagenberg, Hagenberg, Austria

∗

Prologics IT GmbH, Linz, Austria

Keywords:

Business Process Management, Variability Modelling, Variant Management, Graph Transformation.

Abstract:

Business process variability is an active research area in the ﬁeld of business process management and deals

with variations and commonalities among processes of a given process family. Many theoretical approaches

have been suggested in the last years; however, practical implementations are rare and limited in their func-

tionality. In this paper, we propose a new approach for business process variability based on well-known graph

transformation techniques and with focus on practical aspects like deﬁnition of variation points, linking and

propagation of changes, as well as visual highlighting of differences in process variants. The suggested con-

cepts are discussed within a case study comprising two graph transformation systems for generating process

variants; one supports variability by restriction, the other supports variability by restriction and by extension.

Both graph transformation systems are proven to be globally deterministic, but differ regarding their complex-

ity. The overall approach is being implemented in the BPM suite of our partner company.

1 INTRODUCTION

Process variability is related to ﬂexible business pro-

cess management (BPM), one of the most active re-

search areas (Reichert and Weber, 2012). In de-

tail, process variability is concerned with design- and

customization-time decisions and deals with differ-

ences and commonalities among processes of a given

process family (Rosa et al., 2013). Typical ﬁelds of

application are, e.g., production processes, invoice

processes, and delivery processes.

There is a large number of theoretical approaches

to process variability, focusing on variability by re-

striction and/or by extension. However, many experi-

enced researchers assess the tool support for handling

process variants as limited and not adequate (Reichert

and Weber, 2012; Rosa et al., 2013). In addition,

exponential growth makes modelling and maintain-

ing process variants a complex endeavour in practice.

Thus, there is need for establishing a sound method

∗

The research reported in this paper has been partly

supported by the Austrian Ministry for Transport, Innova-

tion and Technology, the Federal Ministry of Science, Re-

search and Economy, and the Province of Upper Austria

in the frame of the COMET center SCCH. This publica-

tion has been written within the project AdaBPM (number

842437), which is funded by the Austrian Research Promo-

tion Agency (FFG).

for explicitly supporting variability in business pro-

cesses in a way that fosters industrial applicability.

In this paper, we propose a new concept for vari-

ant management based on graph transformation tech-

niques. Important aspects of this concept are the indi-

vidual deﬁnition of adaptable and blocked elements as

well as linking and propagation of changes. A further

advantage is the application of graph transformation

rules to deal with the exponentially increasing num-

ber of variants. Instead of manually deﬁning all vari-

ants, a few rules specify concrete variations and the

corresponding variants are automatically generated.

The paper is structured as follows. In Section 2,

we provide an overview of related work on graph

transformation, variability modelling, and tool sup-

port. We present the general approach for modelling

business process variants based on key requirements

in Section 3 and discuss the proposed concepts within

a case study using graph transformation techniques in

Section 4. In Section 5, we summarise our ﬁndings.

2 STATE-OF-THE-ART

This section provides an overview of the state-of-the-

art concerning graph transformation, variability mod-

elling, and the current support of business process

variability in BPM suites.

Natschläger, C., Geist, V., Illibauer, C. and Hutter, R.

Modelling Business Process Variants using Graph Transformation Rules.

DOI: 10.5220/0005665800650074

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 65-74

ISBN: 978-989-758-168-7

2.1 Graph Transformation

Research on graph transformations started around the

1970s; the main idea is the rule-based modiﬁcation of

a graph, where each application of a rule leads to a

graph transformation step. So the transformation of a

graph L (left-hand side) to a graph R (right-hand side)

is based on a rule r (also called production). Apply-

ing the rule r = (L, R) means ﬁnding a match of L in

the source graph and replacing L by R, leading to the

target graph of the graph transformation. The appli-

cation of rules is restricted by application conditions

(AC), which can either be positive or negative. A neg-

ative application condition (NAC) is satisﬁed if it is

not part of a match of L in graph G. A positive ap-

plication condition (PAC) is the counterpart to a NAC

and is satisﬁed if it is part of the match of L in G

(Ehrig et al., 2006, p. 5f, 67ff).

Different approaches for graph transformation

have been proposed like node label replacement,

hyperedge replacement, or the algebraic approach

(Ehrig et al., 2006, p. 10). The algebraic approach,

which was initiated by Ehrig, Pfender, and Schneider

in 1973, is applied for the suggested variability con-

cept. Algebraic graph transformation is supported by

a tool for attributed graph grammar systems (called

AGG). AGG provides a graphical editor and can be

used for specifying graph grammars with a start graph

or for typed attributed graph transformations. In ad-

dition, AGG offers analysis techniques as for consis-

tency checking, critical pair analysis, and termination

evaluation (Ehrig et al., 2006, chapter 15). In previous

work, AGG was applied to implement an algebraic

graph transformation from standard BPMN to Deon-

tic BPMN diagrams and to prove that this is a trusted

model transformation (Natschl

ager et al., 2015). In

Section 4, AGG is used to implement and evaluate

the suggested variability concept.

The algebraic approach to graph transformation

has been generalised to further graph types and high-

level structures such as typed graphs, labelled graphs,

hypergraphs, attributed graphs, and algebraic speci-

ﬁcations. This extension to high-level structures is

called high-level replacement (HLR) (Ehrig et al.,

2006, p. 14ff). The graph transformation for the pro-

posed variability concept is deﬁned as typed attributed

graph transformation system with inheritance that in-

cludes labels.

2.2 Variability Modelling

A survey on business process variability modelling

is provided in (Rosa et al., 2013). The authors dis-

tinguish three phases in the lifecycle of customiz-

able process models: design-time, customization-

time, and runtime. Variability is concerned with

design- and customization-time decisions and subdi-

vided into variability by restriction (i.e., customiz-

able model is the union or least common multiple

of all process variants) and variability by extension

(i.e., customizable model is the intersection or great-

est common denominator of all process variants). The

authors further argue that there is no explicit support

for representing and maintaining multiple variants of

a deﬁned business process in conventional business

process modelling languages. Available approaches

typically extend a modelling language with additional

constructs to capture customizable process models.

Variability by restriction is applied by so-called

conﬁgurable approaches. Conﬁgurable approaches

require a comprehensive reference model that com-

prises all possible process ﬂows and which is conﬁg-

ured at design-time to the required variants (see (Re-

ichert and Weber, 2012) for details). In (Aalst,

2013), twenty BPM use cases are suggested, three of

them relate to conﬁgurable process models: design

conﬁgurable model, merge models into conﬁgurable

model, and conﬁgure conﬁgurable model. Business

process modelling languages supporting the conﬁg-

urable approach are, for example, Conﬁgurable YAWL

(C-YAWL) and Conﬁgurable EPCs (C-EPCs). In

C-YAWL, hiding and blocking operations are applied

to the input and output ports of activities, so activ-

ities can either be hidden (skipped) or the trigger-

ing of the activity (and the subsequent path) is pre-

vented (blocked) (Gottschalk, 2009). C-EPCs, on the

other hand, provide conﬁgurable functions (may be

included, excluded, or conditionally skipped), con-

ﬁgurable connectors (can be mapped to more restric-

tive connectors), and conﬁgurable requirements and

guidelines (If-Then-statements to deﬁne dependencies

between conﬁgurable nodes) (Recker et al., 2006).

Conﬁgurable approaches are useful to adapt, e.g., a

domain-speciﬁc reference model to a concrete organ-

isation. However, the underlying modelling language

must be extended with conﬁgurable elements and the

reference model is extensive since it must comprise

all process ﬂows. Furthermore, local process variants

are restricted in their adaptability.

Adaptable Approaches, in contrast, only require

a base process model, which comprises the standard

process ﬂow and can be adapted through structural

model adaptations based on change patterns (vari-

ability by restriction and by extension). In (We-

ber et al., 2008), eighteen change patterns are sug-

gested and divided into adaptation patterns (e.g.,

add/delete/move/replace fragment) and patterns for

changes in predeﬁned regions to deal with uncer-

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

tainty. In addition, (Doehring et al., 2011) propose

a pattern catalogue with patterns for basic adapta-

tions, time adaptation and exception handling. The

adaptable approach is implemented, e.g., by Provop.

Provop is an approach for modelling and managing

process variants, covering the whole process lifecy-

cle. In the modelling phase, a base process is de-

ﬁned, comprising adjustment points to restrict the re-

gions to which adaptations may be applied. In ad-

dition, a set of reusable change operations is spec-

iﬁed, which can be grouped into so-called options.

Provop supports the following change patterns: in-

sert/delete/move fragment and modify attribute. In

the conﬁguration phase, the user selects a sequence of

options and applies them to the process to conﬁgure

the desired process variant. The conﬁguration may be

context-aware, meaning that the selection and appli-

cation of options is based on the context. The con-

text model then comprises a set of context variables

as well as restricting context constraints. Each con-

text variable speciﬁes one particular dimension, be-

ing visualised in a context cube in which every cell

represents a variant. In the execution phase, a conﬁg-

ured variant is transformed into an executable work-

ﬂow model and deployed to the runtime environment.

Runtime ﬂexibility is provided by the possibility to

dynamically switch execution between different pro-

cess variants. Finally, in the optimization phase, the

base process may be changed according to previous

adaptations, so that the process family evolves over

time (Hallerbach et al., 2009; Hallerbach et al., 2010).

The main similarity between the Provop approach

and our variability concept is that both approaches ap-

ply variability by restriction and by extension. Dif-

ferences concern the implementation of adaptations

(concept of change operations and options vs. graph

transformation techniques with formal foundation)

and the restriction of adaptations (adjustment points

vs. individual blocked/adaptable elements).

Summing up, none of the proposed conﬁgurable

or adaptable approaches ﬁts for our purpose. They

either introduce additional constructs to a modelling

language in order to support process variability, re-

quire extensive reference models, restrict adaptations,

or propose concepts without formal foundation.

2.3 Variability Modelling in BPM Suites

We studied the practical application by comparing in

detail six different BPM suites regarding their sup-

port for variability modelling and variant manage-

ment. The ﬁrst BPM suite is called Aeneis and, ac-

cording to its documentation, claims to support vari-

ant management (Aeneis, 2014). Variant management

is, however, implemented by a simple copy & paste

mechanism. The variant (i.e., copy of a process) can

be modiﬁed without restrictions, since elements are

by default not linked to corresponding elements of the

parent process. Links can be inserted manually, but

then all linked elements are identical and neither side

can be changed without propagation of the change to

the other element. Processes (and variants) can be

compared by a basic comparison tool that lists all el-

ements of each process without highlighting any dif-

ferences. So, in our opinion, Aeneis does not provide

actual variability modelling, but it offers some func-

tionalities required by a rudimentary variant manage-

ment system.

The BPM suite Signavio (Signavio, 2015) does

not mention the support of variant management in

its documentation but provides appropriate function-

ality. First of all, Signavio supports rudimentary vari-

ant management by copying processes and permitting

to adapt the copy (no linking). A graphical compar-

ison tool identiﬁes all changes between two process

models except swap operations. In addition, Signavio

supports stakeholder-speciﬁc views that resemble a

variant management with a reference model. After

having speciﬁed the overall process model (i.e., refer-

ence model), views are deﬁned by selecting and omit-

ting elements (variability by restriction). Only the set-

tings of a view are saved and the view is generated

whenever required. Graphical model comparison is

provided between the reference model and the view

highlighting all differences in the reference model.

Scheer Business Process as a Service (BPaaS)

(Scheer, 2015) offers a simple variant management

limited to variability by restriction with the Scheer

Process Tailor. A reference process is deﬁned and

variants are created by copying the reference process

and removing unnecessary activities. Thus, adapta-

tion of local variants is restricted to delete operations.

Three further BPM suites only support copy &

paste of a process model, which is insufﬁcient for

variant management. Bizagi with its products Mod-

eler, Studio, and Engine is a comprehensive BPM

suite, also including a simulation component but no

variant management (Bizagi, 2014). Axon IVY, based

on the eclipse platform, provides six modules for

modelling, publication, analysis, design, execution,

and monitoring but again variant management is miss-

ing (Axon IVY, 2015). Lastly, BPM suite FireStart

of our industrial partner (Prologics, 2014) currently

lacks support for variant management but is being ex-

tended with the suggested variability concept.

In addition, to the best of our knowledge, also

other well-known tools such as the MS Workﬂow

Manager, IBM Business Process Manager, jBPM,

Modelling Business Process Variants using Graph Transformation Rules

and the BPM suites by Bonitasoft, Camunda, Inubit,

TIBCO, K2, and Appian do not fulﬁll our require-

ments for variability modelling.

Summing up, although variability modelling and

variant management have been discussed in detail

from a theoretical perspective, practical applications

are very limited. Only two of the analysed BPM

suites (Signavio and Scheer BPaaS) support variabil-

ity by restriction and thus part of variant management.

Current implementations especially lack functionality

regarding connections between parent and child pro-

cesses (i.e., links), propagation of changes, and vi-

sual highlighting of differences. These issues are ad-

dressed by the following variability concept.

3 A CONCEPT FOR

VARIABILITY MODELLING

In this section, we present our concept for variabil-

ity modelling, which is called Adaptive Variant Mod-

elling (AdaVM) and part of the overall AdaBPM

framework for advanced adaptivity and exception

handling in formal business process models. The con-

cept of AdaVM is based on the following key require-

ments for business process variability of our part-

ner company Prologics, producer of the BPM suite

FireStart. The requirements stem from a comprehen-

sive BPM vendor survey (2014):

1. deﬁnition of a main process and corresponding

variants,

2. local adaptation/extension of variants,

3. visual highlighting of differences between main

process and variants, and

4. propagation of changes in main process to vari-

ants with notiﬁcation of responsible person.

So, at ﬁrst, the main process model (also called

base or default process model) is deﬁned like any

other process model, with two exceptions: The ﬁrst

exception is that AdaVM restricts variation points by

providing Boolean attributes to globally block insert

operations (to support variability by restriction) and

to locally block modify and delete operations of in-

dividual elements or attributes. Blocked elements or

attributes indicate parts common to all variants and

can neither be changed nor deleted. The second ex-

ception is that the main process model may not be

a semantically valid process variant. Five different

policies have been suggested in (Reichert and Weber,

2012, p. 104f) for specifying the main process model:

(1) reference process, (2) most frequently used pro-

cess, (3) minimum adaptation efforts, (4) superset of

all process variants, and (5) intersection of all process

variants. Only the ﬁrst and second policies represent

a particular variant and are directly executable. The

main process model of the fourth policy can only be

adapted by delete operations (conﬁgurable approach).

AdaVM does not prescribe a policy but it supports and

recommends to use both techniques, variability by re-

striction and by extension (adaptable approach) (see

discussion in Section 4).

In the following, we describe the general approach

of AdaVM for modelling business process variants.

A derived variant is at the beginning a duplication

of the main process model. Every element in the

variant is linked to the corresponding element in the

main process model, e.g., by the same ID or an ad-

ditional attribute specifying the ID of the parent el-

ement. Blocked elements are marked with a block

symbol and disabled (see Figure 1(a)), so that they

can neither be changed nor deleted. All unblocked el-

ements of the variant represent variation points and

can be adapted/extended by applying the following

change operations: insert, delete, and modify. Change

operation move suggested by Provop in (Hallerbach

et al., 2010) is substituted by deletion and insertion of

edges. Three symbols are introduced and correspond

to the three change operations. An inserted element

(node or edge) is marked with a plus symbol (see Fig-

ure 1(b)) and a modiﬁed element is marked with a

pencil symbol (see Figure 1(c)). A deleted element,

however, is usually removed from a process model,

thereby losing any graphical information about the

change. Thus, we decided to disable and grey-out

deleted elements and mark them with a cancel symbol

(see Figure 1(d)). Advantages of this approach are the

visibility of the change and the possibility to restore

a deleted element with its link to the corresponding

parent element. So the link to the corresponding ele-

ment is maintained even if one or more attributes are

changed or the whole element is deleted, only new el-

ements have no connection. An important aspect of

the suggested concept is that also edges are linked to

their parent edges. This provides the possibility to

identify moved (or swapped) elements, a change that

remains unrecognised by version comparison of many

well-known BPM suites (e.g., Signavio or Aeneis).

(a) Blocked (b) Added

Figure 1: Marked Elements.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

The number of variants derived from the main pro-

cess model is not restricted. In some cases, however,

a desired process variant has more similarities (and

dependencies) with an existing variant than with the

main process model. AdaVM addresses this issue by

supporting single inheritance between variants, i.e.,

a variant is derived from another variant. The re-

sult is a tree-structured hierarchy of variants with the

main process model as the root (see Figure 2). Inher-

ited elements of a derived variant are always linked

to the corresponding elements of its parent process

model (e.g., elements of variant V2.1 are linked to

elements of variant V2 which are in turn linked to

elements of main process model MPM). In addition,

every process model passes on all inherited blocking

constraints without modiﬁcation to its derived process

models and may add further restrictions. For example,

variant V2 inherits blocking constraints from the main

process model MPM and may deﬁne additional block-

ing constraints. All blocking constraints are passed

on to the derived variants, i.e. V2.1, V2.2 (and subse-

quently to V2.2.1).

Figure 2: Hierarchy of Main Process Model and Variants.

The last requirement addressed by AdaVM is the

propagation of changes in the main (or parent) pro-

cess to derived variants with notiﬁcation of the re-

sponsible person. Since variability is concerned with

design- and customization-time decisions, no runtime

adaptations are expected. The responsible person of

a derived variant is the process owner. The process

owner has the permission to create/modify the owned

process model and to read all parent and derived pro-

cesses. After every change in a process model (e.g.,

in the main process model MPM), all directly derived

variants (V1, V2, and V3) are searched for an ele-

ment that is linked to the concerned element. If such

an element exists, the process owner of the variant

is notiﬁed about the change and can either accept or

decline it. If the change is accepted, then the next hi-

erarchy level is investigated and further sub-variants

(V1.1, V1.2, V1.3 as well as V2.1, V2.2) are consid-

ered. The change is forwarded until either a process

owner declines the change, no corresponding element

is found, or the leaves of the hierarchy are reached.

Finally, AdaVM implements rule-based graph

transformation techniques to automatically generate

process variants. The main advantages of graph trans-

formation techniques are that context-speciﬁc vari-

ants are dynamically generated and that modiﬁca-

tions are not only deﬁned for one variant but used

to generate several process variants (i.e., only a few

graph transformation rules are required to produce a

large number of process variants). In AdaVM, the al-

gebraic graph transformation approach described in

Section 2.1 is applied. The algebraic approach sup-

ports the above deﬁned change patterns: an element is

inserted if it is only part of R (right-hand side), an el-

ement is deleted if it is only part of L (left-hand side),

and an element is modiﬁed if it is part of L and R but

the values of one or more attributes differ. A graph

transformation system can then either support vari-

ability by restriction (conﬁgurable approach) or vari-

ability by restriction and by extension (adaptable ap-

proach). A comparison of two graph transformation

systems implementing these techniques is provided in

the following section.

4 GRAPH TRANSFORMATION

In this section, the concepts of AdaVM are discussed

within a case study. The case study comprises a busi-

ness process for car services with various variants

for different engine types (i.e., fuel, diesel, electro)

and a distinction between basic (i.e., small) and ex-

tended (i.e., large) services. All variants are gener-

ated by applying algebraic graph transformation. An

advantage of graph transformation is the possibility

to deal with the exponentially increasing number of

variants with a linearly increasing number of graph

transformation rules, e.g., four activities each with

four variations may lead to 256 variants, which can

either be deﬁned manually or automatically gener-

ated by 16 graph transformation rules (in ideal case).

To compare the conﬁgurable with the adaptable ap-

proach, two graph transformation systems have been

implemented in the tool AGG. The ﬁrst graph trans-

formation system is called RM GT S, since the source

graph deﬁnes a comprehensive reference model (RM)

that comprises all possible process ﬂows. The sec-

ond graph transformation system is called V M GT S,

since the source graph comprises the main (or default)

variant model (V M). For demonstration and evalua-

tion purposes, the two graph transformation systems

implement a subset of the AdaVM concepts (i.e., they

Modelling Business Process Variants using Graph Transformation Rules

Figure 3: Type Graph of RM GT S.

address the ﬁrst and second requirement without links

and blocking). The full approach is currently imple-

mented in the BPM suite FireStart. Both graph trans-

formation systems prove the feasibility of the sug-

gested concepts but show differences regarding the

complexity.

The type graph of RM GT S is shown in Figure 3.

RM GT S requires abstract nodes and inheritance re-

lations within the type graph, so an attributed type

graph with inheritance is deﬁned. The type graph

provides four abstract node types (Node, Activity,

Gateway, and Event) as highlighted by curly brack-

ets and italic font. Derived from node type Activ-

ity are all possible tasks of a car service (e.g., Oil-

change, Oil-ﬁlter-change, etc.). Abstract node type

Event is the parent of two concrete node types for

Start and End events, and node type Sequence is used

as ’dummy’ element to remove several subsequent

activities. Derived from exclusive gateways without

condition (ExclGate) and with condition (ExclGate-

Cond) are variant-speciﬁc exclusive gateways check-

ing whether diesel, electro, or large service is desired

(i.e., conﬁgurable elements). One further node type is

called Variables and used to store information regard-

ing the desired variant including attributes for engine

type and whether it should be a small or large service.

Finally, the type graph provides an edge label called

SF for general sequence ﬂows and two further edge

labels SF Yes and SF No applied only after splitting

exclusive gateways. The type graph of V M GT S is

similar, but node types Sequence, ExclGate isDiesel,

ExclGate isElectro, and ExclGate isLarge are not re-

quired and omitted.

An example source graph of RM GT S is shown in

Figure 4. The process ﬂows of all possible variants

are provided within one reference model and variant-

speciﬁc gateways are used to specify differences. The

desired variant is deﬁned by element Variables (vari-

ant: large service for car with electro engine).

For transformation of a source to a target graph,

30 graph transformation rules with corresponding ap-

plication conditions have been deﬁned in RM GT S.

Six of these rules are general and consider conditional

exclusive gateways. In addition, eight concrete rules

have been deﬁned for each variant-speciﬁc gateway

(diesel, electro, large). The aim of these transforma-

tion rules is to generate the desired variant and to re-

move variant-speciﬁc gateways. The rule in Figure 5,

e.g., realises a large service by taking over the activity

from the Yes-Path and by removing the No-Path and

the surrounding gateways. A positive application con-

dition ensures that the rule is only applied if a variant

with a large service should be generated.

The resulting target graph after having ap-

plied all possible transformation rules is shown in

Figure 6. The transformation has replaced all

fuel- and diesel-speciﬁc activities with the activity

Check accumulator for electro engines. In addition,

activity Gear-maintenance for a large service was

included in the variant. Note that the other exclu-

sive gateway for large service was removed, since

Toothed-belt-maintenance and Air-ﬁlter-maintenance

are only relevant for fuel and diesel engines. In sum,

six variants can be automatically generated by chang-

ing the attribute values in the Variables element.

The second graph transformation starts with a de-

fault variant model and uses variability by restric-

tion and by extension to automatically generate fur-

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

Figure 4: Source Graph of RM GT S.

ther variants. An example source graph of V M GT S

is shown in Figure 7 and describes the default variant

for fuel engine and small service. An advantage of the

adaptable approach is that the source graph may al-

ready provide an executable variant. The Variables el-

ement again deﬁnes the desired variant (variant: large

service for car with electro engine).

For transformation of a source graph to all pos-

sible variants, only four graph transformation rules

with application conditions have been deﬁned in

V M GT S. Each transformation rule actually corre-

sponds to one variant-speciﬁc gateway in the refer-

ence model of RM GT S. The graph transformation

rule shown in Figure 8, for example, inserts activity

Gear-maintenance in case of a large service (PAC) if

it has not yet been inserted (NAC). The application of

all possible transformation rules results in the same

target graph as shown in Figure 6.

The presented graph transformations are restricted

to structured diagrams (i.e., gateways are deﬁned in

a bracket structure) and a basic set of process mod-

elling elements. However, further modelling elements

like sub-processes, additional events, or gateways are

only relevant for the business process and may appear

in process variants, but their inﬂuence on variant gen-

eration is limited. For a more detailed discussion on

conﬁgurable nodes and their inﬂuence see (Reichert

and Weber, 2012, p. 96ff).

According to Varr

o et al., the most important cor-

rectness properties of a trusted model transforma-

tion are termination, uniqueness (conﬂuence), and be-

haviour preservation (Varr

o et al., 2006). Behaviour

preservation is not the aim of RM GT S and V M GT S,

since different variants with different behaviour are

generated. Thus, validation of the proposed graph

transformation systems is accomplished by proving

conﬂuence and termination. These two properties en-

sure that the resulting graph is always the same, in-

dependent of the order of applied rules, and that rules

are not cyclic.

In order to prove conﬂuence, it is either necessary

to show that each rule pair is parallel independent for

all possible matches or, in case of parallel dependent

rules, that the GTS is terminating and locally conﬂu-

ent. A GTS is locally conﬂuent if all its critical pairs

(parallel dependent and minimal) are strictly conﬂu-

ent (Ehrig et al., 2006, p. 59ff, 144). RM GT S is

terminating, since all transformation rules delete el-

ements like gateways or activities. Only node type

Sequence is inserted by some rules but subsequently

removed by general rules. The full termination proof

comprising calculated rule, creation, and deletion lay-

ers is not presented due to space limitations. Further-

more, all critical pairs of RM GT S are of the same

rule and same match and, thus, isomorphic. Hence,

RM GT S is locally conﬂuent and terminating, so the

whole graph transformation is conﬂuent. The criti-

cal pairs of V M

GT S comprise different rules, but

strict AC-conﬂuence could be proven for each pair.

A more challenging task was to prove termination of

V M GT S, since all transformation rules insert new

Modelling Business Process Variants using Graph Transformation Rules

(a) PAC (b) LHS (c) RHS

Figure 5: Transformation Rule of RM GT S.

Figure 6: Target Graph [Variant: Electro, Large Service].

node and edge types. Termination is ensured by neg-

ative application conditions (NAC: NotYetInserted).

However, since sequence ﬂows are deleted in every

rule, all rules are automatically classiﬁed as deletion

layers, thereby ignoring the NACs. Thus, we pro-

pose to extend the deletion layer conditions presented

in (Ehrig et al., 2006, p. 31) to also consider NACs.

We further ﬂattened the hierarchy of V M GT S with

the ﬂattening algorithm presented in (Natschl

ager and

Schewe, 2012) to 598 rules without inheritance rela-

tionships and proved termination for all node types.

Summing up, both graph transformation systems are

conﬂuent and, thus, globally deterministic.

We then compared the graph transformation sys-

tems RM

GT S and V M GT S regarding their com-

plexity. Complexity is assessed by the number of

nodes in the type and source graphs as well as by the

amount of transformation rules and application con-

ditions. The complexity of RM GT S and V M GT S

is shown in Figure 9. Interestingly, V M GT S is less

Figure 7: Source Graph of VM GT S.

(a) PAC (b) NAC

(d) RHS

Figure 8: Transformation Rule of V M GT S.

extensive in all measured aspects and, thus, also less

complex. The reason is that the rules of V M GT S

are more speciﬁc and explicitly deﬁne concrete ac-

tivities, e.g. Gear-maintenance, whereas the rules of

RM GT S use abstract node type Activity to represent

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

all possible concrete activities. Thus, an extension

of the process with a new variation would require an

adaptation of (every) reference model in RM GT S. In

contrast, V M GT S would either require an extension

of the default variant or (more likely) a new/extended

transformation rule. So, due to the differences in re-

quired adaptations, assessing the complexity of future

extensions is difﬁcult. However, it can be assumed

that further extensions mainly increase the complex-

ity of source graphs of RM GT S and the amount of

rules and application conditions of V M GT S.

Figure 9: Complexity of RM GT S and V M GT S.

Summing up, we showed that graph transforma-

tion techniques are well-suited for variant manage-

ment. We, therefore, implemented two graph trans-

formation systems for generating process variants;

one supporting only variability by restriction, the

other supporting variability by restriction and by ex-

tension. Both graph transformation systems were

proven to be globally deterministic. Interestingly, the

adaptable approach was easier to implement (as it is

more speciﬁc) and it is less complex regarding the

type graph, source graphs, and the amount of rules

and application conditions. Thus, we recommend to

apply both techniques, variability by restriction and

by extension, for generating process variants. Other

concepts of AdaVM (e.g., linking, propagation of

changes, and visual highlighting of differences) do

not require veriﬁcation and will be directly imple-

mented in BPM suite FireStart.

5 CONCLUSION

In this paper, we presented our concept for Adap-

tive Variant Modelling (AdaVM) as part of the Ada-

BPM framework for advanced adaptivity and excep-

tion handling in formal business process models. The

suggested approach requires fewer modiﬁcations of

the underlying notation, i.e., no conﬁgurable elements

or adjustment points are required, only an individ-

ual blocking of elements is proposed. In addition,

AdaVM considers linking of elements, propagation

of changes, and visual highlighting of differences in

process variants.

We further demonstrated that graph transforma-

tion techniques are well-suited for process variant

management and that variants can be automatically

created by a few graph transformation rules speci-

fying concrete variations. For that purpose, we pro-

vided a case study implementing two graph transfor-

mation systems; one supports variability by restric-

tion, the other supports variability by restriction and

by extension. The ﬁrst system follows the conﬁg-

urable approach by deﬁning the source graph as an

extensive basic model, which comprises all possible

process ﬂows and can be conﬁgured to create vari-

ants. The second system follows the adaptable ap-

proach and the source graph comprises the main (de-

fault) variant model, which can be adapted by struc-

tural model adaptations to obtain new variants. We

proved both systems to be globally deterministic but

encountered differences regarding the complexity of

the graph transformation systems. Interestingly, the

case study reveals that the adaptable approach is less

complex regarding the type graph, source graphs, and

the number of rules and application conditions. Thus,

we intend to apply both techniques, variability by re-

striction and by extension, in AdaVM. Nevertheless,

our next step is to extend the case study to elaborately

evaluate the complexity of conﬁgurable and adaptable

approaches.

Summing up, the key differences of the proposed

concept for variability modelling, compared to other

state-of-the-art approaches, are (i) the support of vari-

ability by restriction and by extension with graph

transformation techniques, (ii) linking and propa-

gation of changes, (iii) individual blocking of ele-

ments/attributes, and (iv) visual highlighting of dif-

ferences in process variants. We, thus, expect that

the variant management implemented by BPM suite

FireStart outperforms other applications with respect

to functionality and usability.

REFERENCES

Aalst, W. v. d. (2013). Business process management: A

comprehensive survey. ISRN Software Engineering,

2013:1–37.

Aeneis (2014). aeneis Handbuch. intellior AG, aeneis 5.7

edition.

Axon IVY (2015). Axon.ivy 5.1 - Designer Guide. ivyTeam

AG.

Bizagi (2014). Bizagi BPM Suite - User Guide. Bizagi.

Doehring, M., Zimmermann, B., and Karg, L. (2011). Flex-

ible workﬂows at design- and runtime using BPMN2

Modelling Business Process Variants using Graph Transformation Rules

adaptation patterns. In Abramowicz, W., editor, Busi-

ness Information Systems, volume 87 of LNBIP, pages

25–36. Springer Berlin Heidelberg.

Ehrig, H., Ehrig, K., Prange, U., and Taentzer, G. (2006).

Fundamentals of Algebraic Graph Transformation.

Springer.

Gottschalk, F. (2009). Conﬁgurable Process Models. PhD

thesis, Technische Universiteit Eindhoven.

Hallerbach, A., Bauer, T., and Reichert, M. (2009). Guar-

anteeing soundness of conﬁgurable process variants in

provop. In IEEE Conference on Commerce and Enter-

prise Computing (CEC), pages 98–105.

Hallerbach, A., Bauer, T., and Reichert, M. (2010). Captur-

ing variability in business process models: The provop

approach. Journal of Software Maintenance and Evo-

lution: Research and Practice, 22:519–546.

Natschl

ager, C., Kossak, F., and Schewe, K.-D. (2015). De-

ontic BPMN: a powerful extension of BPMN with a

trusted model transformation. Software & Systems

Modeling, 14(2):765–793.

Natschl

ager, C. and Schewe, K.-D. (2012). A ﬂattening ap-

proach for attributed type graphs with inheritance in

algebraic graph transformation. Electronic Communi-

cations of the EASST, 47.

Prologics (2014). FireStart Tutorial - Modellierung &

Ausf

uhrung. Prologics.

Recker, J., Rosemann, M., van der Aalst, W., Jansen-

Vullers, M., and Dreiling, A. (2006). Conﬁgurable

reference modeling languages. In Fettke, P. and Loos,

P., editors, Reference Modeling for Business Systems

Analysis, pages 22–46. IGI Global, Pennsylvania.

Reichert, M. and Weber, B. (2012). Enabling Flexibility

in Process-Aware Information Systems: Challenges,

Methods, Technologies. Springer-Verlag Berlin Hei-

delberg.

Rosa, M. L., van der Aalst, W., Dumas, M., and Milani,

F. (2013). Business process variability modeling: A

survey. Technical report, Queensland University of

Technology.

Scheer (2015). Scheer BPaaS. Scheer.

Signavio (2015). Benutzerhandbuch. Signavio.

Varr

o, D., Varr

o-Gyapay, S., Ehrig, H., Prange, U., and

Taentzer, G. (2006). Termination analysis of model

transformations by Petri nets. In Corradini, A., Ehrig,

H., Montanari, U., Ribeiro, L., and Rozenberg, G., ed-

itors, Graph Transformations, volume 4178 of Lecture

Notes in Computer Science, pages 260–274. Springer

Berlin / Heidelberg.

Weber, B., Reichert, M., and Rinderle-Ma, S. (2008).

Change patterns and change support features - enhanc-

ing ﬂexibility in process-aware information systems.

Data and Knowledge Engineering, 66(3):438–466.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development