Business Process Modeling Flexibility: A Formal Interpretation

Anila Mjeda

, Andrew Butterﬁeld

and John Noll

1,3

Lero, The Irish Software Research Centre, U. of Limerick, Ireland

School of Computer Science and Statistics, Trinity College Dublin, Ireland

University of East London, U.K.

Keywords:

Business Process Modelling, Flexible Interpretation, Formal Semantics, Unifying Theories of Programming.

Abstract:

Domain experts from both the software and business process modelling domains concur on the importance

of having concurring and co-supportive business and software development processes. This is especially

important for organisations that develop software for regulated domains where the software development pro-

cesses need to abide by the requirements of the domain-speciﬁc quality assurance standards. In practice, even

when following quite mature development processes to develop high assurance systems, software development

is a complex activity that typically involves frequent deviations and requires considerable context-sensitive

ﬂexibility. We took a business process modelling notation called PML that was speciﬁcally designed to be

lightweight and allow ﬂexibility, and developed formal semantics for it. PML supports a range of context-

sensitive interpretations, from an open-to-interpretation guide for intended behaviour, to requiring a precise

order in which tasks must occur. We are using Unifying Theories of Programming (UTP) to model this range

of semantic interpretations and the paper presents a high-level view of our formal semantics for PML. We

provide examples that illustrate the need for ﬂexibility and how formal semantics can be used to analyse the

equivalence of, or reﬁnement between, strict, ﬂexible, and weak semantics. The formal semantics are intended

as the basis for tool support for process analysis and have applications in organisations that operate in regulated

domains, covering such areas as the certiﬁcation process for medical device software.

1 INTRODUCTION

Software development is a complex activity that re-

quires frequent adaptation from the developers to

cope with external and internal forces such as chang-

ing requirements, evolving design knowledge, and

failures.

Software development in regulated domains such

as medical devices presents additional complexity due

to the restrictions on the software process imposed

by regulations: depending on the potential impact of

device failure, regulations stipulate that certain pro-

cesses must be followed to manage risks and improve

safety.

Organizations must meticulously document how

their processes comply with these regulations and this

heightens the need of synchronicity/synergy between

their business and software development processes.

Indeed, domain experts from both the software sci-

ence and business modelling domains concur on the

pivotal role of these two processes’ mutual support

(Aguilar-Saven, 2004).

In this context, it becomes important to be able

to document an organization’s development process

in sufﬁcient detail to satisfy regulatory constraints,

while still allowing developers as much ﬂexibility as

possible within those constraints.

Modelling both business processes and the (reg-

ulated) software development processes in the same

notation can provide a much-needed lingua franca

which enables a common understanding of the con-

straints, dependencies and synergies of an organisa-

tion’s business and software development processes.

This, for example, could facilitate using the same

modelling notation both to satisfy regulators and to

inform developers as to what tasks are required by

regulations; this ensures that changes to the process

are reﬂected in both presentations.

To satisfy these requirements, we took a business

process modelling notation called “PML” that was

speciﬁcally designed to be lightweight and allow ﬂex-

ibility. We then developed formal semantics for three

levels of interpretation for PML:

1. Strict - the speciﬁed control ﬂow and pre- and

post-conditions dictate the exact order and con-

Mjeda, A., Butterﬁeld, A. and Noll, J.

Business Process Modeling Flexibility: A Formal Interpretation.

DOI: 10.5220/0007577104650472

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 465-472

ISBN: 978-989-758-358-2

465

ditions for enactment of the process.

2. Flexible - the speciﬁed control ﬂow must be en-

acted as written, except that sequential steps can

be re-ordered as long as pre- and post-conditions

are met, and concurrent activities need not all

complete before subsequent activities can start.

3. Weak - the speciﬁed control ﬂow can be ignored:

steps can be performed in any order as long as

their pre-conditions are met. Steps can also be

skipped if their post-conditions are met.

This deﬁnes a hierarchy of ﬂexibility from none

