an empirical comparison of formalisms for modelling and ... · an empirical comparison of...

DOI 10.1007/s00165-016-0405-zThe Author(s) © 2017. This article is published with open access at Springerlink.comFormal Aspects of Computing (2017) 29: 251–307

Formal Aspectsof Computing

An empirical comparison of formalismsfor modelling and analysis of dynamicreconfiguration of dependable systemsAnirban Bhattacharyya1, Andrey Mokhov2 and Ken Pierce11 School of Computing Science, Newcastle University, Claremont Tower, Claremont Road, Newcastle upon Tyne,NE1 7RU, UK2 School of Electrical and Electronic Engineering, Newcastle University, Merz Court, Newcastle upon Tyne, NE1 7RU, UK

Abstract. This paper uses a case study to evaluate empirically three formalisms of different kinds for theirsuitability for themodelling and analysis of dynamic reconfiguration of dependable systems. The requirements onan ideal formalism for dynamic software reconfiguration are defined. The reconfiguration of an office workflowfor order processing is described, and the requirements on the reconfiguration of the workflow are defined.The workflow is modelled using the Vienna Development Method (VDM), conditional partial order graphs(CPOGs), and the basic Calculus of Communicating Systems for dynamic process reconfiguration (basic CCSdp),and verification of the reconfiguration requirements is attempted using the models. The formalisms are evaluatedaccording to their ability tomodel the reconfigurationof theworkflow, toverify the requirementson theworkflow’sreconfiguration, and to meet the requirements on an ideal formalism.

Keywords: Dynamic software reconfiguration,Workflowcase study,Reconfiguration requirements,Formalmeth-ods, VDM, Conditional partial order graphs, Basic CCSdp

1. Introduction

The next generation of dependable systems is expected to have significant evolution requirements [CHNF10].Moreover, it is impossible to foresee all the requirements that a system will have to meet in future when thesystem is being designed [MMR10]. Therefore, it is highly likely that the system will have to be redesigned (i.e.reconfigured) during its lifetime, in order to meet new requirements. Furthermore, certain classes of dependablesystems, such as control systems,must be dynamically reconfigured [KMOS10], because it is unsafe or impracticalor too expensive to do otherwise.

Correspondence and offprint requests to: A. Bhattacharyya, E-mail: [email protected] supplementary material The online version of this article (doi:10.1007/s00165-016-0405-z) contains supplementary material, whichis available to authorized users.

http://crossmark.crossref.org/dialog/?doi=10.1007/s00165-016-0405-z&domain=pdf

http://dx.doi.org/10.1007/s00165-016-0405-z

252 A. Bhattacharyya et al.

Configuration 1

Configuration 2time

Case 1

Configuration 2

Configuration 1

dynamic reconfiguration tasks

Case 2

Configuration 2

Configuration 1

application tasks

dynamic reconfiguration tasks

interference (functional/timing)Case 3

Fig. 1. Dynamic reconfiguration cases

The dynamic reconfiguration of a system is defined as the change at runtime of the structure of the system—consistingof its components and their communication links—or thehardware locationof its software components[Bha13] or their communication links. For example, the dynamic upgrade of a software module in a telecom-munications satellite during the execution of the old version of the module, the removal of a faulty controller ofan aero engine during flight, re-establishing the exchange-to-mobile communication link during a conversationas the mobile crosses the boundary of communication zones, and moving an executing software object betweenservers to achieve load balancing. This paper focuses on dynamic software reconfiguration, because software ismuch more mutable than hardware.

Existing research in dynamic software reconfiguration can be grouped into three cases from the viewpoint ofinterference between application and reconfiguration tasks, which is embedded in time (see Fig. 1). Interferenceis defined as the effect of the concurrent execution of a task on the execution of another task. For example,an incorrect result of a computation performed by the affected task, or a delay in the response time of thecomputation, or the delayed termination or replacement of the task.

Case 1 is the near-instantaneous reconfiguration of a system, in which the duration of the reconfiguration intervalis negligible in comparison to the durations of application tasks. Any executing task in Configuration 1 that isnot in Configuration 2 is aborted, which can leave data in a corrupted or inconsistent state. Alternatively, thereconfiguration is done at the end of the hyperperiod of Configuration 1 (i.e. the lowest common multiple ofthe periods of the periodic tasks in Configuration 1), which can result in a significant delay in handling thereconfiguration-triggering event. This is the traditional method of software reconfiguration, and is applicable tosmall, simple systems running on a uniprocessor.

Case 2 is the reconfiguration of a system in which the duration of the reconfiguration interval is significant incomparison to the durations of application tasks, and any executing task in Configuration 1 that can interferewith a reconfiguration task is either aborted or suspended until the reconfiguration is complete. This is the mostcommonmethod of software reconfiguration (see [SVK97], [AWvSN01], [BD93], and [KM90]), and is applicableto some large, complex, distributed systems. If the duration of the reconfiguration is bounded and the controlledenvironment can wait for the entire reconfiguration to complete, then the method can be used for hard real-time systems; otherwise, the environment can become irrecoverably unstable and suffer catastrophic failure if atime-critical service is delayed beyond its deadline.

Case 3 is the reconfiguration of a system in which the duration of the reconfiguration interval is significant incomparison to the durations of application tasks, and tasks inConfiguration 1 execute concurrentlywith reconfig-uration tasks. This method avoids aborting tasks and reduces the delay on the application due to reconfiguration,but it introduces the possibility of functional and timing interference between application and reconfigurationtasks. If the interference can be controlled, then this method is the most suitable for large, complex, distributedsystems, including hard real-time systems, but it is also the least researched method of software reconfiguration.

An empirical comparison of formalisms for modelling and analysis of dynamic reconfiguration of dependable systems 253

Existing research in Case 3 has focused on timing interference between application and reconfiguration tasks,and on achieving schedulability guarantees (for example, see [SRLR89], [TBW92], [Ped99], [Mon04], [FW05],and [F06]). There is little research on formal verification of functional correctness in the presence of functionalinterference between application and reconfiguration tasks (see [MT00] and [BCDW04]).

Therefore, there is a requirement for formal representations of dynamic software reconfiguration that canexpress functional interference between application and reconfiguration tasks, and can be analyzed to verifyfunctional correctness. There is also a significant requirement for modelling unplanned reconfiguration, that is,reconfiguration that is not incorporated in thedesignof a system (see [CHNF10], [MMR10], and [KMOS10]).Thispaper makes a contribution towards meeting these two key requirements. Research shows that no single existingformalism is ideal for representing dynamic software reconfiguration [Wer99]. Therefore, we use three formalismsof different kinds: the Vienna Development Method (VDM, based on the state-based approach), conditionalpartial order graphs (CPOGs, in which graph families are used for verification of workflow and reconfigurationrequirements), and the basic Calculus of Communicating Systems for dynamic process reconfiguration (basicCCSdp, based on the behavioural approach), to produce representations of a case study, and evaluate how wellthe different representations meet the requirements. The diversity of the three formalisms is manifested in thediversity of their semantics. Thus, VDM has a denotational semantics in order to describe data structures andalgorithms, which helps to refine a specification to an implementation; CPOGs have an axiomatic semantics basedon equations, which helps tomake reasoning about graphs simple and computationally efficient; and basic CCSdp

has a labelled transition system (LTS) semantics, which helps to describe process behaviour and reconfigurationsimply. In order to facilitate comparison of the formalisms, we have defined an LTS semantics for CPOGs andfor the VDMmodel; an LTS semantics for VDM is beyond the scope of this paper.

The rest of the paper is organized as follows: Sect. 2 defines requirements on an ideal formalism for themodelling and analysis of dynamic software reconfiguration. Section 3 describes the case study, in which asimple office workflow for order processing is dynamically reconfigured, and defines the requirements on theinitial configuration, the final configuration, and on the reconfiguration of the workflow. The case study is amodification of the case study used in [Bha13] to evaluate basic CCSdp. The reconfiguration of the workflowis modelled and analyzed using VDM (in Sect. 4), CPOGs (in Sect. 5), and basic CCSdp (in Sect. 6). We havedeliberately not used workflow-specific formalisms (such as [YL05], [AP07], and [HND+11]) for two reasons.First, because of our lack of fluency in them; and second, because we believe the models should be producedusing general purpose formalisms (if possible). VDM, CPOGs, and basic CCSdp are compared and evaluatedin Sect. 7 using the results of the modelling and analysis exercise and the requirements on an ideal formalismdefined in Sect. 2. Related work is reviewed in Sect. 8.

This paper contains considerable material from the first author’s doctoral thesis [Bha13]. The core require-ments on an ideal formalism F1–F11 in the following section are from the thesis, requirement F12 is new andwas suggested by one of the anonymous reviewers. The case study is a modification of the thesis case study:Configuration 1 has been simplified by making it purely linear, Configuration 2 has been made more complexby adding concurrently executing tasks, and the reverse reconfiguration from Configuration 2 to Configuration1 is now considered in the modelling. The descriptions of the syntax and semantics of basic CCSdp are from thethesis, but the modelling now refers to all the designs of Configuration 1 (rather than to only Design 3) and theanalysis based on weak observational bisimulation is new. The sections on VDM, CPOGs, and the comparisonof formalisms are (of course) new.


2. Requirements on an ideal formalism for dynamic software reconfiguration

No single existing formalism is ideal for the modelling and analysis of dynamic software reconfiguration [Wer99].However, it is possible to identify core requirements that an ideal formalismmust meet and to evaluate candidateformalisms against these requirements, such as those in this paper. In this section, we identify and briefly justify aset of core requirements, labelled F1–F12, and use them to evaluate the three formalisms in Sect. 7.We summarizeour findings at the end of this section.

2.1. Requirements on formalisms

We divide the requirements into two groups, the first relating specifically to modelling and verifying dynamicreconfiguration, and the second relating more generally to ‘usable’ formalisms.

Dynamic reconfiguration requirements

F1 It should be possible to model, and to identify instances of, software components and tasks, and their commu-nication links. A software component can be a program or a class (as in Smalltalk or C++) or a module(as in C), a task is a process (as in UNIX), and a communication link is a channel of communication(e.g. a socket-to-socket link over TCP/IP between communicating UNIX processes). Multiple tasks canbe based on the same software component in order to process different transactions concurrently, andmultiple software components can be used to provide fault tolerance. The dynamic reconfiguration of asoftware component or of a task involves the selective reconfiguration of its instances, which is facilitatedby the use of instance identifiers.

F2 It should be possible to model the creation, deletion, and replacement of software components and tasks, andthe creation and deletion of their communication links. These are the fundamental operations used to changethe software structure of a system.

F3 It should be possible to model the relocation of software components and tasks on physical nodes. Softwarerelocation helps to implement load balancing, which is used to improve performance and reliability incloud computing. Thus, software relocation helps to increase the dependability of cloud computing.

F4 It should be possible to model state transfer between software components and between tasks. In dependablesystems with state, state transfer helps to implement Case 2 of dynamic reconfiguration (see Fig. 1) and toimplement software relocation.

F5 It should be possible to model both planned and unplanned reconfiguration. Planned reconfiguration is recon-figuration that is incorporated in the design of a system. Unplanned reconfiguration is reconfiguration thatis not incorporated in the design of a system, which is relevant for legacy systems and for the evolution ofsystems.

F6 It should be possible to model the functional interference between application tasks and reconfiguration tasks.This is the main modelling requirement in Case 3 of dynamic reconfiguration (see Fig. 1), and is anoutstanding research issue.

F7 It should be possible to express and to verify the functional correctness requirements of application tasksand reconfiguration tasks. This is the main verification requirement of dynamic reconfiguration, and is anoutstanding research issue in Case 3.

General requirements

F8 It should be possible tomodel the concurrent execution of tasks. Concurrency can cause functional interferencebetween tasks, and thereby affect the functional correctness of a task, and it is a feature of many dependablesystems. Therefore, it should be modelled.

F9 It should be possible tomodel state transitions of software components and tasks. State affects the functionalityof a task, and thereby affects the functional correctness of the task, and it is a feature of most dependablesystems. Therefore, it should be modelled.


F10 The formalism should be as terse as possible. Terseness supports abstraction, which is essential in removingunnecessary detail from a model, and thereby renders the model easier to understand. Thus, tersenessfacilitates the use of a model.

F11 The formalism should be supported by tools. Otherwise, the formalism will not be used by software engineers.F12 The formalism should be easy to learn and to use. Otherwise, the rate of adoption of the formalism by users

will be low.

2.2. Summary of results

The evaluations of the three formalisms in Sect. 7 show that none of them is ideal, since none of them meetsall the requirements on an ideal formalism for dynamic software reconfiguration defined above. However, theformalisms meet the requirements collectively, and (therefore) are complementary (albeit with extensions).

The main strength of basic CCSdp is in modelling. It can model: abstractly and tersely the compositionand concurrent execution of application and reconfiguration tasks using concurrent processes, their functionalinterference using interleaved transitions, their planned and unplanned reconfiguration using fraction processes,cyclic processes using recursion, and reconfiguration of fraction processes using other fractions. Its main weak-nesses are: inability to control non-deterministic transitions, inability to reconfigure selectively specific processinstances, computational complexity of process matching based on bisimulation, computational complexity andrestrictiveness of process congruence, and lack of tools.

In contrast, the main strength of CPOGs is in verification. A Boolean SAT solver can compare a model andits requirement in canonical form, and efficient model checking is supported by predicates on actions and onaction dependencies and the acyclic topology of CPOGs. Correctness of a reconfiguration between configurationscan be proved using consistent histories of actions of the two configurations and by restricting interferencethrough forbidden actions. Functional interference between tasks can bemodelled using either interleaved actionsor simultaneous actions. Its main weaknesses are: inability to model composition and structure of softwarecomponents and tasks, low level of abstraction for modelling, inability to model cyclic processes, and lack ofavailable tools.

In contrast to both basic CCSdp and CPOGs, the main strength of VDM is in formal software development.It can model workflows, software components, and tasks as data types, which facilitates their refinement to animplementation, its tools for development, simulation, and testing are mature and available, and it is easy to useby system designers. The main weaknesses of VDM-SL are: lack of constructs for modelling concurrency andinterference, and lack of formal verification tools.

3. Case study: dynamic reconfiguration of an office workflow for order processing

The case study described in this section involves the dynamic reconfiguration of a simple office workflow fororder processing, which is a simplified version of real workflows commonly found in large and medium-sizedorganisations [EKR95]. Preliminary versions of the case study are in [MADB12] and [Bha13]. The case studywas chosen for three reasons. First, workflows are ubiquitous, which suggests that our workflow reconfigurationwill be of interest to a large community. Second, the case study is based on published work by other researchers,see [EKR95]. Third, it is both simple to understand and complex enough to exercise all three formalisms.

The workflow consists of a network of several communicating tasks, and the configuration of the workflowis the structure of the network. The workflow does not contain any loop, because loops tend to reduce the scopeof reconfiguration considerably. A loop can have an invariant that is not an invariant of the reconfiguration, andthereby can prevent reconfiguration of tasks constituting the loop during an execution of the loop. The workflowcontains the following tasks:

• Order Receipt: an order for a product is received from an existing customer. The order identifier includesthe customer identifier and the product identifier. An evaluation of the order is initiated to determine whetheror not the order is viable.


Order Receipt

Inventory Check

OK?No

Yes

OK?No

Yes

Credit Check

Evaluation

Reject

Reject

Shipping

Billing

Archiving

Confirmation

Fig. 2. Flow chart of the requirements on Configuration 1

• Evaluation: the product identity is used to check the availability of the product; the customer identity isused to check the credit of the customer. If either check fails, the output is negative and the order is rejected;otherwise, the output is positive and the order is accepted.

• Rejection: if the order is rejected, a notification of rejection is sent to the customer and the workflowterminates.

• If the order is accepted, the following tasks are performed:

– Shipping: the product is shipped to the customer.– Billing: the customer is billed for the cost of the product ordered plus shipping costs.– Archiving: the order is archived for future reference.– Confirmation: a notification of successful completion of the order is sent to the customer.

3.1. Configurations of the workflow

There are two configurations of the workflow: Configuration 1 and Configuration 2. Initially the workflowexecutes Configuration 1. Subsequently, the workflowmust be reconfigured through a process to Configuration 2.Requirements on the two configurations are shown in Figs. 2 and 3 and are explained below. We then identifyrequirements on the reconfiguration from Configuration 1 to Configuration 2, and identify potential designs forthis system.

The initial configuration of the workflow is Configuration 1 and must meet the following requirements foreach order (see Fig. 2):


Order Receipt

Inventory Check

OK?

Yes

OK?Yes

Archiving

OK?

Reject No

Credit Check

Supplier Check

Yes

No

Reject No

+

Shipping

+

Billing

Evaluation

Fig. 3. Flow chart of the requirements on Configuration 2

C1.1 Order Receipt must be performed first. That is, it must begin before any other task.C1.2 Evaluation: in evaluating the order, the product identity is used to perform an inventory check on the

stock of the product, and the customer identity is used to perform a credit check on the customer. If eithercheck fails, the output of Evaluation is negative; otherwise, the output is positive.

C1.3 Evaluation must be performed second.C1.4 If the output of Evaluation is negative, Rejection must be the third and final task of the workflow.C1.5 If the output of Evaluation is positive, the following conditions must be satisfied:

1. Shipping must be performed after Evaluation.2. Billing must be performed after Shipping.3. Archiving must be performed after Billing.4. Confirmation must be performed after Archiving and must be the final task to be performed.5. The customer must not receive more than one shipment of an order (safety requirement).

C1.6 Each task must be performed at most once.C1.7 The order must be either rejected or satisfied (liveness requirement).

After some time, the management of the organization using the workflow decides to change it in order to increasesales and provide a faster service. The new configuration of the workflow is Configuration 2 and must meet thefollowing requirements for each order (see Fig. 3):

C2.1 Order Receipt must be performed first.


C2.2 Evaluation: in evaluating the order, the product identity is used to perform an inventory check on thestock of the product. If the inventory check fails, an external inventory check is made on the suppliers ofthe product. The customer identity is used to perform a credit check on the customer. If either the inventorycheck or the supplier check is positive, and the credit check is positive, the order is accepted; otherwise, theorder is rejected.

C2.3 Evaluation must be performed second.C2.4 If the output of Evaluation is negative, Rejection must be the third and final task of the workflow.C2.5 If the output of Evaluation is positive, the following conditions must be satisfied:

1. Billing and Shipping must be performed after Evaluation.2. Billing and Shipping must be performed concurrently.3. Archiving must be performed after Billing and Shipping and must be the final task to be performed.4. The customer must not receive more than one shipment of an order (safety requirement).

C2.6 Each task must be performed at most once.C2.7 The order must be either rejected or satisfied (liveness requirement).

3.2. Requirements on reconfiguration of the workflow

In order to achieve a smooth transition from Configuration 1 to Configuration 2 of the workflow, the process ofreconfiguration must meet the following requirements:

R1 Reconfiguration of a workflow should not necessarily result in the rejection of an order. In some systems,executing tasks of Configuration 1 are aborted during its reconfiguration to Configuration 2 (see Case 2 inFig. 1). The purpose of this requirement is to avoid the occurrence of Case 2 and ensure the occurrence ofCase 3.

R2 Any order being processed that was received before the start of the reconfiguration must satisfy all therequirements on Configuration 2 (if possible); otherwise, all the requirements on Configuration 1 must besatisfied.

R3 Any order received after the start of the reconfiguration must satisfy all the requirements on Configuration2.

3.3. Designs of the workflow and of its reconfiguration

The two configurations of the workflow described above are stated as requirements because there are a number ofways in which an implementation, and therefore a model, can realise the workflow.We identify four such possibledesigns:

Design 1 There is at most one workflow, and the workflow handles a single order at a time.The workflow is sequential: after an order is received, the thread performs a sequence of tasks, withtwo choices at Evaluation. After the order has been processed, the thread is ready to receive a neworder. This design corresponds to a cyclic executive.

Design 2 There is at most one workflow, and the workflow can handle multiple orders at a time.The workflow is mainly concurrent: after an order is received, the thread forks internally into con-current threads, such that different threads perform the different tasks of the workflow—althoughthe requirements on the configurations severely restrict the degree of internal concurrency of theworkflow—and each thread performs the same task for different orders.

Design 3 There can be multiple workflows, and each workflow handles a single order.After an order is received, the thread forks into two threads: one thread processes the ordersequentially—as in Design 1—but terminates after the order has been processed; the other threadwaits to receive a new order.

Design 4 There can be multiple workflows, and each workflow can handle multiple orders at a time.This design is a complex version of Design 2 with multiple workflows.


In the next three sections, we model the case study workflow and its reconfiguration using three formalismsof different kinds: VDM, CPOGs, and basic CCSdp. For each formalism, we use its ‘idiom’ to identify which ofthe above four designs of the configurations is the most suitable for the formalism, which (in turn) affects howthe reconfiguration of the workflow is performed. Thus, we identify which of the three cases of reconfigurationoutlined in Sect. 1 (instantaneous, sequential, or concurrent) is the most suitable for the ‘idiom’ of the formalism.

4. VDM

The Vienna Development Method (VDM) is a state-based formal method that was originally designed in the1970s to give semantics to programming languages [Jon03]. Since then it has been used widely both in academiaand industry to define specifications of software systems. It is well-suited to formalising requirements and naturallanguage specifications and tofindingdefects. For example, theFeliCa contactless card technology,which iswidelyused in Japan, was developed using VDM [FLS08]. A specification was constructed in VDM that revealed a largenumber of defects (278) in the existing natural-language requirements and specifications. The VDM specificationwas used to generate test cases and as a reference when writing the C++ code that was eventually deployed tomillions of devices.

The VDM Specification Language (VDM-SL) was standardised as ISO/IEC 13817-1 in 1996 [ISO96]. Devel-opments beginning in the 1990s extended the language to cover object-orientation (VDM++ [FLM+05]) and laterto include abstractions for modelling real-time embedded software (VDM-RT [VLH06]). All three dialects aresupported by two robust tools, the commercial VDMTools [Lar01] and the open-sourceOverture1 tool [LBF+10].These tools offer type checking for VDM models, a number of analysis tools such as combinatorial test-ing [LLB10], and interpretationof an executable subset ofVDMthat allowsmodels to be simulated.By connectinga graphical interface to an executablemodel, it is also possible to animate specifications [FLS08], thereby allowingnon-specialists to gain an understanding of the system described by the specification through interaction andinterrogation of the model.

