Decision Model and Notation for Describing Variability in Business

Process Product Lines

Andreas Speck, Aljoscha Jagenow and Melanie Windrich

Institute of Computer Science, Christian-Albrechts-University, Kiel, Germany

Keywords:

Decision Model and Notation, Modeling Variability, Software Product Lines for Business Process Models.

Abstract:

Product line techniques have proven being a successful concept of software reuse. Hence, product line tech-

niques have been applied for business process models. Although there are well established models for de-

scribing business processes such as BPMN or ARIS there is a lack of describing the variability in business

processes.

In the paper, we propose to apply Decision Model and Notation (DMN) for modeling process variability. DMN

has the advantage that it is a known concept and well understood. DMN supports the decision techniques by

deﬁning the variability in business processes and with the rules deﬁning the variability.

1 INTRODUCTION

Software product lines support the reuse of software

components on a large scale. Software systems are

considered as set of reusable assets with speciﬁc rela-

tions among them. The conﬁguration of the assets is

variable. The variability of assets in software product

lines is an important issue in modeling. This requires

a comprehensive notation. (Svahnberg et al., 2001)

presents aspects of features and their modeling.

Based on the successful early approach, the com-

bination of software product lines and business pro-

cesses was discussed. Business processes are key el-

ements in deﬁning and describing the sequences of

activities / workﬂows mainly in a commercial or ad-

ministration context. Such software systems like en-

terprise resource planning (ERP), e-commerce or ad-

ministrative systems are the organizational backbone

of most businesses or administrative units. Business

process models are used to deﬁne the behavior of such

systems (dos Santos Rocha et al., 2015). Due to the

high importance of business process model systems it

is very desirable to ﬁnd techniques making such sys-

tems more reusable like the product line concepts.

A summary and survey about approaches combin-

ing business process models and product lines may

be found in (dos Santos Rocha and Fantinato, 2013).

A conclusion of this review is that the approaches of

applying software product line techniques to business

process models is very promising. However, there is

further need for improvement. A speciﬁc weak point

is the modeling of the variability in business process

models. This need of improved modeling of variabil-

ity is pointed out in more recent surveys like (La Rosa

et al., 2017) and (Pol’la et al., 2020). This demands

a modeling concept for variability in business pro-

cesses.

In the paper, we focus on modeling variability in

business process product lines. We propose to use al-

ready existing and established model types for vari-

ability modeling. An analogous approach proven al-

ready as successful in product line modeling in which

UML models are using UML stereotypes (La Rosa

et al., 2017). First approaches introducing stereotypes

are for instance (Clauß, 2001) or (Speck et al., 2002).

In this paper, we propose to use BPMN (Business Pro-

cess Model and Notation) as a basic notation for de-

scribing the processes which are the invariant parts of

the product lines. This is an attempt taken by a num-

ber of approaches applying product line techniques to

business processes (La Rosa et al., 2017; Pol’la et al.,

2020).

For describing variability in business process

models we propose to look on Decision Model and

Notation (DMN). As a tool, we use the CAMUNDA

modeler. However, our approach is independent from

a speciﬁc tool.

In this paper, we ﬁrst introduce the background of

business process models, product line modeling and

DMN. Then we show how business process variabil-

ity may be modeled by DMN which is followed by an

example in the domain of e-commerce systems which

Speck, A., Jagenow, A. and Windrich, M.

Decision Model and Notation for Describing Variability in Business Process Product Lines.

DOI: 10.5220/0010497204450452

In Proceedings of the 16th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2021), pages 445-452

ISBN: 978-989-758-508-1

445

Figure 1: FODA Product Line Model for an Order Process.

demonstrates how to apply this approach.

2 BASIC CONCEPTS OF

PRODUCT LINES AND

BUSINESS PROCESS MODELS

At ﬁrst, we have a look how variability is modeled

in product line systems. The we present the elements

of the Business Process and Model Notation (BPMN)

used in the paper and introduce then the Decision

Model and Notation (DMN).

2.1 Variability in Product Lines

The Feature-Oriented Domain Analysis (FODA)

(Kang et al., 1990) is a valid model for describing

dependencies between features and feature variabil-

ity. An example of a FODA model representing an

order process in an e-commerce system is depicted

in Figure 1. FODA models arrange the features in

tree structure (in our example Approval, Transaction

and Fulﬁllment are child features of the Order Pro-

cess). There are three different types of dependencies

between the parent feature and its child features (or

sub-features):

• The mandatory dependency requires a child fea-