to maximum. The implication is that a (business or

software) process speciﬁcation could be written that

has a strict interpretation that satisﬁes regulatory con-

straints. If the weak interpretation can be shown to be

equivalent, through comparison of the two interpreta-

tions’ semantics, then the regulators’ need for compli-

ance, and developers’ need for ﬂexibility, are satisﬁed

with a single process and process description.

The remainder of this paper is organized as fol-

lows. In the next section, we introduce PML and

provide an example that will serve to illustrate the

need for ﬂexibility and, later, how formal semantics

can be used to analyze equivalence of strict, ﬂexible,

and weak interpretations. Following that we describe

the formal semantics and how they are derived using

UTP. Finally, we discuss related work, then conclude

with implications and future directions.

2 PML AND PROCESS

FLEXIBILITY

The Process Modelling Language (PML) (Atkinson

et al., 2007) is a shared-state concurrent imperative

language that has been designed to model organiza-

tional/business processes. PML models a process as

a collection of atomic tasks, each of which requires

resources to start, and provides resources when it

completes. PML uses four constructs to model pro-

cess ﬂow: sequence, iteration, selection and

branch:

1. Sequence: Models a series of tasks to be per-

formed in the speciﬁed order:

1 sequence {

action A {}

3 action B {}

}

2. Iteration: Models a series of tasks to be per-

formed repeatedly, where the body is implicitly

interpreted as a sequence:

iteration {

2 action A {}

action B {}

4 }

3. Selection: Models a set of tasks from which only

one can be chosen to be performed:

selection {

2 action choice_A { }

action choice_B { }

4 }

4. Branch: Models a set of concurrent tasks, all of

which have to be performed:

branch {

2 action path_ A { }

action path_ B { }

4 }

The iteration and branch constructs in PML

are underspeciﬁed by design and behave somewhat

unusually. For instance, the iteration construct

has no explicit termination condition. PML acknowl-

edges the ﬂexible nature of processes and leaves the

decision to the agent responsible for enacting the

process to decide when the loop should terminate.

This means that a given iteration construct can

be interpreted in at least two different ways:

• The agents (people) enacting the business pro-

cess use their judgement to determine when the

actions in the body of the iteration have been

repeated enough.

• The availability of resources in the system serves

as loop control. An action in a PML model

can have required resources, that must be avail-

able before the action and begin, and provided

resources, that become available when the ac-

tion completes. The iteration stops when the

required resources of the action following the it-

eration are available, and the required resources

of the ﬁrst action in the body of the iteration are

not available.

Similarly ﬂexible is the behaviour of the branch

construct. The decision on when to proceed beyond

the branch join point is left unspeciﬁed, and thus is

left to the judgement of the agent enacting the pro-

cess model.

In essence, depending on the interpretation, the

trace (enactment history) of a speciﬁc process model

can consist of: 1. an iteration of the non-deterministic

choice of actions whose resources are available; 2. a

sequence of actions that is governed solely by when

the required resources become available; or 3. a pre-

cise pre-deﬁned sequence of actions which deadlock

if the required resources are not available.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

466

Figure 1: PML speciﬁcation of Collect Signatures process.

Note that the body of a process is implicitly interpreted as

a sequence.

2.1 Initial Semantic Considerations

The ﬂexibility of different semantic interpretations of

process terms allows PML to model a process at dif-

ferent levels of granularity and at each of those levels

to cater for context-sensitive interpretations.

To illustrate the attractiveness of the idea, let us

consider a CollectSignatures workﬂow that is re-

quired in a document change approval process. An

organization must put such a process in place in order

to comply with US FDA regulation Title 21 Subchap-

ter H Part 820 “Medical Devices Quality Management

Regulation,” (Food and Drug Administration, United

States Department of Health and Human Services,

2018b) which states in sub-part 820.20:

Each manufacturer shall designate an indi-

vidual(s) to review for adequacy and approve

prior to issuance all documents established to