The models of our case study were developed in VDM-SL (using the Overture tool) and the remainder of thissection uses that dialect. As part of the standardisation process, a full denotational semantics has been definedfor VDM-SL [LP95], as well as a proof theory and a comprehensive set of proof rules [BFL+94]. Proofs in VDMtypically verify internal consistency or are proofs of refinement [Jon90].

We proceed as follows: the VDM formalism is described in more detail in Sect. 4.1, the modelling of the casestudy is described in Sect. 4.2, the analysis of the model is described in Sect. 4.3, an LTS semantics of the modelis defined in Sect. 4.4, and possible extensions to the model are described in Sect. 4.5. An evaluation of the modeland formalism for describing reconfiguration is given in Sect. 7.

4.1. Formalism

Specifications in VDM-SL are divided into modules, where each module contains a set of definitions. Modulescan export definitions to, and import definitions from, other modules in the model. The definitions in a moduleare divided into distinct sections and preceded by a keyword. Definitions can include types, values, functions,state, and operations. Listing 4.1 shows an empty VDM-SL module specification, divided into sections. We givean overview of the definitions later in this section, and further detail is introduced as required during explanationof the model.

A key part of the VDM-SL language is the powerful type system. VDM-SL contains a number of built-inscalar types including booleans, numeric types, and characters. Non-scalar types include sets, sequences, andmaps. Custom types can be defined in the types section, based on built-in types and including type unions andrecord types with named fields. Custom types can be restricted by invariants and violations of these invariantscan be flagged during interpretation of the models.

Functions are pure and have no side effect. They can be defined implicitly (by pre- and post-conditions) orexplicitly. Explicit functions can also be protected with a pre-condition. Only explicit functions can be interpretedby the tools. State allows one or more global variables to be defined for the module. An invariant can be definedover the state to restrict its values. Again, invariant violations can be flagged during interpretation by the tool.

1 http://www.overturetool.org/.

http://www.overturetool.org/


Listing 4.1: Blank VDM-SL module definition�

module MyModule

exports ...imports ...

definitions

types...

functions...

state ... of...end

operations...

values...

end MyModule

��

Operations are functions that are additionally able to read and write state variables. Therefore, operations canhave side effects. Like functions, operations can be defined implicitly or explicitly. Values define constants thatcan be used in functions and operations.

4.2. Modelling

In creating a specification that meets the workflow requirements given in Sect. 3, two approaches are possible inthe VDM ‘idiom’. The first is to build a data model that captures an order and its status, with operations andpre-conditions ensuring that only valid transitions between statuses are possible (e.g. order receipt to inventorycheck). Such a model could also include details of customers and suppliers. The second approach is to model theentire workflow as sequences of actions and build an ‘interpreter’ within the model to execute and reconfigurethe workflow.

These approaches are not orthogonal; a data model would complement a workflow model. The resultingspecification would to be closer to any code to be written in implementing the order system than either approachseparately. In this paper we follow the second approach as this more closely matches the style of the requirementson workflows described in Sect. 3. We return to the data model approach in Sect. 4.5, giving an example of howthe model could be extended to incorporate a data model for orders.

As a general purpose modelling language, VDM-SL does not have built-in notions of concurrency or thread-ing, nor does it have dedicated abstractions for modelling processes. Following a standard VDM-SL paradigmto keep the model small, a single workflow was modelled, with concurrency of the parallel actions modelled asnon-deterministic interleaving; this is Design 1 from Sect. 3. Reconfiguration is achieved by an operation thatswaps a workflow during execution of the interpeter; this is reconfiguration Case 1 as described in Sect. 1. InSect. 4.5 we describe extensions of the model that would facilitate exploration of Designs 2–4, including featuresof the other VDM dialects (VDM++ and VDM-RT).

Analysis of the model is done through testing. This is a common way of using VDM in industry [ALR98,FLS08], using the formal model to record and test assumptions, then using the resulting model as a specificationwhenwriting code.Tests aredefined formanually checkingall valid configurations, and for testingvalid and invalidreconfigurations. Section 4.5 explains extensions that could facilitate greater automation in testing workflows.


The following subsections explain the modelling process in detail. The model is split into three modules:Configurations, containing workflow definitions; Interpreter, containing operations to execute and recon-figure workflows; and Test, which defines test cases for the model.

The contents of the modules are described as follows: first, a set of types is defined that can capture thetwo workflows in the Configurations module. Next, an interpreter is defined in the Interpreter module thatcan ‘execute’ a workflow2 and be reconfigured during execution. In order to test all possible paths through aconfiguration, a method for setting the outcome of external choices (inventory check, credit check, and suppliercheck) is included. The reconfiguration operation is presented in two forms: the first allows reconfiguration to anyarbitrary configuration; the second extends this with a pre-condition to permit only safe reconfiguration. Finally,the Test module is described that includes operations to test all possible paths through the two configurations(in Sect. 4.3).

Workflows and traces

The Configurations module defines types that are used to represent the workflows from Figs. 2 and 3 and areused by the interpreter (shown later). The module also defines two constants that instantiate these workflows, atype to represent a trace of a workflow execution, and some useful auxiliary functions. The types, functions, andvalues of this module are made available to both the other modules using the exports all declaration:

Listing 4.2: Configurations module definition�

module Configurations

exports all

definitions

...

end Configurations

��

The types for capturing workflows and their traces are built around a core type called Action, which enumeratesall possible actions in a workflow (and therefore also in a trace). Any action must be exactly one of the nine listedvalues. The type union is defined using the pipe (|) operator, and the individual values are quote types (basicvalues that can only be compared for equality):

Listing 4.3: Action type definition�

types

-- actions in a workflowAction = <OrderReceipt > | <InventoryCheck > | <Reject >

| <CreditCheck > | <SupplierCheck > | <Shipping >| <Billing > | <Archiving > | <Confirmation >;

��

Based on this type, we define a trace as a sequence of events recording either the occurrence of an action, or aspecial <TERMINATE> event indicating successful completion of a workflow. The invariant on Trace states that ifa termination event occurs, it must occur at the end (i.e. if it appears in a trace of n elements and is not the onlyelement, then it does not appear in the first n − 1 elements):

2 Notice that the Overture tool interprets a VDM-SL specification in the sense that it does not perform a compilation beforehand. We usethe term execute to describe what the interpreter in our model does to a workflow.


Listing 4.4: Event and Trace type definitions�

types

-- record of an action or terminationEvent = Action | <TERMINATE >;

-- trace of eventsTrace = seq of Eventinv t == (<TERMINATE > in set elems t and len t > 1) =>

<TERMINATE > not in set elems t(1, ..., len t - 1);

��

To define a workflow type, it is necessary to allow an order for actions to be specified; this could be done with asequence. However, in this study a recursive definition is used based around a type called Workflow:

Listing 4.5: Workflow type definition�

types

-- workflow with invariantWorkflow = Elementinv w == forall tr in set tracesof(w) & card elems tr = len tr;

-- elements that make up a workflowElement = [Simple | Branch | Par];

��

This definition states that an Element can be one of three other types (expanded below): Simple represents asingle transition such as order receipt to inventory check; Branch represents an OK? choice, such as the creditcheck; and Par represents parallel composition. The square brackets make the type optional, meaning that it cantake a fourth special value (nil) that represents termination (the black circles in Figs. 2, 3).

The Element type can be used ‘as-is’ to represent workflow configurations, but it is not restricted in any way.For example, it can contain repeated actions (i.e. billing or shipping twice). Therefore, we introduce a Workflowtype3 with an invariant that prevents duplicates (by checking that for all possible traces of the workflow, thecardinality of the set of events in the trace is the same as the length of the trace).

The three types of Element are defined as follows:

Listing 4.6: Simple, Branch, and Par type definitions�

types

-- a simple elementSimple :: a : Action

w : Workflow;

-- a conditional elementBranch :: a : Action

t : Workflowf : Workflow;

-- parallel elementsPar :: b1 : Action

b2 : Actionw : Workflow;

��

The above three definitions are record types, that is, compound types with named elements. Each type containsone or more actions to be executed, and one or more elements that follow this action. Therefore, the definitionsare recursive, and the recursion is terminated by a nil value at each leaf. A simple workflow (called T) that rejectsall orders could be defined as:

Listing 4.7: Example workflow definition�

values

T = mk_Simple(<OrderReceipt >, mk_Simple(<Reject >, nil))

��

3 Separating the Element and Workflow definitions is necessary in order to allow the Overture tool to check the invariant at runtime.


Notice that the mk keyword is a constructor used to instantiate values of record types. They are essentially(automatically defined) functions that construct a record with the parameters being assigned, in order, to namedelements.

The Configurations module also defines two auxiliary functions that are useful for invariants and pre-conditions seen later. The first (prefixof) determines if one trace is a prefix of another and the second (tracesof)recursively computes all traces of an element:

Listing 4.8: Headers of the auxiliary functions prefixof and tracesof�

functions

-- true if a is a prefix of b, false otherwiseprefixof: Trace * Trace -> boolprefixof(a, b) == ...

-- compute all traces of an elementtracesof: Element -> set of Tracetracesof(el) == ...

��

Finally, the module defines values (constants) that describe the two configurations from Sect. 3, calledConfiguration1 and Configuration2 respectively:

Listing 4.9: Definitions of Configuration1 and Configuration2�

values

-- first configuration -- second configurationConfiguration1: Workflow = Configuration2: Workflow =

mk_Simple(<OrderReceipt >, mk_Simple(<OrderReceipt >,mk_Branch(<InventoryCheck >, mk_Branch(<InventoryCheck >,

mk_Branch(<CreditCheck >, mk_Branch(<CreditCheck >,mk_Simple(<Shipping >, mk_Par(<Billing >, <Shipping >,

mk_Simple(<Billing >, mk_Simple(<Archiving >, nil)),mk_Simple(<Archiving >, mk_Simple(<Reject >, nil)

mk_Simple(<Confirmation >, nil) ),) mk_Branch(<SupplierCheck >,

) mk_Branch(<CreditCheck >,), mk_Par(<Billing >, <Shipping >,mk_Simple(<Reject >, nil) mk_Simple(<Archiving >, nil)),

), mk_Simple(<Reject >, nil)mk_Simple(<Reject >, nil) ),

) mk_Simple(<Reject >, nil)); )

));

��

Interpreter

The Interpretermodule allows aworkflow to be executed. Themodule exports its definitions so that they can beaccessed by the Testmodule, and it imports required type definitions from the Configurationsmodule, includ-ing the definitions of actions, the prefixof and tracesof auxiliary functions, and the values of Configuration1and Configuration2.

Listing 4.10: Interpreter module definition�

module Interpreter

exports all

imports from Configurations types Workflow , Trace , ...

��


In the VDM idiom, models typically have persistent state, and operations that alter this state. The state of theInterpretermodule records the trace of the execution so far (trace) and the remaining workflow to be executed(workflow). A state is similar to a record type and is defined in a similar manner (the state definition acts as itsown section type):

Listing 4.11: Interpreter state definition�

-- interpreter statestate S of

trace : Traceworkflow : Workflow

init s == s = mk_S([], nil)end;

��

The above state definition contains an init clause that gives initial values to both components of the state (theyare both ‘empty’). An invariant can also be defined with an inv clause. The module provides operations to set(and reset) the state of the interpreter, to step through execution of a workflow or execute it in a single step, andto access the current value of the trace. Operations for reconfiguration are also included and are described below(see Reconfiguration).

An operation called Init is used to prime (set and reset) the interpreter with aworkflow passed as a parameterand an empty trace:

Listing 4.12: Init operation definition�

operations

Init: Workflow ==> ()Init(w) == (

trace := [];workflow := w

);

��

The basic operation of the interpreter is to move an action from the head of workflow and append it to the endof the trace. Once the workflow is empty, the <TERMINATE> element is added to the trace and the execution ends.Since there is no data model underlying the workflow, no additional work is done when moving an action fromthe workflow to the trace. However, an extension is considered towards this in Sect. 4.5.

The absence of a data model also means that the external choices in the workflow (the inventory check, creditcheck, and supplier check) must be made in some other manner. The main analysis method for this model istesting (described in Sect. 4.3). Therefore, it is desirable to be able to control these external choices to ensure testcoverage. In order to do this, a Choices type is introduced, which is a mapping from (choice) actions to Boolean.The invariant ensures that the domain of the map is exactly the set of actions that represent external choices:

Listing 4.13: Choices type definition�

types

-- collapse probabilitiesChoices = map Action to boolinv c == dom c = {<InventoryCheck >, <CreditCheck >, <SupplierCheck >}

��


For example, a run of the workflow where there is sufficient inventory and sufficient credit can be achievedusing the Choices given below. Notice that in this case a supplier check will not be needed because there issufficient stock:

Listing 4.14: NoProblems value definition�

values

-- all branches trueNoProblems = {<InventoryCheck > |-> true ,

<SupplierCheck > |-> true ,<CreditCheck > |-> true};

��

The Interpretermodule defines two operations that execute a workflow, Step and Execute, with the followingsignatures:

Listing 4.15: Step and Execute operation headers�

operations

-- perform a single step of the interpreterStep: Choices ==> Event

-- execute workflow in one goExecute: Choices ==> ()

��

The Step operation performs a single step of execution, updating the trace and moving to the next step of theworkflow. This operation selects the outcome of Branch elements based on the Choices passed as a parameter,and the order of execution of actions in Par elements are selected randomly leading to interleaving of the actions.The Step operation returns the last event that occurred, which is used for reconfiguration (described below). TheExecute operation uses Step operation to execute a workflow and produce a full trace. The let expression isused to ignore the value returned by Step, since it is not needed for a simple execution run:

Listing 4.16: Execute operation definition�

operations

-- execute workflow in one goExecute: Choices ==> ()Execute(c) == (

while workflow <> nil dolet - = Step(c) in skip;

trace := trace ^ [<TERMINATE >]);

��

Reconfiguration

Reconfiguration is enabled by an operation in the Interpreter module. This operation replaces the currentworkflow in the state by another workflow during execution. We consider the case of a single thread of executionmoving from some point in Configuration1 to an appropriate point in Configuration2, with extensions discussedlater.

The following operation is defined in the Interpretermodule that replaces the workflow in the state by theworkflow passed as a parameter to the operation. The point at which this operation is called, and the workflowpassed to the operation, are left to the caller. In this way, the model is able to capture unplanned reconfiguration.


Listing 4.17: Unprotected Reconfigure operation definition�

operations

-- reconfigure , replacing current workflowReconfigure: Workflow ==> ()Reconfigure(w) ==

workflow := w;

��

In this unprotected form, the calling thread is able to make arbitrary changes to the workflow, resulting in tracesthat do not meet the requirements described earlier. For example, double billing a customer by reconfiguring toa workflow with a <Billing> element after billing had already occurred. This is avoided by adding an invari-ant to the state that disallows configurations that could generate illegal traces. Additionally, a pre-condition isadded to the Reconfigure operation to protect the invariant, ensuring that the operation only processes validreconfigurations. Ideally, invariants should be protected by pre-conditions on operations in this fashion, so thatinvariants form a ‘last line of defence’.

It is a requirement that traces produced by the interpreter must be traces of Configuration 1 or Configuration2. Therefore, the invariant states that, given the current trace (which can be empty), the remaining workflow canonly produce traces valid under Configuration 1 or Configuration 2. Similarly, the pre-condition checks that thenewworkflow can only produce valid traces of Configuration 2 (since we currently only consider reconfigurationsfrom Configuration 1 to Configuration 2). With the pre-condition added, the Reconfigure operation is definedas follows:

Listing 4.18: Reconfigure operation with pre-condition�

-- reconfigure , replacing current workflowReconfigure: Workflow ==> ()Reconfigure(w) ==

workflow := wpre w <> nil and

branch_check(trace , workflow , w) andforall t in set {trace ^ ftr | ftr in set tracesof(w)} &

(exists x in set tracesof(Configuration2) & t = x);

��

The pre-condition requires first that the newworkflow is not empty. Second, the branch check auxiliary function(described below) is used to check that the reconfiguration takes account of the outcome of branching actions.Finally, the tracesof auxiliary function is used to check that, for all traces in the set of traces produced byappending the possible traces of the new configuration to the current trace, the resulting trace is a valid trace ofConfiguration 2. The & denotes ‘such that’ in these quantifications. Therefore, all traces that could occur afterreconfiguration are valid under Configuration 2.

The branch check auxiliary function is defined as follows:

Listing 4.19: branch check auxiliary function�

branch_check: Trace * Workflow * Workflow -> boolbranch_check(tr, w, w’) ==

(last(tr) = <InventoryCheck > and first(w) = {<Reject >}=> {<SupplierCheck >} subset first(w’)) and

(last(tr) = <InventoryCheck > and first(w) = {<CreditCheck >}=> {<CreditCheck >} subset first(w’)) and

(last(tr) = <CreditCheck > and first(w) = {<Reject >}=> {<Reject >} subset first(w’)) and

(last(tr) = <CreditCheck > and first(w) = {<Shipping >}=> first(w’) subset {<Billing >, <Shipping >});

��

The above check is necessary in order to take account of the outcome of a branching action. For example, ifthe inventory check passes, then the external supplier check should not be performed. Since actions are notparameterised in this model, the only way to tell which branch (true or false) was taken by the action is toexamine the first element of the remaining workflow, and to check that the first element of the new workflow isa valid replacement. The branch check function explicitly encodes this checking for the inventory check andcredit check. A more general solution is to pass parameters to workflow actions (e.g. to indicate the outcome ofan evaluation action) and to pass a verification condition parameter to Reconfigure. Extensions are discussedin Sect. 4.5.


An invariant is added to the state that is defined similarly to the pre-condition of Reconfigure. However, theinvariant requires that the traces must belong to either Configuration1 or Configuration2, and prefixof isused rather than equality since the trace is incomplete in the intermediate state.

Listing 4.20: Interpreter state definition with invariant�

-- interpreter statestate S of

trace : Traceworkflow : Workflow

init s == s = mk_S([], nil)inv mk_S(trace , workflow) ==

workflow <> nil =>(forall t in set {trace ^ tr | tr in set tracesof(workflow )} &

(exists x in set tracesof(Configuration1) union tracesof(Configuration2) &prefixof(t, x)))

end;

��

4.3. Analysis

The Testmodule defines operations that test both configurations with the five combinations of external choices.These operations call the operations of the Interpretermodule (using the back tick operator: ‘) and output thetrace, which can then be printed to the console inOverture. For example, the operation that tests Configuration1with the NoProblems choices is defined below. This operation initialises the interpreter with Configuration1,executes the interpreter and returns the completed trace:

Listing 4.21: Config1NoProblems operation definition�

module Test

operations

-- Test Configuration 1 / NoProblemsConfig1NoProblems: () ==> TraceConfig1NoProblems() == (

Interpreter ‘Init(Configuration1 );Interpreter ‘Execute(NoProblems );return Interpreter ‘GetTrace ()

);

��

When printed to the console, the output of the Config1NoProblems operation shows the following trace:

Listing 4.22: Output of Config1NoProblems definition�

Test ‘Config1NoProblems() =[<OrderReceipt >, <InventoryCheck >, <CreditCheck >,<Shipping >, <Billing >, <Archiving >, <Confirmation >,<TERMINATE >]

��

Tests are also defined for the other combinations of choices, and named accordingly. For example, the test wherethe Choices map yields false for the credit check is called Config1NoCredit (see online Appendix A).


In order to test the reconfiguration operation, and demonstrate the outcome of a valid and invalid reconfig-uration request, the test module defines an operation called TestReconfig, that takes the Choices required forexecution (c), an action (rp) and a workflow (w) as parameters:

Listing 4.23: TestReconfig operation signature�

operations

TestReconfig: Choices * Action * Workflow ==> ()TestReconfig(c, rp, w) == ...

��

The operation initialises the interpreter, then steps through the execution until the action rp is seen, then attemptsto reconfigure the interpreter to the workflow w. If the reconfiguration is valid under the requirements, the finaltrace will be printed. Otherwise, a message is printed stating that the reconfiguration is invalid (and that thepre-condition would fail if execution continued). In the model as presented, the w passed to the operation isconstructed manually as a suffix of Configuration2. This is a weakness of the model. Discussion of automatingsuch testing appears in Sect. 4.5 below.

Using TestReconfig, two operations are defined that demonstrate a valid and invalid reconfiguration respec-tively. The first, TestReconfigSuccess, reconfigures from Configuration1 to Configuration2 after the inven-tory check (where there is no inventory in stock, so a supplier check is performed). This is a valid reconfiguration,and the console output is as follows:

Listing 4.24: Output of TestReconfigSuccess operation�

[<OrderReceipt >, <InventoryCheck >]Reconfiguring Configuration1 to Configuration2 ...[<OrderReceipt >, <InventoryCheck >, <SupplierCheck >,<CreditCheck >, <Billing >, <Shipping >, <Archiving >,<TERMINATE >]

��

The second operation, TestReconfigFail, attempts to reconfigure from Configuration1 to the parallel com-position of shipping and billing in Configuration2 after shipping has already occurred. This is an invalidreconfiguration, since shipping will occur twice. The output on the console is as below:

Listing 4.25: Output of TestReconfigFail operation�

[<OrderReceipt >, <InventoryCheck >, <CreditCheck >,<Shipping >]

Reconfiguring Configuration1 to Configuration2 ...These potential traces are not valid under Configuration2:* [<OrderReceipt >, <InventoryCheck >, <CreditCheck >,

<Shipping >, <Billing >, <Shipping >, <Archiving >]* [<OrderReceipt >, <InventoryCheck >, <CreditCheck >,

<Shipping >, <Shipping >, <Billing >, <Archiving >]

��

Notice that the Overture tool terminates with an error due to pre-condition failure:

Listing 4.26: Pre-condition failure reported by the Overture tool�

Reconfiguration could generate invalid traces; pre-condition will fail.

Error 4071: Precondition failure: pre Reconfigure in‘Interpreter’

��


4.4. LTS semantics

As part of the ISO standard, a full denotational semantics has been defined for VDM-SL [LP95, ISO96]. Struc-tured operational semantics (SOS) have also been defined for some of the new language features introduced innewer dialects [LCL13]. However, in order to facilitate comparison with the other two formalisms, we develop alabelled transition system (LTS) semantics for the VDM model. Such an LTS would be unwieldy for the wholesemantics defined in the ISO standard, so we restrict this LTS to this model of the case study. This means that ifthe model were to be changed, the LTS would have to be updated. In the general case, this is unwieldy and is nottypically part of a VDM development, but it is instructive in this instance.