ture.

• A child feature may be optional.

• Alternative dependencies requires the selection of

one of the child features.

However, systems may rarely be modeled in a pure

tree structure. In most cases the systems are orga-

nized in a net structure. The cross tree constraints

(REQUIRES and MUTEX ) of FODA express rela-

tions between the features in different branches. Two

of these cross tree constrains in the example are:

• shipping cost requires shipping and

• pay on delivery and electronic delivery are mutu-

ally excluded.

2.2 Business Process and Model

Notation

The Business Process Model and Notation (BPMN)

supports the graphical modeling of business pro-

cesses. The main elements comprise tasks (repre-

senting the basic functionality of the process), work-

ﬂow objects (ﬂow objects such as different gateway

types or events or connection objects representing

the sequence ﬂow). Pools and swim lanes orga-

nize and identify major participants. Further artifacts

are data objects or annotations. A pure example of

a BPMN diagram with some important BPMN ele-

ments is shown in Figure 2 (left side). The tool used

to model this diagram is Camunda. (BPMN, 2021a)

is a Camunda BPMN documentation.

The BPMN diagram (on the left side of Figure 2)

shows a business process model which may serve as

a base for product lines. The basic mechanisms to

realize variability in process models are the attach-

ment or detachment of sequences to the process mod-

els (Sinnhofer et al., 2015; La Rosa et al., 2017). This

means that the paths in the process model may be ex-

tended or shortened. BPMN supports the modeling

of variability. Branching operators of the gateways

such as parallel and exclusive may be sufﬁcient for

describing options and alternatives in a process model

which are important for product lines concepts. How-

ever, purely using these operators will hamper the

ease of understanding business process product line

model and will lead to confusion. The question is now

how to express the variability beyond the pure usage

of gateways as branching operators. The description

of variability need to be separated from the process

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

446

Figure 2: Exemplary BPMN process model (left) and DMN decision requirement diagram on the right.

models.

2.3 Decision Model and Notation

Decision Model and Notation (DMN) (OMG, 2021;

BPMN, 2021b) supports modeling variabilities and

decisions to be taken. There are diagrams, tables and

and the expression language (Friendly Enough Ex-

pression Language, FEEL). The decision diagram or

to be more precise decision requirements diagrams is

at the right side of Figure 2:

• Decisions: several inputs (like input data or the

knowledge) determine an output of the decision.

Tables may be used to describe the decision logic.

• Input data: Information necessary determining a

decision.

• Knowledge Model : decision logic which may be

reused. The decisions based on the same knowl-

edge model may lead to different results depend-

ing on inputs or sub-decisions.

• Knowledge Source: Authorities, committees, reg-

ulations or policies which inﬂuence the knowl-

edge model.

The decisions may be hierarchical. The dependencies

are represented by the directed edges.

The decision tables describe the logic of the de-

cision. The rules are expressed by the rows. The el-

ements of the rules (input and output) are kept in the

columns. The input and output within a rule are con-

nected. The decision tables are attached to the deci-

sions in the DRDs (decision requirements diagram).

Figure 5 in the application example (Section 4) shows

a decision table. The decisions are attached to the

business process models and the decisions represent

the behavior at the gateways.

In modeling the knowledge of the decisions is sep-

arated in the DMN and not kept directly in the busi-

ness process models.

3 VARIABILITY DEFINITION BY

DECISION MANAGEMENT

NOTATION

There are three elements for describing the variabil-

ity in business process models by DMN: decision re-

quirement diagrams (DRD), decision tables and the

variability in business process models itself.

The decisions in the DRD (introduced in previous

Section 2.3) may describe the variability in the pro-

cess. Like the FODA models it is suitable for arrang-

ing the decision requirement diagrams in a tree struc-

ture. This supports a hierarchical structure of variants

(or decisions) in which decisions may be composed to

form underlaying sub-decisions. In contrast to FODA

the DRD do not support the differentiation of types of

dependencies between parent and child features (or

decision and sub-decision). This may be solved by

the decision table. The DRD gives hints about the

motivation for the decisions:

• Knowledge models represent the decision logic.

• Knowledge sources are origins of knowledge

models. These may be authorities or regulations.

• Input data may directly drive the decisions.

The cross-tree dependencies are mutex and re-

quires. Requires requests a speciﬁc output. Mutex

may be expressed by a combination of input and falsi-

ﬁcation of the output value. Similarly alternative and

optional rules may be expressed by the combination

of rows in the tables.

The activation of the rules is determined by the