meet the requirements of this part. The ap-

proval, including the date and signature of the

individual(s) approving the document, shall be

documented.

In our example, suppose the document must be

Figure 2: Strict interpretation of Collect Signatures process.

Figure 3: Flexible interpretation of Collect Signatures pro-

cess.

approved by the Project Manager, Department Head,

Division Director, and Vice President of Engineering.

This would be documented on a document change

approval form that collects signatures from these in-

dividuals. A PML speciﬁcation for this process is

shown in Fig. 1.

A strict interpretation of this workﬂow requires

that the signatures be obtained in order: Project Man-

ager (PM) ﬁrst, then Department Head, then Division

Director, and ﬁnally Vice President of Engineering

(see Fig. 2).

A ﬂexible interpretation, on the other hand, recog-

nizes that the document must have all the signatures

before it can be distributed, but the order is not really

important. As such, signatures could be obtained in

any order, when the individuals are available. This

ﬂexible interpretation is depicted by the speciﬁcation

in Fig. 3. In this interpretation, the process iterates

over signature collection, obtaining signatures one at

a time, when the person is available (the diamonds

indicate selection: “choose one of the following”).

A ﬁnal interpretation would be that each person

could sign a copy of the signature page, and so the

signatures could be collected in parallel. Once all

signatures are obtained, the document can be sub-

Business Process Modeling Flexibility: A Formal Interpretation

467

Figure 4: Weak interpretation of Collect Signatures process.

mitted. This is shown in Fig. 4 (the circles indi-

cate a concurrent branch among all paths). Note that

in this interpretation, the requires predicate for the

distribute document action enforces barrier syn-

chronization: the distribute

document action can-

not be performed until all of the signatures have been

collected, which means all paths of the branch con-

struct must complete.

Why not just use a speciﬁcation that matches the

weak (Fig. 4) interpretation? In some cases, this

might be the best approach. However, there are

some considerations that make the initial speciﬁcation

(Fig. 2) more appropriate. This speciﬁcation captures

the intent of the process: that the signatures act as a

series of gateways to ensure that the Principle Investi-

gator accepts responsibility for the document, and that

the document meets with departmental, institute, and

executive approval. A hierarchical approval sequence

ensures that executives are not bothered with docu-

ments that don’t meet departmental standards. At the

same time, there are sometimes good reasons for cir-

cumventing this hierarchical sequence: for example,

one or more individuals might be unavailable at the

time their signature would be needed in the sequence,

but could convey their intent to sign upon return; wait-

ing for the strict sequence might result in missing the

submission deadline. Also, our experience indicates

that people tend to describe processes as sequential

even when the sequence is not strictly needed; con-

sequently, a sequential speciﬁcation is initially easier

to validate. Later, the speciﬁcation might be evolved

into a concurrent model as part of a process improve-

ment exercise.

Our motivation for analysing context-sensitive

ﬂexibility comes from its relevance in modelling pro-

cesses in regulated domains. The typical quality

assurance standards that regulate safety critical do-

mains, such as the ones that regulate medical de-

vices or avionics software, have both requirements

that need to be followed strictly, and parts which al-

low and in many occasions call for a context-sensitive

ﬂexibility of interpretation.

For illustration purposes, let us consider the Qual-

ity System (QS) Regulation – Medical Device Good

Manufacturing Practices (Food and Drug Administra-

tion, United States Department of Health and Human

Services, 2018a) from the U.S. Food and Drug Ad-

ministration (FDA). Due to the fact that the QS regu-

lation applies to a broad number of devices and pro-

cesses, it follows a ﬂexible approach which prescribes

the essential elements to be incorporated in a manu-

facturer’s quality process without prescribing speciﬁ-

cally how to enact these elements. Furthermore, it is

left to the manufacturer to determine which speciﬁc

quality assurance procedures to implement according

to their speciﬁc process or device.

This ﬂexibility of enactment gives rise to a number