The LTS rules are given in Table 1. The rules are relations that define transitions between tuples of type(Trace × Workflow ), corresponding to the state (S) of the interpreter. The labels on the transitions correspondto the actions that the workflow performs (which are appended to the trace), or τ for unobservable steps (that donot append items to the trace). The LTS rules are defined using the choices and pre Reconfigure functionsdefined in the VDMmodel in order to render the rule definitions concise and human-readable.

The Init rule states that the interpreter can be given a workflow when it does not currently have one and itstrace is empty. This is the initial state of S as defined above: init s == s = mk S([], nil). The Terminate ruleallows the interpreter to terminate when it has no workflow left. The Reset rule allows a terminated interpreterto be reset with another workflow.

The Simple, Branch-T, Branch-F, Par-1 and Par-2 rules encode the logic of the Step operation introducedabove (though not given in full). They correspond to the three elements that form the Workflow type. The actionof a Simple element can always happen. The action performed by a Branch action depends on the choicesparameter that is passed to the Execute operation. For the Par element, the two rules have no hypotheses andtherefore it is non-deterministic choice of which action is performed first. These rules make it clear that thismodel has an interleaving semantics. The Reconfigure rule states that the workflow that is still to be executedcan be replaced in one atomic step, assuming that the new workflow will not violate the pre-condition of theReconfigure operation.

We give three examples of application of the LTS rules in Fig. 4. The first (top) demonstrates a complete run ofthe workflow and is equivalent to the Config1NoProblems test. The second (middle) demonstrates a run in whichthe credit check yields false and is equivalent to the Config1NoCredit test. The third (bottom) demonstratesa reconfiguration from Configuration 1 to Configuration 2 after the inventory check and is equivalent to theTestReconfigSuccess test. Model checking of the reconfiguration is facilitated by the trace of actions and theLTS rule applications, and is shown in online Appendix B.

4.5. Extensions

Themodel describes an interpreter with a single thread. Therefore, interference is not considered beyond the non-deterministic execution of parallel compositions. To allow multiple threads of control, the state of the interpretermust be extended to allow a set of workflows (and their associated traces) to be defined. The reconfigurationoperation must then be extended to reconfigure each thread in turn. This would allow the model to exhibitconcurrent application and reconfiguration actions (Case 3 in Fig. 1). Actions are atomic in the current model,so there is no way to abort actions. To extend the model to allow this, a notion of beginning and completingactions would be required. This could be achieved either by having ‘begin’ and ‘end’ forms of each action, as usedin [CJ07] to investigate fine-grained concurrency in programming languages, or by defining a ‘current action’ inthe state, which is placed there and removed when completed. If reconfiguration occurs between the beginningand end of an action, or if there is a current action present in the state, then an abort occurs.


Table 1. Labelled transition system semantics of the basic VDM model

Init w ∈ Workflow

([], nil)τ−→ ([], w )

Terminate <TERMINATE> �∈ elems tr

(tr , nil)τ−→ (tr ∧ [<TERMINATE>], nil)

Reset <TERMINATE> ∈ elems tr

(tr , nil)τ−→ ([], nil)

Simple(tr , mk Simple(a, e))

a−→ (tr ∧ [a ], e)

Branch-T choices(a)

(tr , mk Branch(a, t, f ))a−→ (tr ∧ [a ], t)

Branch-F ¬choices(a)

(tr , mk Branch(a, t, f ))a−→ (tr ∧ [a ], f )

Par-1(tr , mk Par (b1, b2, e))

b1−→ (tr ∧ [b1], mk Simple(b2, e))Par-2

(tr , mk Par (b1, b2, e))b2−→ (tr ∧ [b2], mk Simple(b1, e))

Reconfigure w ′ ∈ Workflow ∧ pre Reconfigure(tr , w ′)(tr , w )

τ−→ (tr , w ′)

Fig. 4. Examples of LTS rule applications for the VDMmodel


As mentioned at the beginning of this section, there are two further dialects of VDM. These use VDM-SLas their core specification language, but extend it with additional features. VDM++ adds object-orientation andconcurrency through threads. VDM-RT extends VDM++ to add features for modelling real-time embeddedsystems. These are a global ‘wall clock’ that is advanced as expressions are evaluated (to predict real-worldexecution time), and models of compute nodes connected by buses on which objects can be deployed. The(simulated) time taken to evaluate language expressions depends on the speed of the compute nodes and buses,and can be overridden to tune amodel, where measurements of the actual speed of the target system can bemade,in order to make better predictions of behaviour of the final code.

These twodialects are oftenusedaspart of adevelopmentprocess [LFW09] that beginswith a sequentialmodelof the system, which can be constructed in VDM-SL or in VDM++. Conversion from VDM-SL to VDM++ isstraightforward as the core language is the same, the main changes are to turn modules into classes and to turnthe state definition into instance variables. The sequential model is then extended to allow concurrent execution,then a real-time version is made that captures the resources and configuration of the target hardware for whichcode will be written. VDM++ could be used to extend the model and capture true concurrency, allowing Designs2, 3 and 4 (in Sect. 3.3) to be modelled.

In addition, extending the model to use VDM++ allows additional features of the Overture tool to be used.In the above model, tests were created manually and executed for all possible configurations. This is obviouslycumbersome and unscalable for more complicated models. For VDM++ models, Overture has combinatorialtesting features that allow tests to be created using regular expressions. Overture also has true unit testing forVDM++ models.

To extend themodel to allow reconfiguration fromConfiguration 2 back toConfiguration 1, the pre-conditionon Reconfigure needs to be relaxed to permit future traces from both configurations (not just Configuration2 in the current model). To extend the model to add further configurations, a few steps are necessary. First, theconfiguration must be defined as a value in the Configurationsmodule (for example, Configuration3). Testsfor this new configuration should be added to the Testmodule and executed. Finally, the pre-condition must beextended to consider traces of the new configuration to be valid. This is simple if it is acceptable to switch betweenany configuration at any time. However, the definitions would be more complicated if there were restrictions onreconfiguration. For example, if there are ‘points of no return’ in between different configurations.

In Sect. 4.2, extending the current model with a model of data was suggested. This extension represents anaugmentation of the current workflowmodels with the data and operations necessary to allow customers to placeorders. This could include data types for representing orders, such as the following:

Listing 4.27: Example data types for modelling the order system�

CustId = token;OrderId = token;

Order :: custid : CustIdinventoryOK : [bool]

creditOK : [bool]accept : [bool];

state Office oforders : map OrderId to Order

end

��

The above defines identifiers for customers and orders using token types (a countably infinite set of distinct valuesthat can be compared for equality and inequality). The Order type is a record that identifies a customer and thestatus of the order: whether or not the checks have been passed, and whether the order is accepted. The state ofthe model stores all orders in the orders map.

To continue this model, operations should be defined to receive and evaluate orders, and to accept or rejectthem, then to notify the customer, to bill and ship, and finally to archive. Each should manipulate the data modeland be protected by pre-conditions to ensure consistency and make explicit any assumption about the system.


The following implicit operation, defined only in terms of pre- and post-conditions, evaluates an order. Thepre-condition states that the ordermust be known (in the domainof theorders state variable) andbeunprocessed.The post-condition states that the ordersmap should contain an updated record for this order with the result ofthe inventory and credit check. The mu expression allows record values to be overwritten, rather than constructinga new copy with the mk constructor.

Listing 4.28: Example implicit operation to Evaluate an order�

EvaluateOrder(oid:OrderId)ext wr orderspre oid in set dom orders and

orders(oid). inventoryOK = nil andorders(oid). creditOK = nil andorders(oid). accept = nil

post exists iOK , cOK : bool & orders = orders~ ++{oid |-> mu(orders(oid),

inventoryOK |-> iOK , creditOK |-> cOK)};

��

This extended data model could then be connected to the existing interpreter, such that when elements of theworkflow are executed, calls are made to the operations that manipulate the data model. The extended modelwould demonstrate whether it was possible to build an actual order system thatmet the requirements, particularlywhen new configurations are introduced. The data and operations could then be used as a specification duringimplementation in some programming language.

5. Conditional partial order graphs

Conditional partial order graphs (CPOGs) [Mok09] were originally introduced for reasoning about propertiesof families of graphs in the context of asynchronous microcontroller design [MY10] and processors with recon-figurable microarchitecture [MRSY14]. CPOGs are related to featured transition systems (FTSs) that are used tomodel feature families of software product lines [CHS+10]. The key difference between FTSs and CPOGs is thatFTSs use transition systems as the underlying formalism, whereas CPOGs are built on top of partial orders, whichenables the modelling of true concurrency. In this paper, CPOGs are used to represent compactly graph familiesin which each graph expresses a workflow scenario (i.e. a particular collection of outcomes of branching actionsof a workflow) or a particular collection of requirements on workflow actions and their order. For example, therequirements on Configuration 1 of the case study workflow (shown in Fig. 2) can be expressed using a family ofthree simple (i.e. branch-free) graphs (see Fig. 5). We use the term family instead of the more general term set toemphasise the fact that the graphs are annotated with branch decisions, in this case:

• Inventory check OK: No• Inventory check OK: Yes, credit check OK: No• Inventory check OK: Yes, credit check OK: Yes

This can be expressed equivalently using the following predicates:

• ¬(InventoryCheck OK)• (InventoryCheck OK) ∧ ¬(CreditCheck OK)• (InventoryCheck OK) ∧ (CreditCheck OK)

where InventoryCheck and CreditCheck are the names of the two branch actions. Henceforth, we adopt thepredicate notation.


Fig. 5. Expressing workflow requirements on Configuration 1 by a family of graphs (see Fig. 2)

The remainder of this section is organized as follows. In Sect. 5.1 an axiomatic semantics of CPOGs is givenand basic workflow modelling primitives are introduced, which are used in Sect. 5.2 to model the case studyworkflow and to demonstrate how CPOGs can be used for workflow verification by reduction to the BooleanSatisfiability (SAT) problem. An LTS semantics of CPOGs is defined in Sect. 5.3, thereby establishing a formallink with the other two formalisms discussed in this paper. Dynamic reconfiguration is discussed in Sect. 5.4, andwe show that CPOGs use true concurrency semantics when modelling functional interference between workflowand reconfiguration actions. We comment on our experience of automating the verification of the workflowrequirements in Sect. 5.5, and give an overall evaluation of the CPOG-based approach in Sect. 7.

5.1. Formalism

The axiomatic semantics of CPOGs is outlined below, and was first introduced in [MK14] to provide efficientcompositionality and abstraction facilities for graphs. Each element of the algebra represents a family of graphs,and is defined as follows:

Let A be the alphabet of names of actions (e.g. OrderReceipt and InventoryCheck) that represent tasks andsubtasks. Actions can have order dependencies between them.A is used to construct models of workflows and todefine their requirements using the following axioms:

• The empty workflow is denoted by ε, that is, the empty family of graphs.• A workflow consisting of a single action a ∈A is denoted simply by a. It corresponds to a family consistingof a single graph that contains a single vertex a.

• The parallel composition of workflows p and q is denoted by p + q (e.g. the concurrent execution of Billingand Shipping shown in Fig. 3 is denoted by Billing + Shipping). The operator + is commutative, associative,and has ε as the identity:

1. p + q � q + p 2. p + (q + r ) � (p + q) + r 3. p + ε � p

Intuitively, p + q means ‘execute workflows p and q concurrently, synchronising on common actions’.• The sequential composition of workflows p and q is denoted by p → q (e.g. the sequential execution ofShipping followed by Billing shown in Fig. 2 is denoted by Shipping → Billing). The operator → hasa higher precedence than +, is associative, has the same identity (ε) as +, distributes over +, and can bedecomposed into pairwise sequences:


1. p → (q → r ) � (p → q) → r2. p → ε � p and ε → p � p3. p → (q + r ) � p → q + p → r and (p + q) → r � p → r + q → r4. p → q → r � p → q + p → r + q → r

Intuitively, p → q means ‘execute workflow p, then execute workflow q ’. In other words, introduce orderdependencies between all actions in p and all actions in q . Note that if p and q contain common actions theycannot be executed in sequence, as illustrated by an example below.

Figure 6 shows an example of parallel and sequential composition of graphs. It can be seen that the parallelcomposition does not introduce any new order dependency between actions in different graphs; therefore,the actions can be executed concurrently. Sequential composition, on the other hand, imposes order on theactions by introducing new dependencies between actions p, q , and r in the top graph and action s in thebottom graph. Hence, the resulting workflow behaviour is interpreted as the behaviour specified by the topgraph followed by the behaviour specified by the bottom graph. Another example of these operations is shownin Fig. 7. Since the graphs have common vertices, their compositions aremore complicated, in particular, theirsequential composition contains the self-dependencies (q, q) and (s, s) which lead to a deadlock in the resultingworkflow. Action p can occur, but all the remaining actions are locked: neither q nor s can proceed due tothe self-dependencies, while r cannot proceed without q and s . Figures 8a and b illustrate the distributivityand decomposition axioms respectively.

• A conditional workflow is denoted by [x ]p, where x is a predicate expressing a certain condition (e.g. ‘InventoryCheck OK’) and p is a workflow. Intuitively, [x ]p means ‘execute workflow p only if condition x holds’. Wepostulate that [1]p � p and [0]p � ε. This allows us to model branching in flow charts. For example, thealgebraic expression

a → ([x ]p + [¬x ]q)