Hit Policy: The policy Unique (used in our example

in Figure 5) means that only one rule matches. The

policy ﬁrst means that the ﬁrst rule is applied. Exam-

ples for further rules are any, rule orders, output order

or different types of rule collection. Examples of the

usage of rules with decision tables may be found in

documentations like (BPMN, 2021b; OMG, 2021).

Decision Model and Notation for Describing Variability in Business Process Product Lines

447

Order Process

choose

Payment

Method

Service Delivery

chosen

Electronic

Delivery chosen

Shipping chosen

Order Process

Initiated

choose

Fulfillment

Method

Order Process

successful

Approval

Payment

Order Process

completed

Pay by Bank

Transfer chosen

Pay by Credit

chosen

Pay by Delivery

chosen

Pay by Bill chosen

Service Delivery

Conditions

Shipping Data

e.g. Shipping Cost

Calculate Price

Get Price from

Price List

Service Delivery

chosen

Electronic

Delivery chosen

Shipping

chosen

Taxation

Add Shipping

Cost

Payment Fees

Pay by Credit

chosen

Add Credit Card

Fees

Add Pay by

Delivery Fees

Pay by Delivery

chosen

Pay by Bank

Transfer chosen

Pay by Bill chosen

Discount

approved

not approved

Decission for

Electronic

Delivery

Payment Method

Pay by Bank

Transfer

Pay by Credit

Card

Pay by Bank

Transfer chosen

Payment

Pay by Delivery

chosen

Fulfillment

Payment on

Delivery

Payment by Bill

Pay by Bill failed

Order Process

successful

Fulfillment

successful

Fulfillment Method

Pay by Bill chosen

Payment

successful

Pay by Delivery

chosen

Fulfillment

successful

Fulfillment

Shipping

Electronic

Download

Service Delivery

Shipping Data

e.g. Shipping Cost

Service Delivery

Conditions

Credit Card

Payment failed

Pay by Delivery

failed

Pay By Bank

Transfer failed

Decission for

Shipping

Decission for

Service Delivery

Pay by Bill chosen

already

payed

Approval

"false"

Taxation

"true"

Taxation

"false"

Discount

"false"

Discount

"true"

Approval

"true"

Shipping

Cost

"true"

Pay by

Bank

Transfer

"true"

Pay by Credit

Card chosen

Pay by

Credit

Card

"true"

Pay by Delivery

chosen

Pay on

Delivery

"true"

Pay

by Bill

chosen

Pay by

Bill

"true"

Shipping

Service

Delivery

Shipping

"true"

Electronic

Delivery

Electronic

Download

"true"

Service

Delivery

"true"

Figure 3: Example: BPMN Order Process Model.

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

448

4 EXAMPLE FOR APPLYING

DMN

The order process in e-commerce systems serves as

example in the paper. We already introduced this pro-

cess in Section 2) as example for the FODA variabil-

ity model (c.f. Figure 1). We now focus on the dy-

namic behavior modeled as a process. For compari-

son we use the similar functionality as in the FODA

example.

The example consists of a decision requirements

diagram (DRD), an exemplary decision table that are

separated from the BPMN process model in which the

decisions deﬁne the variability.

4.1 BPMN of the Order Process

The decisions presented in the subsequent subsections

affect the BPMN process. In the process these deci-

sions are taken and evaluated according to the rules in

the decision tables.

The Order Process BPMN is shown in Figure 3.

All branches with positive decisions are marked by

‘‘true’’.

The decision about the fulﬁllment method and the

payment method are made at the beginning of the pro-

cess. Each of these decisions result in events thrown

representing the respective decisions.

The Calculate Price sub-process ﬁrst looks up the

concrete price in the Price List. This task is the only

mandatory task in the entire sub-process. The tasks

Taxation and Discount are based on the sub-decisions

respectively and use the decision tables receiving in-

put form their knowledge models. The Payment Fees

sub-process and the potential adding of Shipping Cost

are based on the events thrown by the tasks in which

these methods are chosen.

All the previously mentioned tasks are part of the

Order Process pool. The participants of this pool

take care of the order process. However, there are

other participants caring about the payment and the

fulﬁllment. In e-commerce systems payment and ful-

ﬁllment services are performed by speciﬁc systems

called when required. Hence, these functionalities

are modeled in separate pools. The communication

between the processes is realized by signal events in-

stead of message events for a better overview since the

explicit connecting edges are not required (BPMN,

2021a).

The Payment Method process is divided in two