of interesting questions such as:

1. A control ﬂow perspective of process analysis:

which enactment paths satisfy the regulatory re-

quirements and which are rogue paths which

could compromise compliance to the regulatory

standards?

2. A data ﬂow perspective of process analysis: can

we highlight instances of resource black holes

(where a resource is consumed by an action

that produces no resources) and resource mira-

cles (where resources appear to materialize out

of nowhere, from actions that consume no re-

sources)?

3 PML FORMAL SEMANTICS

We have deﬁned not one, but three, distinct but re-

lated formal semantics for PML. This was done using

a semantic framework known as the Unifying Theo-

ries of Programming (UTP) (Hoare and He, 1998) for

two main reasons: ﬁrst, the UTP framework makes

it easy to formally relate the three semantic models.

Also, it facilitates linking these semantic models to

other application or domain speciﬁc resource seman-

tics models.

3.1 UTP

UTP uses predicate calculus to deﬁne before-after re-

lationships over appropriate collections of free obser-

vation variables. The before-variables are undashed,

while after-variables have dashes. Some observations

correspond to the values of program variables (v, v

while others deal with important observations one

might make of a running program, such as start (ok)

and termination (ok

). The set of observation variables

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

468

associated with a theory or predicate is known as its

alphabet. For example, the meaning of an assignment

statement might be given as follows:

x := e b= ok =⇒ ok

∧ x

= e ∧ ν

= ν

Once started, the assignment terminates, with ﬁnal x

set equal to the e in the before-state, while the other

variables (ν), remain unchanged. UTP supports spec-

iﬁcation languages as well as programming ones, and

a general notion of reﬁnement as universally-closed

reverse implication:

S v P b= [P =⇒ S]

Typically the predicates used in a UTP theory form

a complete lattice under the reﬁnement ordering, with

the most liberal speciﬁcation (Chaos) as its bottom el-

ement, and the infeasible program that satisﬁes any

speciﬁcation (Miracle) as its top. Iteration is then

viewed as the usual least ﬁxed point on this lattice.

3.2 Semantics by Three

A PML description can be viewed as a named collec-

tion of basic actions, deﬁned in terms or the resources

they need in order to start, and the new resources

they produce once they have completed. These are

all explicitly connected together using the control-

ﬂow constructs: sequence, selection, iteration,

branch. However, this is also an implied ﬂow-of-

control ordering induced by the required and provides

clauses of each basic action. Simply put, an action

that requires resource r can’t run until at least one

other action runs that itself provides r. It is this ten-

sion between the explicit and implied control-ﬂow

that provides the basis for our three semantics for a

PML description:

• Weak: control ﬂow is completely ignored, and

execution simply iterates the non-deterministic

choice of actions whose resources are available

(also known as the “dataﬂow interpretation”).

• Flexible: the behaviour is guided by the control

ﬂow, but actions can run out of sequence if their

required resources become available before the

control ﬂow has determined that they should start.

In effect this allows re-ordering of sequences or

execution of more than one selection, if resources

allow.

• Strict: the behaviour follows strictly according to

the control-ﬂow structure, becoming deadlocked

if control requests the execution of actions whose

required resources are not available.

We can demonstrate that these three semantics

form a reﬁnement-chain, in the sense that any pro-

cess enactment that satisﬁes the strict semantics also

satisﬁes the ﬂexible and weak semantics:

Weak v Flexible v Strict

Our collection of semantic models for any given PML

description does not prescribe how such a description

should be enacted. The choice of how to run a process

depends entirely on the context in which it is being

used.

3.3 Concurrency, Global State

Regardless of which of the three semantics we con-

sider, a key common feature is that we are dealing

with what is in effect a concurrent programming lan-

guage with global shared state. Formal semantics

for such languages are well established, in connected

denotational and operational forms e.g. (Brookes,

1996), and more recently in UTP (Woodcock and

Hughes, 2002). What all of these have in com-

mon, along with our three versions (Butterﬁeld et al.,

2016)(Butterﬁeld, 2017), is that basically all such

programs semantically reduce to a top-level iteration

over a non-deterministic choice of all the currently

enabled atomic state-change actions. In the case of

PML, we consider the basic actions as atomic, being

enabled if their required resources are present, and

if applicable control-ﬂow also permits the action to

proceed. For the strict semantics, all the control-ﬂow

constructs are applicable, whereas for the weak view,

none of them have any sway. In the ﬂexible seman-

tics, control ﬂow constraints can be overridden by ‘lo-

cal’ knowledge of actions not strictly scheduled, but

actually able to start in terms of resource provision.

By ‘local’ we usually mean actions contained in the

sequence construct containing the actions in ques-

tion.

3.4 Three Semantics Overview

The weak semantics is easiest: the alphabet consists

of rs and rs

where rs is the set of resources present

before an action or process runs, while rs

denotes the

resources present once it has completed. A basic ac-

tion ﬁrst checks rs to see if its required resources are

available. If they are not present, it will not run, oth-

erwise it is available to be able to run. At any point in

time, one of the basic actions that are so available is

chosen to actually run, and it updates the resource set

accordingly. So the meaning of

action A {

requires { r1 }

provides { r2 }

}

is the predicate

∈ rs ∧ rs

= rs ∪ {r

}

Business Process Modeling Flexibility: A Formal Interpretation

469

Figure 5: The three semantics for PML.

This predicate describes what must be true regard-

ing rs and rs

in the event that this action actually

ran. Its required resource r

must have been in the re-

source set before (r

∈ rs), and its provided resource

will have been added into the resource set afterwards

(rs

= rs ∪ {r

}).

For the weak semantics, we simply collect up all

the basic actions, discarding any information about

the enclosing constructs, and then create a non-

deterministic choice (logical-or) over all of them.

This is enclosed in a loop that repeats until there is no

change in the resources available. The weak seman-

tics was ﬁrst described in (Butterﬁeld et al., 2016),

along with a preliminary version of the strict seman-

tics that wasn’t fully compositional.

For the strict semantics, we keep the loop with

choice structure used above for the weak semantics,

but also add in extra alphabet variables in order to cap-

ture control-ﬂow behaviour. This involves the gener-

ation of labels that identify when ﬂow-of-control is

about to enter or exit any statement (basic action or

control-ﬂow construct). We introduce a designated

label-set (ls) that holds all the labels associated with

the entry points of currently enabled statements. With

every statement we associate an entry label (in) and an

exit label (out). Typically the out label of one state-

ment will correspond to the in label of the next state-

ment to run. A basic action is now enabled when both

its required resources are present, and its entry label

is also in the label set (ls). When it has completed

running, it will have updated rs as described above,

but also ls, by removing its in label and adding its out

label.

in ∈ ls ∧ r

∈ rs

∧ rs

= rs ∪ {r

} ∧ ls

= ls \ {in} ∪ {out}

Careful use of a label generation mechanism and la-

bel substitutions allows us to give each statement a

semantics independent of its context, but in such a

way that it is easy for a more complex construct to

use it and set it up in context. For example, the se-

quential composition of two instances of the above

action would be achieved by generating a new label

(mid, say), and substituting it in for the out label of

the ﬁrst instance, and the in label of the second. Then

the two resulting predicates would be connected with

logical-or. In effect, the variables in and out are used

to manage contextual information in a compositional

manner. Full details of the fully compositional strict

semantics can be found in (Butterﬁeld, 2017).

The ﬂexible semantics requires a few more

context-aware alphabet variables to propagate action

enabling information to surrounding ﬂow of control

constructs, and is still under development.

3.4.1 Example

We can now consider how our three semantics deal

with the Collect Signatures example (Figs. 1 to 4).

Our semantics describes all the possible execution

orders that can arise, given some starting state.

With the strict semantics, applied to this example,

we get only one sequence: PM ; dept head ; dir

; VP ; distr doc (here we shorten action name

obtain XX sig to XX), which is precisely that of

Fig. 2. With the weak semantics, the ﬁrst four actions

can occur in any order, while the ﬁfth must wait until

all the previous four are done. This gives 24 differ-

ent interleavings of the four parallel actions in Fig. 4.

In this case, because each arm of the selection in the

ﬂexible semantics has only one action (Fig. 3), we get

the same 24 interleavings as for the weak case.

3.5 Current State

The current state of development of these semantic

models is as follows — the extremal ones, weak and

strict, are complete, while the ﬂexible semantics has

thrown up a number of interesting choices—there is a

spectrum of possibilities here, depending on how ‘lo-

cal’ the ﬂexibility is. The current plan is to formalise

the degree of ﬂexibility that corresponds to the PML

analysis and simulation tool described in (Atkinson

et al., 2007).

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

470

4 RELATED WORK

Osterweil’s 1987 paper (Osterweil, 1987) highlighted

the importance of efﬁcient software processes to de-

liver qualitative software and argued the idea of de-

veloping and using model processing languages that

are similar to programming languages. Just a few

years later, in 1993, a survey (Armenise et al., 1993)

found that by then, there were quite a number of pro-

cess modelling notations (the survey identiﬁes Adele,

ALF, APPL/A, DesignNet, Entity, EPOS, FunSoft,

HFSP, Marvel, Merlin, MVP-L, Oikos and SPADE)

that exhibited syntax similar to program languages.

To date, many different treatments of process ﬂex-

ibility have been proposed in the literature and recent

extensive reviews of the ﬁeld can be found in (Rosa

et al., 2017) and (Cognini et al., 2018). Yet, many

issues that come with ﬂexibility remain to be solved,

and of particular interest to us is the need for further

research in the veriﬁcation (ensuring correctness) of

ﬂexible business processes (Cognini et al., 2018).

To contextualize our approach we will refer to the

taxonomy proposed by (Reichert and Weber, 2012)

that identiﬁes four types of process ﬂexibility needs

: (1) Variability – deﬁned as the ability of providing

different variants of the same process; (2) Adaptation

– deﬁned as the ability to (temporarily) deviate the

execution path of a process; (3) Looseness – deﬁned

as the ability to execute a process when the decisions

affecting the control ﬂow are under-speciﬁed (and the

execution path can be different in different runs); and,

(4) Evolution – deﬁned as a permanent modiﬁcation

of the process.

In this taxonomy our approach maps both into

Variability and Looseness.

Additionally, of particular interest for us is the

treatment of process ﬂexibility seen from the lens

of ‘equal enough’ processes by van der Aalst et al

(van der Aalst et al., 2006), where a Petri nets ap-

proach is used to distinguish between negligibly dif-

ferent and completely different processes.

In our approach, we support the reasoning about

ﬂexible deployment by using the Unifying Theo-

rems of Programming (UTP) (Hoare and He, 1998)

framework for developing a range (which goes from

“weak” to “strong”) of formal semantics for PML.

5 CONCLUSIONS

In this paper, we discuss our insights into mod-

elling context-sensitive (business and software) pro-

cess ﬂexibility. We developed formal semantics for

a lightweight and ﬂexibility-friendly process model-

ing language called PML. Our semantics cover three

levels of interpretation for PML: strict, ﬂexible and

weak interpretations. We are using Unifying Theories

of Programming (UTP) to model this range of seman-

tic interpretations and the paper presents a high-level

view of our formal approach. The added beneﬁt of us-

ing the UTP framework is that we have semantically

interoperable levels of interpretation for a process de-

ﬁned in PML. This can help to determine those sit-

uations where the interpretation level does not mat-

ter. Surprisingly this also gives us useful information

about the nature of the process being modelled, and

often guidance as to when ﬂexibility is feasible or not.

The formal semantics have applications in regulated

domains, covering such areas as the certiﬁcation pro-

cess for medical device software. In particular, we can

exploit the uniﬁcation aspect of UTP to add in formal

models of resources themselves to extend the scope

of our analyses.

ACKNOWLEDGMENTS

This work was supported, in part, by Science Foun-

dation Ireland grants10/CE/I1855 and 13/RC/2094 to

Lero - the Irish Software Research Centre(www.lero.

ie).

REFERENCES

Aguilar-Saven, R. S. (2004). Business process modelling:

Review and framework. International Journal of pro-

duction economics, 90(2):129–149.

Armenise, P., Bandinelli, S., Ghezzi, C., and Morzenti, A.

(1993). A survey and assessment of software pro-

cess representation formalisms. International Journal

of Software Engineering and Knowledge Engineering,

3(3):401–426.

Atkinson, D. C., Weeks, D. C., and Noll, J. (2007). Tool

support for iterative software process modeling. In-

formation & Software Technology, 49(5):493–514.

Brookes, S. D. (1996). Full abstraction for a shared-variable

parallel language. Inf. Comput., 127(2):145–163.

Butterﬁeld, A. (2017). UTCP: compositional semantics for

shared-variable concurrency. In da Costa Cavalheiro,

S. A. and Fiadeiro, J. L., editors, Formal Methods:

Foundations and Applications - 20th Brazilian Sym-

posium, SBMF 2017, Recife, Brazil, November 29 -

December 1, 2017, Proceedings, volume 10623 of

Lecture Notes in Computer Science, pages 253–270.

Springer.

Butterﬁeld, A., Mjeda, A., and Noll, J. (2016). UTP Seman-

tics for Shared-State, Concurrent, Context-Sensitive

Process Models. In Bonsangue, M. and Deng, Y., ed-

itors, TASE2016. under review.

Business Process Modeling Flexibility: A Formal Interpretation

471

Cognini, R., Corradini, F., Gnesi, S., Polini, A., and Re,

B. (2018). Business process ﬂexibility-a systematic

literature review with a software systems perspective.

Information Systems Frontiers, 20(2):343–371.

Food and Drug Administration, United States Department

of Health and Human Services (2018a). Quality sys-

tem (QS) regulation – medical device good manufac-

turing practices. https://tinyurl.com/y7uoefv8.

viewed: 4th January 2019.

Food and Drug Administration, United States Department

of Health and Human Services (2018b). Quality sys-

tem regulation. https://tinyurl.com/y72mdqwr.

viewed: 4th January 2019.

Hoare, C. A. R. and He, J. (1998). Unifying Theories of Pro-

gramming. Prentice-Hall International, Englewood

Cliffs, NJ.

Osterweil, L. (1987). Software Processes are Software too.

In Proceedings pf 9th International Conference on

Software Engineering, pages 2–13, Monterey, CA.

Reichert, M. and Weber, B. (2012). Enabling ﬂexibil-

ity in process-aware information systems: challenges,

methods, technologies. Springer Science & Business

Media.

Rosa, M. L., Van Der Aalst, W. M., Dumas, M., and Milani,

F. P. (2017). Business process variability modeling: A

survey. ACM Computing Surveys (CSUR), 50(1):2.

van der Aalst, W. M. P., de Medeiros, A. K. A., and Weijters,

A. J. M. M. (2006). Process equivalence: Compar-

ing two process models based on observed behavior.

In Proceedings of the 4th International Conference on

Business Process Management, BPM’06, pages 129–

144, Berlin, Heidelberg. Springer-Verlag.

Woodcock, J. and Hughes, A. P. (2002). Unifying theories

of parallel programming. In George, C. and Miao, H.,

editors, Formal Methods and Software Engineering,

4th International Conference on Formal Engineering

Methods, ICFEM 2002 Shanghai, China, October 21-

25, 2002, Proceedings, volume 2495 of Lecture Notes

in Computer Science, pages 24–37. Springer.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

472