corresponds to a branching performed after action a ∈ A, which is followed by workflow p if predicate xholds, and by workflow q if predicate x does not hold. Alternatively, we can say that the above expressioncorresponds to a family of graphs, in which vertex a is followed by actions from the graphs coming eitherfrom family p or from family q , as illustrated in Fig. 8c, where a dotted line between vertex a and variablex indicates that the variable is assigned a value during the execution of action a. We will use the followingshort-hand notation for a clearer correspondence with flow charts:{

a Yes−→ p df� a → [A OK]p

a No−→ p df� a → [¬(A OK)]p

where predicate ‘A OK’ corresponds to the successful completion of a branching action a. For example, theexpression

InventoryCheckYes−→ CreditCheck + InventoryCheck

No−→ Reject → End

corresponds to the first branching in Fig. 2: if the inventory check is completed successfully the workflowcontinues with the credit check, otherwise the order is rejected and the workflow ends (actions Start and Enddenote respectively the start and end circles used in the flow chart).


Fig. 6. Parallel and sequential composition example (no common vertex)

Fig. 7. Parallel and sequential composition example (common vertices)

Notice that operatorsYes−→ and

No−→ bind less tightly than → to reduce the number of parentheses. Operator[x ] has the highest precedence and has the following useful properties (proved in [MK14]):

1. [x ∧ y ]p � [x ][y ]p 2. [x ∨ y ]p � [x ]p + [y ]p

3. [x ](p + q) � [x ]p + [x ]q 4. [x ](p → q) � [x ]p → [x ]q

Notice that the condition operator can be used not only to create conditional workflows, but also to createconditional workflow dependencies. For example, in the expression p + q + [x ](p → q), if x � 0, the expressionsimplifies to the parallel composition p + q , but if x � 1, the expression simplifies to the sequential compositionp → q . In other words, actions in q conditionally depend on actions in p.

To summarise, the following operators are used to create and manipulate graph families corresponding toworkflows (in decreasing order of precedence):

[x ]p, p → q , a Yes−→ p, a No−→ p, and p + q , where a is an action, x is a predicate, and p and q are workflows.

The algebraic notation is used to translate flow charts into mathematical descriptions amenable to automatedverification, as described in the next subsection.

5.2. Modelling and analysis

The granularity of concurrency in CPOGs is a single action, and the granularity of reconfiguration is a singleaction and a single dependency between actions. Multiple actions and dependencies can also be reconfiguredby a single reconfiguration action that sets Boolean variables in the predicates that guard the actions and theirdependencies. Thus, it is possible to model all three cases of dynamic reconfiguration identified in Sect. 1. ACPOG can easily express concurrent actions, and (therefore) Case 3 of reconfiguration fits the CPOG ‘idiom’best. However, we have modelled Case 1 of reconfiguration for simplicity. Notice that the different designs of thecase study workflow configurations are represented as the same CPOGmodel, because CPOGs cannot representcyclic processes.

We now describe how to specify workflow requirements and their reconfiguration as families of graphs, howto reason about the correctness of such specifications, and how to manipulate them using the operators of thealgebra.


(a)

(b)

(c)

(d)

Fig. 8.Manipulating parameterised graphs. a Distributivity, b Decomposition, c Branching graph family, d Transitive reduction/closure

The algebraic notation can be used to translate the flow chart in Fig. 2 into the following expression:

c1 � Start → OrderReceipt → (

InventoryCheckNo−→ Reject → End +

InventoryCheckYes−→ (

CreditCheckNo−→ Reject → End +

CreditCheckYes−→ Shipping → Billing → Archiving → Confirmation → End

))

The expression can be rewritten using the axioms in order to prove that certain requirements hold. For example,any expression can be rewritten into a so-called canonical form [MK14], which is sufficient for checking most ofthe requirements listed in Sect. 3.1.


Proposition 1 Any workflow expression can be rewritten in the following canonical form [MK14]:(∑a∈V

[fa ]a

)+

( ∑a,b∈V

[fab ](a → b)

)(1)

where:

• V is a subset of actions that appear in the original expression;• for all a∈V , fa are canonical forms of Boolean expressions and are distinct from 0;• for all a, b∈V , fab are canonical forms of Boolean expressions such that fab ⇒ fa ∧ fb (that is, a dependencybetween actions a and b can exist only if both actions exist).

In other words, the canonical form of an expression lists all constituent actions and all pairwise dependenciesbetween them (along with their predicates). The canonical form can contain redundant transitive dependencies,such as p → r in presence of both p → q and q → r . Such terms can be eliminated to simplify the resultingexpression. This corresponds to the well-known transitive reduction procedure, which can be formalised by addingthe following axiom [MK14]:

if q �� ε then p → q + p → r + q → r � p → q + q → r

The axiom can be used to add or to remove transitive dependencies as necessary, see Fig. 8d.Rewriting a workflow expression manually by following the CPOG axioms is tedious and error-prone. This

motivated us to automate computation of the canonical form and the transitive reduction, as will be discussedin Sect. 5.5. By applying these procedures to c1 we obtain its reduced canonical form shown below. For brevity,we will denote predicates InventoryCheck OK and CreditCheck OK simply by x and y respectively. Actions arevisually separated from dependencies by a horizontal line.

c1 � [1]Start + [1]OrderReceipt +[1]InventoryCheck + [x ∨ y ]Reject +[1]End + [x ]CreditCheck +[x ∧ y ]Billing + [x ∧ y ]Shipping +[x ∧ y ]Archiving + [x ∧ y ]Confirmation +

[1](Start → OrderReceipt) +[1](OrderReceipt → InventoryCheck) +[x ](InventoryCheck → CreditCheck) +[x ](InventoryCheck → Reject) +[x ∧ y ](CreditCheck → Reject) +[x ∨ y ](Reject → End) +[x ∧ y ](CreditCheck → Shipping) +[x ∧ y ](Shipping → Billing) +[x ∧ y ](Billing → Archiving) +[x ∧ y ](Archiving → Confirmation) +[x ∧ y ](Confirmation → End)

The resulting expression gives us plenty of valuable information that can be used for analysis of the workflow. Inparticular, the following correctness properties can be verified:

• The starting and ending actions are part of the workflow regardless of possible outcomes of the branchingactions, as indicated by ‘unconditional’ terms [1]Start and [1]End.

• The billing, shipping, archiving, and confirmation actions are performed if and only if both the inventory andinternal credit checks are successful; in fact, all these actions are pre-conditioned with the predicate x ∧ y .

• An order is rejected if either the inventory check or the internal credit check fails, as confirmed by term[x ∨ y ]Reject.

• The first action after Start is always OrderReceipt, as confirmed by term [1](Start → OrderReceipt) and thefact that all other actions transitively depend on OrderReceipt.

• The shipping and billing actions are always performed sequentially: whenever the actions occur([x ∧ y ]Billing and [x ∧ y ]Shipping) so does the dependency [x ∧ y ](Shipping → Billing).

• There are no cyclic dependencies and therefore each action is performed at most once.


We now translate the workflow requirements for Configuration 2 shown in Fig. 3 into our notation, verifyseveral relevant correctness properties, and highlight the differences between the two configurations. The flowchart in Fig. 3 can be translated into the following expression:

c2 � Start → OrderReceipt → (

InventoryCheckYes−→ cc +

InventoryCheckNo−→ (

SupplierCheckYes−→ cc

SupplierCheckNo−→ Reject → End

))

where expression cc corresponds to the part of the workflow starting with the CreditCheck action:

cc � CreditCheckNo−→ Reject → End +

CreditCheckYes−→ (Billing + Shipping) → Archiving → End

The ability to abstract and share/instantiate common behaviour (e.g. cc in the above workflow) is essentialfor specifying real-life reconfigurable systems, where monolithic specifications are impractical. Our prototypeimplementation supports abstraction and sharing (see Sect. 5.5 for further details).

Expression c2 can now be prepared for further analysis by converting it into the canonical form andtransitively reducing the result as described above. For brevity, we denote predicates InventoryCheck OK andSupplierCheck OK by x1 and x2 respectively, thereby emphasising that roles of inventory and supplier checks aresimilar; the predicate CreditCheck OK is denoted by y as before. The resulting expression is shown below.

c2 � [1]Start + [1]OrderReceipt + [1]End +[1]InventoryCheck + [x1]SupplierCheck +[x1 ∨ x2]CreditCheck + [x1 ∧ x2 ∨ y ]Reject +[(x1 ∨ x2) ∧ y ]Billing +[(x1 ∨ x2) ∧ y ]Shipping +[(x1 ∨ x2) ∧ y ]Archiving +

[1](Start → OrderReceipt) +[1](OrderReceipt → InventoryCheck) +[x1](InventoryCheck → SupplierCheck) +[x1](InventoryCheck → CreditCheck) +[x1 ∧ x2](SupplierCheck → CreditCheck) +[x1 ∧ x2](SupplierCheck → Reject) +[(x1 ∨ x2) ∧ y ](CreditCheck → Reject) +[x1 ∧ x2 ∨ y ](Reject → End) +[(x1 ∨ x2) ∧ y ](CreditCheck → Billing) +[(x1 ∨ x2) ∧ y ](CreditCheck → Shipping) +[(x1 ∨ x2) ∧ y ](Billing → Archiving) +[(x1 ∨ x2) ∧ y ](Shipping → Archiving) +[(x1 ∨ x2) ∧ y ](Archiving → End)

Using the derived expression, the following properties of Configuration 2 can be verified:

• The billing and shipping actions are concurrent as indicated by the lack of any dependency between them.This is different from Configuration 1 where the actions could only occur in sequence:[x ∧ y ](Shipping → Billing).

• The credit check is conducted when either inventory or supplier check is successful, as indicated by term[x1 ∨ x2]CreditCheck. Again, this is different from Configuration 1, where there was no way around theinventory check.


• Consequently, an order is rejected under the condition x1 ∧ x2 ∨ y , that is, when either both inventory andsupplier checks have failed, or the credit check has failed. By negating this condition we obtain (x1 ∨ x2)∧ y ,which guards the billing, shipping, and archiving actions, as well as dependencies between them.

• The confirmation action is missing in c2, as intended. We can also highlight this by adding a redundant term[0]Confirmation to c2.

As demonstrated above, Configurations 1 and 2 have several important differences. Hence, if a system’sconfiguration is dynamically changed from one configuration to another, the systemmay end up in an impossiblestate according to the new configuration. Such situations may lead to the system’s failure, and (therefore) mustbe prevented. In Sect. 5.4 we discuss how the CPOG-based modelling and verification approach can be used todescribe formally such situations, determine under which circumstances they can occur, and derive practicablereconfiguration guidelines to prevent their occurrence.

5.3. LTS semantics

In this section, we define an LTS semantics of CPOGs in order to facilitate comparison with the other twoformalisms. The definition is based on CPOG firing rules introduced in [Mok09] and the canonical form con-struction [MK14] (see Proposition 1).

According to (1), any algebraic CPOG expression can be uniquely represented by a directed graph (V ,E )whose vertices V and arcs E ⊆ V × V are labelled with Boolean conditions fa and fab (respectively) that aredefined on a set of Boolean variables X . A variable x ∈X is said to be controlled by a vertex vx ∈V if the valueof the variable x is changed by the action associated with the vertex vx . Notice there is at most one such vertexfor each variable. Therefore, the value of each variable can be changed at most once.

Given an assignment of variables ψ : X → {0, 1}, a vertex v ∈V and an arc (v1, v2)∈E are termed active iftheir respective conditions evaluate to 1 under the assignment, denoted by fv |ψ � 1 and fv1v2 |ψ � 1 respectively;otherwise, v and (v1, v2) are termed inactive. There are 2|X | possible variable assignments. Therefore, a CPOGcan describe up to 2|X | possible graphs comprised of active vertices and arcs.

The preset of a vertex v ∈ V , denoted by preset(v , ψ), is defined to be the set of active (determined by ψ)vertices that are connected to v by active arcs (u, v )∈E :

preset(v , ψ) � {u | u ∈ V ∧ fu |ψ � 1 ∧ fuv |ψ � 1 }.A history is a subset of active vertices H ⊆ V whose corresponding actions have already occurred. The

number of possible histories is bounded by 2|V |.A labelled transition system (LTS) is a triple (S ,A,→), where S is the set of states,A is the alphabet of actions

that label state transitions, and →: S × A × S is the transition relation. We will use the shorthand notations1

a−→ s2 to denote (s1, a, s2) belongs to the relation →.ACPOGdefines anLTSwith 2|V | ·2|X | states that correspond to all possible histories andvariable assignments.

Hence, every state s ∈ S is a pair (H , ψ). We fix the initial state s0 ∈ S to be equal to (∅,0) where 0 is the zerovariable assignment: 0(x ) � 0 for all x ∈X .

The alphabet of actions of the LTS directly corresponds to the CPOG vertices. Therefore, A � V .The transition relation can be captured by the following rule:

preset(w , ψ) ⊆ H ∧ w �∈H ∧ fw |ψ � 1 ∧ ∀ x ∈X (vx �� w ⇒ ψ ′(x ) � ψ(x ))(H , ψ)

w−−→ (H ∪ {w}, ψ ′)

In other words, the system can transition from state s1 � (H , ψ) to state s2 � (H ∪ {w}, ψ ′) by executing theaction corresponding to an active vertex w ∈ V if the vertex preset belongs to the history H and the action hasnot been performed previously. The new variable assignment ψ ′ must be identical to the old variable assignmentψ on all variables that are not controlled by vertex w .


Notice that the above rule defines the execution of a single action, and thereby defines an interleaving semanticsfor pseudo-concurrent actions. In order to define the semantics of true concurrency, the LTS syntax must beextended to enable a set of actions to be performed simultaneously, which results in the following alternative rulefor the transition relation:

∀w ∈W (preset(w , ψ) ⊆ H ∧ w �∈H ∧ fw |ψ � 1) ∧ ∀ x ∈X (vx �∈ W ⇒ ψ ′(x ) � ψ(x ))

(H , ψ)W−−−→ (H ∪ W , ψ ′)

Thus, the alternative rule allows multiple actions in a set W ⊆ V to be performed simultaneously. Hence, everydiamond{

s1X−−→ s ′ Y−−→ s2

s1Y−−→ s ′′ X−−→ s2

is augmented with a diagonal transition s1X∪Y−−−−→ s2.

Figure 9 shows three CPOG examples and the corresponding LTSs. The states are denoted by grey ovals withthe history/assignment pairs, for example ({a}, 0) means H � {a} and ψ(x ) � 0. The first CPOG (see Fig. 9a)corresponds to a system with two possible sequential behaviours: a → b → c (when x � 1) and a → b → d(when x � 0), where the choice between c and d is made during the execution of action a by appropriatelysetting variable x , denoted by the dotted line between a and x and by vx � a using the above notation. Thecorresponding LTS (on the right-hand side) contains a non-deterministic choice in the initial state (∅,0). Thesecond CPOG (shown in Fig. 9b) contains the same set of behaviours, but the choice is delayed until action b.Notice the corresponding LTS is not bisimilar to the previous one. The third CPOG (shown in Fig. 9c) containsa sequential behaviour a → b → d (when x � 0) and a concurrent behaviour a → b → (c + d ) (when x � 1).The corresponding LTS shows the effect of combinatorial state explosion due to concurrency; the single steptransition {c, d} is shown with a dotted arc.

Reconfiguration example

We now give an example illustrating CPOG LTS semantics in the presence of dynamic reconfiguration. Fig-ure 10 (top) shows two system configurations: P � a → (b + c), where actions b and c can execute in parallel,and Q � a → b → c, where b and c are executed in sequence. This example is based on our case study, with band c corresponding to Shipping and Billing respectively.

We algebraically combineP andQ to form S � r+[¬x ]P+[x ]Q , where variable x indicates the completion ofthe reconfiguration action r that reconfigures the system from P toQ . The LTS semantics of the complete systemS is shown in Fig. 10 (bottom). Notice that actions {a, b, c} and the reconfiguration action r are concurrent. TheLTS shows the interference between the reconfiguration and computation actions, specifically, if r is executed afterc in state ({a, c}, 0) of P then the history {a, c} of the resulting state ({a, c, r}, 1) with r elided is an inconsistenthistory ofQ , since c cannot execute before b inQ . In the next section, we discuss interference in more detail andshow how we can derive reconfiguration guidelines that restrict concurrency and guarantee the system does notreach an inconsistent state due to reconfiguration. In this example, such a guideline is: reconfiguration action rshould be executed before action c, which makes the inconsistent state ({a, c, r}, 1) unreachable.

The above example illustrates that CPOG theory and LTS semantics apply to both computation and recon-figuration actions. Therefore, a special reconfiguration rule is not required.


(a)

(b)

(c)

Fig. 9.Examples ofCPOGLTS semantics. aEarly choice between two sequential behaviours, bLate choice between two sequential behaviours,c Late choice between sequential and concurrent behaviours

5.4. Dynamic reconfiguration

In this section, we show how CPOGs can be used to reason about dynamic reconfiguration, in particular, how toprove reconfiguration requirement R2 in Sect. 3.2. We start by elaborating the important notion of history fromthe previous section, which allows reasoning about states of a system whose behaviour is described by a CPOGspecification.

A historyH ⊆A is a set of actions that have occured in a system up to a certain moment in time. The set mustbe causally closed, that is, if an action has occured then all the actions it depends on must also have occurred.However, since CPOGs are capable of describing not just single workflows but families of workflows, the notionof causality must be clarified. In fact, we can only talk about conditional causality, where an action b dependson another action a under a condition x , or algebraically: [x ](a → b). This leads to the following notion ofconsistency.

Given a history H and a CPOG specification S , we define the consistency condition C (H ,S ) under which allactions in H could have occurred without violating the specification S as follows:

C (H ,S ) �∧a∈H

fa ∧∧

a �∈H , b∈Hfab (2)

where fa and fab are from the canonical form of the specification S (see Proposition 1). In other words, a historyH is consistent with a specification S if and only if:

• Every a∈H must be allowed by the specification, that is, its condition fa must be satisfied.• For each pair of actions a and b such that a is not in the history but b is, the dependency a → b must not bein the specification, that is, fab must not be satisfied.


Fig. 10. CPOG LTS semantics and dynamic reconfiguration

To clarify the above, consider the following example. Let H � {Start,OrderReceipt, InventoryCheck,Reject}.The consistency condition forH with respect to Configuration 1 isC (H , c1) � x , whichmeans that historyH canonly be consistent if the inventory check failed, as otherwise actionReject should causally depend onCreditCheck,but the latter is not present in H . The consistency condition with respect to Configuration 2 is C (H , c2) � false,because to be rejected an order must either fail the supplier check or fail the credit check, but neither of them isinH . Therefore, we call historyH inconsistent with the specification c2. The reader may recognise that the notionof a history is related to (and in fact is quite similar to) the notion of a conflict free subset of events in an eventstructure [NPW81].


Having defined the notion of consistency, we can now formulate the circumstances under which a system canbe reconfigured from one configuration to another. If a system’s state is described by a history H then it can bedynamically reconfigured from S1 to S2 under the condition that H is consistent with both S1 and S2, that is:

C (H ,S1) ∧ C (H ,S2)

In other words, both S1 and S2 must be compatible with respect to history H .Referring to our previous example, we can say that specifications c1 and c2 are not compatible with respect

to history {Start,OrderReceipt, InventoryCheck,Reject}, because C (H , c1) ∧ C (H , c2) � x ∧ false � false.To model unplanned reconfiguration we introduce new reconfiguration actions that can add and remove

workflow actions and/or requirements on their order by modifying the graph family (i.e. adding new graphs andremoving existing graphs that are no longer relevant). Notice that reconfiguration actions can occur concurrentlywith workflow actions and can also have requirements imposed on their order.

Consider a concurrent reconfiguration action r that changes the system’s configuration from c1 to c2. Thecombined family of graphs that contains c1, c2, and r can be specified as follows:

S � r + [¬r done]c1 + [r done]c2 (3)

where predicate ‘r done’ is true after the execution of reconfiguration action r , and false before that. Noticethe initial specification c1 is defined independently of the reconfiguration action r and the new specification c2.Therefore, the reconfiguration is unplanned.

We can now compute a set R(r ,S ) of safe reconfiguration histories by finding consistent histories H thatremain consistent after the execution of action r :

R(r ,S ) � {H | C (H ,S ) ∧ C (H ∪ {r},S ) �� false} (4)

For example, we know that:

{Start,OrderReceipt, InventoryCheck,Reject} �∈R(r ,S )

However, if we drop action Reject the result is a safe reconfiguration history:

{Start,OrderReceipt, InventoryCheck}∈R(r ,S )

An important practical question arises at this point: is it possible to derive reconfiguration guidelines fromR(r ,S ) such that implementing the guidelines will ensure the safe reconfiguration of the system? We give apositive and constructive answer below, but with no claim for optimality.

To derive reconfiguration guidelines for the specification S defined above, notice that all histories which areconsistent with S and do not contain the actions Reject or Confirmation also belong toR(r ,S ):

∀H (H ∩ RC � ∅ ∧ C (H ,S ) �� false ⇒ H ∈R(r ,S )) (5)

where RC � {Reject,Confirmation} is a set of forbidden actions. It is easy to check that any history that does notcontain the forbidden actions is consistent with Configurations 1 and 2 by inspecting Figs. 2 and 3 respectively(online Appendix C illustrates this using graphical representations of the consistent histories of c1 and c2).Therefore, we can formulate the following guideline: the reconfiguration should only be permitted when noforbidden action has occured. This guideline can be enforced by transforming the specification S into Ssafe asfollows:

Ssafe � S + r → (Reject + Confirmation) (6)

That is, we require action r to occur before the forbidden actions.Similarly, we can ensure that the reverse reconfiguration (from c2 to c1) is safe by the following specification:

S revsafe � r → (SupplierCheck + Reject + Billing) + [¬r done]c2 + [r done]c1 (7)


The reason for forbidding action Billing, which seems innocuous, is that Billing must occur after Shipping inConfiguration 1. If we do not forbid Billing, then a reconfiguration from c2 to c1 can bring the system to a statein which Billing has occurred but Shipping has not, which is inconsistent with c1.

5.5. Implementation

We have automated CPOG transformation and verification procedures described in this section in a prototypeimplementation as an embedded domain-specific language (DSL) in Haskell [Hud96], although the implementa-tion is not yet publicly available. We have also successfully cross-checked the results using Maude, a well-knownenvironment for rewriting logic [MAU15]. However, implementing CPOG axioms and transformations as acollection of rewrite rules in Maude was a fragile and challenging process: any new rewrite rule could triggernon-termination of the tool’s rewrite engine, requiring its manual shutdown and restart. Therefore, we decided tofocus our implementation effort on the DSL, where we had full control over the internal CPOG-specific rewriteengine. An additional benefit of embedding our DSL in Haskell was that the DSL acquired abstraction, sharing,and parameterisation capabilities essentially for free due to the purity and rich type system of Haskell.

As shown in [Mok09], most interesting properties that can be defined on CPOGs are reducible to the BooleanSatisfiability (SAT) problem [ES04]. For example, checking the equivalence of two CPOGs requires a pairwisecomparison of conditions fa and fab of their canonical forms for equality, and each such comparison is triviallya SAT problem. When working with Maude we relied on its built-in SAT solver, but with our Haskell-basedimplementation we decided to use Binary Decision Diagrams (BDDs) [Lee59] to store CPOG conditions in acanonical form and to share of their common subexpressions. We noticed that in practice, actions and depen-dencies between actions typically have the same or similar conditions; canonical forms of the expressions c1 andc2 are good examples of this phenomenon.

6. Basic CCSdp

Basic CCSdp is a two-sorted process algebra based on basic CCS [Mil89], which is extended with a singleconstruct—the fraction process P ′

P—in order to describe unplanned process reconfiguration. Therefore, basic

CCSdp has a behavioural approach to describing a system. One sort is used to represent general purpose com-putation actions, including communication, the other sort is used to represent process reconfiguration actions,and interference between the two kinds of action is represented by interleaving actions. The process expressionsare amenable to equational reasoning using the theory developed in [Bha13] and to model checking. We proceedby defining the syntax and semantics of basic CCSdp briefly, modelling the case study, then attempting to verifyreconfiguration requirement R3; an overall evaluation of the formalism is given in Sect. 7.

It is important to notice that basic CCSdp is an experimental process algebra developed as a test bed in orderto explore the properties of the fraction process, define its semantics, and develop its theory. Having done this in[Bha13], it should be possible to import the fraction process and its transition rules into any process algebra thatenables reaction between processes using the parallel composition operator, and thereby support the modellingof unplanned process reconfiguration. Thus, the fraction process is intended as a ‘plug-in’ for process algebras,and basic CCSdp is the first demonstrator.

6.1. Syntax

LetN be the countable set of names (e.g. a, b, c) that represent both input ports and input actions of the processesin basic CCSdp; and letN be the countable set of complementary names (e.g. a, b, c) that represent both outputports and output actions of the processes in basic CCSdp, where N � {l | l ∈N }. Let PN be the countable setof names (e.g. A, B , C ) of the processes in basic CCSdp. The sets N , N , and PN are assumed to be pairwisedisjoint.


Thus, given a ∈ N , a represents the input action on the input port a of a process; and a represents thecomplementaryoutput actionon the output port a of aprocess. Internal actionof aprocess, such as the interactionbetween complementary actions a and a, is represented by the special action τ .

Let L be the set of names that represent both ports and actions of the processes in basic CCSdp, whereL � N ∪ N . As usual in CCS, ∀ l ∈N (l � l ).

Let I be the set of input and output ports/actions of the processes in basic CCSdp and their internal action,where I � L ∪ {τ }.

Let P be the set of processes in basic CCSdp.The syntax of a process P in P is defined as follows:

P ::� PN <β > | 0 |∑i∈I

αi .P | P | P | PP

where PN ∈PN , β is a tuple of elements of L, α∈I, and I is a finite indexing set.Thus, the syntax of basic CCSdp is the syntax of basic CCS without the restriction operator (ν) and extended

with the P ′P

construct.As inCCS, 0 is theNILprocess,which has nobehaviour. Prefix (e.g.α.P )models sequential action. Summation

(e.g. α1.P1 + α2.P2) models non-deterministic choice of actions by a process. Notice that a non-0 term in asummation is guarded by a prefix action in order to prevent the creation of an infinite number of processes, whichcomplicates reasoning. A<β> models the invocation of a constant process named A, instantiated with a tupleof port/action names β. A(β) has a unique definition, which can be recursive. As usual in CCS, A(β) is used todefineA, andA<β> is used to represent an instance ofA (e.g.A(a, b) � a.b.A<a, b>). Parallel composition (e.g.P | P ′) models the execution of concurrent processes and their direct functional interaction, as well as processcomposition and decomposition. Interaction between processes is synchronous and point-to-point.

A fraction (e.g. P ′P) is a process that models process replacement and deletion. On creation, the fraction P ′

Pidentifies any instance of a process matching its denominator processP with which it is composed in parallel, andreplaces that process atomically with the numerator process P ′. If no such process instance exists, the fractioncontinues to exist until such a process is created (or the fraction is itself deleted or replaced). If there is morethan one such process instance, a non-deterministic choice is made as to which process is replaced. Similarly, ifmore than one fraction can replace a process instance, a non-deterministic choice is made as to which fractionreplaces the process. Deletion of a process P is achieved by parallel composition with 0

P. If P progresses to Q ,

then P ′P

will not replace Q by P ′ (unless Q matches P ). Notice that a fraction has no communication behaviour;its only behaviour is to replace a process with which it is composed in parallel that matches its denominator. Thematching is done by behaviour using a bisimulation, as explained in the following section.

The precedence of the operators (in decreasing order) is: fraction formation, relabelling, prefix, summation,parallel composition.

6.2. LTS semantics

LetR be the countable set of reconfiguration actions of the processes in P (e.g. ρX , ρY , ρZ ) that create a processinP ; and letR be the countable set of complementary reconfiguration actions of the processes inP (e.g. ρX , ρY ,ρZ ) that delete a process in P , whereR � {ρX | ρX ∈R} (see the Creat and Delet rules below). Each action inR is represented by ρX , with X ∈P . The sets N , N , {τ },R, R, and PN are assumed to be pairwise disjoint.4

The interaction between complementary reconfiguration actions (such as ρX and ρX ) results in the replace-ment of one or more processes (see the Creat , Delet , and React rules below).

Let C be the set of reconfiguration actions of the processes inP , where C � R∪R. As before,∀ λ∈L∪C (λ � λ).Let A be the set of actions of the processes in P , where A � I ∪ C.The labelled transition system (LTS) rules for basic CCSdp are a superset of the LTS rules for basic CCS

without the restriction operator (ν), consisting of an unchanged rule of basic CCS (i.e. Sum) plus basic CCS rulesapplicable to reconfiguration transitions (i.e. React , L-Par, R-Par, and Ident) plus additional rules to describenew reconfiguration behaviour (i.e. Creat , Delet , CompDelet , L-React, and R-React). See Table 2.

4 The reconfiguration actions ρX , ρX are written as τrX , τ rX respectively in [Bha13]. The change to ρX , ρX simplifies the notation, and isdue to advice from Kohei Honda.


Table 2. Labelled transition system semantics of basic CCSdp

Sum k∈I∑

i∈I αi .Pi

αk−→Pk

where I is a finite indexing set

React λ∈L∪C ∧ Pλ−→P ′ ∧ Q

λ−→Q ′

P |Q τ−→P ′ |Q ′

L-Par μ∈A ∧ Pμ−→P ′

P |Q μ−→P ′ |QR-Par μ∈A ∧ Q

μ−→Q ′

P |Q μ−→P |Q ′

Ident|b|�|a | ∧ μ∈A ∧ P [ b

a]

μ−→P ′

A<b>μ−→P ′

where A(a) � P

CreatP∼of Q ∧ P∈P+

P ′P

ρQ−→P ′Delet

P∼of Q ∧ P∈P+

PρQ−→0

CompDeletR∼of R1|R2 ∧ P

ρR1−→P ′ ∧ P ′ρR2−→P ′′

PρR−→P ′′

L-ReactR∼of R1|R2 ∧ P

ρR1−→P ′ ∧ P ′ ρR−→P ′′ ∧ QρR2−→Q ′

P |Q τ−→P ′′ |Q ′ R-ReactR∼of R1|R2 ∧ P

ρR1−→P ′ ∧ QρR2−→Q ′ ∧ Q ′ ρR−→Q ′′

P |Q τ−→P ′ |Q ′′

The Sum rule states that summation preserves the transitions of constituent processes as a non-deterministicchoice of alternative transitions. For example, the process InventoryCheckNotOK o .0+InventoryCheckOK o .0 can eitheroutput InventoryCheckNotOK o or output InventoryCheckOK o non-deterministically then terminate.

The React rule states that if two processes can perform complementary transitions, then their parallel com-position can result in a τ transition in which both processes undergo their respective complementary transitionsatomically. Notice that this rule results from overloading the semantics of the parallel composition operator (|).The rule has been extended from L to L∪ C in order to be applicable to processes that can perform complemen-tary reconfiguration transitions. For example, consider the processes CONFIG1 and CONFIG2 defined in Sect. 6.3.The fraction process CONFIG2

CONFIG1 can perform ρCONFIG1 to become CONFIG2 by the Creat rule because CONFIG1 is apositive process (defined below), and CONFIG1 can perform ρCONFIG1 to become 0 by the Delet rule. Therefore,CONFIG1 | CONFIG2

CONFIG1 can become 0 | CONFIG2 by the React rule because ρCONFIG1 and ρCONFIG1 are complemen-tary actions in C. Thus, the fraction process CONFIG2

CONFIG1 reconfigures CONFIG1 to CONFIG2, since 0 is the identityprocess. Notice also that the reconfiguration actions are not port names, sinceL and C are disjoint. Therefore, thereconfiguration reaction does not require a communication channel. Hence, fraction processes specify the effectsof process reconfiguration rather than describe mechanisms for implementing process reconfiguration.

The L-Par and R-Par rules state that parallel composition preserves the transitions of constituent processes,including reconfiguration transitions. For example, consider the processes ARC 1, ARC 2, and ARCH 1 defined inSect. 6.3. The process ARC 2

ARC 1 | 0ARCH 1 can perform ρARC 1 to become ARC 2 | 0

ARCH 1 by the Creat and L-Par rules,or it can perform ρARCH 1 to become ARC 2

ARC 1 | 0 by the Creat and R-Par rules. The relationship between the L-Parand R-Par rules and the other LTS rules indicates that the granularity of process reconfiguration using fractionprocesses is a single concurrent process.

Creat and Delet are the key rules of dynamic process reconfiguration. The Creat rule states that if P is apositive process (P ∈ P+, see Definition 1 below) that matches Q using strong of-bisimulation (P ∼of Q , seeDefinition 2 below), then the fraction process P ′

Pcan perform the reconfiguration transition ρQ that results in the

creation of P ′. The Delet rule is complementary to the Creat rule, and states that if P is a positive process thatmatches Q using strong of-bisimulation, then P can be deleted by performing the reconfiguration transition ρQ

that is complementary to the reconfiguration transition ρQ performed by some fraction that creates a process.Thus, P ′ replaces P as a result of the reaction between P ′

Pperforming ρQ and P performing ρQ (defined by the

React rule).The hypotheses of Creat and Delet use the notions of positive process (P ∈P+) and strong of-bisimulation

(∼of ). The reconfiguration transitions are restricted to positive processes in order to retain the identity propertyof 0 in parallel compositions up to ∼of , so that 0 and processes similar to 0 (i.e. processes with no behaviour) can


be ignored, which simplifies process matching. In contrast, a positive process is a process with behaviour, that is,a process that can communicate, or can perform an internal action, or can perform a reconfiguration action onanother process. The notion is defined as follows:

Definition 1 P+ denotes the set of positive processes of P , which is the smallest subset of P that satisties thefollowing conditions:

1. ∀ α∈I ∀ p∈P (α.p∈P+)2. ∀ p, q ∈P (p + q ∈P ∧ (p∈P+ ∨ q ∈P+) �⇒ p + q ∈P+)3. ∀ p, q ∈P (p∈P+ ∨ q ∈P+ �⇒ p | q ∈P+)

4. ∀ p∈P ∀ q ∈P+(

pq

∈P+)

5. ∀ β ∈I ∀X ∈PN (β.X ∈P+)

Rule 4 above enables recursive fraction processes to be defined that can reconfigure other fraction processesusing, for example, the Creat , Delet , and React rules. Therefore, the reconfiguration of a reconfiguration systemcan be modelled, so that the dynamic evolution of a system throughout its lifetime can be modelled in a uniformmanner.

Definition 2 Strong of-bisimulation (∼of ) is the largest symmetric binary relation on P such that the followingcondition holds ∀(p, q) ∈∼of

∀ α∈Ip ∪ Rp ∀ p ′ ∈P (p α−→ p ′ �⇒ α∈Iq ∪ Rq ∧ ∃q ′ ∈P (q α−→ q ′ ∧ (p ′, q ′) ∈∼of ))

where Ip ∪ Rp and Iq ∪ Rq are the sets of actions in I ∪ R that p and q can perform respectively.

Strong of-bisimulation is used for process matching for two reasons that have several advantages. First, strongof-bisimulation is a relation between processes. One advantage of using a relation is that modelling reconfigu-ration mechanisms is avoided, which simplifies models through abstraction. A second advantage is that specialreconfiguration operators that require syntactic proximity of their operands are avoided, so that the reconfiguringprocesses can be located in the context of the system model, which enables dynamic evolution of a system due tochanges in its environment to be modelled abstractly. A third advantage of syntactic separation of the reconfig-uring processes and the configuration model is modularity: syntactically separate models of a configuration andits reconfiguring processes can be produced that interact when composed in parallel and result in the requiredreconfiguration. A fourth advantage is that a relation defines a pre-condition that allows a process to be reconfig-ured only when it is in a specified state, which is an important requirement for reconfigurable systems. The secondreason is that strong of-bisimulation (rather than structural congruence or syntactic equality) helps to maximizethe terseness of expressions modelling reconfiguration, which simplifies models through abstraction. Notice thatrestriction is not currently used in basic CCSdp because restriction renders strong of-bisimuation undecidable[CHM94], which complicates tool support for process matching based on strong of-bisimuation.

The mutual dependency between LTS transitions and strong of-bisimulation suggests the dependency iscircular, which is problematic. However, the dependency is an inductive relationship if the depth of fractionalrecursion of a process is bounded suitably. Therefore, we restrictP to the domain of the sfdrdepth function (definedbelow), which creates an inductive relationship between LTS transitions and strong of-bisimulation, and therebyavoids a circular dependency. sfdrdepth is defined as follows:

succ : P x N −→ P P such that succ(p, i ) �{{p} if i � 0

{q ′ ∈P | ∃q ∈succ(p, i − 1)(∃α∈Iq ∪ Rq (qα−→ q ′))} else

succ(p, i ) is the set of i th successor processes (or equivalently, i th successors) of p. That is, the set of processesreached after i consecutive transitions in I∪ R starting from p, with succ(p, 0) � {p}.

successors : P −→ P P such that successors(p) �⋃i∈N

succ(p, i )

successors(p) is the set of all the successors of p, including p. That is, the set of all the processes reached afterzero, one or more consecutive transitions in I∪ R starting from p.

sfdrdepth : P −→ N such that sfdrdepth(p) � max{fdrdepth(s) | s ∈successors(p)} with

fdrdepth : P −→ N such that fdrdepth(s) �{0 if Rs � ∅1 +max{sfdrdepth(X ) | ρX ∈Rs} else


Thus, for any process p in basic CCSdp, sfdrdepth(p) is the maximum depth of fractional recursion of p andits successors.

For example, for any process p in basic CCS, any successor p ′ of p is also a process in basic CCS(by definition of the LTS rules of basic CCS)�⇒ fdrdepth(p ′) � 0 (by definition of fdrdepth, ∵ Rp ′ � ∅)�⇒ sfdrdepth(p) � 0 (by definition of sfdrdepth, because p ′ is arbitrary).For the fraction process b.0

a .0 , successors(b.0a .0 ) � {b.0

a .0 } ∪ successors(b.0) (by definition of successors)�⇒ sfdrdepth( b.0

a .0 ) � max{fdrdepth(s) | s ∈{b.0a .0 } ∪ successors(b.0)} (by definition of sfdrdepth)

�⇒ sfdrdepth( b.0a .0 ) � fdrdepth( b.0

a .0 ) (by the previous example, because b.0 is a process in basic CCS)�⇒ sfdrdepth( b.0

a .0 ) � 1 +max{sfdrdepth(a.0)} (by definition of fdrdepth, ∵ ρa .0∈R b.0a .0)

�⇒ sfdrdepth( b.0a .0 ) � 1 (∵ sfdrdepth(a.0) � 0, by the previous example).

The remaining three LTS rules facilitate the reconfiguration of multiple concurrent processes by a singlefraction process through a single transition.CompDelet states that consecutive delete transitions of a process canbe composed intoa singledelete transitionof theprocess.The rule is applicableonly if it is used in combinationwithL-Par or R-Par. For example, consider the processes ICH 1, CC 1, and CCH 1 defined in the following section. The

transitions ICH 1 | CC 1 | CCH 1 ρICH1−→ 0 | CC 1 | CCH 1 ρCCH1−→ 0 | CC 1 | 0 can be composed into the single

transition ICH 1 | CC 1 | CCH 1ρICH1 |CCH1

−→ 0 | CC 1 | 0. The L-React and R-React rules enable a fractionprocess to reconfigure processes on both sides of the fraction through a single transition. Collectively,CompDelet ,L-React, andR-React ensure thatparallel composition involving fractionprocesses is commutative andassociativewith respect to strong of-bisimulation, which are necessary in order tomodel unplanned dynamic reconfigurationabstractly.

Regarding the soundness of the semantics of basic CCSdp, the LTS transitions are defined to be the smallest

relation on P that satisfies the LTS rules. Therefore, a process p ∈ P performs a transition pμ−→p ′ with μ ∈ A

and p ′ ∈ P if and only if the hypothesis of some LTS rule that determines the pμ−→p ′ transition is satisfied.

Furthermore, the LTS rules do not contain any negative premise, nor any negative transition. Therefore, the LTSrules contain no contradiction. Therefore, the LTS semantics of basic CCSdp is sound.

6.3. Modelling

The granularity of reconfiguration using the fraction process is a single concurrent process, and multiple concur-rent processes can also be reconfigured by a single fraction process through a single transition. Thus, it is possibleto model all three cases of dynamic reconfiguration identified in Sect. 1 (see online Appendix D.1 for examplesof Case 1 and Case 2 reconfigurations using fraction processes). The scope of reconfiguration of Configuration1 and of functional interference between application and reconfiguration tasks is maximum when the modelconsists of the maximum number of concurrent processes (i.e. model of Design 4 in Sect. 3.3). However, it iseasiest to demonstrate both the strengths and the weaknesses of basic CCSdp using Design 1. Furthermore, themodels of all four designs in Sect. 3.3 are similar, and differ only in the location of the recursion. Therefore, weproceed by modelling Design 1 of Configuration 1 and Configuration 2 and Case 3 of the reconfiguration, andattempt to verify reconfiguration requirement R3 in the following section; the models of Designs 2, 3, and 4 ofConfiguration 1 are given in online Appendix D.2.

Modelling Configuration 1

Let O be the set of possible order identifiers, which can be infinite.Configuration 1 consists of a set of tasks. Each task consists of a set of subtasks, which aremodelled as actions

of processes in P . For example, the subtasks of the Order Receipt task are modelled as the actions of the REC

process. The subtasks of the Evaluation task are modelled as actions of the processes IC , ICH , CC , and CCH .The Rejection task is modelled as the actions RejectIC o and RejectCC o in the processes ICH and CCH respectively.The Confirmation task is modelled as the action Confirmo in the ARCH process. Notice that Configuration 1 isa cyclic executive, which is modelled by the recursive definition of CONFIG1 following RejectIC o , RejectCC o , andConfirmo .


Configuration 1 of the workflow is denoted by the process CONFIG1, andCONFIG1 � REC 1 | IC 1 | ICH 1 | CC 1 | CCH 1 | SHIP1 | BILL1 | ARC 1 | ARCH 1

REC 1 �∑

o∈O Receipto .InventoryChecko and denotes the Order Receipt task. By convention, we omit the 0 processat the end of a trace of actions by a process.

IC 1 �∑

o∈O InventoryChecko .(InventoryCheckNotOK o + InventoryCheckOK o ) and denotes the Inventory Check sub-task of Evaluation.

ICH 1 �∑

o∈O InventoryCheckNotOKo .RejectIC o .CONFIG1 + InventoryCheckOKo .CreditChecko and denotes subtasks ofEvaluation and Rejection.

CC 1 �∑

o∈O CreditChecko .(CreditCheckNotOK o + CreditCheckOK o ) and denotes the Credit Check subtask ofEvaluation.

CCH 1 �∑

o∈O CreditCheckNotOKo .RejectCC o .CONFIG1 +CreditCheckOKo .Shipo and denotes subtasks of Evaluationand Rejection.

SHIP1 �∑

o∈O Shipo .Billo and denotes the Shipping task,

BILL1 �∑

o∈O Billo .Archiveo and denotes the Billing task.

ARC 1 �∑

o∈O Archiveo .ArchiveOK o and denotes the Archiving task.

ARCH 1 �∑

o∈O ArchiveOKo .Confirmo .CONFIG1 and denotes the Confirmation task.

The execution of Configuration 1 of the workflow is modelled as transitions of the CONFIG1 process. If theactionRejectIC o is performedby ICH 1 orRejectCC o is performedbyCCH 1, theprocesses tobe executed subsequentlyin CONFIG1 are deleted implicitly (i.e. garbage collected). The process deletion can be represented explicitly (e.g.as RejectIC o . CONFIG1

CC 1 | CCH 1 | SHIP1 | BILL1 | ARC 1 | ARCH 1 in ICH 1), but this has the disadvantage of encoding informationabout the workflow’s structure within a workflow process, which (in general) complicates reconfiguration ofworkflows.

Modelling Configuration 2

Configuration 2 is different in structure from Configuration 1, although some of the tasks are unchanged (suchas Inventory Check and Credit Check), and this difference is reflected in the processes used to model Con-figuration 2. For example, a new process SC is needed in order to model the new subtask (Supplier Check)of the Evaluation task. The CCH process must be different in order to ensure that Shipping and Billing areperformed concurrently. The removal of the Confirmation task implies the ARCH process is no longer needed.

Configuration 2 of the workflow is denoted by the process CONFIG2, andCONFIG2 � REC 1 | IC 1 | ICH 2 | CC 1 | CCH 2 | SHIP2 | BILL2 | ARC 2

REC 1 �∑

o∈O Receipto .InventoryChecko andIC 1 �

∑

o∈O InventoryChecko .(InventoryCheckNotOK o + InventoryCheckOK o )

ICH 2 �∑

o∈O InventoryCheckNotOKo .(SupplierChecko | SC ) + InventoryCheckOKo .CreditChecko and denotes subtasksin Evaluation that initiate a Supplier Check or a Credit Check.

SC �∑

o∈O SupplierCheckNotOKo .RejectIC o .CONFIG2 + SupplierCheckOKo .CreditChecko and denotes the newSupplier Check handling subtask in Evaluation followed by either Reject or initiation of a Credit Check.Notice that SC represents a stock check external to the organisation, and (therefore) communicates with a pro-cess external to CONFIG2 (unlike IC 1 and CC 1 in both CONFIG1 and CONFIG2). Thus, there is no SCH process inCONFIG2 that corresponds to ICH 2 or CCH 2, such a process would be located in the context of CONFIG2, and(therefore) the external behaviours of CONFIG1 and CONFIG2 are different.


CC 1 �∑

o∈O CreditChecko .(CreditCheckNotOK o +CreditCheckOK o )

CCH 2 �∑

o∈O CreditCheckNotOKo .RejectCC o .CONFIG2 + CreditCheckOKo .(Shipo | Billo ) and denotes subtasks inEvaluation and Rejection, including the concurrent initiation of Shipping and Billing.

SHIP2 �∑

o∈O Shipo .ShipOK o and denotes the changed Shipping task that allows Shipping and Billing to beperformed concurrently.

BILL2 �∑

o∈O Billo .BillOK o and denotes the changed Billing task that allows Shipping and Billing to beperformed concurrently.

ARC 2 �∑

o∈O ShipOKo .BillOKo .Archiveo .CONFIG2 + BillOKo .ShipOKo .Archiveo .CONFIG2 and denotes the changedArchiving task.

The execution of Configuration 2 of the workflow ismodelled as transitions of theCONFIG2 process. Processesare deleted implicitly following the execution of the RejectIC o action or the RejectCC o action (as in CONFIG1).

Modelling the reconfiguration

The workflow is reconfigured by a reconfiguration manager (modelled by the process RM defined below) thatis activated after receiving a triggering message from an observer in the environment of the workflow (e.g. ahuman operator or a reconfiguration tool) and reconfigures the workflow fromConfiguration 1 to Configuration2. There are two ways of reconfiguring the workflow (depending on its state of execution), and they are triggeredby different messages. The trigger1 guard models receipt of the message that is used to trigger reconfiguration ofthe workflow if it has not yet started to execute. After the release of trigger1, RM replaces the process CONFIG1

with the process CONFIG2, see online Appendix D.1. The trigger2 guard models receipt of the message that is usedto trigger reconfiguration of the workflow if it has completed Order Receipt and Inventory Check but notyet determined the subtask to be performed after the Inventory Check. After the release of trigger2, RM deletesthe process ARCH 1, replaces the processes ICH 1, CCH 1, SHIP1, BILL1, and ARC 1 with the processes ICH 2, CCH 2,SHIP2, BILL2, and ARC 2 respectively, as shown in online Appendix D.1.

RM � trigger1.CONFIG2

CONFIG1+ trigger2.

(ICH 2

ICH 1| CCH 2

CCH 1| SHIP2

SHIP1| BILL2

BILL1| ARC 2

ARC 1| 0ARCH 1

)

Thus, RM performs two operations of unplanned process reconfiguration, namely, the deletion and replacementof processes that are not designed to be reconfigured. The definitions of CONFIG1 and RM are modular, that is,syntactically separate, and CONFIG1 is not syntactically altered in order to be reconfigured by RM . The reconfig-uration of CONFIG1 occurs through its reactions with RM in the expression CONFIG1 | RM . The step throughwhich RM is added to the context of CONFIG1, that is, the step through which CONFIG1 becomes CONFIG1 | RM ,is performed outside basic CCSdp, and thereby captures the fact that the reconfiguration is unplanned. Noticethat because RM is located in the context of CONFIG1 and contains CONFIG2, Configuration 2 is located in theenvironment of the workflow. Therefore, Configuration 2 is not pre-defined within the workflow. Hence, an arbi-trary number of configurations and reconfigurations can be represented for the workflow in an incremental way,which can be used to represent the dynamic evolution of the workflow throughout its lifetime.

The concurrent execution of the workflow and reconfiguration tasks is represented as the set of total orders(i.e. sequences) of the transitions of the processes modelling the tasks, and the functional interference betweenthe tasks is represented using interleaved transitions of the processes.

6.4. Analysis

Reconfiguration requirement R3 states that any order received after the start of the reconfiguration must sat-isfy all the requirements on Configuration 2. Clearly, CONFIG2 satisfies all the requirements on Configuration2. Therefore, after the execution of either of the two actions that start the reconfiguration process RM in theexpression CONFIG1 | RM | trigger1 + trigger2 the resulting expressions must be weakly observationally bisimilarto CONFIG2, that is, the following property must hold:


CONFIG1 | CONFIG2

CONFIG1≈o CONFIG2

∧ CONFIG1 | ICH 2

ICH 1| CCH 2

CCH 1| SHIP2

SHIP1| BILL2

BILL1| ARC 2

ARC 1| 0ARCH 1

≈o CONFIG2

Weak observational bisimulation is defined as follows, based on [Mil99].Let T ∗

trans be the transitive reflexive closure of the set of τ transitions of the processes in P ,where T ∗

trans � {(r , s)∈P x P | r τ→ s}∗, let q ⇒ q ′ denote (q, q ′)∈T ∗trans ,

let β be a tuple of elements of L with | β | ∈ N+,

and let qβ⇒ q ′′ denote

∀ i ∈ [1.. | β |] ∃qi−1, qi−1,1, qi ∈P (q � q0 ∧ qi−1 ⇒ qi−1,1 ∧ βi ∈Lqi−1,1 ∧ qi−1,1βi→ qi ∧ q|β| ⇒ q ′′).

Weak observational bisimulation (≈o) is the largest symmetric binary relation on P such that the followingcondition holds ∀(p, q) ∈≈o

∀ p ′ ∈P(if p

β⇒ p ′ then ∃q ′ ∈P(q

β⇒ q ′ ∧ (p ′, q ′)∈≈o

))

Both reconfigurations of CONFIG1 by the fraction processes in RM can result in processes that are weaklyobservationally bisimilar to CONFIG2, as shown in online Appendix D.1. However, neither of the left processexpressions of the two conjuncts is weakly observationally bisimilar to CONFIG2, that is,

CONF IG1 | CONFIG2

CONFIG1 �≈o CONF IG2 ∧ CONFIG1 | ICH 2

ICH 1 | CCH 2

CCH 1 | SHIP2

SHIP1 | BILL2

BILL1 | ARC 2

ARC 1 | 0ARCH 1 �≈o CONFIG2

The proof is given in online Appendices D.3 andD.4 and consists of finding a sequence of transitions of CONFIG1

in a parallel composition that cannot be matched by CONFIG2 in the context containing only the processReceipto | RejectICo . The problem is caused by lack of control of non-deterministic transitions of processexpressions in basic CCSdp, which is inherited from CCS. The purpose of restricting the context of the processexpressions in onlineAppendixD.3 is to prevent behaviour of the expressions thatwould unnecessarily complicatethe proof.

6.5. Extensions

Basic CCSwas used as the host process algebra in which to explore the properties of the fraction process ‘plug-in’,define its semantics, and develop its theory, because basic CCS is very simple. However, in order to use the fractionprocess effectively, a hosting process algebra must meet certain requirements. As the above analysis shows, oneof the requirements is a facility to control non-deterministic transitions, which is absent in CCS.

Onewayof controlling problematic non-deterministic transitions is to use a priority scheme for transitions (see[Bra02]) that is designed to satisfy requirements onworkflows andon their reconfiguration. Since the requirementscan be application specific, different priority schemes may be necessary. Therefore, the semantics of basic CCSdp

should be extended with a generic notion of transition priority such that different systemmodels can be producedusing different priority schemes. Notice that the use of a priority scheme raises the issue of compositionality ofprocess expressions, but that this issue exists whenever there is functional interference between processes. Onesolution is to use rely and guarantee conditions [Jon81] on process transitions, which (if satisfied) implicitlydefine a set of partial orders on the transitions, which can be explicitly defined by a priority scheme. Thus,the compositionality of the processes is ensured by the satisfaction of their rely and guarantee conditions and isimplemented using the priority scheme.Use of process identifiers in processmatching and the restriction operator(see below) also help to achieve compositionality of processes.

Online Appendix D.2 describes models of Configuration 1 with multiple executing workflows. In order todescribe the unplanned reconfiguration of such models, a dynamic binding between CONFIG1 instances andRM instances is necessary that will support the selective reconfiguration of specific process instances. Such abinding can be achieved by extending the semantics of process matching to use process identifiers. If a processidentifier is passed as a parameter to a fraction process, the fraction can reconfigure different process instancesin a flexible and controlled manner. Furthermore, the identification of a specific process for reconfigurationprecludes the matching of other processes, and thereby significantly reduces the computational complexity of


process matching. For example, in the expression p1 | p2 | p3 | x (i ).p′

p(i ) where p1, p2, and p3 are different

instances of the same process p, p ′p(1) will be able to reconfigure only p1, and the processes p2, p3, p1 | p2, p1 | p3,

p2 | p3, and p1 | p2 | p3 will not be matched. Notice that basic CCSdp is a class-based process algebra; thatis, like numbers in arithmetic, the processes in basic CCSdp are classes, and different instances of a process canbe used interchangeably in any context with identical results. However, the use of process identifiers in processmatching makes the modification of basic CCSdp an instance-based process algebra, so that different instancesof a process with different identifiers in identical contexts can produce different results.

Process matching based on strong of-bisimulation produces very terse models, but is computationally verycomplex. The computational complexity of process matching can be reduced significantly by using syntax-basedprocess matching with process identifiers, discussed in [Bha13]. Moreover, the restriction operator (ν) can beadded to basic CCSdp to enable scoping of names, since restriction does not affect the decidability of syntacticprocess matching.

We briefly consider the reverse reconfiguration of a workflow (from Configuration 2 to Configuration 1)for the sake of completeness. The reconfiguration is performed by the reconfiguration manager denoted by theprocess MR:

MR � trigger3.

(

CONFIG1

CONFIG2

)

+ trigger4.

(

ICH 1

ICH 2| CCH 1

CCH 2| SHIP1

SHIP2| BILL1

BILL2| ARC 1 | ARCH 1

ARC 2

)

Transposing Configuration 1 and Configuration 2 in the reconfiguration requirements defined in Sect. 3.2, thereconfiguration from Configuration 2 to Configuration 1 is restricted by the existence of Supplier Check. Con-sider an executing workflow that started before the reconfiguration (see Figs. 3, 2). If the outcome of InventoryCheck is negative then Supplier Check is performed, which cannot be done in Configuration 1. Therefore, evenif the Supplier Check is positive, the reconfigured workflow cannot meet Requirement C1.2 of Configuration1. Hence, the reconfiguration should not be performed. If the outcome of Inventory Check is positive thenthe workflow can be reconfigured just after Credit Check. However, there is no mechanism in basic CCSdp fortesting the history of transitions of a workflow in order to determine a reconfiguration transition. Such testingcan be performed by extending the syntax of a process to include the history of transitions that produced theprocess, and extending the semantics of process matching to include matching of traces of transitions, which willincrease the potential for reconfiguration of workflows.

7. Comparison of VDM, CPOGs, and basic CCSdp

In this section, we evaluate and compare the strengths and weaknesses of VDM, CPOGs, and basic CCSdp withrespect to the requirements on an ideal formalism defined in Sect. 2, using material presented in Sects. 4, 5, and 6to justify our findings, which are summarised in Table 3. Notice that what is currently done using the formalismsis indicated in the table in normal font, and what is feasible (albeit with extensions) is indicated in italics. Recollectthat for the case study, the formalisms were used according to their respective ‘idioms’.

F1: It should be possible to model, and to identify instances of, software components and tasks, and theircommunication links

VDM-SL allows workflows to be represented as data types, including their actions, configurations, and traces. Inthis paper, VDM-SL was used to model tasks as simple data types, and to model workflows as linked tasks. Aninvariant was defined that excludes invalid workflows. VDM-SL does not have specific mechanisms for modellingcommunication links, but these can be modelled where appropriate. Below we describe an extended developmentprocess using other dialects of VDM that have built-in mechanisms (including object-orientation) for modellingsoftware components, tasks, and their communication links more completely.

A CPOG represents a software component or a task as a set of graphs of actions, where each vertex and arcof a graph can be guarded by a predicate. Hence, Configuration 1 of the case study workflow is represented as theCPOG c1. Different instances of a software component or of a task can be identified using CPOGs with differentidentifiers and subscripting the actions with their CPOG identifier. There is no facility for value passing betweenactions, but a value to be passed can be encoded into the name of a receiving action (as in basic CCSdp) that isguarded by a Boolean variable corresponding to the value. There is no communication facility for actions, but the


behaviour of a communication link can be represented by aCPOG,which enables synchronous and asynchronouspoint-to-multipoint communication to be modelled. An instance of a communication link can be represented asa CPOG instance. There is a close relationship between CPOGs and a basic process algebra, because a CPOG isthe unfolding of a process.

In basic CCSdp, software components and tasks are represented as processes. Hence, the case study workflowin Configuration 1 is represented as the process CONFIG1. Different instances of a software component or of atask can be identified using processes with different identifiers, for example, A � REC and B � REC , or RECA andRECB (as in CCS). Notice that basic CCSdp (as in basic CCS) has no facility for value passing, but that a value tobe passed (e.g. o) can be encoded into a process identifier (e.g. REC ), so that a unique value passed to a processcan be used to identify the process instance uniquely (e.g. RECo). A communication link is represented as a pair ofcomplementary port names on two processes, and is used to model synchronous point-to-point communication.Instances of communication links can be identified indirectly using process identifiers and port names that areunique to the linked processes. Alternatively, a communication link can be represented as a process (not usedin the case study), which enables both synchronous and asynchronous point-to-multipoint communication tobe modelled, and different instances of a communication link can be identified using processes with differentidentifiers.

F2: It should be possible to model the creation, deletion, and replacement of software components andtasks, and the creation and deletion of their communication links

The VDM model described in this paper used the VDM-SL dialect. Following a standard VDM-SL paradigmto keep the model small, a single workflow was modelled, with concurrency of the parallel tasks modelled asnon-deterministic interleaving. With sufficient work, the model could be extended to include these features, butit is common to use another dialect of VDM as a development continues. As described in Sect. 4.5, there aretwo other dialects of VDM that extend the language with features for modelling object-orientation (VDM++)and real-time (VDM-RT); these dialects form a family. Guidance exists [LFW09] for a development process thatbegins with VDM-SL and moves through VDM++ and finally VDM-RT, adding complexity at each stage andmoving closer to implementation. The features of the VDM++ dialect [FLM+05] could be used to extend theexisting model to include dynamic creation, deletion, and replacement of software components and tasks. Eachwould be represented by a class, which would include definition of a thread of control. These classes can then beinstantiated as objects dynamically. A new thread can be spawned using the start keyword, which can be calledon an object whose class defines a thread. Objects can be deleted once their threads have completed, or when allreferences to them are removed (in which case they are cleaned up by the garbage collector).

The creation and deletion of software components and tasks is represented respectively as the creation anddeletion of CPOGs, and replacement is a combination of CPOG creation and deletion. The target CPOG (mod-elling a software component or a task) is guarded by one or more predicates that are set by the reconfigura-tion actions and determine which actions and action dependencies of the CPOG are active (can be performed)or inactive (cannot be performed). For example, c1 is reconfigured to c2 by embedding c1 in the expressionr + [¬r done]c1 + [r done]c2. The guards [¬r done] and [r done] penetrate into c1 and c2 respectively, byProposition 1 and the four properties of conditional workflows in Sect. 5.1, and thereby guard individual actionsand their dependencies. Therefore, before the execution of reconfiguration action r only actions in c1 can be per-formed, and after the execution of r has set the guard value only the remaining actions in c2 can be performed. AnewCPOG (cnew ) can be added to an existing CPOG (cold ) by parallel composition (cold +cnew ) or by sequentialcomposition (cold → cnew ), and an existing CPOG ([x ]cold ) can be deleted by setting its guard ([x ]) to false. Thegranularity of reconfiguration is a single action and a single dependency between actions, and an entire CPOGcan also be reconfigured by setting a Boolean variable. Since communication links can be represented as CPOGs,the creation and deletion of communication links can be expressed respectively as the creation and deletion ofCPOGs.

In basic CCSdp, the replacement, deletion, and creation of software components and tasks can be mod-elled using fraction processes. A target process (modelling a software component or a task) is reconfiguredby a fraction process with the denominator of the fraction binding dynamically to the target using the strongof-bisimulation relation and the numerator of the fraction replacing the target through a reaction transition.Thus, ARC 1 | ARC 2

ARC 1τ−→ ARC 2. The fraction and target processes perform complementary reconfiguration actions

that combine to produce the reaction transition (τ ) that results in the replacement of the target. The granularity


of reconfiguration is a single concurrent process (e.g. ARC 1), and multiple concurrent processes can also bereconfigured through a single reaction transition (e.g. CONFIG1 | CONFIG2

CONFIG1τ−→ CONFIG2). Deletion of a process is

expressed as replacement with the identity process (0). Thus, ARCH 1 | 0ARCH 1

τ−→ 0. A process is created either byincluding it in the numerator of a fraction (e.g. ARC 2 | ARC 1 | ARCH 1

ARC 2τ−→ ARC 1 | ARCH 1), or by using a guarded

parallel composition of processes that creates a new process after the guard is released (as in CCS). Since com-munication links between software components and between tasks can be represented as processes, the creationand deletion (and replacement) of communication links can be expressed as process replacement using fractions.Alternatively, basic CCSdp can be extended to enable link passing, as in π -calculi [Mil99], or a π -calculus can beextended with the fraction process and its semantics.

F3: It should be possible to model the relocation of software components and tasks on physical nodes

In VDM-SL, physical nodes are not modelled. However, the VDM-RT dialect [VLH06] has features that supportsuch modelling. The VDM-RT dialect extends VDM++ with abstract models of compute nodes and commu-nication buses. A VDM-RT model must describe one or more compute nodes (e.g. CPUs) to which objects aredeployed. Objects on the same node compete for computation time. In order to call an operation of an objectdeployed to a different CPU, a communication link between them must be defined. Currently, the graph of com-pute nodes and communication linksmust be declared statically before simulation, and object deployment cannotbe changed dynamically. However, multiple simulations with different configurations can be run and compared.

In CPOGs, physical nodes are not modelled. However, it is possible to represent the location of an actionusing a set of Boolean variables specific to the action that represent all possible locations of the action. Thus, thelocation of a CPOG can be represented, whichmodels the location of a software component or a task. Relocationis represented as a change in the value of location-indicating Boolean variables by their controlling actions.

In basic CCSdp, physical nodes are not modelled. Hence, the relocation of software components or taskson physical nodes cannot be modelled. However, if the process syntax is extended with a location attribute andthe semantics of communication is extended with process passing, then relocation can be modelled simply ascommunication with process passing in which the location of the process being passed changes from the locationof the sending process to the location of the receiving process.

F4: It should be possible to model state transfer between software components and between tasks

VDM-SL is state-based, with models using persistent state and operations over that state. State transfer can bemodelled through parameter passing in operation calls. The object-orientation features of VDM++ and VDM-RT dialects extend this by allowing objects to be passed as parameters that contain both state and functionality.Additionally, the concurrency features of these two dialects allow for synchronisation between threads, whichcan model state transfer where appropriate.

In a CPOG, there is no facility for data communication between actions. However, it is possible to use a setof action specific Boolean variables to represent communication data. The Boolean variables can collectivelyrepresent all possible data values to be communicated by an action, including the state of a CPOG, that can beused in predicates of actions in another CPOG, which enables data communication and state transfer betweensoftware components and between tasks to be modelled. A more expressive variant of CPOGs enables Booleanvariables to be controlled bymore than one action and their value to be changedmore than once [MSY12], whichsimplifies the modelling of data communication.

In basic CCSdp, state transfer between software components and between tasks can be modelled by encodinginformation about the state in the names of the complementary communicating actions and (thereby) selectingthe process with the transferred state in a summation, or by replacing the receiving process with the process thathas received the transferred state using a fraction process. Alternatively, basic CCSdp can be extended to expressvalue passing communication.


F5: It should be possible to model both planned and unplanned reconfiguration

In VDM-SL, both planned and unplanned reconfiguration can be modelled. In the model of the case study,the Reconfiguration operation allows the workflow to be changed in the Interpreter module during theexecution of the interpreter. The interpreter is not in control of when the reconfiguration operation is called, andConfiguration1 is defined independently of the Reconfiguration operation and Configuration2. Therefore, thereconfiguration is unplanned. A pre-condition ensures that any requested reconfiguration is valid. Notice thatVDM can pass functions as parameters to operations. Therefore, it is possible to pass a predicate (expressing apre-condition or an invariant) as well as a workflow as parameters to a reconfiguration operation (although thiswas not modelled). This is necessary because the invariants and pre-conditions that must be satisfied in orderto ensure the correctness of a reconfiguration cannot always be pre-defined for a dynamically evolving system.Planned reconfiguration was not modelled for this case study, but a simple extension can be envisioned where theReconfiguration operation is called internally by the interpreter at a planned time, or in response to plannedstimuli.

CPOGs can be used to model both planned and unplanned reconfiguration. In the planned reconfigurationof a CPOG, the CPOG consists of different configurations (each represented as a CPOG) with pre-definedreconfiguration predicates and reconfiguration actions that determine the value of the predicates. The execution ofthe reconfiguration actions deactivates actions and action dependencies in the target CPOG and activates actionsand action dependencies in the destination CPOG, and thereby reconfigures the target to the destination. In theunplanned reconfiguration of a CPOG, the target CPOG (e.g. c1) is typically embedded within a reconfigurationCPOG (e.g. r+[¬r done]c1+[r done]c2), which performs reconfiguration actions (e.g. r ) that control the actionsand action dependencies of the target through reconfiguration predicates (e.g. [¬r done]) and thereby replacethe target with the destination CPOG (e.g. c2) located in the target’s environment. The reconfiguration actionsconstitute a CPOG and (therefore) can themselves be reconfigured. Hence, CPOG reconfiguration is recursive.

In basic CCSdp, planned and unplanned reconfiguration can both be modelled using fraction processes. Formodelling planned reconfiguration, the reconfiguring fractions are located within the system model, whereas forunplanned reconfiguration, the fractions are located in the context of the system model. The target process tobe reconfigured does not require any syntactic modification or syntactic proximity to a reconfiguring fraction.Therefore, the modelling of reconfiguration can be modular. Thus, a system with n configurations can be repre-sented by n syntactically separate process expressions (eachmodelling a different configuration), and the n(n−1)reconfigurations of the system can be represented by n(n−1) syntactically separate process expressions that con-tain fraction processes. Furthermore, the reconfiguration of the reconfiguration software can be represented bythe replacement of one or more fraction processes by other fractions, since the notion of fraction process isrecursive. The selective reconfiguration of specific process instances requires the extension of the semantics ofprocess matching to use process identifiers.

F6: It should be possible to model the functional interference between application tasks andreconfiguration tasks

The tasks modelled in VDM-SL are atomic, and (therefore) cannot be interrupted during their execution. How-ever, the Reconfiguration operation can be called during workflow execution, and (therefore) can interfere withthe workflow as a whole. An extended concurrent model in VDM++ or VDM-RT could represent true functionalinterference, if the reconfiguration tasks are run in a separate thread to application tasks and true race conditionscan occur.

In CPOGs, functional interference between application tasks and reconfiguration tasks is represented explic-itly as a CPOG resulting either from an interleaving of computation and reconfiguration actions or from thesimultaneous execution of the actions. The interference can be controlled using the predicates on the interferingactions and on their dependencies.

In basic CCSdp, functional interference between application tasks and reconfiguration tasks is representedexplicitly as a process expression resulting from an interleaving of communication, internal, and reconfigurationtransitions of concurrently executing processes. The control of interference can be achieved by extending thesemantics of transitionswith rely and guarantee conditions on transitions orwith a priority scheme for transitionsderived from such conditions.


F7: It should be possible to express and to verify the functional correctness requirements of applicationtasks and reconfiguration tasks

The verification of the case study in VDM-SL used simulation and testing. These techniques are weaker thanmodel checking and proof. The two VDM tools do not currently support model checking due to the generality ofthe formalism.However, experimental coupling to SPINhas been reported [LOKA16].While a proof theory existsfor core VDM functionality, there is currently a lack of tool support for discharging proof obligations, althoughproof obligations can be generated automatically. In addition, the object-oriented and real-time extensions toVDM are currently not covered by the proof theory. However, this is an active area of research.

Tasks and functional requirements on tasks can both be expressed as CPOGs. The verification of functionalcorrectness of a task can be done in different ways. The axioms support equational reasoning and can transformthe CPOG of a task into the CPOG of its requirement, assuming the two CPOGs are algebraically equivalent.Alternatively, we can show that both CPOGs have the same set of consistent histories. Finally, the LTS semanticsof CPOGs supports model checking [MY08, Mok09].

In basic CCSdp, the equational theory uses congruence based on strong of-bisimulation (∼of ), developedin [Bha13]. However, strong of-bisimulation is too strong for the case study. Therefore, weak observationalbisimulation (≈o) was used to express requirement R3 and to attempt its verification. However, equationalreasoning requires an invariant to be verified, which can be lacking in a reconfiguration where the source anddestination configurations are significantly different. In these situations, temporal logic and model checking canbe used.

F8: It should be possible to model the concurrent execution of tasks

VDM-SL does not have built-in abstractions for modelling concurrency. In this paper, concurrent execution oftasks was achieved using non-deterministic interleaving of tasks defined using the Par type. Modelling of fine-grained concurrency or true parallelism is of course possible [CJ07], but takes more effort. The VDM++ andVDM-RT dialects permit modelling of true concurrency and, as described above, can be used to continue themodelling as part of a more complete development process.

In CPOGs, concurrently executing tasks are represented as concurrently executing CPOGs. The LTS rules ofCPOGs show that a CPOG can perform either one transition at a time or a set of multiple transitions simultane-ously. Therefore, CPOGs have both an interleaving semantics of concurrency and a true concurrency semantics,and thereby can model both pseudo-concurrency and true concurrency. Hence, the concurrent execution of tasksis modelled as the set of partial orders of the transitions of the concurrent CPOGs representing the tasks. Thegranularity of concurrency in CPOGs is a single action.

In basic CCSdp, concurrently executing tasks are represented as concurrently executing processes. The LTSrules of the algebra show that a process expression can perform only one transition at a time. Therefore, basicCCSdp has an interleaving semantics of concurrency, and thereby models pseudo-concurrency rather than trueconcurrency (as in CCS). Hence, the concurrent execution of tasks is modelled as the set of total orders of thetransitions of the concurrent processes representing the tasks. The preemption of actions is not modelled. Noticethat the granularity of reconfiguration is the same as the granularity of concurrency.

F9: It should be possible to model state transitions of software components and tasks

State transitions in VDM are modelled using operations acting on global state (in VDM-SL) or on object state(in VDM++ and VDM-RT).

In CPOGs, state transitions of software components and of tasks are modelled as transitions of CPOGs,see the LTS rules in Sect. 5.3. The state of a CPOG G is given by (H , ψ), where H is the set of completedactions performed byG , and ψ is the assignment of values to Boolean variables performed by actions in H afterinitialisation of the variables.

In basic CCSdp, state transitions of software components and of tasks aremodelled as transitions of processes,see Table 2. The state of a process P after performing one or more transitions is given by process P ′.


F10: The formalism should be as terse as possible

The VDM dialects are general purpose languages, with many similarities to imperative programming languages.Hence, they lack built-in abstractions for modelling processes (for example) and (therefore) are in general lessterse than process algebras in this regard. However, the VDM dialects allow for abstract data type definition,permitting terse description of data types relative to implementations. Similarly, implicit definition of operationsusing only post-conditions permits terse definition of functionality.

CPOGs are a compact representation of graphs, and graphs are a useful formalism for model checking.Thus, CPOGs are useful for verification by model checking using SAT solvers and by equational reasoning usingalgebraic manipulation. CPOGs are a less expressive formalism than basic CCSdp, and their key limitation is theinability to represent cyclic processes. However, CPOGs can be obtained from cyclic process descriptions usinga standard unfolding procedure [McM93]. Furthermore, more expressive variants of CPOGs enable predicatesto be defined over non-Boolean variables, and Boolean variables to be controlled by more than one action andtheir value to be changed more than once, which increases the terseness of CPOG models.

Basic CCSdp is a terse formalism for several reasons. First, CCS is terse. Second, fraction processes do notcontain implementation detail. Third, overloading the parallel composition operator avoids the use of a newoperator for performing reconfiguration, such as the interrupt operator in CSP. Fourth, process matching usesbehaviour tomatch processes rather than structural congruence or process syntax, which enables the denominatorof a fraction to match a larger set of processes than is possible with structural congruence or syntactic equality.The terseness of basic CCSdp models can be increased by extending the algebra to enable value passing, whichavoids the summation of action names encoded with values (used in the case study).

F11: The formalism should be supported by tools

VDM is supported by two industrial-strength tools (Overture5 and VDMTools6) that are both under activedevelopment. These tools provide syntax highlighting and type checking facilities, and include interpreters thatallow simulation of the workflow case study. The tools also provide more advanced features such as unit andcombinatorial testing, proof obligation generation, and code generation.

The algebraic manipulation of CPOGs can be automated either by reusing standard term rewriting engineslikeMaude or by developing a custom proof assistant embedded in a high-level language likeHaskell; the authorseventually followed the latter approach. However, the tools are not yet ready for public release.

Basic CCSdp is a new process algebra, and the notions of fraction process and process matching are extremelynovel. Therefore, the algebra does not have tool support at present, although there are plans to develop toolsfor modelling and verification. The computational complexity of process matching based on behaviour suggeststhat a simpler form of matching is required, for example, based on syntactic equality or a decidable structuralcongruence, that will also allow the restriction operator to be added to the algebra to enable scoping of names.

F12: The formalism should be easy to learn and to use

VDM is a well-established formal method with a history of industrial use, with a variety of materials availableincluding books [Jon90, FLM+05, FL09] and examples that are included with the Overture tool.7 Typically,engineers can begin modelling with only a few days training. Agerholm et al. [ALR98] support this claim,suggesting that this is because ‘VDM supports a range of abstraction levels and its concepts are easy to learn’and that ‘validation based on testing (animation/prototyping) is already well-known to engineers, in contrast toother techniques typically associated with formal methods such as refinement and formal proof.’ [ALR98, p. 83].So the adaptability of VDM as a general language is seen as a strength in this instance.

5 http://overturetool.org/.6 http://www.vdmtools.jp/en/.7 See Overture examples repository: http://overturetool.org/download/examples/.

http://overturetool.org/

http://www.vdmtools.jp/en/

http://overturetool.org/download/examples/


Table3:

Summaryof

compa

risonof

theVienn

aDevelop

mentMetho

d,Con

dition

alPartial

Order

Graph

s,an

dba

sicCCSd

p

Vienn

aDevelop

mentMetho

dCon

dition

alPartial

Order

Graph

sBasicCalculusof

Com

mun

icating

System

sfordy

namicprocess

reconfi

guration

Recon

figurationop

erations

(see

F2)

Workfl

owreplacem

ent

Actionan

daction

depend

ency

creation

,activation

,and

deactivation

Process

creation

,replacement,an

ddeletion

Mod

ellin

gof

statetran

sfer

(see

F4)

Mod

elba

sedon

persistent

glob

alstate

withop

erations

that

perm

itpa

rameter

passing

Sha

redBoo

lean

variablescanbe

used

tostoreglob

alstate

Selectionof

apre-defin

edprocessin

asummation,

orreplacem

entby

apre-defin

edprocessusingafraction

process

Mod

ellin

gof

plan

nedan

dun

plan

ned

dyna

micreconfi

guration

(see

F5)

Recon

figurationop

erationiscalledby

theinterpreterforplan

ned

reconfi

guration

,orby

the

environm

entforun

plan

ned

reconfi

guration

Recon

figurationaction

san

dpredicates

used

tomod

elreconfi

guration

;location

oftheaction

san

dpredicates

distingu

ishesp

lann

edfrom

unplan

nedreconfi

guration

Fractionprocessused

tomod

elreconfi

guration

;locationof

fraction

distingu

ishesplan

nedfrom

unplan

ned

reconfi

guration

Mod

ellin

gof

function

alinterference

betw

eenap

plicationan

dreconfi

guration

tasks(see

F6)

Workfl

owresultingfrom

atom

icreplacem

entof

currentlyexecuting

workfl

owwithinpu

tworkfl

ow

CPOG

resultingfrom

interleavedor

simultaneou

scompu

tation

and

reconfi

guration

action

s

Process

expression

resultingfrom

interleavedcompu

tation

and

reconfi

guration

tran

sition

s

Con

currency

mod

el(see

F8)

Interleaving

seman

tics

Interleaving

andtrue

concurrency

seman

tics

Interleaving

seman

tics

Formal

seman

tics

(see

Sects.4,

5,6)

Denotationa

lsem

antics

Axiom

aticseman

tics

Lab

elledtran

sition

system

Verification

offunction

alcorrectnesso

fap

plicationan

dreconfi

guration

tasks

(see

F7)

Simulationan

dtesting

Equ

ationa

lreasoning

usingax

ioms,

consistent

histories,an

dmod

elchecking

Equ

ationa

lreasoning

usingstrong

of-bisim

ulation,

useof

weak

observationa

lbisimulation,

andmod

elchecking

Metho

dfordy

namicreconfi

guration

(see

Sects.4,

5,6)

Trace

prefixinclusion

Con

sistenthistoryinclusionan

dforbiddenaction

sNon

e

Tool

supp

ort(see

Fll)

Overturean

dVDMTo

olsallowtype

checking

,interpretation,

automated

testing,

proo

fob

ligationgeneration

,an

dcode

generation

;exp

erim

ental

mod

elchecking

isin

developm

ent

Haskell-ba

sedtoolsforalgebraic

man

ipulationusingax

ioms

Non

e


CPOGs are as easy to learn as graphs, which are a very simple formalism. However, CPOGs were designedfor hardware and (therefore) are relatively low-level and less easy to use than formalisms designed for software,such as VDM. In using CPOGs, the designer is expected to operate with low-level events and conditions, andat present it is not known whether any higher level concept has a meaningful interpretation in CPOG theory.Another limitation is the lack of mature tool support. We were able to employ generic tools like Maude andto implement a prototype domain-specific language in Haskell. However, interoperability with other existingtool-kits is very limited. It is unrealistic to expect CPOGs to be used to specify a complete system. Therefore, it isessential to develop tools that enable conversion between well-established system design methods, such as VDM,and CPOGs in order to use the verification capabilites offered by CPOGs.

Basic CCSdp is as easy to learn and to use as basic CCS, which is a simple formalism. Furthermore, thereaction transition through which a fraction process reconfigures a target process (e.g. p/ | P ′

P/

τ−→ P ′ ) resemblesthe cancellation of numbers in arithmetic (e.g. 3/ . 2

3/ � 2). Therefore, the behaviour a fraction process is likelyto be surprisingly familiar to users. Moreover, the complexity of the theory behind the fraction process will beencapsulated within analysis tools. It is also quite possible that the tools of the algebra will be embedded in a toolchain with a graphical front end, so that the end users will not need to use CCSdp directly.

8. Related work

There is a considerable amount of research into formalisms for the dynamic reconfiguration of software[WIdlIA12]. The research can be categorised into approaches based on process algebras, graphs, logics, andcontrol theory [BCDW04]. We review a selection of formalisms and then summarize the key findings.

8.1. Process algebras

π -calculi are extensions of theCalculus of Communicating Systems (CCS) [Mil89], which form a large and diversefamily of process algebras and are widely used in the study of dynamic reconfiguration, see [MPW92], [Tho90],[HT91], [Bou92], [PV98], and [RS03]. As in basic CCSdp, software components and tasks are represented asprocesses, and their communication links are represented as pairs of complementary port/action names (e.g. aand a). An individual process can be identified by a unique process identifier (e.g.A(a, b) � a.b.A<a, b>), but acommunication link has no identifier. As inmost process algebras, a process can be easily created (e.g. a.(P1 | P2))or deleted (e.g. a.0) if designed to do so, but modelling the deletion of non-terminating processes is problematic.The special feature of π -calculi is the passing of port/action names as parameters and the uniform treatmentof parameter values and variables, which in combination enable link creation and deletion to be modelled verysimply. For example, if P � x < y > .P ′ and Q � x (u).u(v ).Q ′ and R � y <w > .R′, then P in the expressionP | Q | R passes the port name y to Q (thereby substituting u by y) so that Q can communicate with R (andthereby receive w ), which is expressed by the following transitions:

x <y>.P ′ | x (u).u(v ).Q ′ | y<w >.R′ τ−→ P ′ | y(v ).{yu

}Q ′ | y<w >.R′ τ−→ P ′ |

{wv

} {yu

}Q ′ | R′

The communication link between Q and R can be deleted by a subsequent substitution of u. Relocation ofprocesses on physical nodes is easily modelled in higher-order π -calculi [Tho90] using process passing, whichcan be encoded in first-order π -calculi [San93]. This is important, because the theory of first-order π -calculi issimpler than the theory of higher-orderπ -calculi. State transfer ismodelled as communicationwith value passing.Thus, planned reconfiguration is easily modelled. Notice that the modelling of reconfiguration is based on com-munication, which cannot be unplanned. Therefore, the modelling of unplanned reconfiguration is problematic.Functional interference between processes is modelled using interleaved transitions, since π -calculi have an inter-leaving semantics of concurrency. Verification of functional correctness is based on equational reasoning usingstructural congruence or process congruence based on strong or weak bisimulation; the LTS of π -calculi enablesmodel checking of processes. However, there is no control over non-deterministic transitions, nomethod forman-aging reconfiguration, and bisimulation is undecidable. The expressivity of π -calculi complicates verification ofrequirements, which requires processes to be restricted, for example, to finite control processes formodel checking[MKS09]. π -calculi are reasonably terse because they describe only communication and its reconfiguration. Toolsupport forMilner’s, Parrow’s, andWalker’s synchronous π -calculus [MPW92] includes theMobilityWorkbench[VM94], which checks for open bisimilarity between processes and for deadlocks, and TyPiCal [Kob06], which isa type-based static analyzer for checking deadlock freedom and termination; and tool support for the asynchro-


nous π -calculus Aπ [HT91][Bou92] includes Pict [PT00], which is a strongly-typed programming language. Thetools facilitate the use of π -calculi by researchers, but are not designed for use by system designers.

Another large family of process algebras is designed specifically forworkflowsand service-oriented computing,see [BLZ03], [BHF05], [BBC+06] and [GLG+06], and includes webπ∞[LM07] and the Calculus for OrchestrationofWeb Services (COWS) [PT12]. webπ∞ is a conservative extension ofAπ designed to model web service orches-tration [Maz06]. The process syntax ofAπ is extended with the construct 〈|P ; Q |〉x (termed a workunit) in orderto model error handling [LM07]. The workunit executes P until either P terminates (whereupon the workunitterminates) or an interrupt is received on channel x during the execution of P . The interrupt can be sent either byP or by a process in the context of the workunit, and causes the premature termination of P (without rollback)and the execution of Q . Thus, workunits can be used to model event-triggered planned process reconfiguration.However, unplanned process deletion and process replacement cannot be modelled, and specific instances ofprocesses cannot be identified for reconfiguration. Currently, webπ∞has no tool support. COWS represents asystem as a composition of services provided by components (termed partners) [PT12]. Services consist of otherservices or basic operations, and are loosely coupled and reusable computational units that communicate asyn-chronously using messages. There is no notion of a transaction or of a session between communicating services,but messages contain sufficient header information for a session to be inferred by a service using patternmatchingbetween message headers (termedmessage correlation). Link reconfiguration is restricted to output capability, asin the localised π -calculus Lπ [SW01], that is, a received name can be used only for invoking a service. Processreconfiguration is achieved by creating a service instance, and by terminating a service instance using the killoperator. The combination of asynchronous communication, message correlation, output capability, the killoperator, and the publish-discover-bind & invoke paradigm of service-oriented computing enables a high degreeof reconfiguration of a workflow to be expressed. Tool support for COWS consists of the CMC ‘on-the-fly’model checker that can verify formulae expressed in the SocL branching-time temporal logic using a COWSexpression converted into a doubly labelled transition system, that is, an LTS in which each transition is labelledwith a set of actions [FGL+12]. However, as with webπ∞, unplanned process deletion and process replacementcannot be modelled, since the kill operator is embedded within the system model and is statically bound to theservice instance to be terminated; true concurrency cannot be represented, since COWS has only an interleavingsemantics; and there is no development tool for refining a COWS expression to an implementation.

Paradigm is a coordination modelling language that can represent dynamic adaptation in distributedcomponent-based systems [AGdV14]. Each component of a system is represented as a state transition diagram(STD) with sub-STDs (termed phases) used to represent the internal transitions of the component. An individualcomponent can be identified by a unique identifier (e.g. McPal or McPhili ). The phases of a component areconnected by sets of states they have in common (termed traps) that enable transitions between two phases ofthe component (termed phase transfers) to be synchronized with other phase transfers in concurrently executingcomponents of the system. Each transition of the system is defined by a consistency rule that determines thesynchronised phase transfers of the components involved in the transition. Thus, communication between com-ponents is not explicitly represented; hence, link reconfiguration is not represented. Dynamic reconfigurationis expressed as coordination involving a special reconfiguration component (McPal) to create and delete STDs.Thus, unplanned component creation and deletion is represented.McPal uses shared variables (e.g.Crs andCrsi )that store STDs, phases, traps, and consistency rules to delegate (and thereby distribute) the reconfiguration ofcomponents to subsidiary reconfiguration components (e.g. McPhili ), and controls the reconfiguration using acombination of orchestration and choreography. The use of traps and consistency rules to define system transi-tions (including reconfiguration transitions) enables both interleaving concurrency and true concurrency to behandled, enables functional interference to be controlled, and in combination with the use of shared variablesfacilitates state transfer between components. Tool support is provided by the mCRL2 model checker (based onACP [BK84]) that can verify formulae expressed in a variant of the modal μ-calculus [BS07] using a Paradigmmodel converted into an mCRL2 process model. However, the Paradigm models are not terse, since each sys-tem transition must be defined explicitly by a consistency rule, and there is no development tool for refining aParadigm model to an implementation.

8.2. Graphs

Graph-based formalisms for dynamic reconfiguration include graph grammars, such as Graph Abstractions forConcurrent Programming (GARP) [KK88] and �-grammars [KGC89], rewriting systems, such as the Chemical


Abstract Machine (CHAM) [BB92] and Maude [MAU15], and formalisms based on category theory, such asReo [KMLA11] and CommUnity [WLF01].

GARP models a system as a directed graph, in which named vertices (termed agents) represent tasks thatcommunicate asynchronouslybymessagepassing throughports.Agentsperformcomputation, andgraph rewritesthat reconfigure the model by replacing a vertex with a subgraph defined in a production rule. Thus, GARPmodels planned task reconfiguration, but the reconfiguration of communication links is not modelled. Trueconcurrency is represented, but interference between computation and reconfiguration actions is not represented,since graph rewrites are atomic. Hence, GARP models the effect of dynamic reconfiguration rather than theprocess of reconfiguration. State transfer is modelled through parameter passing to an agent. The similarity ofgraph grammars to string grammars enables a GARP model to be converted to a program. However, there is nomethod for formally verifying a requirement using a GARP model.

CHAM is based on theGAMMA formalism defined in [BM90]. GAMMAmodels a data value as amolecule,the system’s state as a solution (i.e. a finite multiset) of molecules, and a computation as a sequence of reactionsbetweenmolecules defined by transformation rules between solutions and guarded by reaction conditions. Differ-ent reactions can run with true concurrency if their source multisets are disjoint; otherwise, a non-deterministicchoice is made as to which reaction will occur. GAMMA uses multisets in order to avoid unnecessary orderingrestrictions in the specification of an algorithm caused by the use of list-based data structures. CHAM extendsGAMMA by allowing the user to define the syntax of a molecule; a membrane construct is used to encapsulate asolution, so that it behaves like a single molecule, thereby enabling a large system to be structured as a hierarchyof solutions; and an airlock construct is used to control reactions between a given solution and its environment.System reconfiguration is expressed as rewrites of multisets of molecules [Met96]. CHAM has been used to spec-ify software architectures [IW95], and to specify the dynamic reconfiguration of software architectures [Wer99].However, as with GARP, CHAM does not model the process of reconfiguration. Furthermore, the conceptsunderlying the CHAM constructs are very different from those normally used by architects to design systems[Ore98], so that ensuring a CHAM description is an abstraction of an architect’s description becomes an issue.In contrast, the ‘conceptual gap’ between the architect’s description and a process algebraic description is muchless. There is no development tool for refining a CHAM model to an implementation.

Reo is a channel-based coordination language that uses connectors to model the composition and reconfig-uration of component-based systems [KMLA11]. A channel is a means of communication with an associatedprotocol (e.g. FIFO) and can be synchronous or asynchronous. A channel has two endpoints (i.e. nodes) that canbe connected to communication ports of components or can be used to compose channels. A connector is a setof components and channels, and is represented by a typed hypergraph whose vertices and edges denote nodesand channels/components respectively. Notice that a component is treated as a type of channel in Reo. Reconfig-uration consists of the atomic replacement of one or more connectors, and is performed using double pushout(DPO) graph rewriting [EPS73]. A reconfiguration is defined by a rule consisting of a pattern (formulated using agraph grammar) that must be matched by one or more connectors, and a template that describes the rewrite to beperformed on the matched connectors. Additional conditions can be defined to restrict further the application ofthe rules, such as conditions on the state of a component or of a channel. Structural and behavioural invariantscan be defined on a connector to ensure consistency of the state of the reconfigured connector. However, thereis no common formal semantics for connector execution and graph rewriting. Therefore, functional interferencebetween connectors and the reconfiguration engine cannot be formally expressed or analyzed. Tool support isprovided on the Eclipse platform and includes centralized and distributed execution engines that runReomodels,a reconfiguration engine to perform pattern matching and DPO graph rewriting, graphical editors, and a codegenerator that can be invoked from an editor to produce Java code from a Reo model [SEN08]. The authors arenot aware of any proof of correctness of the code generator. Third party tools are also used, namely, the GRaphsfor Object-Oriented VErification (GROOVE) tool [Ren03] for symbolic model checking using computation treelogic (CTL) formulae, and the Attributed Graph Grammar (AGG) system [Tae03] for checking whether or nottwo rules are in conflict in the reconfiguration of a connector.

8.3. Logics

Logic-based formalisms for dynamic reconfiguration include the Generic Reconfiguration Language (Gerel)[EW92], Aguirre-Maibaum’s specification language [AM02], the half-order dynamic temporal logic (HDTL)[CKCB01], and linear temporal logic (LTL) [Pnu77], [Maz14].


The Aguirre-Maibaum language is a declarative specification language for component-based systems thatuses a combination of first-order logic (to reason about data types) and temporal logic (to reason about actions).A software component is represented as an instance of a class, a communication link between components isrepresented as an instance of an association, and classes are combined using associations to produce a subsystem.A class definition consists of: attributes that represent variables of basic data types, actions that represent themethods of the class, exports that represent the public methods offered by the class to its environment, readvariables that are used to obtain information from the environment, and axioms that define the effect of theactions on the attributes. Communication between components is represented using synchronised actions andshared attributes, and the behaviour of associations is defined by axioms in the subsystem definition. Statetransition, state transfer, and component relocation can all be described as effects of actions on attributes.Reconfiguration is represented as the planned creation and deletion of instances of classes and of associations ina subsystem, but unplanned reconfiguration is not represented. The declarative nature of the language enablesthe effect of reconfiguration to be described easily, but describing the process of reconfiguration with functionalinterference between application and reconfiguration tasks is problematic. The language supports verification offunctional correctness by model checking, but there is no tool support, and there is no development method forrefining a model to an implementation.

8.4. Control theory

The application of control theory to dynamic software reconfiguration is relatively new in comparison to theother formal approaches, and is focused on modelling control loops and synthesizing controllers in self-adaptivesoftware systems [PCHW12]. One example is given in [FHM15], which presents an automated method of synthe-sizing cascade controller systems with multiple actuators and multiple controlled variables (termed dimensions)based on a prioritization of the dimensions. Each actuator has an associated control variable (termed a knob) thatcan affect one ormore dimensions simultaneously, and the knobs are partitioned according to the highest priorityof the dimensions they control. Thus, a knob associated with a given priority does not control any dimensionwith a higher priority. The method accepts as input a set of quantified goals (termed setpoints) to be achieved forthe dimensions, a set of knobs, and possibly a prioritization scheme for the dimensions, and outputs a synthesizedcontrol system. No assumption is made about the relationship between a knob and a setpoint, which is deter-mined empirically at runtime using existing parametric modelling techniques, and the setpoints are achieved bycalculating values of the knobs in decreasing order of priority, which reduces the computational complexity of thecalculations. The method assumes that each knob has default value, the number of knobs is greater than or equalto the number of setpoints, and that there is at least one dimension that is free (i.e. the dimension can be maxi-mized or minimized without guaranteeing a specific value). Dynamic reconfiguration consists of the replacementof one set of controllers by another set of dynamically synthesized controllers. However, the research does notaddress the process through which the replacement occurs, and (therefore) the interference between controllersand reconfiguration tasks is not addressed. Nevertheless, the absence of any pre-defined relationship betweenknobs and setpoints supports unplanned reconfiguration. The method is amenable to automation that wouldrender it highly usable by system designers, but it currently lacks tool support.

8.5. Summary

The review of related work shows that no single formalism or category of formalisms is ideal, since none of themmeets all the requirements on an ideal formalism for dynamic software reconfiguration defined in Sect. 2.

π -calculi represent the planned creation, deletion, and replacement of components/tasks using processes, andthe planned creation and deletion of communication links using port/action names, but they cannot represent theunplanned creation, deletion, and replacementof components/tasks (unlikebasicCCSdp).Functional interferencebetween concurrently executing tasks is represented using interleaved transitions, since true concurrency cannotbe represented (unlike CPOGs). The same limitations exist in webπ∞ and in COWS. Paradigm can express bothplanned and unplanned creation and deletion of components/tasks (but not reconfiguration of communicationlinks), and also functional interference due to interleaving concurrency and true concurrency, but its models arenot as terse as those of basic CCSdp or of CPOGs, and it lacks development tools (unlike VDM).

Graph-based formalisms such asGARPandReo represent reconfiguration in terms of graph rewrites, and canrepresent both interleaving concurrency and true concurrency. However, they have no formal semantics for


representing the execution of both application tasks and reconfiguration tasks (unlike CCSdp and CPOGs), and(therefore) they cannot formally express or analyze functional interference between the two kinds of task (unlikeCCSdp and CPOGs). Like GARP, CHAM represents the effect of reconfiguration rather than the process ofreconfiguration, and (therefore) expressing interference between application and reconfiguration tasks is prob-lematic. Furthermore, the CHAMnotion of reconfiguration as the application of rewrite rules to rewrite rules canbe problematic for a system designer to understand (unlike the fraction process in basic CCSdp, a reconfigurationaction in a CPOG, and a reconfiguration operation in a VDM model).

The Aguirre-Maibaum language can represent the planned creation and deletion of tasks (using classinstances) and of communication links (using association instances), but not in an unplanned manner. Further-more, representing interference between application and reconfiguration tasks is problematic, since the languageis declarative. However, the language supports model checking, which is also supported by VDM, CPOGs, andbasic CCSdp. In fact, temporal logics are complementary to VDM, CPOGs, and basic CCSdp, because require-ments on application tasks, reconfiguration tasks, and on their interference can be formulated using temporallogics, and the formulae can be verified by model checking the VDM, CPOG, and basic CCSdp expressions thatrepresent the execution of the tasks.

The reconfiguration presented in [FHM15] does not discuss the process of reconfiguration, and (therefore)the issue of interference between application and reconfiguration tasks is not addressed. However, the research iscomplementary to our use of VDM, CPOG, and basic CCSdp, because VDM can be used to verify formally thatthe synthesized controllers are a correct implementation of their specification, and basic CCSdp and CPOGs canbe used to construct and to verify correct reconfiguration paths between the old set of controllers and the newset of controllers that take into account interference between the concurrent execution of old controllers, newcontrollers, and reconfiguration tasks.

9. Concluding remarks

This paper has used the dynamic reconfiguration of a simple office workflow for order processing as a case studyin order to compare empirically the modelling and analysis capabilities of three formalisms of different kinds,namely, VDM, CPOGs, and basic CCSdp.

The evaluations of the three formalisms show that none of them is ideal, since none of them meets all therequirements on an ideal formalism for dynamic software reconfiguration defined in Sect. 2. For example, keyrequirements include: the ability to express tersely change in the composition and structure of software com-ponents and tasks for both planned and unplanned dynamic reconfiguration; the ability to express tersely theconcurrent execution of tasks and their functional interference; and the ability to verify the functional correct-ness requirements of tasks, which includes verifying the functional correctness of refinements. Neither VDM,nor CPOGs, nor basic CCSdp meets all three requirements. However, the formalisms meet the requirementscollectively. Furthermore, all three formalisms can easily express traces of actions. Therefore, the formalismsare complementary, and it should be possible to combine them using basic CCSdp for modelling, CPOGs forverification, and VDM for type checking and refinement.

The main strengths of basic CCSdp are its ability: to model abstractly and tersely the composition andconcurrent execution of application and reconfiguration tasks using concurrent processes, to model their func-tional interference using interleaved transitions, and tomodel their planned and unplanned reconfiguration usingfraction processes. Furthermore, cyclic processes can be modelled using recursion, and fraction processes canthemselves be reconfigured using other fractions. The main weaknesses of basic CCSdp are its inability to controlnon-deterministic transitions and inability to reconfigure selectively specific process instances, the computationalcomplexity of process matching based on strong of-bisimulation, the computational complexity and restrictive-ness of process congruence that severely limits the use of equational reasoning to verify requirements [Bha13],and lack of tools. In contrast, themain strength of a CPOG is its ability to verify requirements efficiently. Amodeland its requirement can each be transformed into a canonical form and then compared using a Boolean SATsolver, and the predicates on actions and on action dependencies and the acyclic topology of a CPOG supportefficient model checking. The correctness of a reconfiguration from one configuration to another can be provedusing consistent histories of actions of the two configurations and by restricting interference through forbiddenactions. Furthermore, functional interference between tasks can be modelled using either interleaved actions orsimultaneous actions. The main weaknesses of a CPOG are: its inability to model composition and structure ofsoftware components and tasks, its low level of abstraction for modelling, its inability to model cyclic processes,and lack of available tools. In contrast to both basic CCSdp and CPOGs, VDM was designed for formal devel-


opment of software. The main strengths of VDM-SL are: its ability to model workflows, software components,and tasks as data types, which facilitates their refinement to an implementation, its mature and available tools fordevelopment, simulation, and testing, and its ease of use by system designers. The main weaknesses of VDM-SLare lack of constructs for modelling concurrency and interference, and lack of formal verification tools.

All three formalisms can represent traces of actions or transitions. Furthermore, a CPOG is the unfolding ofa process. Therefore, it is possible to map a process to a CPOG. A variant of CPOGs with variables whose valuecan be changedmore than once by actions can be used to simplify the mapping. A recursively defined process canbe unfolded to a CPOG using a standard unfolding procedure. Rely and guarantee conditions on the transitionsof a process can be used to define a priority scheme for the transitions in order to control their non-determinismand to define a partial order between their corresponding actions in the CPOG of the process. As with CPOGs, itshould be possible to convert a process in basic CCSdp into a graph of actions in VDM-RT for type checking andrefinement into an executable form. Thus, it should be possible to construct an integrated approach to the formalmodelling, verification, and development of dynamically reconfigurable dependable systems based on VDM,CPOGs, and basic CCSdp or a combination of similar formalisms. We intend to demonstrate this hypothesis inour future work.

Acknowledgements

The research leading to this paper was funded from several sources: Bhattacharyya’s research was funded by theUK Engineering and Physical Sciences Research Council (EPSRC) under the terms of a graduate studentship,the PlatformGrant on Trustworthy Ambient Systems (TrAmS), and the EP/K001698/1 UNCOVER project, andby the European Community’s Seventh Framework (FP7) Deploy project; Mokhov’s research was funded bythe UNCOVER project and by the Royal Society Research Grant ‘Computation Alive’; and Pierce’s researchwas funded from the FP7 and Horizon 2020 programmes (287829 COMPASS, 644047 INTO-CPS, and 644400CPSELabs). The authors acknowledge the help given by numerous colleagues, in particular: JeremyBryans, JohnFitzgerald, Regina Frei, Kohei Honda, Alexei Iliasov, Cliff Jones, Victor Khomenko, Maciej Koutny, ManuelMazzara, Richard Payne, Traian Florin Serbanuta, Giovanna Di Marzo Serugendo, and Chris Woodford.

This is a revised version of the paper. The authors thank the anonymous reviewers for their constructivefeedback and helpful suggestions, the implementation of which undoubtedly improved the quality of the paper.

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 InternationalLicense (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and repro-duction in any medium, provided you give appropriate credit to the original author(s) and the source, provide alink to the Creative Commons license, and indicate if changes were made.

References

[AGdV14] Andova S, Groenewegen LPJ, de Vink EP (2014) Dynamic adaptation with distributed control in Paradigm. Sci ComputProgram 94:333–361

[ALR98] Agerholm S, Lecoeur, P-J, Reichert E (1998) Formal specification and validation at work: a case study using VDM-SL. In:Proceedings of the second workshop on formal methods in software practice, FMSP ’98, pp 78–84, New York, NY, USA,ACM

[AM02] Aguirre N, Maibaum T (2002) A temporal logic approach to the specification of reconfigurable component-based systems.In: Proceedings of the 17th IEEE international conference on automated software engineering, pp 271–274

[AP07] Ardagna D, Pernici B (2007) Adaptive service composition in flexible processes. IEEE Trans Softw Eng 33(6):369–384[AWvSN01] Almeida JPA, Wegdam M, van Sinderen M, Nieuwenhuis L (2001) Transparent dynamic reconfiguration for CORBA. In:

Proceedings of the 3rd international symposium on distributed objects and applications, pp 197–207[BB92] Berry G, Boudol G (1992) The chemical abstract machine. Theor Comput Sci 96(1):217–248[BBC+06] BorealeM, BruniR, Caires L,DeNicolaR, Lanese I., LoretiM,Martins F,MontanariU,RavaraA, SangiorgiD, Vasconcelos

V, Zavattaro G (2006) SCC: a service centered calculus. In: Proceedings of the 3rd international workshop on web servicesand formal methods (WS-FM), pp 38–57

[BCDW04] Bradbury JS, Cordy JR, Dingel J, Wermelinger M (2004) A survey of self-management in dynamic software architecturespecifications. In: Proceedings of the 1st ACM SIGSOFT workshop on self-managed systems, pp 28–33

[BD93] Bloom T, Day M (1993) Reconfiguration and module replacement in Argus: theory and practice. Softw Eng J (Special Issue)8(2):102–108

[BFL+94] Bicarregui J, Fitzgerald J, Lindsay P,MooreR,Ritchie B (1994) Proof in VDM: a practitioner’s guide. FACIT. Springer-Verlag.ISBN 3-540-19813-X

http://creativecommons.org/licenses/by/4.0/


[Bha13] Bhattacharyya A (2013) Formal modelling and analysis of dynamic reconfiguration of dependable systems. PhD thesis, New-castle University School of Computing Science. http://hdl.handle.net/10443/1851.

[BHF05] Butler M, Hoare T, Ferreira C (2005) A trace semantics for long-running transactions. In: Proceedings of the symposium onthe occasion of 25 years of CSP, pp 133–150

[BK84] Bergstra JA, Klop JW (1984) Process algebra for synchronous communication. Inf Control 60:109–137[BLZ03] Bocchi L, Laneve C, Zavattaro G (2003) A calculus for long-running transactions. In: Proceedings of the 6th IFIP WG 6.1

international conference on formal methods for open object-based distributed systems (FMOODS), pp 124–138[BM90] Banatre JP, Le Metayer D (1990) The GAMMAmodel and its discipline of programming. Sci Comput Program 15(1):55–77[Bou92] Boudol G (1992) Asynchrony and the π -calculus. Technical report 1702. Institut National de Recherche en Informatique et

en Automatique[Bra02] Bravetti M (2002) Specification and analysis of stochastic real-time systems. PhD thesis, University of Bologna[BS07] Bradfield J, Stirling C (2007) Handbook of modal logic, chapter Modal mu-calculi. Elsevier Science Inc, New York, NY, pp

721–756[CHM94] Christensen S, Hirshfeld Y, Moller F (1994) Decidable subsets of CCS. Comput J 37(4):233–242[CHNF10] Coyle L, Hinchey M, Nuseibeh B, Fiadeiro JL (2010) Guest Editors’ introduction: evolving critical systems. IEEE Comput

43(5):28–33[CHS+10] Classen A, Heymans P, Schobbens P-Y, Legay A, Raskin J-F (2010) Model checking lots of systems: efficient verification of

temporal properties in software product lines. In: Proceedings of the 32nd ACM/IEEE international conference on softwareengineering, ACM, vol 1, pp 335–344

[CJ07] Coleman JW, Jones CB (2007) A structural proof of the soundness of rely/guarantee rules. J Log Comput 17:807–841[CKCB01] Cho SM, Kim HH, Cha SD, Bae DH (2001) Specification and validation of dynamic systems using temporal logic. IEE Proc

Softw 148(4):135–140[EKR95] Ellis C, Keddara K, Rozenberg G (1995) Dynamic change within workflow systems. In: Proceedings of the conference on

organizational computing systems, ACM, pp 10–21[EPS73] Ehrig H, Pfender M, Schneider HJ (1973) Graph-grammars: an algebraic approach. In: IEEE conference record of the 14th

annual symposium on switching and automata theory, pp 167–180[ES04] Een N, Sorensson N (2004) An extensible SAT-solver. Theory and applications of satisfiability testing, pp 333–336[EW92] Endler M, Wei J (1992) Programming generic dynamic reconfigurations for distributed applications. In: Proceedings of the

international workshop on configurable distributed systems, IET, pp 68–79[FGL+12] Fantechi A, Gnesi S, Lapadula A, Mazzanti F, Pugliese R, Tiezzi F (2012) A logical verification methodology for service-

oriented computing. ACM Trans Softw Eng Methodol 21(3):16:1–16:46[FHM15] Filieri A,HoffmannH,MaggioM (2015) Automatedmulti-objective control for self-adaptive software design. In: Proceedings

of the 10th joint meeting on foundations of software engineering, pp 13–24[FL09] Fitzgerald J, Larsen PG (2009) Modelling systems—practical tools and techniques in software development, 2nd edn. Cam-

bridge University Press, The Edinburgh Building, Cambridge CB2 2RU, UK. ISBN 0-521-62348-0.[FLM+05] Fitzgerald J, Larsen PG, Mukherjee P, Plat N, Verhoef M (2005) Validated designs for object-oriented systems. Springer, New

York[FLS08] Fitzgerald J, Larsen PG, Sahara S (2008) VDMTools: advances in support for formal modeling in VDM. ACM Sigplan Not

43(2):3–11[F06] Farcas E (2006) Scheduling multi-mode real-time distributed components. PhD thesis, University of Salzburg Department of

Computer Sciences[FW05] Fischmeister S, Winkler K (2005) Non-blocking deterministic replacement of functionality, timing, and data-flow for hard

real-time systems at runtime. In: Proceedings of the 17th Euromicro conference on real-time systems, pp 106–114. IEEEComputer Society

[GLG+06] Guidi C, Lucchi R, Gorrieri R, Busi N, Zavattaro G (2006) SOCK: a calculus for service oriented computing. In: Proceedingsof the 4th international conference on service-oriented computing (ICSOC), pp 327–338

[HND+11] Hilario M, Nguyen P, Do H,Woznica A, Kalousis A (2011) Ontology-based meta-mining of knowledge discovery workflows.In: Jankowski N, Duch W, Grabczewski K (eds) Meta-learning in computational intelligence, volume 358 of Studies incomputational intelligence. Springer, pp 273–315

[HT91] Honda K, Tokoro M (1991) An object calculus for asynchronous communication. In: Proceedings of the 5th Europeanconference on object-oriented programming (ECOOP), pp 133–147

[Hud96] Hudak P (1996) Building domain-specific embedded languages. ACM Comput Surv 28(4):196[ISO96] Andrews DJ (1996) Information technology—programming languages, their environments and system software interfaces—

Vienna Development Method—specification language—part 1: base language[IW95] Inverardi P, Wolf AL (1995) Formal specification and analysis of software architectures using the chemical abstract machine

model. IEEE Trans Softw Eng 21(4):373–386[Jon81] Jones CB (1981) Development methods for computer programs including a notion of interference. PhD thesis, Oxford Uni-

versity[Jon90] Jones CB (1990) Systematic software development using VDM, 2nd edn. Prentice-Hall, Inc., Upper Saddle River, NJ[Jon03] Jones CB (2003) The early search for tractable ways of reasonning about programs. IEEE Ann Hist Comput 25(2):26–49[KGC89] Kaplan SM, Goering SK, Campbell RH (1989) Specifying concurrent systems with �-grammars. In: Proceedings of the 5th

international workshop on software specification and design, pp 20–27[KK88] Kaplan SM, Kaiser GE (1988) Garp: graph abstractions for concurrent programming. In: Proceedings of the 2nd European

symposium on programming, pp 191–205[KM90] Kramer J, Magee J (1990) The evolving philosophers problem: dynamic change management. IEEE Trans Softw Eng

16(11):1293–1306

http://hdl.handle.net/10443/1851


[KMLA11] Krause C, Maraikar Z, Lazovik A, Arbab F (2011) Modeling dynamic reconfigurations in Reo using high-level replacementsystems. Sci Comput Program 76:23–36

[KMOS10] Karsai G, Massacci F, Osterweil LJ, Schieferdecker I (2010) Evolving embedded systems. IEEE Comput 43(5):34–40[Kob06] Kobayashi N (2006) A new type system for deadlock-free processes. In: Proceedings of the 17th international conference on

concurrency theory (CONCUR), pp 233–247. Springer-Verlag[Lar01] Larsen PG (2001) Ten years of historical development: “Bootstrapping” VDMTools. J Univers Comput Sci 7(8):692–709[LBF+10] Larsen PG, Battle N, Ferreira M, Fitzgerald J, Lausdahl K, Verhoef M (2010) The overture initiative-integrating tools for

VDM. SIGSOFT Softw Eng Notes 35(1):1–6[LCL13] Lausdahl K, Coleman JW, Larsen PG (2013) Semantics of the VDM real-time dialect. Technical report ECE-TR-13, Aarhus

University[Lee59] Lee C-Y (1959) Representation of switching circuits by binary-decision programs. Bell Syst Tech J 38(4):985–999[LFW09] Larsen PG, Fitzgerald J, Wolff S (2009) Methods for the development of distributed real-time embedded systems using VDM.

Int J Softw Inform 3(2–3):305–341[LLB10] Larsen PG, Lausdahl K, Battle N (2010) Combinatorial testing for VDM. In: Proceedings of the 8th IEEE international

conference on software engineering and formal methods, SEFM ’10, pp 278–285, Washington, DC, USA, September 2010.IEEE Computer Society. ISBN 978-0-7695-4153-2.

[LM07] Lucchi R, Mazzara M (2007) A pi-calculus based semantics for WS-BPEL. J Log Algebr Program 70(1):96–118[LOKA16] Lin H-H, Omori Y, Kusakabe S, Araki K (2016) Towards verifying VDMusing SPIN. In: Proceedings of the 4th international

workshop on formal techniques for safety-critical systems, volume 596 of Communications in computer and informationscience, pp 241–256. Springer

[LP95] Larsen PG, Pawłowski W (1995) The formal semantics of ISO VDM-SL. Comput Stand Interfaces 17(5–6):585–602[MADB12] Mazzara M, Abouzaid F, Dragoni N, Bhattacharyya A (2012) Toward design, modelling and analysis of dynamic workflow

reconfiguration—a process algebra perspective. In: Proceedings of the 8th international workshop on web services and formalmethod (WS-FM), volume 7176 of Lecture notes in computer science, pp 64–78. Springer-Verlag

[MAU15] The Maude System (2015) http://maude.cs.uiuc.edu. Accessed 4 Aug 2016.[Maz06] Mazzara M (2006) Towards abstractions for web services composition. PhD thesis, University of Bologna Department of

Computer Science[Maz14] Mazzara M (2014) LTL-based verification of reconfigurable workflows. Appl Math Sci 8(172):8581–8600[McM93] McMillan KL (1993) Using unfoldings to avoid the state explosion problem in the verification of asynchronous circuits. In:

von Bochmann G, Probst D (eds) Computer aided verification. Springer, pp 164–177[Met96] LeMetayerD (1996) Software architecture styles as graph grammars. In: Proceedings of the 4th symposiumon the foundations

of software engineering, pp 15–23[Mil89] Milner R (1989) Communication and concurrency. Prentice-Hall, Inc., Upper Saddle River, NJ[Mil99] Milner R (1999) Communicating and mobile systems: the π -calculus. Cambridge University Press, Cambridge[MK14] Mokhov A, Khomenko V (2014) Algebra of parameterised graphs. ACM Trans Embed Comput 13(4s):1–22[MKS09] Meyer R,KhomenkoV, Strazny T (2009) A practical approach to verification ofmobile systems using net unfoldings. Fundam

Inform 94(3–4):439–471[MMR10] Mens T, Magee J, Rumpe B (2010) Evolving software architecture descriptions of critical systems. IEEE Comput 43(5):42–48[Mok09] Mokhov A (2009) Conditional partial order graphs. PhD thesis, Newcastle University[Mon04] Montgomery J (2004) A model for updating real-time applications. Real-Time Syst 27(2):169–189[MPW92] Milner R, Parrow J, Walker D (1992) A calculus of mobile processes, parts I and II. Inf Comput 100(1):1–77[MRSY14] Mokhov A, Rykunov M, Sokolov D, Yakovlev A (2014) Design of processors with reconfigurable microarchitecture. J Low

Power Electron Appl 4(1):26–43[MSY12] Mokhov A, Sokolov D, Yakovlev A (2012) Adapting asynchronous circuits to operating conditions by logic parametrisation.

In: IEEE international symposium on asynchronous circuits and systems (ASYNC), IEEE, pp 17–24[MT00] Medvidovic N, Taylor RN (2000) A classification and comparison framework for software architecture description languages.

IEEE Trans Softw Eng 26(1):70–93[MY08] Mokhov A, Yakovlev A (2008) Verification of conditional partial order graphs. In: International conference on application

of concurrency to system design (ACSD), IEEE, pp 128–137[MY10] Mokhov A, Yakovlev A (2010) Conditional partial order graphs: model, synthesis and application. IEEE Trans Comput

59(11):1480–1493[NPW81] Nielsen M, Plotkin GD, Winskel G (1981) Petri nets, event structures and domains, part I. Theor Comput Sci 13:85–108[Ore98] OreizyP (1998) Issues inmodelingandanalyzingdynamic software architectures. In:Proceedingsof the internationalworkshop

on the role of software architecture in testing and analysis, pp 54–57[PCHW12] Patikirikorala T, Colman A, Han J, Wang L (2012) A systematic survey on the design of self-adaptive software systems using

control engineering approaches. In: Proceedings of the 7th international symposium on software engineering for adaptive andself-managing systems, pp 33–42

[Ped99] Pedro PSM (1999) Schedulability of mode changes in flexible real-time distributed systems. PhD thesis, University of YorkDepartment of Computer Science

[Pnu77] Pnueli A (1977) The temporal logic of programs. In: Proceedings of the 18th IEEE annual symposium on foundations ofcomputer science, pp 46–57

[PT00] Pierce BC, Turner DN (2000) Pict: a programming language based on the pi-calculus. In: Plotkin G, Stirling C, Tofte M (eds)Proof, language and interaction: essays in honour of Robin Milner. MIT Press, Cambridge, MA, pp 455–494

[PT12] Pugliese R, Tiezzi F (2012) A calculus for orchestration of web services. J Appl Log 10:2–31[PV98] Parrow J, Victor B (1998) The fusion calculus: expressiveness and symmetry in mobile processes. In: Proceedings of the 13th

annual IEEE symposium on logic in computer science, pp 176–185

http://maude.cs.uiuc.edu


[Ren03] RensinkA (2003)TheGROOVEsimulator: a tool for state space generation. In: Pfaltz JL,NaglM,BohlenB (eds)Applicationsof graph transformations with industrial relevance. Springer, pp 479–485

[RS03] Rounds WC, Song H (2003) The �-calculus: a language for distributed control of reconfigurable embedded systems. In:Proceedings of the 6th international workshop on hybrid systems: computation and control, pp 435–449

[San93] Sangiorgi D (1993) Expressing mobility in process algebras: first-order and higher-order paradigms. PhD thesis, Universityof Edinburgh Department of Computer Science

[SEN08] SEN3. The Reo Project (2008). http://reo.project.cwi.nl/reo/wiki. Accessed 4 Aug 2016[SRLR89] Sha L, Rajkumar R, Lehoczky J, Ramamritham K (1989) Mode change protocols for priority-driven preemptive scheduling.

J Real-Time Syst 1(3):243–264[SVK97] Stewart DB, Volpe RA, Khosla PK (1997) Design of dynamically reconfigurable real-time software using port-based objects.

IEEE Trans Softw Eng 23(12):759–776[SW01] Sangiorgi D, Walker D (2001) The π -calculus: a theory of mobile processes. Cambridge University Press, Cambridge[Tae03] Taentzer G (2003) AGG: a graph transformation environment for modeling and validation of software. In: Pfaltz JL, Nagl

M, Bohlen B (eds) Applications of graph transformations with industrial relevance. Springer, pp 446–453[TBW92] Tindell K, Burns A, Wellings A (1992) Mode changes in priority pre-emptively scheduled systems. In: Proceedings of the

IEEE real-time systems symposium, pp100–109[Tho90] Thomsen B (1990) Calculi for higher order communicating systems. PhD thesis, University of London Imperial College of

Science, Technology and Medicine Department of Computing[VLH06] Verhoef M, Larsen PG, Hooman J (2006) Modeling and validating distributed embedded real-time systems with VDM++.

In: Misra J, Nipkow T, Sekerinski E (eds) FM 2006: formal methods. Lecture notes in computer science, vol. 4085. Springer,Berlin, pp 147–162

[VM94] Victor B, Moller F (1994) The mobility workbench—a tool for the π -calculus. In: Proceedings of the 6th internationalconference on computer aided verification, pp 428–440. Springer-Verlag

[Wer99] Wermelinger MA (1999) Specification of software architecture reconfiguration. PhD thesis, University of Lisbon Departmentof Informatics

[WIdlIA12] WeynsD, IftikharMU, de la IglesiaDG,AhmadT (2012)A survey of formalmethods in self-adaptive systems. In: Proceedingsof the 5th international C* conference on computer science and software engineering, pp 67–79

[WLF01] WermelingerM, Lopes A, Fiadeiro JL (2001) A graph based architectural (re)configuration language. ACM SIGSOFT SoftwEng Notes 26(5):21–32

[YL05] Yu T, Lin KJ (2005) Adaptive algorithms for finding replacement services in autonomic distributed business processes. In:Proceedings of the 7th international symposium on autonomous decentralized systems, IEEE, pp 427–434

Received 25 April 2016Accepted in revised form 7 September 2016 by Jose N. OliveiraPublished online 20 January 2017

http://reo.project.cwi.nl/reo/wiki

an empirical comparison of formalisms for modelling and ... · an empirical comparison of...

Documents