parts in between which the Fulﬁllment Method is pro-

cessed, since there is the possibility to pay before or

after the fulﬁllment. All the tasks in the Payment

Method and Fulﬁllment Method pools are depending

on the events thrown at the beginning of the Order

Process. The payment attempts may fail which is

considered. However, the concrete effects of a failed

payment are not modeled in this example. The de-

cision table for the Payment Method is described in

Section 4.3

4.2 DRD Example

The Order Process Product Line DRD in Figure 4

is considered as a decision which consists of the sub-

decisions Aproval, Calculate Price, Payment Method

and Fulﬁllment Method.

The (sub-)decision Approval is driven by the Com-

pliance Rules for Approval as business knowledge

which is imposed by the knowledge source of the

Compliance Rules Team which may be the legal ad-

visors of the company.

The (sub-)decision Calculate Price depends on

the rules of the Price List knowledge model. The sub-

decisions are Taxation, Discount , Payment Fees and

Shipping Cost. Taxation is driven by the knowledge

model Taxation Rules which are based on the source

of Legal Taxation Regulations. An example of such

a rule may be that for purchases from certain other

countries no value-added tax has to be withheld. If a

Discount is realized depends on the rule in the Dis-

count Decision Table. Two different types of fees –

Credit Card Fees and Pay on Delivery Fees – deter-

mine the Payment Fees decision. The Credit Card

Fees and Pay on Delivery Fees also have an impact on

the sub-decisions Pay by Credit Card or Pay on De-

livery as part of the Payment Method (sub-)decision.

The sub-division of Shipping Cost requires Shipping.

The (sub-)decision Payment Method uses one con-

crete kind of payment. The alternatives are the sub-

decisions Pay by Bank Transfer, Pay by Bank Credit

Card, Pay on Delivery and Pay by Bill. The concrete

realization of one of these sub-decisions is driven by

the input data Choose Payment Method. Pay on De-

livery interacts with Electronic Delivery. This mutual

exclusion is expressed explicitly in the decision table.

The sub-decisions Service Delivery, Electronic

Delivery and Shipping form the Fulﬁllment Method

(sub-)decision.

4.3 Exemplary Decision Table

We take the Payment Method decision table as de-

picted in Figure 5. This decision table is directly afﬁl-

The ﬁgure is not a screenshot of CAMUNDA but re-

drawn for better visibility. The DRD model of Camunda is

rather voluminous.

Decision Model and Notation for Describing Variability in Business Process Product Lines

449

Figure 4: Decision Requirements Diagram (DRD) for the Order Process Model.

iated to the Payment Method decision and deﬁnes the

decisions.

The table consists of four rules, each in a row. All

rules depend on the input of the Payment Method cho-

sen. These are the already presented Pay by Bank

Transfer, Pay by Credit Card, Pay on Delivery and

Pay by Bill. These will result in the corresponding

events with similar names, Payment Fees when there

are such fees and a determination of the Fulﬁllment

Method. In case of Pay on Delivery there is only Ship-

ping permitted.

Such decision tables may exist for the other

(sub-) decisions like Calculate Price and Fulﬁllment

Method. Since the rules in these tables will be in gen-

eral similar, we do not present them.

5 RELATED WORK

In general the concept of reuse is to some extend sup-

ported by business process models, however, reuse is

not the main focus. Reuse has been considered in

reusing certain functions (Becker et al., 2000). Com-

plex systems like product lines have not been consid-

ered.

With the orchestration of web services the reuse

on a large scale emerged. Not only single services are

to be reused, but also entire process sequences. An

example for typical ﬁrst approaches to apply product

line concepts for business processes for web services

is (Fantinato et al., 2010). The Business Process Ex-

ecution Language (BPEL) is the modeling language

for orchestration web service systems. As micro ser-

vices may be considered as successors based on web

services micro services are also subject of reuse con-

cepts (Sinnhofer et al., 2020).

A concept of adapting business processes in

variant-rich workﬂow-based systems is using the con-

text in a certain state for determining which variant of

the process is to be realized. The variants need to have

a context-aware conﬁguration. (Saidani et al., 2015)

presents a concept of context awareness for adapting

business process models. This context awareness is

achieved by a context meta-model supported by an

ontology. This adaptation of business process models

is some kind of variability. Business objects are con-

sidered as long-living reusable assets while the pro-

cesses are reﬁned (Rulle and Siegeris, 2014).

A recent overview of the modiﬁcations in busi-

ness process models in order to achieve variability is

presented in (La Rosa et al., 2017). All approaches

share the same basic concept of extending or short-

ening process paths in the same way as presented in

this paper. Feature trees are also used by many ap-

proaches. However, these feature trees are used in the

traditional way like FODA (c.f. Figure 1). Although

BPMN as process model notation is used by many ap-

proaches, none of these previous approaches proposes

to use decision model and notation (DMN).

A remarkable idea is supporting the distributed

product line conﬁguration by web-based systems.

An example is ProductlinRE, an online management

tool for requirements engineering of software prod-

uct lines (Ghofrani and Fehlhaber, 2018). The on-

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

450

Figure 5: Decision Table for Payment Method.

line system uses feature trees describing the variabil-

ity. From different locations these feature tree models

may be accessed and the variants may be selected in

teamwork. Such distributed working would also be

supported by using decision requirements diagrams

(DRD) which also bear the option to be used in a dis-

tributed environment.

Some of the features in a decision requirements di-

agram (DRD) may be cross-cutting in the meaning of

aspect-oriented programming (AOP) or separation of

concerns (SoC) concepts. Applying aspect-oriented

concepts allows to identify the cross-cutting features

with dependencies across the entire feature model

(Varela et al., 2011). These cross-cutting features may

be considered as cross tree constraints. The advantage

of clustering features as aspects and separating them

in concerns is that these are more easy to handle. And

entire groups of features may be activated or deacti-

vated in one step. Such an approach may be supported

decision requirements diagrams (DRD) and decision

tables. However, a speciﬁc notation for expressing the

aspects does not exist yet.

The basic understanding of the capabilities of De-

cision Management and Notation (DMN) may be

found in the standard documentation (OMG, 2021) or

basic tutorials like (BPMN, 2021b). (Taylor et al.,

2013) explains the background for applying DMN.

(Figl et al., 2018) presents further examples for ap-

plying DMN, e.g. hierarchies of decisions, the separa-

tion of decisions and process models or conventions.

These are base of our work.

6 CONCLUSION AND FUTURE

WORK

Software product lines are well established concepts

supporting software reuse on a large scale. Busi-

ness process models are a typical method for de-

scribing the behavior of commercial software systems

like ERP (enterprise resource planing) systems, e-

commerce or administrative systems. Due to the im-

portance of both product lines and business process

models it is an obvious choice to seek for a combi-

nation. As an extension of the well established busi-

ness process model and notation (BPMN) the concept

of decision model and notation (DMN) has emerged.

DMN may help to solve the lack of appropriate mod-

eling languages for variabilities (as desired by the

product line concept) in business process models and

to reduce the complexity of the model as proposed in

(Taylor et al., 2013).

We propose applying DMN models and decision

tables as means to deﬁne the variabilities in business

process product lines. The variability in product lines

are typically modeled in a tree structure. Decision

requirements diagram (DRD) provide a similar tree

structure in which the variability of the features which

in DMN are called decisions (resulting in functions

which realize the features) may be deﬁned. In contrast

to traditional feature tree structures DRD also provide

the model elements representing the origin of the de-

cision rules. The rules themselfes are deﬁned in the

decision tables. In rule tables both types of depen-

dencies (mutual exclusion and require) between deci-

sions may be expressed. The concrete location of the

variants in the business process model are deﬁned in

the process model (in BPMN notation).

In our current approach, we do not consider yet

another approach to express variants besides DMN:

Case Management Model and Notation (CMMN).

CMMN provides modeling elements which reduce

the effort for describing the variants in a process

model. The models provide a more condensed view

of the variants. The open issue is if such simpliﬁed

modeling will be accepted be the systems developers

and if CMMN provides all the required techniques for

modeling the variants.

Further future challenges are techniques for auto-

Decision Model and Notation for Describing Variability in Business Process Product Lines

451

mated checking in the phase of the development of a

business process product line. This comprises the de-

velopment of the process model itself as well as the

design of the variants. The consistency of the variants

and correctness of order in the process models need

to be assured. An automated support of this quality

control would be desirable.

REFERENCES

Becker, J., Rosemann, M., and von Uthmann, C. (2000).

Guidelines of business process modeling. In Busi-

ness Process Management, Models, Techniques, and

Empirical Studies, volume 1806 of Lecture Notes in

Computer Science, pages 30–49. Springer.

BPMN (2021a). BPMN Camunda, Documentation,

https://camunda.com/bpmn/.

BPMN (2021b). Camunda, DMN Tutorial,

https://camunda.com/dmn/.

Clauß, M. (2001). A proposal for uniform abstract mod-

eling of feature interactions in UML. In Proceedings

of the ECOOP 2001 Workshop on Feature Interaction

in Composed Systems (FICS 2001), Budapest, Hun-

gary, June 18-22, 2001, volume 2001-14 of Technical

Report, pages 21–25. University of Karlsruhe, IPD.

dos Santos Rocha, R. and Fantinato, M. (2013). The use of

software product lines for business process manage-

ment: A systematic literature review. Information and

Software Technology, 55(8):1355–1373.

dos Santos Rocha, R., Fantinato, M., Thom, L. H., and Eler,

M. M. (2015). Dynamic product line for Business

Process Management. Business Process Management

Journal, 21(6):1224–1256.

Fantinato, M., de Souza Gimenes, I. M., and de Toledo,

M. B. F. (2010). Product Line in the Business Pro-

cess Management Domain, chapter 20, pages 497–

530. Taylor and Francis Group, LLC.

Figl, K., Mendling, J., Tokdemir, G., and Vanthienen, J.

(2018). What we know and what we do not know

about DMN. Enterprise Modeling and Information

Systems Architectures EMISA Forum, 13(2):24–26.

Ghofrani, J. and Fehlhaber, A. L. (2018). Productlinre:

online management tool for requirements engineer-

ing of software product lines. In Proceeedings of

the 22nd International Systems and Software Product

Line Conference - Volume 2, SPLC 2018, Gothenburg,

Sweden, September 10-14, 2018, pages 17–22. ACM.

Kang, K., Cohen, S., Hess, J., Novak, W., and Peterson, A.

(1990). Feature-Oriented Domain Analysis (FODA)

Feasibility Study. Technical Report CMU/SEI-90-TR-

2, Carnegie Mellon University, Software Engineering

Institute, Pittsburgh, PA.

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

F. P. (2017). Business Process Variability Modeling:

A Survey Article. ACM Computing Surveys, 50(2):1–

45.

OMG (2021). OMG, Decision Model and Notation (DMN),

https://www.omg.org/dmn/.

Pol’la, M., Buccella, A., and Cechich, A. (2020). A. Anal-

ysis of variability models: a systematic literature re-

view. Software and Systems Modeling, pages 1619–

1374.

Rulle, A. and Siegeris, J. (2014). From a family of state-

centric PAIS to a conﬁgurable and parameterized busi-

ness process architecture. In Business Process Man-

agement - 12th International Conference, BPM 2014,

Haifa, Israel, September 7-11, 2014. Proceedings,

volume 8659 of Lecture Notes in Computer Science,

pages 333–348. Springer.

Saidani, O., Rolland, C., and Nurcan, S. (2015). Towards

a generic context model for BPM. In 48th Hawaii

International Conference on System Sciences, HICSS

2015, Kauai, Hawaii, USA, January 5-8, 2015, pages

4120–4129. IEEE Computer Society.

Sinnhofer, A. D., Oberhauser, R., and Steger, C. (2020).

From adaptive business processes to orchestrated mi-

croﬂows. In Proceedings of Business Modeling

and Software Design. BMSD 2020, pages 152–168.

Springer, LNCS.

Sinnhofer, A. D., P

uhringer, P., and Kreiner, C. (2015).

varbpm - a product line for creating business process

model variants. In Proceedings of the Fifth Interna-

tional Symposium on Business Modeling and Software

Design - Volume 1: BMSD, pages 184–191. INSTICC,

SciTePress.

Speck, A., Clauß, M., and Franczyk, B. (2002). Concerns

of variability in ”bottom-up” product-lines. In In:

Proceedings of Second Workshop on Aspect-Oriented

Software Development, pages 19–24. GI, Gesellschaft

ur Informatik.

Svahnberg, M., van Gurp, J., and Jan, B. (2001). On the no-

tion of variability in software product lines. Technical

report, University of Karlskrona/Ronneby.

Taylor, J., Fish, A., Vanthienen, J., and Vincent, P. (2013).

Emerging Standards in Decision Modeling—an Intro-

duction to Decision Model & Notation, pages 133–

146. WfMC, Workﬂow Management Coalition.

Varela, P., Ara

ujo, J., Brito, I. S., and Moreira, A. (2011).

Aspect-oriented analysis for software product lines

requirements engineering. In Proceedings of the

2011 ACM Symposium on Applied Computing (SAC),

March 21 - 24, 2011, pages 667–674. ACM.

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

452