Document [original]

Decomposition for Compositional

Verification

Genehmigte Dissertation

zur Erlangung des Grades eines

Doktors der Naturwissenschaften

der Fakultät für Elektrotechnik, Informatik und Mathematik

der Universität Paderborn

vorgelegt von

Dipl.-Inform. Björn Metzler

Paderborn, im Mai 2010

Mitglieder der Promotionskommission:

•Prof. Dr. Heike Wehrheim (Vorsitzende, Gutachterin)

•Prof. Dr. Steve Schneider (Gutachter)

•Prof. Dr. Gitta Domik

•Prof. Dr. Wilhelm Schäfer

•Dr. Matthias Tichy

Die Dissertation wurde am 15. Januar 2010 bei der Fakultät für Elektrotechnik, Informtik

und Mathematik der Universität Paderborn eingereicht und am 27. April 2010 vor der

Promotionskommission verteidigt und durch die Fakultät angenommen.

Abstract

Within the domain of safety-critical systems, software engineering becomes a major

challenge, as failures of a system may have life-threatening ramifications. In order to

ensure the reliability of software, its correctness is essential. For the correctness proof of

a model, integrated formalisms with an underlying formal semantics can be used.

Several obstacles complicate a successful application of model checking software

models. The main challenge is to cope with the state explosion problem, that is, the

exponential growth of the system’s state space in the size of the model. Several approaches

deal with this well-known problem. One of them is compositional verification.

The basic idea of compositional verification is that the check of correctness of a complex

system can be divided into smaller verification tasks. The technique avoids to build up

the entire state space of the model, as it solely needs to deal with the individual state

spaces of the single components of a system.

In order to facilitate an application of this technique, two problems need to be ad-

dressed: the model itself must be assembled from several components which is, in general,

not the case. Furthermore, an application of compositional reasoning must provide an

efficiency advantage over monolithic model checking.

Within this thesis, we develop a technique on how to decompose software models

specified in the integrated formalism CSP-OZ. Such a decomposition results in two

components suitable for the application of compositional reasoning.

A first challenge is posed by a proof of correctness, showing the equivalence of the

original specification and a decomposition in our semantic domain. In order to achieve

this, we carry out a dependence analysis by means of a specification’s dependence graph.

The analysis leads to a set of correctness criteria, based on which the graph is fragmented

into two parts. The fragmentation then results in the decomposition of the specification.

In addition, we introduce several techniques and algorithms to restore the specification’s

original control flow and its data flow.

As a second challenge, we address the practicability of compositional reasoning: we

identify heuristics for measuring the quality of a valid decomposition. Here, we neglect

inefficient decompositions. This allows us to consider only those, which most likely result

in an effective compositional verification.

Overall, our approach facilitates a general application of compositional reasoning, as

it does not rely on systems composed of several components. Moreover, valid decompo-

sitions, which are assessed as good by our heuristics, are beneficial for a compositional

verification.

The whole approach is tool-supported due to an integration into a graphical modelling

environment, allowing for the modelling,analysis,decomposition and (compositional)

verification of integrated specifications. Model checking itself is performed within an

assume-guarantee-based verification framework. Here, we use two proof rules, which

are shown to be valid in our semantic domain. Along with this, we provide several case

studies and experimental results.

Zusammenfassung

Die Softwareentwicklung im Bereich von sicherheitskritischen Systemen stellt eine große

Herausforderung dar, da Systemfehler lebensgefährliche Konsequenzen haben können.

Die Korrektheit von Software ist essentiell, um ihre Verlässlichkeit zu garantieren. Für den

Korrektheitsbeweis eines Softwaremodells eignen sich integrierte Formalismen, welchen

eine formale Semantik zu Grunde liegt.

Das Model Checking von Softwaremodellen wird durch verschiedene Hindernisse

erschwert. Die größte Herausforderung ist die Bewältigung der Zustandsexplosion, des

exponentiellen Wachstums des Zustandsraums mit der Größe des betrachteten Systems.

Eine Reihe von Techniken beschäftigt sich mit diesem populären Problem, unter anderem

die kompositionelle Verifikation.

Die grundlegende Idee bei der kompositionellen Verifikation ist die Zerlegung des

Korrektheitsbeweises in Teilaufgaben. Diese Methodik vermeidet die Konstruktion des Zu-

standsraums des gesamten Systems, stattdessen werden die Zustandsräume der einzelnen

Systemkomponenten betrachtet.

Die Anwendbarkeit dieser Technik ist an zwei Voraussetzungen gebunden. Zum einen

muss das Softwaremodell aus mehreren Einzelkomponenten zusammengesetzt sein, was im

Allgemeinen nicht der Fall ist. Des Weiteren muss die Anwendung der kompositionellen

Verifikation einen Effizienzvorteil gegenüber dem direkten Model Checking erbringen.

Diese Arbeit beschäftigt sich mit der Dekomposition von Softwaremodellen, spezi-

fiziert in dem integrierten Formalismus CSP-OZ. Eine solche Zerlegung definiert zwei

Komponenten, welche sich für die kompositionelle Verifikation eignen.

Eine erste Herausforderung dieser Arbeit stellt ein Korrektheitsbeweis dar, welcher die

Äquivalenz der ursprünglichen Spezifikation und einer Dekomposition in der zugrunde

liegenden semantischen Domäne zeigt. Dazu wird eine Abhängigkeitsanalyse durchgeführt,

die auf dem Abhängigkeitsgraphen einer Spezifikation basiert. Diese Analyse führt zu einer

Menge von Korrektheitsbedingungen, auf deren Basis der Graph in zwei Teile zerlegt wird.

Daraus ergibt sich die Dekomposition der Spezifikation. Zusätzlich werden Techniken und

Algorithmen zur Wiederherstellung des Kontroll- und Datenflusses der ursprünglichen

Spezifikation vorgestellt.

Eine zweite Schwierigkeit betrifft die Praktikabilität der kompositionellen Verifikation.

Dazu werden in dieser Arbeit Heuristiken zur Messung der Qualität einer validen De-

komposition ermittelt, wobei ineffiziente Dekompositionen vernachlässigt werden. Dies

erlaubt es, ausschließlich solche Zerlegungen zu betrachten, die eine effektive kompositio-

nelle Verifikation in Aussicht stellen.

Insgesamt ermöglicht die beschriebene Technik die Anwendung von kompositioneller

Verifikation, da sich der Ansatz nicht nur auf zusammengesetzte Systeme beschränkt.

Außerdem sind durch die Heuristiken favorisierte valide Dekompositionen vorteilhaft für

die Anwendung der kompositionellen Verifikation.

Für den gesamten Ansatz existiert eine Werkzeugunterstützung. Diese basiert auf

einer Integration in eine grafische Modellierungsumgebung, welche die Modellierung,

Analyse,Dekomposition und (kompositionelle) Verifikation von integrierten Spezifikatio-

nen erlaubt. Das Model Checking wird im Rahmen eines Frameworks im Kontext des

Assume-Guarantee Beweisverfahrens durchgeführt. Dabei werden zwei Beweisregeln ver-

wendet, deren Korrektheit gezeigt wird. Schließlich werden einige Fallstudien sowie

experimentelle Ergebnisse präsentiert.

Acknowledgments

I am grateful to a number of persons for their support, guidance and patience over the

last couple of years.

First of all, I would like to express my profound gratitude to Professor Dr. Heike

Wehrheim for the supervision, the everlasting support and the opportunity to write this

PhD thesis. She constantly pointed the right direction and helped in a dedicated manner,

which is anything but naturally.

I also would like to thank the members of my PhD committee, Professor Dr. Steve

Schneider, Professor Dr. Wilhelm Schäfer, Professor Dr. Gitta Domik and Dr. Matthias

Tichy for their assistance and invaluable advice.

For the proof reading of this thesis and the English review, sincere thanks to Isabela

Anciutti, Dr. Uwe Bubeck, Christian Estler, Dr. Dorina Ghindici, Dr. Andreas Goebels, Nils

Timm, Simon Titz and Daniel Wonisch.

In our research group, I enjoyed a very warm and collaborative atmosphere. Here,

special acknowledgements to Thomas Ruhroth, who always lent a helping hand and

never backed down from assisting on all kinds of problems.

There are several students to whom I am greatly thankful for doing most of the

implementation of the thesis’ approach within Syspect: Klaus Herbold for implementing

the decomposition, Meik Piepmeyer for developing the heuristics-based mass validation,

Sebastian Micus for integrating the counterexample analysis and, last but not least, Daniel

Wonisch for doing an excellent job in writing a compiler for the translation of Syspect

export into CSP

, integrating

FDR2

into Syspect and developing the learning-based

CSPLChecker.

I am also grateful to the members of the research group “Correct System Design”

supervised by Professor Dr. Ernst-Rüdiger Olderog. In particular, I would like to thank

Johannes Faber, who provided assistance to our extension of Syspect in many aspects,

always coming up with helpful ideas or additional features. Furthermore, I am in debt to

Ingo Brückner and Sven Linker who theoretically and technically provided the basis for

this work by developing the slicing approach. It was a great pleasure to work with Ingo

on several papers and discuss our related topics.

Most of all, there are three persons to whom my gratefulness is never-ending: my

parents, Peter and Inge Metzler, for taking care of me in so many different aspects of life

and for their limitless encouragement and patience. Finally, my heartfelt gratitude to my

beloved girlfriend Celina: you are an inspiration to my life and the most warm-hearted

and affectionate person I ever met. No words can describe the love and emotions I have

for you. Your perpetual care, support and love mean the world to me.

Contents

1 Introduction 1

1.1 A Vision of Correct Software . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Formal Methods and their Combination . . . . . . . . . . . . . . . . . . . 2

1.3 Compositional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Contributions.................................. 5

1.5 ThesisStructure................................. 6

2 Background: Integrated Formal Methods 9

2.1 A Survey of (Integrated) Formal Methods . . . . . . . . . . . . . . . . . . 9

2.2 The Integrated Formalism CSP-OZ . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Case Study: Candy Machine . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Object-Z................................. 16

2.2.3 CSP ................................... 20

2.2.4 Semantics of CSP-OZ . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 DependenceAnalysis.............................. 27

2.3.1 Dependence Analysis for CSP-OZ: Motivation . . . . . . . . . . . . 27

2.3.2 Definition of the Control Flow Graph . . . . . . . . . . . . . . . . . 29

2.3.3 Definition of the Data Dependence Graph . . . . . . . . . . . . . . 32

2.3.4 Definition of the Dependence Graph . . . . . . . . . . . . . . . . . 36

3 Background: Compositional Reasoning 41

3.1 Approaches to the State Space Explosion . . . . . . . . . . . . . . . . . . . 42

3.2 Compositional Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Assume Guarantee Proof Rules . . . . . . . . . . . . . . . . . . . . 43

3.2.2 Obstacles to the Application of Assume Guarantee Reasoning . . . 45

3.2.3 Learning for Compositional Verification . . . . . . . . . . . . . . . 45

3.3 Assume-Guarantee Reasoning for CSP . . . . . . . . . . . . . . . . . . . . 47

3.3.1 Application Example: Elevator System . . . . . . . . . . . . . . . . 49

3.3.2 Soundness of Assume-Guarantee Proof Rules . . . . . . . . . . . . 50

3.4 RelatedWork .................................. 53

4 Decomposition of a Specification 55

4.1 Overview .................................... 56

4.2 Cut of a Dependence Graph . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.1 Fragmentation of the Control Flow Graph . . . . . . . . . . . . . . 58

4.2.2 Correctness Criteria for the Fragmentation . . . . . . . . . . . . . . 61

4.2.3 DefinitionofaCut ........................... 66

4.2.4 Candy Machine Revisited: Cut of the Dependence Graph . . . . . . 70

xContents

4.3 Decomposing CSP-OZ Specifications . . . . . . . . . . . . . . . . . . . . . 72

4.3.1 Intermediate Definition of the Decomposition . . . . . . . . . . . . 75

4.3.2 Preservation of the Data Dependences . . . . . . . . . . . . . . . . 81

4.3.3 Preservation of the Control Flow . . . . . . . . . . . . . . . . . . . 86

4.3.4 Renaming for the Decomposition . . . . . . . . . . . . . . . . . . . 98

4.3.5 Definition of the Decomposition . . . . . . . . . . . . . . . . . . . . 100

4.3.6 Candy Machine Revisited: Decomposition . . . . . . . . . . . . . . 101

4.3.7 Improvement of the Decomposition . . . . . . . . . . . . . . . . . . 103

4.4 Decomposition for the General Case: Number Swapper . . . . . . . . . . . 106

4.5 RelatedWork ..................................109

5 Correctness of the Decomposition 111

5.1 Ensuring Correct Synchronisation . . . . . . . . . . . . . . . . . . . . . . . 113

5.2 Correctness for the CSP Part . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.2.1 Properties of the Decomposition: CSP Part . . . . . . . . . . . . . . 119

5.2.2 Correctness of the Decomposition: CSP part . . . . . . . . . . . . . 132

5.3 Correctness for the Object-Z Part . . . . . . . . . . . . . . . . . . . . . . . 138

5.3.1 Properties of the Decomposition: Object-Z Part . . . . . . . . . . . 140

5.3.2 Correctness of the Decomposition: Object-Z part . . . . . . . . . . 146

5.4 Correctness of the Renaming for the Decomposition . . . . . . . . . . . . . 159

5.5 CSP Laws for Parallel Composition . . . . . . . . . . . . . . . . . . . . . . 164

5.6 Proof of the Main Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . 166

6 Finding Reasonable Decompositions 167

6.1 Decomposition Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

6.1.1 First Heuristic: Cut Size . . . . . . . . . . . . . . . . . . . . . . . . 169

6.1.2 Second Heuristic: Even Distribution . . . . . . . . . . . . . . . . . 170

6.1.3 Third Heuristic: Few Transmission . . . . . . . . . . . . . . . . . . 170

6.1.4 Fourth Heuristic: Few Addressing . . . . . . . . . . . . . . . . . . . 172

6.2 Evaluation of Decomposition Heuristics . . . . . . . . . . . . . . . . . . . . 172

6.3 Candy Machine Revisited: Evaluation of Cuts . . . . . . . . . . . . . . . . 174

6.4 Case Study: Two Phase Commit Protocol . . . . . . . . . . . . . . . . . . . 175

6.5 Discussion....................................180

6.6 RelatedWork ..................................181

7 Implementation and Experimental Results 183

7.1 Syspect .....................................184

7.1.1 ClassDiagrams.............................184

7.1.2 StateMachines.............................186

7.1.3 Component Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 187

7.1.4 ExporttoCSP-OZ............................187

7.2 Decomposition Framework for Syspect . . . . . . . . . . . . . . . . . . . . 188

7.2.1 Decomposition Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . 189

7.2.2 MassValidation.............................191

Contents xi

7.2.3 Model Checking with FDR2 and the CSPLChecker . . . . . . . . . . 192

7.2.4 Counterexample Analysis . . . . . . . . . . . . . . . . . . . . . . . 196

7.2.5 OverallWorkflow............................198

7.3 ExperimentalResults..............................200

7.3.1 Overview ................................200

7.3.2 Verification Results for the Candy Machine . . . . . . . . . . . . . . 201

7.3.3 Verification Results for the Two Phase Commit Protocol . . . . . . . 204

7.3.4 Verification Results for the Number Swapper . . . . . . . . . . . . . 207

7.3.5 Discussion................................207

8 Conclusion 217

8.1 Summary ....................................217

8.2 FutureWork...................................219

Glossary of Symbols 223

Bibliography 229

List of Figures 239

List of Tables 243

Index 245

1Introduction

Contents

1.1 A Vision of Correct Software . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Formal Methods and their Combination . . . . . . . . . . . . . . . . 2

1.3 Compositional Verification . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Contributions............................... 5

1.5 ThesisStructure ............................. 6

1.1 A Vision of Correct Software

Over the last decades, research in Computer Science underwent a major focus change:

as hardware and software systems influence our daily lives in many critical and even

life-threatening situations, systematic approaches to ensure their quality in terms of

correct functionality are essential. Trustworthiness and safety-critical hardware and

software are required in many areas such as aerospace manufacturing, the automotive

industry and medical care, to mention only a few. The more we depend on these systems,

the more confidence we need to have in their reliability.

Software quality assurance (SQA) [

Gal04

] is an approach to observe the engineering

process regarding to the quality of the resulting software. Since weaknesses and errors

can be introduced at any given point in the process of software development, they need

to be excluded at an early stage of the design process.

One SQA methodology is the model-driven development (MDD) [

MDA

]: software

systems are described as models in some (domain specific) language. For modelling

object-oriented systems, the Unified Modelling Language (UML) [

BJR99

] is the current

de facto standard.

In order to ensure software quality, techniques for early model analysis have been

developed, which makes MDD highly useful. One specific analysis technique is software

testing [

Xie96

], aiming at the detection of errors in the model. Automated testing can be

of great benefit if hidden faults can be determined and corrected early in the development

process. However, correctness of a program can never be achieved by testing:

Program testing can be a very effective way to show the presence of bugs, but it is

hopelessly inadequate for showing their absence. [Dij72]

Since malfunctions are in many cases unacceptable, errors in critical parts of the system

have to be ruled out completely. Limited computing resources make the verification of

21 Introduction

large models practically impossible. Therefore, a possible strategy is to verify vital parts

of a system complemented by testing the system’s functionality and non-critical aspects.

For a system’s verification, the model needs to be specified in some mathematical

formalism incorporating a well-defined semantics. One particular kind of mathematical-

based techniques are formal specification languages (formal methods [

CW96

]). Based on

their precise semantics, they allow for the application of verification techniques. In order

to guarantee a reliable system, the developer needs to adhere to the specification, which

has to be proven correct.

1.2 Formal Methods and their Combination

An informal description of a software model – such as by using an intuitive description

based on natural language – is not sufficient for mathematical-based proof techniques

due to its missing formal semantics. Owed to its expressive power, the UML does not have

a common mathematical-based representation and is often referred to as a semi formal

modelling language. This lack of a precise underlying semantics makes the verification of

UML models generally impossible.

Formal methods [

CW96

] are widely-used as a mathematical-based approach of design-

ing software and hardware systems and they receive considerable attention from the

research community. The existence of a well-defined underlying semantics, making a

precise analysis of the system technically feasible, is common to all formal languages.

There are a lot of different notations and techniques, with all of them holding their

specific advantages and disadvantages. In general, formal methods can be classified

into several categories for describing different aspects of a system, among them are

state-based techniques using set theory and predicate logic such as Z [

ISO00

] and the

B-method [

Abr96

]. In contrast, process algebras like CSP [

Hoa85

] and CCS [

Mil89

], for

instance, specify the system’s behavioural aspects.

Individual formalisms do not cover all relevant aspects to describe a complex system as

a whole. Instead of redefining existing methods moving away from the original intention

for a specific method, recent research has shifted to the domain of integrated formal

methods. Focusing on more than one specific facet, they combine different languages to

model different viewpoints of a system within one, well-defined formalism. By defining a

common and consistent semantics, these notations incorporate the advantages of each

individual formalism. Some examples are the combination of the process algebra CSP

with the state-based formalism B into CSP||B [

ST02

], the formalism Event-B [

AH06

], a

combination of the B method [

Abr96

] with events, and the method we are focusing on in

this thesis, CSP-OZ [

Fis97

], a combination of CSP with the object-oriented extension of Z,

Object-Z [Smi00].

In terms of the overall goal (that is, the verification of a system model), the system

has to be specified in an (integrated) formalism and needs to be proven correct against

certain requirements of the system. This act is called formal verification.

1.3 Compositional Verification 3

1.3 Compositional Verification

Besides theorem proving, model checking [

CGP99

] is the most widespread formal verifi-

cation method. Given a specification S, specified as a finite state-transition system, and a

requirement P, formulated in some logical formalism, model checking fully automatically

proves or disproves that the system meets the requirement. This is in general denoted by

S|=P.

As the complexity of software and hardware systems increases, so does the complexity

of its models. The most common and major problem for the applicability of model

checking is the state explosion: the size of the software model, represented by a state

transition system, exponentially grows with the size and number of its components and

data domains. In particular, model checking for integrated specifications needs to deal

with the state explosion problem: for instance, the behavioural part of the specification

can incorporate concurrency, leading to an exponential blow-up of its branching structure.

In addition, its state space can be large or even infinite due to its possibly infinite data

types.

In general, building up the full state space of a model is infeasible. In order to

allow model checking to scale to complex systems, several techniques to tackle this

problem were proposed. To mention some of them, symbolic model checking aims at

an efficient representation of the model’s state space whereas partial order reduction

and data abstraction techniques try to reduce the state space of a model by exploring its

concurrency structure and by abstracting from concrete data values, respectively. These

techniques complement each other and can be combined.

Amongst these techniques, compositional verification [

dRHH+01

] is one promising

approach: instead of verifying a software model as a whole, the components of the model

are analysed separately. The verification results can then be combined into one global

result. For an application of this divide-and-conquer approach, the system needs to be

structured into several (parallel) components. That being the case, different strategies

can be applied in order to incrementally prove a system correct without ever building up

its full state space.

The main technique of compositional verification is assume-guarantee reasoning [

FP78

Jon83, MC81], applied to a system usually structured into two components. For a given

property Pon the overall system composed of S

and S

, both components can be verified

separately without building the global state space. In order to do so, an environment

assumption Aneeds to be identified, describing the connection and interdependences

between the components. The application of an appropriate proof rule, employing A,

yields the correctness of the system with respect to P.

Assume-guarantee reasoning has been researched for more than three decades. Re-

cently, a new strategy to fully automatically generate the assumption [

CGP03

BGP03

]

gave a new impulse to this area of research. The strategy is based on automatic learn-

ing, thereby freeing the user from a manual computation of the assumptions used in

assume-guarantee reasoning.

However, the technique relies on a given structuring of the system into parallel com-

ponents. Moreover, the efficiency of this approach depends on several factors: if the

41 Introduction

generated assumption is too large or the size of the components is not well-balanced,

applying the approach can again lead to large state spaces and even worse verification

run-times compared to monolithic (direct) verification. It is essential to think about good

decompositions to ensure applicability and scalability of the approach [CAC06].

SS2

Figure 1.1: Decomposition of a specification Sinto S1and S2

correctness of

proof rule

correctness of

decomposition

A+

Figure 1.2: Illustration of the overall approach of this thesis

In this thesis, we construct and evaluate decompositions of integrated specifications.

The starting point is a specification Sfor which we want to show a specific property P. We

1.4 Contributions 5

define a set of correctness criteria, serving as the basis for the decomposition of S. Figure

1.1 illustrates the overall idea. The decomposition results in two specification parts, S

and S

. These two parts represent the two parallel components of the decomposed system.

An appropriate synchronisation between S

and S

ensures that the decomposition and

the original system are behaviourally equivalent which is subsequently shown in the

correctness proof.

and S

then serve as the input for assume-guarantee-based proof rules. The proof

rule, as illustrated in Figure 1.2, states the following: if S

satisfies an assumption A

(described by the symbol ‘

’) and if S

satisfies Punder the assumption A, then the

overall system composed of S

and S

satisfies P. Correctness of the decomposition yields

that Ssatisfies P, if, and only if, the conclusion of the proof rule can be inferred.

The approach is based on several context-specific heuristics pointing the direction for

reasonable decompositions. The technique thus allows for an efficient application of

assume-guarantee reasoning. Within our implemented framework for CSP-OZ, we trans-

late the obtained components to the input language of a model checker and ultimately

apply the learning-based approach. We are able to evaluate different decompositions by

comparing verification run-times with those for monolithic verification.

1.4 Contributions

Compositional verification for integrated formal methods has been researched in [

ST04

But09

]. These works perform the decomposition of a system by hand and rely on the fact

that it can be carried out effectively.

Learning for compositional verification, especially to automate the verification process,

was introduced in [

CGP03

] and further developed in [

PGB+08

]. The techniques are,

however, not applied in the context of formal methods and rely on systems which are

already composed of several components.

Alur and Nam [

NA06

Nam07

] use assume-guarantee-based reasoning in the context of

symbolic model checking. They apply the learning framework to automatically generate

assumptions and decompose a given system. In addition, they propose heuristics to

improve the decomposition process. In their semantic domain of symbolic transition

modules solely based on boolean variables, they do not deal with the aspects of inte-

grated formalisms such as data flow, control flow and synchronisation. Furthermore, the

developed heuristics only focus on aspects of the learning framework and they do not

consider the (dependence structure of the) original system.

The key contribution of this thesis is an approach on how to combine all of these

strategies, that is, how to effectively apply compositional verification for integrated

formal methods: based on several correctness criteria and certain heuristics, we explicitly

decompose the given system. The result of the decomposition serves as the input for the

learning-based automated verification process.

Overall, the thesis’ contributions are given as follows. We define an approach to decom-

pose specifications written in CSP-OZ. The approach does not rely on systems which are

already composed of several processes but, instead, leads to self-defined decompositions.

61 Introduction

CATEGORY CONTRIBUTIONS

Decomposition XDecomposition for integrated specifications.

XExploitation of specification’s dependence structure.

Heuristics-based approach to detect reasonable decomposi-

tions.

Soundness Proof XEquivalence between original and decomposed system.

XCorrectness in context of assume-guarantee framework.

Implementation XIntegration into graphical modelling framework.

XIntegration into assume-guarantee-based framework.

XEvaluation-based on case studies.

Table 1.1: Contributions of this thesis

In order to achieve reasonable decompositions, we investigate heuristics, exploiting the

dependence structure of the specification as well as algorithms for the assumption identi-

fication. We present a correctness proof, showing that our decomposition preserves the

observable behaviour of the specification. Since the decomposition mandatorily modifies

the specification’s internal behaviour, the proof incorporates several techniques to link the

original system to its decomposition. We integrate the approach along with the learning

strategy into a graphical modelling framework for CSP-OZ [

Sys06

]. An evaluation of the

approach is performed based on several case studies and two different learning strategies

according to [CGP03] and [BGP03].

1.5 Thesis Structure

This thesis is structured as follows.

Chapter 2 provides an overview of (integrated) formal methods and introduces the

employed formalism CSP-OZ [

Fis97

], a combination of the process algebra CSP [

Hoa85

and the state-based formalism Object-Z [

Smi00

]. The semantics of CSP-OZ and necessary

definitions are given. For an illustration of CSP-OZ, we present the running case study of

this thesis. Along with this, we provide background on the dependence analysis for CSP-

OZ, which serves as the basis for the decomposition approach. The dependence structure

of a specification is defined by means of a dependence graph developed in [

Brü08

reflecting the control flow of a specification’s CSP part as well as data dependences with

1.5 Thesis Structure 7

respect to the Object-Z part. We present the definition and slightly modify it for our

purpose.

Chapter 3 introduces compositional reasoning and starts with an overview on relevant

techniques to cope with the state explosion problem in model checking. We survey

compositional verification, particularly in the context of integrated formal methods.

Afterwards, we present the specific method we deal with in this thesis: the assume-

guarantee paradigm. The learning strategy to automatically generate assumptions is

introduced next. In order to integrate assume-guarantee reasoning into our setting, we

show the correctness of two compositional proof rules in the semantic domain of CSP-OZ.

The chapter concludes with a discussion of related work.

Chapters 4-6 are the core chapters of this thesis. In Chapter 4, we introduce our

definition for the decomposition of a CSP-OZ specification. We start by defining correct-

ness criteria for a fragmentation of a specification’s dependence graph into two parts.

Subsequently, we define the decomposition of the specification itself resulting in two

specification parts. These parts represent the two parallel components for the employed

compositional proof rules. We motivate and describe the employed techniques to guar-

antee a semantics-preserving decomposition and illustrate the individual steps on the

running case study. Finally, we discuss works closely related to our approach.

Chapter 5 presents the correctness proof of our approach. Ultimately, we show that

the decomposition does not change the overall semantics of the specification. Several

properties, relating the decomposed specification to the original system, are proven. We

show that the original specification and the decomposed system, that is, the composition

of the two parallel components, are behaviourally equivalent in our semantic domain.

Achieving this is done through employing the compositional semantics of CSP-OZ along

with the criteria on a correct decomposition.

Chapter 6 describes techniques and heuristics for finding reasonable decompositions.

These are the ones for which model-checking-based on our approach will presumably

outperform monolithic model checking. We motivate and discuss some context-specific

heuristics for good decompositions. Furthermore, we introduce a second, bigger case

study, on which we illustrate the application of the heuristics.

Chapter 7 introduces our implementation framework and experimental results. The

graphical modelling framework Syspect [

Sys06

] for modelling CSP-OZ specifications

serves as the platform. We describe our integration of the decomposition approach and

the integration of the learning framework along with the heuristics-based identification

for reasonable decompositions. Additionally, we evaluate our approach on three case

studies and discuss the results.

Chapter 8 summarises this thesis, discusses the main results and points out possible

topics for future work.

2Background: Integrated Formal Meth-

ods

Contents

2.1 A Survey of (Integrated) Formal Methods . . . . . . . . . . . . . . . 9

2.2 The Integrated Formalism CSP-OZ . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Case Study: Candy Machine . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Object-Z............................... 16

2.2.3 CSP ................................. 20

2.2.4 Semantics of CSP-OZ . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Dependence Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.1 Dependence Analysis for CSP-OZ: Motivation . . . . . . . . . . 27

2.3.2 Definition of the Control Flow Graph . . . . . . . . . . . . . . . 29

2.3.3 Definition of the Data Dependence Graph . . . . . . . . . . . . 32

2.3.4 Definition of the Dependence Graph . . . . . . . . . . . . . . . 36

The introduction gave a brief overview on the subject area and goals of this thesis. The

following two chapters provide the necessary background for the main part of this work.

In this chapter, (integrated) formal methods, and in particular CSP-OZ, will be introduced

in Sections 2.1 and 2.2. The dependence analysis for CSP-OZ, which serves as the basis

for the decomposition, is presented in Section 2.3.

2.1 A Survey of (Integrated) Formal Methods

Model-driven software development aims at the abstract description of a system by

specifying a software model in some domain specific language. A model needs to

precisely reflect the relevant aspects of the software product to be developed. After an

accurate analysis, tools are used to automatically generate code from the model.

The Unified Modelling Language (UML) [

BJR99

] is undeniable the notation to model

object-oriented systems in a graphical and intuitive way. The acceptance of the UML as a

standard, not only in the academic but also in the industrial field, was not an overnight

process. Over many years, researchers defined and evaluated different notations to finally

end up with the UML 1.0 proposed in 1997.

Due to the lack of a common precise formal semantics, the UML is not adequate for a

rigorous formal analysis. Even though there exist several tools supporting the automated

verification of UML diagrams [

BGH+05

DWQQ01

BBK+04

], they are all restricted to

part of the language.

In the perspective to define mathematically-based languages suitable for formal specifi-

cation and verification, researchers all over the world investigate different techniques

10 2 Background: Integrated Formal Methods

and formalisms. Over the last three decades, a huge amount of formal methods has been

developed. In [

CW96

], Clarke and Wing surveyed the current state of the art. More

recently, Bowen [

Bow09

] set up a Wiki [

Wik06

] used by the formal methods community

which gives a detailed overview over many individual formalisms and shows the broad

spectrum of research in this area.

Formal methods can be classified into different categories. Mainly, these are behaviour

oriented techniques concentrating on the dynamic aspects of a system such as communi-

cation, concurrence and control flow, state-based formalisms for the specification of the

data and functional aspects and languages to describe hybrid systems which incorporate

both, discrete and continuous behaviour.

Behaviour Oriented Formalisms:

Among the formalisms to describe behavioural as-

pects of a system, Petri Nets [

Rei85

] are a graphical notation to illustrate distributed

systems. Process algebras such as CCS [

Mil89

], CSP [

Hoa85

] and LOTOS [

ISO89

]

describe concurrent systems by using an algebraic language. Milner also devel-

oped the strongly CCS related

-calculus [

Mil99

]. Another widely used formalism,

particularly in the context of the UML, are State Charts [Har87].

State Based Formalisms:

The most popular techniques concentrating on the data as-

pects of a system, that is, describing a system’s state space, are Z [

Spi92

ISO00

a set theory and first-order-predicate-logic-based formalism, and the Z related B

method [

Abr96

], where B is slightly more low-level and focused on automatic code

generation with great success in industrial application [

Abr06

]. Object-Z [

Smi00

] is

an extension of Z to additionally integrate object-oriented concepts into Z. Event-B

[

AH06

] extends the B method with guarded events. Abstract State Machines [

BS03

]

describe a system’s state space and its modifications by using transformation rules

and functions.

Formalisms for Hybrid Systems:

For the specification of hybrid systems, hybrid au-

tomata [

ACHH92

] combine the description of discrete and continuous behaviour of

a system. For the description of continuous real time aspects, in 1994, Alur and Dill

developed a real time extension for finite state automata, called timed automata

[AD94].

Naturally, different description languages specify different viewpoints of a system. The

analysis of large systems thus requires more than one dedicated formalism to reason

about different aspects. Many researchers advocating formal methods agree on the

statement that there exists no single notation covering all aspects of complex software

systems. For this reason, they aim at combining existing, well researched languages, into

one consistent new formalism, an integrated formal method.

These combinations range from the integration of two or more viewpoints into a single

formalism. Combinations of a process calculus with a state-based technique are, for

instance, CCS-Z [

TA97

] combining CCS and Z, the combination of CSP and Z into CSP-Z

[

MS98

], along with CSP||B [

TS99

], a combination of CSP with the B-method. Fischer

[Fis97] integrated CSP and Object-Z into the formalism CSP-OZ.

2.2 The Integrated Formalism CSP-OZ 11

The integration of time aspects into existing formalisms is, for instance, researched in

the context of Timed CSP [

Sch99

], an integration of real time into CSP. E-LOTOS [

ISO01

]

supplements LOTOS to support time and incorporates a functional-language-based data

typing part. In [

Hoe06

], Hoenicke extended CSP-OZ with the real time interval logic

Duration Calculus [ZH04] into CSP-OZ-DC.

The differences between these combinations can also be found in how the new seman-

tics is defined. As an example, Circus [

WC02

], a combination of CSP, Z and a refinement

calculus [

SWC02

], introduces a new semantics from scratch, that is, the semantics of CSP

and Z are redefined into a new model, using Hoare’s approach of Unifying Theories of

Programs [

HJ98

]. Other formalisms, such as CSP||B, keep the original semantics and

are thus able to use existing tools.

The following section stepwise introduces the applied formalism, CSP-OZ, illustrated

by an example. In order to familiarise this formalism for the core chapters, we introduce

the syntax and semantics of CSP-OZ along with necessary definitions and characteristics.

2.2 The Integrated Formalism CSP-OZ

Ever since its introduction in 1978 by Sir Anthony Hoare [

Hoa78

], the process algebra

Communicating Sequential Processes (CSP) draws a lot of attention and is widely used

for the specification of concurrent systems. The basic underlying concept is a description

of a system by events and processes: a process defines the communication and interaction

aspects by using an underlying alphabet, its set of events.

The state-based Z notation was developed by Jean-Raymond Abrial and others in the

late 1970s. By using the concept of operation schemas, a Z specification describes the

state space and its modifications based on mathematical theory [

Spi92

]. Smith [

Smi00

]

defined an object-oriented extension of Z, Object-Z.

The integrated formalism we will concentrate on in this thesis is CSP-OZ, a combination

of CSP with the object-oriented specification language Object-Z, introduced in [

Fis97

]

and further elaborated on in [

Fis00

]. In his PhD thesis, Fischer developed the formalism

by preserving the original semantics of both, CSP and Object-Z, with the objective to

reuse existing theories and tools for both, CSP and Object-Z. In comparison to [

Smi00

he introduced a slightly modified notation for Object-Z to which we will refer in this

thesis.

We introduce CSP-OZ by means of an example serving as the running case study for

this thesis. Afterwards, we give an overview on the syntax and semantics along with

required definitions for the incorporated formalisms CSP, Object-Z and CSP-OZ itself.

2.2.1 Case Study: Candy Machine

The following example of a CSP-OZ specification describes a candy machine allowing

for the payment and collection of several goodies. At first, we define some basic types

needed for the specification and start with a free type Candies denoting the set of possible

candies a customer may order. These are either a chocolate, a cookie or crisps:

12 2 Background: Integrated Formal Methods

Candies ::= CHOC |COOKIE |CRISPS

For simplification, the candy machine only accepts coins with value 1or 2:

Coins == {1,2}

We define a constant identifying the maximal value of all inserted coins, which we set

to 5:

Max == 5

Next, we give an axiomatic definition for a function determining the price of each of

the candies:

price :Candies →N

price(CHOC)=1∧price(COOKIE)=2∧price(CRISPS)=3

In general, a CSP-OZ specification consists of a set of a classes which can then be

combined to define the overall system. In Chapter 4, we will consider a specification

consisting of several classes. As of now, in our running example, we will sufficiently deal

with a specification comprising one class only.

I[interface definition]

main [CSP part]

OZ [Object-Z part]

Figure 2.1: Structure of a CSP-OZ specification

The general structure of a CSP-OZ class named Sis depicted in Figure 2.1. A class

consists of three parts, namely its interface, its CSP part and its Object-Z part. The Object-Z

part is again divided into its state schema, initial state schema and its set of operation

schemas as shown in Figure 2.2.

S.OZ

State [state schema]

Init [initial state schema]

enable op [enable-schemas]

effect op [effect-schemas]

Figure 2.2: Structure of the Object-Z part of a CSP-OZ specification

The fundamental concept of CSP-OZ is the connection between CSP part and Object-Z

part by using the interface Ias the common alphabet for both viewpoints of the system:

one operation schema of the Object-Z part corresponds to a set of events of the CSP part.

2.2 The Integrated Formalism CSP-OZ 13

For achieving this correspondence, the interface defines a set of typed channels. A

channel declaration has the form

chan name[p1:t1;. . . pn:tn],

where name identifies the name of the channel and p

is a decorated parameter of type

ti. We distinguish between three different parameter categories:

Input:

Input parameters are decorated with ’?’ and controlled by the environment of

the class. Neither the CSP part nor the Object-Z part can control input parameters.

However, the guard of an operation can refer to input parameters, thus allowing

the operation to be blocked for a subset of the values of the parameter’s type.

Output:

Output parameters are decorated with ’!’ and controlled by the class itself.

Predicates of an operation schema can restrict output values. If the operation is

executed, the value is determined non-deterministically.

Simple:

In contrast to input and output parameters known from CSP and Object-Z,

simple parameters are an extension in CSP-OZ and they are in general used for

indexing purposes. Simple parameters are undecorated and controlled by the class

and its environment. They can be restricted by both, the Object-Z part and the CSP

part.

Figure 2.3 shows the actual CSP-OZ specification of the candy machine. Here, the

interface comprises eight channels. For instance, channel pay has one input parameter

of type Coin modelling the customer’s payment. In contrast, channel deliver has one

output parameter of type Candies modelling a goody the machine dispenses. Note that all

parameters are inputs to the CSP part since neither of them is a simple parameter. Some

channels such as abort do not use any parameters.

As already mentioned, the CSP part of the specification describes the dynamic behaviour

of a system by means of the possible sequences of events and their orderings. This is

achieved by a set of process equations. As a convention, the initial process of a class’

CSP part is named

main

. The remaining set of process equations comprises four process

names: Payout describes the behaviour of the system if the customer chooses to abort the

procedure and collects his money. Select models the selection of an item and Order its

actual ordering. Finally, Deliver describes the delivery of the ordered items.

The Object-Z part starts with the class’ state schema, containing the set of state variables

for the description of the class’ state space and its modifications. These are two variables,

sum and credits, of type

to denote the current sum of money paid by the customer and

the remaining credits, respectively. A sequence of coins paid models the inserted coins,

and a second sequence items the previously ordered candies before the actual delivery.

Finally, the variable selected of type Candies describes the current item, selected by the

customer.

The initial state schema of the class defines the set of valid initial configurations by

using predicates, restricting the values of the state variables. In our example, both

14 2 Background: Integrated Formal Methods

CandyMachine

chan pay : [coin? : Coins]chan payout : [coin! : Coins]

chan abort chan switch chan order

chan select : [ca? : Candies]chan deliver : [ca! : Candies]chan term : [rest! : N]

main c

=pay?coin →main 2Payout 2switch →Select

Payout c

=payout?coin →Payout 2abort →Skip

Select c

= (select?ca →(Select 2Order)) 2Deliver

Order c

=order →Select

Deliver c

=deliver?ca →Deliver 2term?rest →Skip

sum,credits :N

paid :seqCoins

items :seqCandies

selected :Candies

Init

sum = 0

paid =h i

items =h i

enable pay

sum + 2 ≤Max

enable payout

paid 6=hi

enable abort

paid =hi ∧ sum = 0

enable switch

sum ≥2

enable order

credits ≥price(selected)

enable select

credits ≥1

enable deliver

items 6=hi

enable term

items =hi

effect pay

∆(sum,paid)

coin? : Coins

sum0=sum +coin?

paid0=paid ahcoin?i

effect payout

∆(sum,paid)

coin! : Coins

sum0=sum −coin!

paid0=tail paid

coin! = head paid

effect switch

∆(sum,credits,paid)

sum0= 0 ∧paid0=h i

credits0=sum

effect order

∆(items,credits)

items0=items ahselectedi

credits0=credits −price(selected)

effect select

∆(selected)

ca? : Candies

selected0=ca?

effect deliver

∆(items)

ca! : Candies

items0=tail items

ca! = head items

effect term

∆(credits)

rest! : N

credits0= 0

rest! = credits

Figure 2.3: Candy machine specification

2.2 The Integrated Formalism CSP-OZ 15

sequences need to be initially empty, and the initial sum of money is equal to zero. The

remaining state variables are not restricted by the initial state schema.

The static behaviour of the class is described in terms of a set of

enable

- and

effect

schemas, conjointly defining the behaviour of an operation schema. An

enable

schema

defines the precondition of an operation by again using predicates referring to state

variables of the class. An operation can only be executed if its respective precondition is

satisfied. Otherwise, the operation is blocked. For instance, operation deliver is blocked if

there are no items to deliver, that is, items

=h i

holds. Besides, order can only be executed

if there are enough credits left to pay the price of the selected items.

effect

schema defines an operation and how its execution modifies the state space.

It starts with its

∆

-list, comprising the set of state variables, modified by the operation.

All variables not appearing in this list remain unchanged. As an example, the

effect

schema of payout modifies the variables sum and paid. Next, the schema can contain a set

of parameter declarations, corresponding to the parameters in the operation’s interface

declaration. Finally, the predicate part of the schema defines the actual modifications

of the state variables. For that purpose, a predicate can refer to the possible values of

a state variable after execution of the operation; these post-state values are depicted in

primed form. For instance, payout restricts the post value of sum,sum’, to sum

−

coin

Thus, the operation ensures that the only possible value of sum after execution of payout

is exactly the original amount of money, reduced by the value of the dispensed coin. Note

that the operation abort possesses an empty

effect

schema which leaves all variable

values unchanged. In this thesis, we will leave out empty schemas.

We will now describe the dynamic behaviour of the class and its state space modifica-

tions by clarifying and illustrating its workflow. Figure 2.4 illustrates the CSP part of the

specification as a state transition graph, according to the operational semantics of CSP as

given in [Ros98].

A customer has three initial options, modelled by the CSP operator

for external

choice by the environment: first, if the amount of already inserted money increased by

two is smaller than Max, a user can insert a coin into the machine (pay) followed by

(using the prefix operator

→

) a call of the initial process

main

. The coin and its value

are stored in the variables paid and sum, respectively. Second, the customer can chose to

cancel buying candies as described in the process Payout, where he repeatedly collects

his coins (payout) by emptying the paid sequence. After a possibly empty sequence of

payouts, the process is finally aborted and terminates (denoted by

Skip

, the basic CSP

process for termination). As a last option, if the user inserted at least coins of an overall

value of

, he can request to process to the ordering of candies (switch), for which the

process Select is called. The customer may now select an item which she wants to order.

If enough credits are left, the item is ordered by storing it in the sequence items and

reducing the credits by the respective amount. Otherwise, the customer needs to reselect

another item. If he ordered at least one item, he can proceed to get his candies delivered.

In this case, the machine dispenses the items one by one in the correct order. The process

terminates after the potential order and delivery of candies. Remaining spare money is

returned.

Next, we clarify some syntactical aspects of Object-Z, CSP and CSP-OZ along with

16 2 Background: Integrated Formal Methods

main

Payout

Order

Select

Deliver

pay

switch

payout

Skip

select

order

deliver

Skip

term

abort

payout

deliver Skip

abort Skip

term

Figure 2.4: Illustration of the CSP part of the candy machine specification

defining their semantics. For more details, we refer to [

Smi00

Spi92

ISO00

], [

Ros98

Sch99

] and [

Fis00

] for comprehensive documentations on (Object-)Z, CSP and CSP-OZ,

respectively.

2.2.2 Object-Z

As already explained, we use a sightly adapted version of the Object-Z language as

introduced in [

Fis00

]. Therefore, we will continue to refer to the Object-Z part of a

CSP-OZ class specification, denoted by OZ, instead of pure Object-Z class specifications.

OZ generally consists of a state schema, an initial state schema and a set of operation

schemas, where elements of the latter comprise an

enable

schema and

effect

schema,

as depicted in Figure 2.2. The keywords

State

and

Init

denote the state schema and

initial state schema of a class, respectively. Thus, OZ can be denoted by a tuple:

OZ = (State,Init,(enable op)op∈Op,(effect op)op∈Op)

In the remainder of this thesis, we denote the sets of all values for input parameters,

output parameters and simple parameters of an operation schema op by In

(op)

,Out

(op)

and Simple

(op)

, respectively. Elements of these sets are tuples adhering to the types of

the operation parameters. The set Events is defined as the set of operation names of OZ,

completed by values for their parameters:

Events ={op.in.sim.out |op ∈Op,in ∈In(op),sim ∈Simple(op),out ∈Out(op)}

The state schema

State

defines the state space of OZ and comprises the set of state

variables the class uses along with their types. Additionally, the state schema contains a

2.2 The Integrated Formalism CSP-OZ 17

(possibly empty) set of state invariants – a set of predicates, which have to be satisfied

initially as well as for any reachable state of the class. The set of state variables will

be referred to as V. A state of OZ is defined as a valuation of all state variables: for

1,...,

, a state sis denoted as the tuple s

= (

1,...,

where v

are values of x

within the variable’s domain. We write State(s)or, equivalently, s∈State, to refer to

states of the OZ state space, and we use s.xito denote the value of xiin the state s.

For the definition of our decomposition, we need to project a state s

∈State

on a

subset of the state variables V0⊆V:

Definition 2.2.1. (State Projection)

Let V ={x1,...,xn}, and let s = (v1,...,vn)with s ∈State. We use

(v1,...,vn) = ((v1,...,vn−1),vn).

The projection of s on the set of state variables V

0⊆

V, denoted by s

V0

, is inductively

defined as

((. . . (v1), . . . vn−1),vn)V0:= ((. . . (v1), . . . vn−1)V0,xn6∈ V0,

((. . . (v1), . . . vn−1)V0,vn),xn∈V0.

The initial state schema restricts the initial valuation of the state variables. The

enable

schema defines an operation’s guard. It consists of a declaration part for possible input-

and simple parameters (

enable

-schemas must not declare output variables) and a

predicate part, containing predicates solely referring to unprimed state variables, that is,

to the state before the operation took place. If the conjunction of these predicates is not

satisfied, the operation is blocked.

enable

op can be interpreted as a predicate, denoted

by enable op(s,in,sim)with s∈State,in ∈In(op)and sim ∈Simple(op).

An operation’s

effect

schema declares the possible post states after the operation took

place. It consists of a

∆

-list, comprising all variables which are modified by the operation.

The subsequent declaration part contains the schema’s parameters and its predicate part

defines the restriction on the post-state. For this, variables denoted in primed form refer

to post state values. For any variable xnot contained in the

∆

-list, x

ximplicitly holds.

effect

schema can be denoted as the predicate

effect

(

sim

out

with

s∈State,in ∈In(op),sim ∈Simple(op),out ∈Out(op)and s0∈State0.

In the remainder of this thesis, we let ref

(op)

denote the set of referenced variables of an

operation (those occurring in unprimed form), whereas mod

(op)

denotes its set of modified

variables (those occurring in its

∆

-list). In addition, we set all

(op) :=

ref

(op)∪

mod

(op)

The precondition of an effect-schema can be defined as

pre effect op(s,in,sim) :=

∃out ∈Out(op),s0∈State0•effect op(s,in,sim,out,s0)

In this thesis, we assume that

enable

(

sim

)⇒pre effect

(

sim

)

holds.

This corresponds to the blocking view of operations as described in [

Fis00

]: an operation

can only be executed if its precondition is satisfied, otherwise it is blocked.

18 2 Background: Integrated Formal Methods

As an

enable

-schema can always be strengthened such that

enable ∧ ¬ pre effect

is impossible, this is not a restriction. For instance, consider the following operation op:

enable op

i? : N

x>y

effect op

∆(x)

i? : N

x0=i?∧x0>y0

For any value of i

such that i

?≤

yholds,

pre effect

op is not satisfied. Adding

i?>yto enable op schema ensures the previous implication.

When referring to an operation op, comprising

enable

op and

effect

op, we denote

its entire predicate part by

op.

pred whereas the declaration part will be denoted by

op.

dec.

In case we need to refer to the delta list of an operation, we write op.delta.

Semantics of Object-Z

As we are interested in the sequences of events of a specification, our approach is based

on an operational semantics for Object-Z and ultimately for CSP-OZ.

For the Object-Z part of a specification, we need to reason about events and states. The

decomposition approach analyses a specification’s dependence structure. A description

of paths solely referring to events is insufficient, since we need to incorporate the state

space and its modifications as well.

In order to be precise, execution of an event op

sim

out within the Object-Z part,

changing the before state sinto the after state s

, refers to an operation’s

enable

- and

effect-schema:

sop.in.sim.out

−→ s0⇔(enable op(s,in,sim)∧effect op(s,in,sim,out,s0))

The notation we are using is closely related to the Object-Z semantics of [

Brü08

] which

itself is based on the history semantics of Object-Z [

Smi95

]: sequences of state valuations

and operation calls describe the possible behaviours.

As a semantic model, we use labelled transitions systems (LTS). In order to reason

about states of the Object-Z part, a path of a labelled transition system is an alternating

sequence of states and events.

Definition 2.2.2. (Labelled Transition System)

Let E be an alphabet of events. A labelled transition system (LTS) M

= (

0,→)

over E

consists of

•a set of states S,

•a set of initial states S0⊆S and

•a transition relation →⊆ S×E×S.

A path of an LTS is a finite or infinite sequence

1, . . . i

alternating between states

and events such that (si,ei,si+1)∈→ holds for all i ≥0.

2.2 The Integrated Formalism CSP-OZ 19

Note that paths of LTS can be infinite but do not need to be infinite. Next, we define

the operational semantics of OZ in terms of labelled transitions systems.

Definition 2.2.3. (Labelled Transition System for Object-Z)

Let OZ be the Object-Z part of a CSP-OZ class specification. The LTS semantics of OZ is

defined as the labelled transition system M

OZ = (

0,→OZ)

, defined over E

Events, with

•S={s|s∈State},

•S0={s∈S|Init(s)},

• →OZ={(s,op.in.sim.out,s0)|

enable op(s,in,sim)∧effect op(s,in,sim,out,s0)}.

The set of all paths of MOZ is defined as Traces(OZ). Moreover, let

traces(OZ) := {πEvents |π∈Traces(OZ)}

and for tr ∈traces(OZ),

trOp := (h i,tr =h i

hopia(tr0Op),tr =hop.in.sim.outiatr0

Finally, for π∈Traces(OZ), let π[i]denote the i-th state and π.i the i-th event of π.

For clarification,

denotes a trace within Traces

(OZ)

distinguishing it from tr

∈

traces(OZ)not comprising states. We exemplify the definition with our case study:

Example 2.2.4.

The following trace, named

, is a valid path of the LTS of the Object-Z

part of the candy machine:

(sum = 0,credits = 0,paid =h i,items =h i,selected =COOKIE),pay.2,

(sum = 2,credits = 0,paid =h2i,items =h i,selected =COOKIE),switch,

(sum = 0,credits = 2,paid =h i,items =h i,selected =COOKIE),select.CHOC,

(sum = 0,credits = 2,paid =h i,items =h i,selected =CHOC),order,

(sum = 0,credits = 1,paid =h i,items =hCHOCi,selected =CHOC),deliver.CHOC,

(sum = 0,credits = 1,paid =h i,items =h i,selected =CHOC),term.1,

(sum = 0,credits = 0,paid =h i,items =h i,selected =CHOC)

Its projection on events is given by

tr =πEvents =hpay.2,switch,select.CHOC,order,deliver.CHOC,term.1i.

The projection of tr on its set of operation names yields

trOp =hpay,switch,select,order,deliver,termi.

20 2 Background: Integrated Formal Methods

P::= Skip (Termination)

|Stop (Deadlock)

|a→P1(Prefixing)

|P12P2(External Choice)

|P1uP2(Internal Choice)

|P1o

9P2(Sequential Composition)

|P1kAP2(Interface Parallel)

|P1A1kA2P2(Alphabetised Parallel)

|P1k| P2(Interleaving)

|P1\A (Hiding)

|X (Process Call)

|PJRK(Renaming)

Figure 2.5: Simplified grammar of CSP

2.2.3 CSP

In general, a CSP process Pis defined over a set of communication events which the

process can perform: its alphabet. For this, we need the notion of channels. A channel

consists of a name and a finite, possibly empty, sequence of data types T

1× · · · ×

, the

type of the channel. An event is then composed of the channel name and possible data

values, corresponding to the channel’s type.

In our example specification of a candy machine, the channel payout is of type Coins.

Thus, payout

denotes a possible event, communicated by the CandyMachine which is

composed of the channel name payout and the value 1according to its type.

In this thesis, we will, in general, refer to an alphabet Events, denoting a global set

of all events which corresponds to the set of events for the Object-Z part. These are

comprised of the operation names and values for their parameters. If we want to refer to

the distinguished alphabet of a process P, we use the notation

P. Accordingly, we let

Op denote the set of channel names, corresponding to the set of operation names for the

Object-Z part. We use the terms operation and channel synonymously throughout this

thesis.

The inductive definition of a CSP process, which we will refer to in this thesis, is

summarised in the grammar, given in Figure 2.5. Here, a

∈

Events denotes an event and

A,A1,A2⊆Events sets of events.

Skip

and

Stop

are basic CSP processes for termination and deadlock, respectively.

Stop

does not communicate at all whereas

Skip

solely communicates the reserved

event

to indicate successful termination. The prefix process a

→

communicates the

event aand subsequently behaves as P

describes the external choice (resolved

by the environment) between both processes P

and P

whereas P

denotes the

internal choice (resolved internally). P

describes sequential composition meaning

that first, P

is executed and, if P

successfully terminates, P

is allowed to occur. P

1kA

defines the interface parallel composition of two processes, which need to synchronise

on all events in A. Similarly, the alphabetised parallel composition P

1A1kA2

needs

to synchronously perform any events within A

1∩

. We will sometimes leave out the

2.2 The Integrated Formalism CSP-OZ 21

synchronisation alphabet(s) and denote the parallel composition of two processes by

, if the alphabet is not considered. The interleave process P

1k|

is a special case

of parallel composition where the synchronisation alphabet is empty. P

Abehaves

similar to P

, except that events from Aare hidden, that is, invisible to the environment.

All events within Aare renamed to a distinguished, internal event

. Since CSP processes

are defined via process equations,Xdenotes the body, that is, the right hand side, of a

process equation. Finally, P

JRK

depicts the process where all events eoccurring in Pare

renamed to R(e), according to a relation R:Events →P(Events).

From now on, we let L

CSP

denote the set of all CSP terms. We introduce some additional

generalisations and abbreviations, which we will use in the remainder of this thesis. First,

binary operators can be indexed over some finite indexing set I. As an example, the

indexed external choice, denoted by

2i∈IPi,

defines the external choice over all processes P

with i

∈

I. Similarly, N-way indexed

parallel composition can be denoted by

i=1 Pi.

Based on associativity laws, N-way indexed parallel composition can be transformed

into a chain of binary parallel compositions. The same holds for the remaining binary

operators. Therefore, in the following definitions and proofs, we do not need to deal

separately with indexed operators.

The prefix choice process a

→P1

initially offers any event of Aand subsequently

behaves as P

. Prefix choice can be seen as generalisation of prefixing. For finite A,

according to [

Ros98

], prefix choice can equivalently be transformed into indexed external

choice based on the equivalence

a:A→P1⇔2a:Aa→P1

The process RunAdefined as

RunA

=a:A→RunA

can always communicate any member of A. If no alphabet is specified, we assume

A=Events and set Run := RunEvents.

Sometimes, it is convenient to refer to the set of events extending a set of channel

names with all possible parameter values. This motivates the following definition from

[Ros98]:

Definition 2.2.5. (Extension of channels)

Let c be a channel of type T1× · · · × Tk. The extension set of c is defined as

{| c|} := {c.v1.....vk|vi∈Ti}.

22 2 Background: Integrated Formal Methods

The definition allows us to refer to a set of channel names as the synchronisation

alphabet, meaning that the extension sets of their operations are synchronised.

A channel includes an ordering on its data types. Partially defined events fix a (possibly

empty) subset of its type while the remaining data values (possibly none) are undeter-

mined. Achieving this is done through using the underscore- (don’t care-) symbol

"_"

order to refer to positions within a channel’s type and define:

Definition 2.2.6. ((Extensions of) partial events)

Let c be a channel of type T

1× · · · ×

. c

1.....

is a partial event if v

j∈

j∪ { }

. Its

extension set is defined as

{| c.v1.....vk|} := {c.v0

1.....v0

k|(v0

j=vj,vj6=

j∈Tj,otherwise )}.

Note that by definition, the set of partial events includes the set of (complete) events.

We give an example for Definition 2.2.6:

Example 2.2.7. Let c be a channel of type N×B. Then,

{| c. . true |} ={c.v1.true |v1∈N}and

{| c.3.|} ={c.3.true,c.3.false}.

Semantics of CSP

In order to analyse specifications and, in particular, CSP processes, we need to consider

the formalism’s semantics. The standard semantic model of CSP is the failures-divergences

model. In addition, the less discriminating stable failures model and the least restrictive

traces model can be chosen.

Traces of a CSP process describe its observable behaviour by means of sequences

of events. The prefix closed set of all finite traces of a CSP process Pis denoted by

traces

(

)⊆P(

Events

∗)

. Elements are described as sequences

2,...,

with e

i∈

Events. Internal events (

-events) do not appear in the traces of a process. For instance,

pay

.2,

switch

select

CRISPS

order

deliver

term

.2i

describes a valid trace of the

candy machine’s CSP part.1

Afailure of a CSP process Pis expressed as a tuple

(

)∈

Events

∗×P(

Events

)

where

tr denotes a trace and Aa set of events which Pis unable to accept after tr has been

performed. For instance,

switch

i,{

pay

})

is a failure of the CSP part of the candy

machine.

Divergence within a CSP process Pdescribes the ability of Pto perform an infinite

sequence of internal events. The set of divergences of a process Pcontains the set of

traces after which Pcan diverge.

Our decomposition approach focusses on the verification of safety properties. As

explained in [

Weh00

] and [

OW05

], this allows us to move to the semantic domain of the

CSP traces model.

1Note that this is not a valid trace if we additionally consider the Object-Z part.

2.2 The Integrated Formalism CSP-OZ 23

Next, we introduce some notations adopted from [

Sch99

] and [

Ros98

] which we will

use in this thesis, and we start with the projection of a trace on a set of events:

Definition 2.2.8. (Trace Projection)

The projection of tr

∈

traces

(

)

with respect to a set of events A is denoted by

tr

A and

defined as:

h iA=h i,

(haiatr)A=(trA,a6∈ A,

haia(trA),a∈A

As an example:

hpay.2,switch,select.CRISPS,order,deliver.COOKIE,term.2i{pay,term}=

hpay.2,term.2i.

The set of initial events, a process is able to perform, is defined as follows:

Definition 2.2.9. (Initials)

Let P be a CSP process. Then,

initials(P) := {a| hai ∈ traces(P)}

For instance, initials(main) = {pay,switch,payout}.

In order to describe that a certain CSP process satisfies a given property, also described

as a process, we need to be able to effectively compare processes. The general concept

behind this is to show refinement of one process by another. If a specification Qrefines

another specification P, then Qis more restrictive and preserves the behaviour of P. In

our semantic domain of traces, preservation means that Qoffers fewer traces than Pthus

not allowing more behaviour. This gives rise to the following definition:

Definition 2.2.10. (Trace Refinement)

Let P

Q be CSP processes. Q is a trace refinement of P, if traces

(

)⊆

traces

(

)

. We write

PvTQ. P is trace equivalent to Q, P =TQ, if, and only if, P vTQ and Q vTP.

The traces of a CSP process can be obtained by defining its transition graph. A labelled

transition system for a process can be deduced from the operational semantics of CSP.

LTSs are the standard way for describing CSP processes in terms of transition graphs. For

more details on the operational semantics of CSP, we refer to [Ros98].

Definition 2.2.11. (Labelled Transition System for CSP)

The LTS semantics of a CSP process

main

over a set of events A is defined as the labelled

transition system MCSP = (S,S0,→CSP)with

•S=LCSP the set of all CSP terms,

•S0={main},

• →CSP according to the operational semantics of CSP.

The labelled transition system definitions for Object-Z and CSP will be used to define

the operational semantics of CSP-OZ.

24 2 Background: Integrated Formal Methods

Case Study Revisited

One particular property of the candy machine specification can informally be described

as follows:

“ The amount of money, paid by the customer, must be equal to the sum of the values of

all delivered candies plus the potential spare money. ”

For specifying properties of a specification, we will use CSP as the modelling language.

This is reasonable since the semantics of CSP-OZ specifications can jointly be given in

terms of CSP alone as we will see in Section 2.2.4.

Figure 2.6 defines a CSP process Prop, exactly describing the previously introduced

property. Here, all three comprised processes have a parameter of type

, counting the

current amount of inserted money and credits, respectively. This yields three sets of

families of process equations. Paying

(

)

monitors the sum of inserted money whereas

Collecting

(

)

decreases the sum by the specific costs of the delivered candies. In order to

identify the respective candy delivered by the machine, we explicitly denote the parameter

for the event deliver. Finally, Terminate

(

)

calls the event term with the remaining money

of value i.

Prop =Paying(0)

Paying(i) = 2j∈Coins(pay.j→Paying(i+j)) 2Collecting(i)

Collecting(i) = deliver.CHOC →Collecting(i−1) 2

deliver.COOKIE →Collecting(i−2) 2

deliver.CRISPS →Collecting(i−3) 2

Terminate(i)

Terminate(i) = term.i→Skip

Figure 2.6: Correctness requirement for the candy machine specification

In order to show that Prop is valid for the specification of a candy machine, we need to

prove

Prop vTCandyMachine \ {| payout,abort,startOrder,select,order |}.

As we are only interested in the behaviour reflected by Prop, all events not occurring in

Prop are hidden.

2.2.4 Semantics of CSP-OZ

For the definition of the semantics of CSP-OZ, Fischer [

Fis00

] uses an extension of CSP,

which he calls CSP

, and ultimately defines a CSP

process capturing the semantics

2.2 The Integrated Formalism CSP-OZ 25

of a CSP-OZ class. Figure 2.7 shows a simplified version of his definition: a function

Semantics inputs a CSP-OZ class and translates it into a CSP process. Here, the operator

&represents guarding of an event defined as

b&P:⇔(if bthen Pelse Stop).

Semantics(S) =

let

Z PART(s)=

2op∈Op,in∈In(op),sim∈Simple(op)enable op(s,in,sim) &

uout∈Out(op),s0∈State0•effect op(s,in,sim,out,s0)

(op.in.sim.out →Z PART(s0))

Z MAIN = us∈State •Init(s)Z PART(s)

within

Z MAIN kEvents main

Figure 2.7: Translation of a CSP-OZ specification into a CSP process

The basic underlying idea for this definition is to define a CSP process Z MAIN mod-

elling the Object-Z part of the specification and putting it in parallel with the specifica-

tion’s original CSP part

main

. Both processes need to synchronise on Events. Z MAIN

non-deterministically chooses a valid initial state sand subsequently calls Z PART

(

)

Z PART

(

)

recursively executes operations of the Object-Z part in an arbitrary order

as long as the operation’s

enable

-schema is satisfied. Input parameters are determin-

istically chosen (using

) whereas output parameters and post states are determined

non-deterministically (using

). This is motivated by the idea that output parameters

and post states are internally chosen by a specification.

We aim at using the model checker

FDR2

[

For05

] for verifying CSP-OZ specifications

against certain requirements. For this, we need to translate a CSP-OZ specification to

the input language of

FDR2

, CSP

, without changing its semantics. A tool-supported

translation of CSP-Z to CSP

has been accomplished in [

MS01

], [

FMS01

]. Bolton and

Davies compare data refinement in Object-Z with failures-refinement in CSP based on the

Object-Z semantics as given in [

Smi95

] and use a translation of Object-Z to CSP

. In the

context of refinement, Schneider [

Sch05

] introduced a more general translation from

abstract data types (ADTs) [

LZ74

] to CSP, which can be applied for (part of) Object-Z as

well.

In our context of CSP-OZ, Fischer [

Fis97

] derives a failures-divergences semantics for

CSP-OZ based on the definition from Figure 2.7. This allows us to generally use a CSP

model checker based on this transformation of CSP-OZ specifications. A transformation

function using the above translation and resulting in a process defined in CSP

26 2 Background: Integrated Formal Methods

introduced in [

FW99

]. In Chapter 7, we will apply this transformation to use

FDR2

for

checking trace refinements. We give more details on

FDR2

and the tools we are using

there.

Our aim is to give an operational semantics for CSP-OZ by using the definition from

Fischer. In this thesis, we are interested in the paths a specification might execute.

In this particular case, we do not need to deal separately with external choice and

internal choice: based on the operational semantics of CSP, the trace semantics does not

distinguish between external and internal choice. More precisely, for two CSP processes

P1and P2:

P12P2=TP1uP2.

Next, we define the operational semantics of CSP-OZ by putting the labelled transition

systems for the specification’s CSP part and Object-Z part in parallel. The parallel

composition of two labelled transition systems is defined as follows:

Definition 2.2.12. (Parallel composition of labelled transition systems)

Let

M1= (S1,S10,→1)

and

M2= (S2,S20,→2)

be two labelled transition systems

over the same set of events E. The parallel composition of M

and M

is defined as

M1kEM2= (S,S0,→)with

•S=S1×S2, S0=S1

0×S2

•(s1,s2)e

→(s0

1,s0

2)if one of the three conditions

a) s1

→1s0

1∧s2

→2s0

b) s1

→1s0

1∧s0

2=s2,

c) s0

1=s1∧s2

→2s0

holds.

The operational semantics of CSP-OZ is then defined as the parallel composition of

CSP

and M

, synchronising on Events. Note that we assume the alphabets of operations

of the CSP part and the Object-Z part to be equal. This is not a restriction, as any

operation solely represented in the CSP part of a class can be added to its Object-Z part

by using an empty predicate part not modifying the state space of the class. Conversely,

operations exclusively appearing in the Object-Z part can be integrated into the CSP

process by globally offering them based on an additional interleaving. Besides, based

on the operational semantics of CSP, M

CSP

can indeed perform

-events whereas M

cannot.

Table 2.1 gives an overview on the two semantics of CSP-OZ which we introduced

in this section. When showing correctness of our approach, we will refer to the LTS

semantics of CSP-OZ, incorporating state valuations and events in their paths. The

more discriminating CSP

semantics maps a CSP-OZ class specification on a CSP process,

preserving the original behaviour within the failures-divergences model.

Even though the translation of CSP-OZ to CSP

uses the CSP

semantics and is thus

semantics-preserving for any of the three models of CSP, our approach solely focusses on

the traces model.

2.3 Dependence Analysis 27

LTS SEMANTICS CSPZSEMANTICS

Semantic model traces model of CSP failures-divergences model of CSP

Alphabet for paths (State ×Events)Events

Application in thesis correctness proof model checking (trace refinement)

Table 2.1: Comparison between the different semantics for CSP-OZ

2.3 Dependence Analysis

The main aspects of this thesis are the construction and evaluation of decompositions for

software models, specified in CSP-OZ. We require correctness of our approach, meaning

that the decomposition must preserve the observable behaviour of the specification. This

is achieved by a correctness proof, requiring a representation of the model on which the

decomposition and the general proof can be carried out. This representation must reflect

the structure of the specification as well as the interdependences between its elements.

In his PhD thesis [

Brü08

], Brückner introduced a dependence analysis for CSP-OZ

based on the definition of a (program) dependence graph. In the context of program

slicing [

Wei81

], he uses it to show correctness of his approach. Since a dependence graph

precisely reflects all the specification’s interdependences, we can take advantage of this

construction and use his graph in a slightly modified version.

This section introduces the dependence analysis for CSP-OZ specifications mainly

according to [

Brü08

]. We start with a small motivation, stepwise present the dependence

graph and illustrate its definition by means of our case study. Instead of repeating all the

details of the dependence analysis, we concentrate on the main aspects and an illustration

of the concept. Along with that, we describe our context-specific modifications and

introduce some necessary properties of the dependence graph.

2.3.1 Dependence Analysis for CSP-OZ: Motivation

The introduction already gave an overview on the overall goals of this thesis. In particular,

Figure 1.1 illustrated the approach for decomposing a given specification Sinto two

components S1and S2, yielding a system S1kS2.

Decomposing a CSP-OZ specification Smeans that Sis split-up into two smaller CSP-OZ

specifications S

and S

. For that purpose, the specification’s elements, such as operation

schemas and state variables, are distributed over S

and S

. In order to define correct

decompositions, we cannot simply assign these constituents to S

and S

at random:

the specification’s elements might depend on each other. The distribution of dependent

elements over both components is not beneficial but generally possible. A definition

of S

and S

needs to conform to the structure of the original model such that the

28 2 Background: Integrated Formal Methods

Swapper

chan store b,move a,move b

main c

=store b →move a →move b →Skip

a,b,tmp :N

Init

a= 1

b= 2

effect store b

∆(tmp)

tmp0=b

effect move a

∆(b)

b0=a

effect move b

∆(a)

a0=tmp

Figure 2.8: Simple CSP-OZ class specification for swapping two numbers

(observational) equivalence of Sand S1kS2can be deduced.

We illustrate the need for a precise specification’s analysis with a small example.

Consider the simple CSP-OZ specification Swapper as given in Figure 2.8. The specification

swaps two natural numbers aand bwith respective values

and

by using a temporary

variable tmp.

A decomposition could, for instance, yield two specifications Swapper

and Swapper

such that store b and move b are distributed over different components. This defini-

tion bears some problems: first, the parallel composition of the resulting CSP parts

needs to preserve the original ordering of events

store b

move a

move b

according to

Swapper

.main

. In the parallel composition Swapper

Swapper

, the operation move b

must not be performed prior to any other event. The dependence graph must therefore

comprise edges reflecting the control flow of a specification’s CSP part.

Second, consider the Object-Z part of the resulting specification part Swapper

: the

variable tmp is modified within store b. We need to ensure that move b refers to the

correct value of tmp. The modified value somehow needs to be restored within Swapper

This interconnection needs to be reflected in the dependence graph as well. Here, we use

edges representing the specification’s data dependences.

In general, we need to preserve the dependence structure of both, a specification’s CSP

part and Object-Z part. Our dependence analysis for CSP-OZ specifications addresses this

issue by using two graphs:

acontrol flow graph (CFG), which represents the workflow of the specification’s CSP

part and

adata dependence graph (DDG), representing the interdependences between state

variables and parameters of the specification’s Object-Z part.

The overall dependence structure is subsequently defined in the specification’s (pro-

gram) dependence graph (DG) combining the CFG and DDG. Our definition of the DG

2.3 Dependence Analysis 29

mainly corresponds to the one by Brückner [

Brü08

]. However, in this thesis and contrary

to Brueckner’s definitions, the DG is defined with respect to operation nodes. We do

not separately consider an operation’s

enable

- and

effect

-schema and its contained

predicates.

A decomposition defines a split-up of the dependence graph which then leads to the

decomposition of the underlying specification. Preservation of the observable behaviour

is defined in terms of correctness criteria on this fragmentation in Chapter 4.

2.3.2 Definition of the Control Flow Graph

In order to analyse a program in respect of its execution paths, control flow analysis

[

All70

] is a standard practice. A control flow graph is a graph theoretical representation

of a program.

The definition of [

Brü08

] yields a control flow graph representing a CSP process. Nodes

of this graph mainly correspond to CSP events and CSP operators. We start with the

general definition of the control flow graph. Ultimately, we are interested in a dependence

graph for a CSP-OZ specification S. To this end, the following definitions refer to the CSP

part main of a CSP-OZ specification and to the set of operation schemas Op of S.

Definition 2.3.1. (Control Flow Graph (CFG) of S)

The control flow graph (CFG)

CFGS= (

,−→)

of a CSP-OZ specification S is defined over a

set of nodes N =cf(N)∪op(N)and a set of edges −→⊆ N×N.

Nodes of the CFG either correspond to a CSP operator or to an operation schema of

the underlying specification. Table 2.2 denotes all nodes along with the corresponding

CSP operators, if existent.

We use a unique node

start

, representing the start of

main

. The set Ncomprises the set

of nodes op(N)which is defined as

op(N) = {opi|op ∈Op}∪{init}.

Here, a special node init represents the initial state schema of a class, comprising all initial

predicates. For the definition of the CFG, the

init

-node is conjoined with the

start

-node of

the class. As an operation schema op may occur more than once in main and thus in its

CFG, we denote the i-th occurrence of the respective operation node by opi.

cf(

)

is the set of CSP operator nodes plus a set of additional nodes representing

entry and leaving of a process. The whole set complies with the elements of the CSP

grammar as given in Figure 2.5. Some of these operators, namely the ones corresponding

to external choice, internal choice, both parallel operators (which are not separately

dealt with in the CFG) and interleaving, introduce branching into the CFG. Here, we

introduce split nodes and corresponding join nodes, which are denoted by cfop and uncfop

for

cfop ∈ {extch,intch,par,interleave}

, respectively. According to operation nodes, the

same notation for the i-th occurrence of a CSP operator node applies.

Note that we do not separately consider parallel composition of classes since, on graph

level, parallel composition of classes and processes is equally dealt with [

Brü08

]. Thus,

we equally treat specifications consisting of one and several classes.

30 2 Background: Integrated Formal Methods

Node CSP operator Name

start - (Start of main)

opi- (Operation Node for op ∈Op)

skip iSkip (Termination)

stop iStop (Deadlock)

extch i2(Split External Choice)

unextch i- (Join External Choice)

intchiu(Split Internal Choice)

unintch i- (Join Internal Choice)

seq io

9(Sequential Composition)

par ik(Split Parallel)

unpar i- (Join Parallel)

interleave ik| (Split Interleave)

uninterleave i- (Join Interleave)

start.X - (Process Entry)

term.X - (Process Termination)

call.X - (Process Call)

ret.X - (Process Return)

Table 2.2: Table of nodes of the control flow graph

The remaining four nodes are used for structuring of CSP process definitions: start of a

process X, termination of X, call of Xand returning from X. As an example, executing

switch in the candy machine and subsequently calling the process Select corresponds to a

CFG path h. . . , switch,call.Select,start.Select, . . . i.

In general, a CFG node

n∈

Nmust always have zero, one or two successor nodes. We

denote a single successor node by

succ(n)

, in case of two successor nodes we separately

denote each one with succ one(n) and succ two(n), respectively.

Paths of the CFG precisely reflect the control flow of

main

. For the correctness proof,

we make one important observation: according to the definition of the CFG, the sole

possibility of cycles within the CFG are process calls within the CSP part. This is reflected

in [

Brü08

] where the definition of G

CFG

introduces cycles into the CFG solely for the case

of call-nodes.

Figure 2.9 shows a slightly simplified version of the CFG for the candy machine

specification. We omit unextch nodes, term nodes and ret nodes to avoid a blow up in the

illustration. Operation nodes are highlighted in grey.

The following notations for paths of the CFG are mainly corresponding to [Brü08]:

Definition 2.3.2. (Paths of the Control Flow Graph)

Let

CFGS= (

,−→)

be the CFG of

, and let

n,n’ ∈

N. We use the following notations for

paths of the CFG, that is, sequences of nodes, visited, when walking along the edges of the

graph:

•pathCFG

denotes the set of all paths of the CFG whereas

pathCFG(n,n’)

denotes the set

of paths starting in nand terminating in n’.

2.3 Dependence Analysis 31

start

pay

switch

order term deliver

select

start.Order

call.Order

start.Deliver

call1.Select

start.Select

call1.Payout

call3.Select

call2.Select

call1.Deliver

call.main

Skip2

start.Payout

abortpayout

call2.Payout

call2.Deliver

Skip1

extch2

extch3

extch5

extch1

extch4

Figure 2.9: Control flow graph (CFG) for the candy machine specification

•nπ

−→ n’

denotes that

π∈pathCFG(n,n’)

whereas

n∗

−→ n’

denotes that there exists

some path from nto n’, that is, pathCFG(n,n’)6=∅.

•For n,n’ ∈op(N), we write

n•

−→ n’ if, and only if, (∃π∈pathCFG(n,n’)•π∩op(N) = {n,n’}).

We will sometimes need to refer to paths connecting two operation nodes

n,n’

without

additional operation nodes in between. For this, we use the last definition. For

π∈

pathCFG(n,n’)

, we let

x∈π

denote that

x∈

Nis an arbitrary node on the path

, including

nand n’ themselves.

32 2 Background: Integrated Formal Methods

We give a small illustrating example for the previous definition:

Example 2.3.3. For the CFG of the candy machine from Figure 2.9, we get:

• hstart,extch1,switch,call1.Select,start.Select,extch3,selecti ∈ pathCFG,

• hswitch,call1.Select,start.Select,extch3,selecti ∈ pathCFG(switch,select),

•start.Deliver −→ extch5,

•switch ∗

−→ order and

•select •

−→ order.

Next, we define a mapping between the set of operation nodes of the CFG,

op(

)

, and

the set of operations Op of a specification:

Definition 2.3.4. (Labelling of CFG nodes)

Let

CFGS= (

,−→)

be the CFG of

, and let Op be the set of all operation schemas of S. The

labelling function l

:op(

)→

Op maps an operation node of the CFG on its corresponding

schema name: l(opi) := op. For O ⊆Op, we define

l−1[O] := {n∈op(N)|l(n)∈O}.

As multiple occurrences of an Object-Z operation within the CSP part of a specification’s

class are possible, the cardinality of

op(

)

is greater or equal than the cardinality of Op:

for all op

∈

Op, there exists at least – but in many cases more than – one occurrence

opi

within the DG. Thus, the mapping lis surjective but in general not injective. If l−1[{op}]

only contains one element, we denote it by op, leaving out the index.

For a more precise definition and description of the CFG, we refer to [Brü08].

2.3.3 Definition of the Data Dependence Graph

The control flow of a program can be represented in a graph theoretical way, and the

same applies to its data flow. Data flow analysis and data dependence graphs [

Den74

]

aim at an evaluation and description of dependent program statements, incorporating

data values. A data dependence is, for instance, given if one statement modifies a certain

program variable, while another statement refers to it, and the variable is not overwritten

in between.

The data dependence graph, which we consider, is solely defined over the set of nodes

op(

)

, that is, the set of operation schemas of a specification plus its initial state schema.

It supplements the CFG in the sense that its edges are related to paths of the CFG and

that it is mainly derived from the Object-Z part of a specification.

As already mentioned,

enable

- and

effect

-schemas are comprised into one opera-

tion node. Dealing with operation nodes instead of its constituents is reasonable, since,

as we will see in Chapter 4, our decomposition approach does not further decompose an

operation but rather keeps operations as atoms.

2.3 Dependence Analysis 33

Besides, we refer to a normalisation of the Object-Z part of Saccording to [

Brü08

]: as

a state invariant needs to hold before and after execution of each method, it can safely

be copied to the

effect

-schema of each method and eliminated from the state schema,

without changing the behaviour of the specification.

The definition of the data dependence graph is as follows:

Definition 2.3.5. (Data Dependence Graph (DDG) of S)

The data dependence graph (DDG)

DDGS= (op(

),999K)

of a specification S is defined over

a set of nodes op(N)and a set of edges 999K⊆op(N)×op(N).

Edges of the DDG incorporate several dependences with all of them being introduced

in [

Brü08

]. Table 2.3 denotes all comprised edges. Note that we do not consider control

dependences, as we will explain in the next section.

Edge Name

999K (Direct Data Dependence)

idd

999K (Initial Data Dependence)

ifdd

999K (Interference Data Dependence)

L999K (Synchronisation Dependence)

sdd

999K (Synchronisation Data Dependence)

Table 2.3: Table of edges of the data dependence graph

The simplest example is a (direct) data dependence: assume a certain state variable v

∈

being modified in some operation schema op

and referenced in some other operation

schema op

, that is, v

∈(

mod

(op1)∩

ref

(op2))

. For all operation nodes

n∈

−1(

n’ ∈

−1(

, such that there exists a CFG path from the first to the latter node and vis

not further modified on this path, the DDG contains a data dependence edge ndd

999K n’.

Initial data dependences are a special case of direct data dependences. Since the initial

state schema poses restrictions on the set of state variables, an initial data dependence

connects the representation of the initial state schema with an operation if some variable

vis restricted in

Init

and referenced in op, without being overwritten in between. As

initial data dependences will frequently be used in the following chapters, we introduce

a separate notation: init idd

999K n’, if, and only if, init dd

999K n’ for n’ ∈l−1(op).

An interference data dependence exists from one node to another if both nodes are

located in different branches of an interleaving or parallel composition and, again, the

source node modifies a variable that the target node references. Note that, in general,

there is no CFG path connecting both nodes.

Synchronisation dependences model the fact that synchronised events within a parallel

composition have a mutual dependence on each other. These edges can more likely be

seen as a representation of the control flow. However, we integrate them in the DDG,

since we want to keep the original definition of the CFG. Note that synchronisation

dependences are always symmetric.

34 2 Background: Integrated Formal Methods

Finally, synchronisation data dependences complement synchronisation dependences.

They connect two operation nodes if they are connected by a synchronisation dependence,

and one of the corresponding operations declares an output variable which the other

corresponding operation uses as an input.

Since we will need to refer to the precise conditions for some of these edges later on,

we give their definitions next.

Definition 2.3.6.

((Direct-, Interference-) Data Dependence, Synchronisation Dependence)

1.) A direct data dependence exists from n∈op(N)to n’ ∈op(N),ndd

999K n’, if, and only if,

∃op1,op2∈Op •n∈l−1(op1),n’ ∈l−1(op2)∧(nodes corresp. to two operations)

∃v∈(mod(op1)∩ref(op2)) ∧(v modified in op1, referenced in op2)

∃π∈pathCFG(n,n’)•(nodes are connected by CFG path)

∀m∈π•v∈mod(l(m)) ⇒(m=n)∨(m=n’)(no further modification of v)

2.)

An interference data dependence exists from

n∈op(

)

n’ ∈op(

)

nifdd

999K n’

, if, and

only if,

∃op1,op2∈Op •n∈l−1(op1),n’ ∈l−1(op2)∧(nodes corresp. to two operations)

∃v∈(mod(op1)∩ref(op2)) ∧(v modified in op1, referenced in op2)

∃m= (interleave ∨parS•op ∈S)∧(interleaving or parallel composition)

∃π∈pathCFG(m,n)∧(first node in one branch)

∃π0∈pathCFG(m,n’)•(second node in the other branch)

π∩π0={m}(no join of branches within paths)

3.) A synchronisation dependence exists between n,n’ ∈op(N),nsd

L999K n’, if, and only if,

∃op ∈Op •n,n’ ∈l−1(op)∧(two nodes corresponding to same operation)

∃m=parS•op ∈S∧(parallel composition with operation synchronised)

∃π∈pathCFG(m,n)∧(first node in one branch of parallel composition)

∃π0∈pathCFG(m,n’)•(second node in the other branch of par. composition)

π∩π0={m}(no join of branches within paths)

Sometimes, we explicitly need to refer to the state variable responsible for a data

dependence. This leads to the following notation:

Definition 2.3.7. ((Direct-, Interference-) Data Dependence by Reason)

Let

ndd

999K n’

, and let the state variable v satisfy the criteria from Definition 2.3.6, 1.). In

this case, we write

ndd

999K(v)n’

and say that

ndd

999K n’

holds by reason of v. Correspondingly,

we define nifdd

999K(v)n’.

Note that

ndd

999K n’

and

nifdd

999K n’

can hold by reason of more than one variable. The

definitions for all kinds of dependences can be found in [

Brü08

]. We immediately deduce

a small lemma which we will frequently use in the following chapters:

Lemma 2.3.8. (Direct data dependence requires CFG path)

Let n,n’ ∈op(N)such that ndd

999K n’. Then, n∗

−→ n’.

2.3 Dependence Analysis 35

Proof. Immediately follows from Definition 2.3.6, 1.). 2

Customer

chan insert one,insert two chan ticket : [t! : B]

main c

= (insert one →Skip k| insert two →Skip)o

9ticket?t→Skip

money :N

Init

money = 0

effect insert one

∆(money)

money0=money + 1

effect insert two

∆(money)

money0=money + 2

effect ticket

t! : B

t! = true

Machine

chan ticket : [t? : B]

main c

=ticket?t→Skip

enable ticket

t? : B

t? = true

System

Customer {|insert one,insert two,ticket|}k{|ticket|} Machine

Figure 2.10: Simple CSP-OZ class specification for a ticket machine

Since our main case study does not incorporate all kinds of data dependences, we give

a small example to illustrate them. Figure 2.10 shows a ticket machine specification

consisting of two classes Customer and Machine. The overall system is defined as the

parallel composition of both classes, synchronising on the set

{| ticket |}

. The customer

can insert coins of value

and

in an arbitrary order and afterwards, the machine

dispenses the ticket. The full DDG of this small specification is given in Figure 2.11. Edges

are labelled according to Table 2.3.

The specification incorporates the following dependences:

Initial Data Dependence:

Since the state variable money is restricted in the initial state

schema of Customer, referenced within insert one,insert two and possibly not

overwritten in between, there exist two initial data dependences (



) from

Init

to the respective operations.

Synchronisation Dependence:

The operation schema ticket is synchronised be-

tween both classes thus yielding a synchronisation dependence (

) between

Customer.ticket and Machine.ticket.

36 2 Background: Integrated Formal Methods

Customer.init money = 0

money' = money+1

Customer.insert_one

Customer.ticket t! = true

Customer.insert_two

money' = money+2

Machine.ticket

t? = true

sdd

idd idd

ifdd

Figure 2.11: Data dependence graph (DDG) for the ticket machine specification

Interference Data Dependence:

Based on money

∈(

mod

(insert one)∩

ref

(insert two))

and vice versa money

∈(

mod

(insert two)∩

ref

(insert one))

, both nodes are

connected via a (symmetric) interference data dependence (¯).

Synchronisation Data Dependence:

As Customer

ticket sends the value of the parame-

ter tto Machine

ticket, a synchronisation data dependence (

), with Customer

ticket

as the source node and Machine

ticket as the target node, connects both operation

nodes.

The sole remaining data dependence, which we did not yet exemplify, is the direct data

dependence. In the candy machine specification, one such edge is the link from switch to

select due to credits ∈(mod(switch)∩ref(select)).

Figure 2.12 gives an extract of the DDG for the candy machine specification which

solely comprises direct data dependences and initial data dependences. All edges of the

DDG will be given in the next section as part of the specification’s dependence graph.

2.3.4 Definition of the Dependence Graph

The idea of the definition of a (program) dependence graph (PDG), as introduced in

[

FOW87

], is the unification of all the dependences of a program into one determined

graph which can then serve as the sole basis for the analysis of a program.

2.3 Dependence Analysis 37

init

items = <>

paid = <>

sum = 0

sum ≥ 2

sum' = 0credits' = sum switch

credits' = 0 rest! = credits

items = <>

term

selected' = ca?credits ≥ 1 select

idd

Figure 2.12: Extract of DDG for the candy machine specification

According to the structure of CSP-OZ specifications, the analysis of their dependence

structure is two-folded: the construction of the overall dependence graph of the specifica-

tion comprises the control flow graph for representing the control flow of a specification

and the data dependence graph as a representation of its data flow. We will now consoli-

date both graphs into one. Again, we start with the general definition:

Definition 2.3.9. (Dependence Graph (DG) of S)

The dependence graph (DG)

DGS= (

,−→DG)

of a CSP-OZ specification S is defined over a

set of nodes N and a set of edges −→DG⊆N×N, where

•N=cf(N)∪op(N)and

• −→DG= (−→ ∪999K),

according to Definition 2.3.1 and Definition 2.3.5 for the CFG and DDG, respectively.

The dependence graph is defined over the same set of nodes N

=cf(

)∪op(

)

as the

CFG and comprises both, edges of the CFG and the DDG. Recall that edges of the DDG

always connect operation nodes.

Our definition of the DG differs from the one defined in [Brü08] in several points:

Definition based on Operation Nodes:

Our set of DG nodes comprises operation nodes

instead of predicate nodes. Data dependences thus connect the respective opera-

tion nodes which contain the responsible predicates. This definition corresponds

to Brückner’s simplified graph representation, using super nodes. However, we

additionally consolidate

enable

- and

effect

schemas of an operation into one

node. The coarsening is motivated by the idea that in our decomposition, we will

38 2 Background: Integrated Formal Methods

keep operations atomic, that is, we will either assign all or none of the original

predicates of an operation to the generated components.

Inclusion of the CFG:

In our context, a decomposition completely needs to adhere to the

CFG, since we must not destroy the overall dependence structure of a specification.

Therefore, in contrast to Brückner, we integrate the full CFG into our dependence

graph.

Neglect of Control Dependences:

Based on the previous explanations, neither direct

nor indirect control dependences as defined in [

Brü08

] are relevant in our context.

Neglect of Symmetric Data Dependences:

Symmetric data dependences model shar-

ing of modified variables between two predicates. These edges are only used for

connecting two predicates within the same operation. Analogous to the previous

explanations, we can safely omit them.

Paths of the DG are defined according to paths of the CFG, except that we use the

notation

pathDG

. Finally, we present the dependence graph for our case study in Figure

2.13. We do not explicitly distinguish between the several types of edges of the DDG here.

The

Init

schema of the specification, attached with outgoing initial data dependences,

is linked to the start-node of the graph.

2.3 Dependence Analysis 39

start

pay

switch

start.Order

call.Order

start.Deliver

call1.Select

start.Select

call1.Payout

call3.Select

call2.Select

call1.Deliver

call.main

Skip2

start.Payout

abortpayout

call2.Payout Skip1

call2.Deliver

order term deliver

select

control dependence

data dependence

extch1

extch3

extch2

extch5

extch4

init

Figure 2.13: Dependence graph (DG) for the candy machine specification

3Background: Compositional Reasoning

Contents

3.1 Approaches to the State Space Explosion . . . . . . . . . . . . . . . . 42

3.2 Compositional Reasoning . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Assume Guarantee Proof Rules . . . . . . . . . . . . . . . . . . 43

3.2.2 Obstacles to the Application of Assume Guarantee Reasoning . 45

3.2.3 Learning for Compositional Verification . . . . . . . . . . . . . 45

3.3 Assume-Guarantee Reasoning for CSP . . . . . . . . . . . . . . . . . 47

3.3.1 Application Example: Elevator System . . . . . . . . . . . . . . 49

3.3.2 Soundness of Assume-Guarantee Proof Rules . . . . . . . . . . 50

3.4 RelatedWork............................... 53

In the introduction, we discussed strategies to ensure the reliability of a software

system. Our approach concentrates on the verification of a system model with respect

to certain requirements. This is achieved by specifying the system in the integrated

formalism CSP-OZ, as introduced in the previous chapter, and employ model checking.

Model checking [

CGP99

] is a technique to automatically verify a system model, repre-

sented as a finite state machine, against desired properties of the system, described in

some logical formalism. It either shows the validity of the desired properties or produces

counterexamples, giving some insight on why the model is invalid. The methodology is

introduced in [

EC80

CES86

], and extensive research has been devoted to it over the last

years.

Even though model checking algorithms generally have a linear or at worst polynomial

complexity in the size of their underlying models [Sch02], they all need to compute the

state space of the system, which exponentially grows in the number of its components.

Therefore, the main focus of attention is to cope with this decisive task, know as the state

explosion problem.

This chapter provides the necessary background on model checking techniques and

particularly on compositional verification as our object of research. Section 3.1 elaborates

on the most relevant techniques to tackle the state explosion problem. Subsequently,

Section 3.2 gives an overview on compositional verification and introduces our employed

proof method, assume-guarantee reasoning. Along with this, we describe a methodology

on learning assumptions for an automation of assume-guarantee-based verification.

Section 3.3 puts assume-guarantee reasoning into our semantic context. Finally, Section

3.4 discusses related work on compositional verification.

42 3 Background: Compositional Reasoning

3.1 Approaches to the State Space Explosion

Verification of program correctness incorporates the analysis of any possible program exe-

cution and any reachable state. In order to achieve this, mathematical-based techniques

aim to build a model, representing all possible program configurations. This structure

is in general referred to as a program’s state space. Model checking verifies the system

model against certain requirements by analysing its state space.

Due to limited computing resources, automated verification of a software model can

only construct models up to a certain extent. Thus, if the state space of a model becomes

larger and larger, model checking becomes infeasible.

Model checking of specifications written in an integrated formal method are highly

afflicted from the state explosion problem: as the data-oriented description of a system

may cause an enormous state space due to large or even infinite data types, so does the

behaviour-oriented description, owed to its concurrency. If two diverse formalisms are

combined into one, automated formal verification suffers from both of these problems at

the same time.

There are many strategies to tackle state explosion, with most of them having their

specific advantages in certain domains. The most important techniques are described in

the following.

Partial order reduction [

KP88

God96

] concentrates on the analysis of the concurrency

of a system. More precisely, it aims at identifying independent and thus commutative

transition paths in asynchronous systems. As a result, different orderings on these

transitions can be conjoined. This technique clearly has its key benefits if applied to

behaviour-oriented formalisms, incorporating asynchronous concurrency.

In order to apply model checking for infinite state systems, abstraction techniques need

to be employed. In general, these techniques aim at either removing or simplifying parts

of the system model.

One such technique is data abstraction [

CGL94

], which aims at handling large data

domains. It is based on the idea of abstract interpretations [

CC77

]. Instead of evaluating a

property with respect to all possible data values, an abstraction mapping identifies a set of

concrete values for one abstract value. If the mapping satisfies certain correctness criteria,

properties of the abstract system also hold for the concrete system. Data abstraction

techniques for CSP-OZ were introduced in [Weh00].

However, too coarse abstractions can lead to wrong verification results. Counterexample

guided abstraction-refinement [

CGJ+03

] iteratively refines an initially minimal abstraction

and is guided by the model checker’s counterexamples. In case of a spurious counterex-

ample, based on an over-approximation of the system, the model is refined, and the

verification process is repeated. In the context of CSP and Z, this technique has been

applied in [DW07].

Symmetry reduction [

CJEF96

] aims at finding behavioural symmetries to subsequently

reduce the model. A similar approach is followed in [

RW94

] in the context of sequential

composition.

Another abstraction technique is cone-of-influence reduction [

Kur94

]. Based on a certain

property under interest, this technique aims at eliminating all specification elements

3.2 Compositional Reasoning 43

which do not influence the verification property. For that purpose, the dependence

structure of the specification is computed and analysed. A similar technique is program

slicing [

Wei81

] which was successfully applied in the context of CSP-OZ [

Brü08

], as

already mentioned in Section 2.3.

Symbolic model checking [

JEK+90

McM93

] aims at representing the state space in

a canonical and more efficient form by means of a boolean encoding (ordered binary

decision diagrams, [

Bry86

]). Many existing model checkers work on a symbolic represen-

tation of the original state machine and by using symbolic model checking algorithms.

Bounded model checking,[

BCCZ99

] as one branch of symbolic model checking

[

CBRZ01

], incrementally tries to find finite prefixes of counterexamples by examining

paths up to a certain bound k. If no counterexample is found, the bound is incremented,

and the algorithm continues. The bounded model checking problem can efficiently be

reduced to the propositional satisfiability problem (SAT) [DP60].

3.2 Compositional Reasoning

The strategy to cope with the state explosion problem we focus on is compositional

verification. Many systems are not defined as one single large component but more likely

composed of smaller parts. Compositional verification [

dRHH+01

] uses this property by

means of a “divide and conquer” approach: instead of verifying the system as a whole,

the verification task is split up into smaller subtasks. The components of the system are

verified independently, and the verification results are combined.

The benefits are evident: instead of computing the global state space of the overall

system, compositional verification merely needs to deal with the individual state spaces

of the system components and thus avoids the state explosion problem up to a certain

extent.

There are a lot of different compositional proof strategies [

BCC98

] but the most popular

ones are based on the assume-guarantee paradigm [

FP78

Jon83

MC81

]: since, in general,

a system component Sdepends on its environment, it cannot be verified in isolation.

However, if a certain environment assumption A is assumed for S, a guarantee condition G

of Scan be inferred. Typically, this is expressed by a logical triple

, stating that if

Sis part of an overall system satisfying A, then the system must guarantee G.

Assume guarantee reasoning uses the previously described paradigm in terms of

inference rules. In our context and in the context of [

BGP03

], A,Sand Grepresent

labelled transition systems. Thus, we may let

)

denote the language of the assumption

A, that is, its set of traces over

Σ∗

on the underlying LTS, where

denotes the trace

alphabet of A. Furthermore, let

denote the complement of this language, that is,

L(A)C= Σ∗\ L(A).

Next, we present the different proof rules, which we will deal with in this thesis.

3.2.1 Assume Guarantee Proof Rules

Proof rules adhering to the assume-guarantee paradigm can be classified into different

categories. Suppose an overall system Sto be composed of two components S

and

44 3 Background: Compositional Reasoning

running in parallel: S

1||

. The simplest assume-guarantee proof rule can be

described as follows: if component S

guarantees (satisfies) an assumption A, and if

component S

satisfies a property Prop under the assumption A, then the overall system

S1|| S2satisfies Prop. This can be denoted as an inference rule as given in Figure 3.1.

htrueiS1hAi

hAiS2hPropi

htrueiS1|| S2hPropi

Figure 3.1: Basic assume-guarantee proof

rule (B-AGR)

hA1iS1hPropi

hA2iS2hPropi

L(A1)C∩ L(A2)C=∅

htrueiS1|| S2hPropi

Figure 3.2: Parallel assume-guarantee proof

rule (P-AGR)

From now on, this rule will be denoted by

(B-AGR)

and it will be called the basic

assume-guarantee proof rule. It can be classified as being sequential in the sense that the

first premise,

true

, needs to be evaluated before the second premise,

2hPropi

can be considered – Amust already be determined before it can serve as an assumption

for S2.

Another proof rule is motivated by the need for a symmetric computation of assumptions

for both components. One particular symmetric proof rule is given in [

BGP03

] and

depicted in Figure 3.2. In contrast to the basic proof rule, we call this rule the parallel

proof rule and refer to it as (P-AGR).

The main difference to rule

(B-AGR)

is the usage of one additional premise and

assumption. Moreover, the rule allows for a parallel computation of the first and second

premise, since both assumptions do not appear on the right hand side of both logical

triples.

The first premise states that under the assumption A

, component S

satisfies Prop. The

second premise states the corresponding for A

and S

. In order to show that S

1||

satisfies Prop, we need a third premise: the intersection of the complements of both

assumption languages needs to be empty.

In [

BGP03

], the authors show that the third premise, which is equivalent to

L(A1)∪

L(A2)=Σ∗

, is indeed necessary. The intuitive reason can roughly be described as follows:

restricts S

to Prop and A

restricts S

to Prop, whereas the conclusion states that

1||

satisfies Prop without any restriction. Thus, the unification of the languages

of both assumptions must contain all possible words. This ensures that no possible

behaviour is ruled out by both assumptions at the same time.

A third class of assume-guarantee proof rules are referred to as circular proof rules.

These rules either involve circularity on the assumptions or, as in our case, on the

components: one circular proof rule as introduced originally in [

GL91

] is depicted in

Figure 3.3 which we will refer to as rule (C-AGR). Here, two premises coincide on their

component. In general, in comparison to non-circular ones, proving soundness and

completeness of circular proof rules is rather difficult [Mai03].

In this thesis, we will focus on non-circular rules and on the the first two proof rules,

3.2 Compositional Reasoning 45

htrueiS1hA1i

hA1iS2hAi

hA2iS1hPropi

htrueiS1|| S2hPropi

Figure 3.3: Circular assume-guarantee rule (C-AGR)

rules

(B-AGR)

and

(P-AGR)

. For an application of these proof rules, one needs to identify

appropriate assumptions.

3.2.2 Obstacles to the Application of Assume Guarantee Reasoning

Several issues complicate the application of assume-guarantee reasoning. First, the system

needs to be composed of several components. If this is not the case, assume-guarantee

reasoning is not applicable at all.

Furthermore, the identification of environment assumptions had to be done manually

by the user. By the use of a new technique based on a learning approach and proposed in

[

CGP03

], this process can now fully be automated. We will introduce the approach in the

next section.

Even though that automated learning of an assumption removes one of the obstacles

assume-guarantee reasoning has to deal with, its usefulness in comparison to monolithic

verification is still questionable: the major aim of this technique is to explore smaller state

spaces. However, an unadvantageous decomposition can still lead to large assumptions

and thus large state spaces. In [

CAC06

], the authors investigated the effectiveness of

assume-guarantee reasoning based on exploring different decompositions of a given

system and comparing memory usage. The results show that only in very few cases,

assume-guarantee reasoning indeed outperforms non-compositional verification. Even

worse, in most cases, the explored state spaces are actually larger in compositional

verification.

In particular in the context of compositional verification for formal methods, these

considerations motivate the need for a technique to define decompositions which are

advantageous for an application of assume-guarantee-based techniques. We address this

problem in Chapter 6.

3.2.3 Learning for Compositional Verification

In order to apply an assume-guarantee-based proof rule, environment assumptions

need to be identified. Consider the basic proof rule

(B-AGR)

. Unfortunately, it is a

non-trivial process to find an assumption which, on the one hand, abstracts from S

over-approximating it and which is, on the other hand, strong enough for S

, such that

Prop can be deduced. This applies to any of these proof rules.

46 3 Background: Compositional Reasoning

Over many years, the development of an assumption had to be done manually by the

user, not allowing assume-guarantee reasoning to be performed in an automatic manner.

Recently, a new technique to fully automatically generate assumptions [

CGP03

] based on

alearning algorithm [

Ang87

] has been developed. The core idea for this technique is to

use a model checker to learn the assumption. This technique can be applied with respect

to several assume-guarantee proof rules [

PGB+08

] and in a framework, freeing the user

from manual interference.

Teacher L*

Membership Queries

„Is the word an element

of the language?“

YES / NO

Equivalence Queries

„Is the conjecture

correct?“

YES / counterexample

Figure 3.4: Illustration of the L∗algorithm

The basis for this approach is an algorithm which learns an unknown regular language

(in our case: the language of the assumption) and returns a deterministic finite automaton

(DFA) accepting this language. The algorithm is called L

∗

, and it was introduced in

[

Ang87

]. We describe the basic idea of the algorithm: suppose that Uis an unknown

regular language over some alphabet

. For an effective learning of U, the algorithm

requires an oracle which correctly answers two different questions:

Question (Membership Query):

Given a word wover the alphabet Σ, is wan element of U?

Answer:

Yes, if wis an element of U,no otherwise.

Question (Equivalence Query):

Does the DFA Daccept the language U?

Answer:

Yes, if L(D) = Uholds, a counterexample w ∈(L(D)\U)∪(U\ L(D)) otherwise.

3.3 Assume-Guarantee Reasoning for CSP 47

If the oracle (or teacher, as it is called in the context of L

∗

) correctly answers this question,

the algorithm always terminates and outputs a DFA DU, such that L(DU) = Uholds.

Figure 3.4 illustrates this concept. The approach presented in [

CGP03

] incorporates the

∗

algorithm into an assume-guarantee-based framework for the automatic computation

of the required assumptions. The technique can be applied to all three previously

introduced proof rules, as shown in [

PGB+08

]. Here, a model checker serves as the

teacher. The idea is to incrementally compute the assumption.

counterexample

analysis

false

true

spurious

counter-

example

real

counter-

example

is valid

is invalid

Figure 3.5: Illustration of the L∗based learning framework

As an example, for the basic proof rule

(B-AGR)

, the framework starts by making use of

∗

to compute an assumption Asuch that

iS2hPropi

holds. Afterwards,

htrueiS1h

checked.

If the result is true, correctness of the proof rule yields that

htrueiS1kS2hPropi

holds. Otherwise, the counterexample is analysed. A spurious counterexample leads

to a refinement of the verification process, a valid counterexample to the refutation of

htrueiS1kS2hPropi. This is illustrated in Figure 3.5.

Next, we put assume-guarantee reasoning into our context by translating both rules,

(B-AGR)

and

(P-AGR)

, into the semantic domain of CSP-OZ. Subsequently, we show their

soundness.

3.3 Assume-Guarantee Reasoning for CSP

Since our application of assume-guarantee reasoning lies in the domain of CSP-OZ

specifications, we need to translate the previously identified proof rules into our context

and show their correctness. Fortunately, as already explained in Chapter 2, CSP-OZ

1In terms of an LTS, true corresponds to the empty language.

48 3 Background: Compositional Reasoning

specifications can be translated into semantic equivalent CSP processes. Therefore, it is

sufficient to consider the semantic domain of CSP.

Verification properties can mainly be classified into two categories [

OL82

]: safety and

liveness properties. Safety properties follow the principle of

“ Nothing bad will ever happen! ”

meaning that a violation of a safety property is given by a finite counterexample. In

contrast, liveness properties can be described by

“ Something good will eventually happen! ”

describing that at some point, the property will be satisfied, not allowing to contradict a

liveness property by a finite counterexample.

Our decomposition approach focuses on safety properties. This allows us to move

to the domain of the CSP trace semantics instead of the more discriminating failures-

divergences semantics: as explained in [

Weh00

] and [

OW05

], in contrast to liveness

properties dealing with deadlock or livelock freedom, when dealing with safety properties,

the CSP traces model is sufficient. An approach for verifying liveness properties in the

context of compositional reasoning is, for instance, given in [

CGK97

]. According to this,

the learning-based approach, as explained in the previous section, is also considering

safety properties.

By translating assume-guarantee proof rules into the CSP traces model, a logical triple

hPropi

becomes a trace refinement condition Prop

Swhich is by definition

equivalent to traces(AkS)⊆traces(Prop).

We need to be more precise and consider the respective alphabets of A,Sand Prop. Here,

the alphabet of the assumption depends on the particular proof rule: for the basic rule,

(B-AGR)

= (

2∪

)∩

whereas for the parallel rule,

(P-AGR)

= (

1∩

2)∪

Setting αS=X,αProp =Yand αA= Σ, the condition becomes

Prop vT(AΣkXS)\(Events \Y),

where the right hand side processes need to be restricted to the alphabets of the left hand

side processes by using hiding.

Figures 3.6 and 3.7 specify rules

(B-AGR)

and

(P-AGR)

, rephrased in terms of CSP

trace refinement, where we additionally set αS1=X1and αS2=X2.

We take a closer look at the third premise of rule

(P-AGR)

: in comparison to the work

[

CGP03

], the authors move from the domain of labelled transitions system (LTS) to finite

state machines (FSM) [

BGP03

] and construct the complement co M of a FSM Mto denote

the third premise of rule (P-AGR) by

L(co A1kco A2) = ∅

However, it is impossible to construct a CSP process co P for some process P, accepting

the complement of its language. This is based on the fact that the set of traces of a CSP

process is always prefix-closed whereas its complement is not. Thus, co P does not exist

3.3 Assume-Guarantee Reasoning for CSP 49

AvTS1\(Events \Σ)

Prop vT(AΣkX2S2)\(Events \Y)

Prop vT(S1X1kX2S2)\(Events \Y)

Figure 3.6: Rule

(B-AGR)

rephrased in

terms of CSP trace refinement

Prop vT(A1ΣkX1S1)\(Events \Y)

Prop vT(A2ΣkX2S2)\(Events \Y)

(A12A2)vTRunΣ

Prop vT(S1X1kX2S2)\(Events \Y)

Figure 3.7: Rule

(P-AGR)

rephrased in

terms of CSP trace refinement

and we use the equivalent

condition

L(A1)C∩ L(A2)C=∅

. In our semantic domain of

the CSP traces model, this means traces

(

1)C∩

traces

(

2)C=∅

. We will now show that

(

2)vTRunΣ

and traces

(

1)C∩

traces

(

2)C=∅

are equivalent, implying that rule

(P-AGR) corresponds to rule 1 from [BGP03].

Lemma 3.3.1. (Correspondence between rule (P-AGR) and rule 1 from [BGP03])

Let A1and A2be two CSP processes over the alphabet Σ. Then,

(A12A2)vTRunΣ

holds, if, and only if,

traces(A1)C∩traces(A2)C=∅.

Proof.

(A12A2)vTRunΣ

⇔traces(A12A2) = traces(RunΣ)(Definition of RunΣ)

⇔traces(A12A2) = Σ∗(Definition of traces(RunΣ))

⇔traces(A12A2)C=∅

⇔(traces(A1)∪traces(A2))C=∅(Definition of traces for external choice)

⇔traces(A1)C∩traces(A2)C=∅

Next, we give a small example illustrating the application of rule (B-AGR).

3.3.1 Application Example: Elevator System

Figure 3.8 defines a CSP specification of a simple elevator system. It consists of two

processes Elevator and User. The overall system is defined as the parallel composition of

both processes, synchronising on the intersection of their alphabets

X1:= {req floor,req close,move,stop,req open}

and

X2:= {req floor,enter,req close,req open,leave}.

50 3 Background: Compositional Reasoning

Elevator c

=req floor →req close →move →stop →req open →Elevator

User c

=req floor →enter →User 2

req close →User 2

req open →leave →User

System c

=Elevator X1kX2User

Figure 3.8: CSP specification of a simple elevator system

The property, which we want to verify, is given as follows: a user entering the elevator

(enter) will always lead to him leaving (leave) the elevator. As a CSP process, we write:

Prop

enter

→

leave

→

Prop. Let Y

:= {

enter

leave

}

denote the alphabet of the property.

Based on the definition of [CGP03], we get

Σ=(X2∪Y)∩X1={req floor,req close,req open}.

In order to show that

Prop vT(Elevator X1kX2User)\(Events \Y)

holds, we can apply rule (B-AGR) by defining

=req close →A2req floor →A0

A0c

=req close →A02req open →A

Then, both premises of the rule are satisfied, that is,

traces(Elevator)Σ⊆

traces

(

)

and traces(AΣkX2User)Y⊆traces(Prop)hold.

3.3.2 Soundness of Assume-Guarantee Proof Rules

After translating both rules,

(B-AGR)

and

(P-AGR)

, into our setting of CSP, we need to

show their soundness. In his bachelor’s thesis, Wonisch [

Won08

] integrated the approach

of [

CGP03

] into a framework for compositional reasoning about CSP processes, which he

implemented by using the CSP model checker

FDR2

as the teacher. For that purpose, he

showed the following soundness theorem for rule (B-AGR):3

Theorem 3.3.2. (Soundness of basic proof rule)

Let S

and Prop be CSP processes. Let X

Y be alphabets, and let A be a CSP process

2This is based on L(A)C=L(co A)and L(AkB) = L(A)∩ L(B).

3We omit dealing with the technical aspect of X-freedom.

3.3 Assume-Guarantee Reasoning for CSP 51

defined over the alphabet Σ=(X2∪Y)∩X1. Then, the following proof rule is sound:

AvTS1\(Events \Σ)

Prop vT(AΣkX2S2)\(Events \Y)

Prop vT(S1X1kX2S2)\(Events \Y)

(3.1)

Proof. See [Won08], Theorem 1. 2

We will now correspondingly show soundness of the parallel proof rule (P-AGR).

Theorem 3.3.3. (Soundness of parallel proof rule)

Let S

and Prop be CSP processes. Let X

Y be alphabets such that Y

⊆

1∪

, and

let A

be CSP processes defined over the alphabet

Σ=(

1∩

2)∪

Y. Then, the following

proof rule is sound:

Prop vT(A1ΣkX1S1)\(Events \Y)

Prop vT(A2ΣkX2S2)\(Events \Y)

(A12A2)vTRunΣ

Prop vT(S1X1kX2S2)\(Events \Y)

(3.2)

Proof. Let

t∈traces((S1X1kX2S2)\(Events \Y)).

We need to show t

∈

traces

(

Prop

)

. The definition of traces for hiding ([

Ros98

]) yields the

existence of

s∈traces(S1X1kX2S2),

such that t



Y. Moreover, since sis defined over X

1∪

and by applying the definition

of traces

(

XkY

)

([

Ros98

]), for u

1:=

X1

and u

2:=

X2

, we get u

i∈

traces

(

. Mainly

corresponding to the correctness proof of the basic assume-guarantee rule, [

Won08

], we

will now show:

(i) s(Σ ∪X1)∈traces(A1ΣkX1S1)or (*)

s(Σ ∪X2)∈traces(A2ΣkX2S2), (**)

(ii) (*) ⇒t0

1:= s0

1Y∈traces(Prop)and t0

1=t,

(iii) (**) ⇒t0

2:= s0

2Y∈traces(Prop)and t0

2=t,

where both, (∗)and (∗∗)lead to the conclusion t∈traces(Prop).

For property (i), let s0

i:= s(Σ ∪Xi). We first deduce

1Σ=(s(Σ ∪X1))Σ = sΣand

2Σ=(s(Σ ∪X2))Σ = sΣ.

52 3 Background: Compositional Reasoning

Based on the third premise and the fact that s

Σ∈

traces

(RunΣ)

by definition of

RunΣ

we have s

Σ∈

traces

(

. Thus, either s

Σ∈

traces

(

or s

Σ∈

traces

(

holds.

Second, we get

1X1= (s(Σ ∪X1))X1=sX1=u1and

2X2= (s(Σ ∪X2))X2=sX2=u2,

with u

1∈

traces

(

. Both combined: if s

Σ = s0

1Σ∈

traces

(

, we use

1X1∈

traces

(

to deduce s

1∈

traces

(

1ΣkX1

. Otherwise, we get s

2∈

traces

(

2ΣkX1

. This

concludes the proof of (i).

Next, we show (ii), (iii) is analogous. If (*) holds, t

1:= s0

1

∈

traces

(

Prop

)

follows

immediately from the first premise. We are left to show t0

1=t:

=s0

1Y(Definition of t0

= (s(Σ ∪X1))Y(Definition of s0

=s((Σ ∪X1)∩Y)(Definition of trace projection)

=s(((X1∩X2)∪Y∪X1)∩Y)(Definition of Σ)

=sY

=t(Definition of t)

This concludes the proof. 2

The following example [

Sch09

] shows that the restriction

Σ=(

1∩

2)∪

Yis indeed

required.

Example 3.3.4. Let S1=a→a→Stop, S2=b→b→Stop and

Prop = (a→a→Stop)2(b→b→Stop).

Thus, we get X

1={

}

, X

2={

}

and Y

}

. Now assume

Σ = ∅

and A

2=Stop

Then, all three premises of the parallel rule are satisfied:

•We get (Stop ∅k{a}S1) = a→a→Stop and thus Prop vTa→a→Stop.

•Also, (Stop ∅k{b}S2) = b→b→Stop and therefore Prop vTb→b→Stop.

•Finally, Run∅=TStop, hence (Stop 2Stop)vTRun∅.

However, Prop

vT(

→

→Stop {a}k{b}

→

→Stop)

does not hold as Prop does not

allow the trace

which

(

→

→Stop {a}k{b}

→

→Stop)

is able to conduct.

In case of Σ=(X1∩X2)∪Y={a,b}, the third premise becomes

(Stop 2Stop)vTRun{a,b},

which is clearly not satisfied.

Summing up, we have shown the applicability of the proof rules

(B-AGR)

and

(P-AGR)

in the semantic domain of CSP. This allows us to apply compositional reasoning, based

on the following decomposition approach in our context. Moreover, we can evaluate the

efficiency of different decompositions by using the CSP model checker FDR2 [For05].

3.4 Related Work 53

3.4 Related Work

Model checking and (automated) compositional verification of specifications, written

in (integrated) formal methods, is extensively researched. We give a brief overview on

recent works, mainly in the context of our employed methods.

Model Checking for Formal Methods:

In order to allow model checking of a software

system, it needs to be specified in some formal language.

Leuschel examines LTL model checking [

LMC01

] for CSP by using the model

checker

FDR2

[

For05

]. In [

SW05

], Smith and Wildman consider model checking

of Z specifications by translating Z into the input language of the model checker

SAL [

BGL+00

]. Derrick et al. also investigate Z model checking by using SAL in

[

DNS08

]. Smith deals with model checking Object-Z specifications with respect to

temporal logic formulae in [KS01].

CSP-Z model checking is researched in [

MS01

]. Model checking CSP-OZ specifi-

cations by again using

FDR2

is described in [

FW99

]. We use this approach in our

implementation framework.

Compositional Verification for Formal Methods:

Compositional verification has its

early application within the scope of model checking in [

EDK89

] and later in

[

GL91

CGP99

]. Proof rules for verifying real time system have been developed in

[

CMP94

]. In the context of UML, compositional verification (and model checking)

of embedded real time systems is, for instance, investigated in [

SGT+03

]. By

defining a formal semantics for a domain specific subset of the UML, the authors

allow themselves to reason about individual software components instead of the

complete system.

In our context, Winter and Smith [

WS03

] deal with compositional verification for

Object-Z. They analyse the class structure of an Object-Z specification and argument

about restricted environments, allowing for the definition of a compositional proof

rule. Modular reasoning of Object-Z is also investigated by Griffiths [

Gri97

Gri98

In [

MG07

], Moffat and Goldsmith examine compositional reasoning for CSP by

identifying and showing several proof rules with respect to some CSP operators and

certain structures of the overall system. Compositional reasoning for CSP is also

analysed in [Moo90].

Compositional verification for integrated formal methods has extensively be re-

searched in the context of CSP||B [

ST02

]. Amongst other works [

ST04

ST05

Evans, Schneider and Treharne investigated how to decompose specifications into

so-called chunks [

STE05

]. For Event-B, Butler [

But09

] described how to decompose

specifications for independent refinement checks.

Assume-Guarantee Reasoning:

Assume-guarantee reasoning was first introduced in

[

FP78

Jon83

] and further developed in [

Pnu84

]. Several variants being applied

in different domains, such as assumption-commitment for synchronous message

54 3 Background: Compositional Reasoning

passing [

MC81

] and rely-guarantee for shared-variable concurrency [

Jon83

], exist.

All of them can be subsumed under the roof of the assume-guarantee paradigm.

The book [

dRHH+01

] gives a profound overview on compositional reasoning and

the assume-guarantee paradigm in particular.

Automated Compositional Reasoning:

Ever since the introduction of compositional

reasoning, one of the major goals is to fully automate this verification process. The

idea to automatically generate assumptions in the context of assume-guarantee

reasoning was first proposed in [GPB02].

Learning assumptions for compositional reasoning was introduced in [

CGP03

] and

initially with respect to the basic proof rule

(B-AGR)

. The following paper [

BGP03

]

extended the idea to symmetric proof rules, such as rule

(P-AGR)

. Apart from

these authors, several other articles investigate this particular field of research:

[

GP08

] contains a selection of articles on learning techniques for automated assume-

guarantee reasoning. Nam and Alur [

AMN05

NA06

Nam07

] investigate L

∗

-based

learning of assumption in the context of symbolic model checking. In the same

context, the article [

APR+01

] presents a SAT-based technique for lazy learning of

assumptions. Several articles concentrate on the optimisation of the L

∗

algorithm

to more effectively compute the assumptions [GGP07, GMF07, CS07, CS08].

Besides the application of learning in the area of model checking, the L

∗

algorithm

is used in several other software verification domains. For instance, in [

CCST05

the authors use assumption learning in the context of simulations. Alur et al.

[

Aˇ

CMN05

] tackle synthesis of interface specifications based on learning. In the

context of black box checking, that is, verifying a software system without a model,

L∗is used to learn an unknown system [GPY02].

4Decomposition of a Specification

Contents

4.1 Overview ................................. 56

4.2 Cut of a Dependence Graph . . . . . . . . . . . . . . . . . . . . . . 58

4.2.1 Fragmentation of the Control Flow Graph . . . . . . . . . . . . 58

4.2.2 Correctness Criteria for the Fragmentation . . . . . . . . . . . . 61

4.2.3 Definition of a Cut . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.4 Candy Machine Revisited: Cut of the Dependence Graph . . . . 70

4.3 Decomposing CSP-OZ Specifications . . . . . . . . . . . . . . . . . . . 72

4.3.1 Intermediate Definition of the Decomposition . . . . . . . . . . 75

4.3.2 Preservation of the Data Dependences . . . . . . . . . . . . . . 81

4.3.3 Preservation of the Control Flow . . . . . . . . . . . . . . . . . 86

4.3.4 Renaming for the Decomposition . . . . . . . . . . . . . . . . . 98

4.3.5 Definition of the Decomposition . . . . . . . . . . . . . . . . . . 100

4.3.6 Candy Machine Revisited: Decomposition . . . . . . . . . . . . 101

4.3.7 Improvement of the Decomposition . . . . . . . . . . . . . . . . 103

4.4 Decomposition for the General Case: Number Swapper . . . . . . 106

4.5 RelatedWork................................109

As previously stated, we focus on decomposing specifications, allowing for an effi-

cient application of compositional reasoning. To this end, we analyse a specification’s

dependence structure by means of its dependence graph, as defined in Chapter 2.

The following core chapter presents the correctness criteria and the definitions for

the decomposition of CSP-OZ specifications. Before going into the technical details, we

start by outlining our approach in Section 4.1. Section 4.2 defines and illustrates the

fragmentation of a dependence graph, denoted as cut. The fragmentation is based on

certain correctness criteria, resulting in the decomposition of the specification itself, as

introduced in Section 4.3. A special case of the definition will be illustrated by means of

the case study from Chapter 2. Additionally, Section 4.4 introduces a second, smaller case

study, exemplifying the general case of a decomposition. In the final section, we discuss

related work.

In order to facilitate an illustrative and fluent description of the approach, we postpone

most of the correctness proofs to the next chapter.

56 4 Decomposition of a Specification

4.1 Overview

Compositional verification follows a “divide and conquer” approach: to cope with the

state explosion problem, a local verification with respect to the components of a software

model is applied.

However, as already stated in Section 3.2.2, two major obstacles complicate the

application of compositional verification and particularly assume-guarantee reasoning.

First, the technique is only applicable if the overall model is composed of at least two

components. If this is not the case, the model needs to be decomposed, without changing

its observable behaviour.

Less evident, second, a decomposition itself does not always lead to an effective

application of compositional verification. Disadvantageous decompositions may still

cause large state spaces during model checking. We will deal with the aspect of classifying

decompositions in Chapter 6.

In this chapter, we construct decompositions of specifications written in CSP-OZ, pre-

serving the specification’s semantics in the domain of the CSP traces model. As the

dependence graph comprises the complete dependence structure of a specification S, our

strategy primarily targets the distribution of the DG. Henceforward, Sitself is decomposed

such that the resulting specification parts S

and S

correspond to the generated segments

of the DG.

A distribution of the DG is accomplished on the level of its operation nodes. Correctness

criteria refer to the control flow and thus to CSP operator nodes as well. In order to

fragment the DG into two subgraphs, we define a set

C⊆op(

)

, which serves as the link

between them. We will call this set a cut motivated by the intuition that it identifies the

line(s) of intersection of the graph. The set of cut nodes is common to both subgraphs

and, consecutively, to both specification parts. From the specification point of view, the

cut serves as the interface, that is, the synchronisation alphabet, between the specification

parts S1and S2.

Figure 4.1 illustrates the individual steps of our approach.

Computation of the DG, ¬:

Given a specification S, we first compute its dependence

graph

DGS= (

,−→DG)

, as introduced in Chapter 2. We mainly focus our considera-

tions on its set of operation nodes.

Identification of the Cut, :

Next, we identify a cut of the dependence graph: a set of

operation nodes, yielding a correct fragmentation of the DG (represented by grey

nodes in the figure). In Section 4.2, we present the definition of a cut along with

the correctness criteria for the segmentation.

Fragmentation of the DG, ®:

Determining the set of cut nodes and distributing the set

of operation nodes results in two subgraphs. The cut itself is represented in both

subgraphs.

Decomposition of the Specification, ¯:

The fragmentation of the DG leads to the defi-

nition of the two specification parts of S,S

and S

. Section 4.3 precisely defines

4.1 Overview 57

S1S2

Figure 4.1: Cut identification, fragmentation of the dependence graph and decomposition

of the specification

the decomposition and introduces the additional constructs required to ensure the

(trace) equivalence of Sand S1kS2.

Next, we introduce our definition of a cut along with the criteria which need to be

satisfied such that the observable behaviour of the specification is preserved. We illustrate

the definitions and criteria on several small examples and especially on our case study.

58 4 Decomposition of a Specification

4.2 Cut of a Dependence Graph

Before we introduce the definition of a valid cut of a dependence graph, we start with

identifying its fragmentation with respect to two sets of operation nodes. Correctness

criteria on the fragmentation consecutively lead to the definition of the cut. Since most

of our definitions are not restricted to the dependence graph, we introduce them for

arbitrary graphs and subsequently apply them in our specific context.

4.2.1 Fragmentation of the Control Flow Graph

We are interested in identifying two different subgraphs of the DG. In particular, these

subgraphs should not arbitrarily intersect. Thus, we need to define different segments of

the graph which are disjoint.

The control flow graph comprises all nodes of the dependence graph and defines the

workflow and the dynamic behaviour of a specification. Therefore, we will define a

fragmentation of the control flow graph alone instead of considering the dependence

graph. Subsequently, the data flow needs to be evaluated to verify that a corresponding

fragmentation of the DG is correct.

In general, the technique needs to deal with all different kinds of nodes and edges.

However, the subsequent distribution of nodes refers to operation nodes, which is sufficient

in our context: we do not distribute the set of CSP operator nodes. This will be achieved

in Section 4.3, where we define a projection of a CSP process with respect to a set of

events.

nodes of N2

nodes of N1

nodes of N N

1 2

Figure 4.2: Illustration of Definition 4.2.1

First, the following definition determines all nodes reachable from one set of nodes N

not intersecting with another set of nodes N2.

Definition 4.2.1. (Interval from N1to N2)

Let G= (N,−→)be a graph, and let N1,N2⊆N. Then,

−→ N2:= {n’ ∈N| ∃ n∈N1, π ∈pathG(n,n’)•π∩N2=∅} \ N1.

4.2 Cut of a Dependence Graph 59

The interval excludes both, N

and N

, as illustrated in Figure 4.2. Intuitively, it can

be regarded as the set of nodes “between” N

and N

. Note that both, N

and N

, are

allowed to be empty.

The previous definition allows us to divide the set of nodes of a graph into several

subsets (or phases, as we call them). Next, we introduce the fragmentation of the CFG,

which is defined with respect to two sets of operation nodes, C1and C2:

Definition 4.2.2. (Fragmentation of the control flow graph)

Let

CFGS= (

,−→)

be the control flow graph of a specification S, and let

C1,C2⊆op(

)

Moreover, let

StartNodes := {start.P|P∈LCSP}

and

start1:= ({start}to

−→ C1)∩StartNodes.

Afragmentation of (the set of operation nodes of)

CFGS

with respect to a tuple

(C1,C2)

is a

set of three phases Ph1,Ph2and Ph3defined as

1.) Ph1:= (({start}to

−→ C1)∩op(N)) ∪ {init}, (Phase 1)

2.) Ph2:= (C1

−→ C2)∩op(N), (Phase 2)

3.) Ph3:= (C2

−→ start1)∩op(N). (Phase 3)

and

serve as the two lines of intersection for the graph. The first phase

Ph1

contains all operation nodes before the first line of intersection. We add the unique

init-node of the specification to Ph1, comprising the set of initial predicates.

The second phase includes the set of operation nodes between both lines of intersection.

Finally, the third phase comprises the set of operation nodes behind the second line of

intersection. A first correctness criterion will exclude that any two of the five sets have a

common element.

Intuitively, one would expect

Ph3:= (C2

−→ ∅)∩op(

)

. However, we need to

“stop” adding nodes to

Ph3

after reaching a recursive call back to

Ph1

. Otherwise, our

subsequently defined correctness criteria on a fragmentation would rule out allowed

recursive calls. Therefore, we define a set

start1

, comprising all nodes

start.

Xoccurring

before the first line of intersection. This specific point will become clearer in the next

section.

In the general case of a cut, as introduced in Section 4.2.3, we use the previous

definition as follows: we determine two sets of operation nodes, namely

and

, which

will from now be called the first cut and the second cut. The definition results in five

disjoint sets of operation nodes

Ph1

Ph2

and

Ph3

. Henceforth, we will refer to

Ph1

Ph2

and

Ph3

as the phases of a fragmentation, whereas

and

will be referred to

as its cut sets.

The following lemma states that a fragmentation of the CFG is always complete in the

sense that no nodes are left out:

60 4 Decomposition of a Specification

Lemma 4.2.3. (Completeness of Fragmentation)

Let

CFGS= (

,−→)

be the control flow graph of a specification S, and let

(C1,C2)

be a

fragmentation. Then,

Ph1∪C1∪Ph2∪C2∪Ph3=op(N).

Proof.

The left-to-right inclusion is obvious. For the opposite inclusion, let

n∈op(

)

Based on the definition, the special init-node is an element of

Ph1

. Moreover, as any CFG

node is reachable from the unique

start

-node, there exists

π∈pathCFG(start,n)

. Without

loss of generality let π=hstart,n1,...,nkiand nk=n.

n∈Ph1

, we immediately deduce the right-to-left inclusion. Otherwise,

π∩C16=∅

holds.

n∈C1

would again conclude the proof. If

n6∈ C1

, there exists an index

1≤

such that

nl1∈C1

. Since

is reachable from

nl1

, either

n∈Ph2

or, otherwise, there exists

nl2∈C2

for some l

2≤

k. If l

k, we have shown

n∈C2

. In the opposite case, we

deduce that

is reachable from

which either leads to

n∈Ph3

or to

π∩start16=∅

based on the definition of

Ph3

. In this case, we infer that there exists some l

and

nl3∈start1

. Here, l

36=

since l

2∈op(

)

and l

3∈StartNodes

. Hence, the path

hstart,...,nl3icontains at least three different nodes nl1,nl2and nl3.

Reapplication of the previous ideas now starting in

nl3

yields a sequence of nodes

which continuously traverses the CFG through its five fragments. As the length of the

sequence increases with every cycle, but never leaves the set Ph1∪C1∪Ph2∪C2∪Ph3,

it eventually reaches n, yielding the right-to-left inclusion. 2

nodes of Ph2

nodes of Ph1

nodes of C2

nodes of C1

nodes of Ph3

Figure 4.3: Fragmentation of the DG

Figure 4.3 illustrates the fragmentation. As already mentioned, we do not deal with

nodes of

cf(

)

here. Thus, all boxes denote operation nodes. Besides, nodes of

Ph1

and

Ph3

have the same colour, since both segments will be assigned to the same component

in Section 4.3. Hence, we will mostly not distinguish between Ph1and Ph3.

4.2 Cut of a Dependence Graph 61

Since the definition of the fragmentation cannot be arbitrary, we need to specify

additional correctness constraints. These criteria coarsely describe the following aspects:

Criterion 1 – disjointness:All fragments are disjoint.

Criterion 2 – no crossing:

The lines of intersection (cut sets) are not circumvented by

data dependence edges.

Criterion 3 – no reaching back:

Paths of the CFG have to comply to the ordering of

the fragments.

Criterion 4 – all-or-none:

The set of operation nodes corresponding to the same schema

must not be distributed over different fragments.

We give a detailed definition of the correctness criteria next.

4.2.2 Correctness Criteria for the Fragmentation

In order to define a correct fragmentation of the DG and ultimately a correct decomposition

of the specification, several correctness criteria need to be satisfied. If possible, a criterion

will again be defined for arbitrary graphs.

Most of the criteria will rule out specific edges of the DG with respect to the fragmenta-

tion. We illustrate these edges by means of a recurrent figure. Recall that nodes of the

cut sets and phases are always operation nodes, that is, elements of op(N).

Criterion 1: disjointness

As a first and straightforward correctness criterion, we require that all segments resulting

from the graph fragmentation are pairwise disjoint. Intuitively, this is motivated by the

fact that we aim at a partitioning of the dependence graph. We recall the set theoretical

definition for disjointness:

Definition 4.2.4. (disjointness)

Let

G= (

,−→)

be a graph, and let N

2⊆

N. Then, N

and N

satisfy

disjointness

, if,

and only if, N1and N2are disjoint, that is, N1∩N2=∅.

The definition of a cut will comprise the condition that

Ph1

Ph2

and

Ph3

are pairwise disjoint. Based on the construction of the different phases, this constraint

is particularly related to CFG paths, as it excludes several edges between the different

segments. For instance, as

Ph1

and

Ph2

have to be disjoint, a direct edge from a node

Ph2

to a node of

Ph1

is impossible: the definition of

Ph2

yields that the target node

would be an element of (Ph1∩Ph2).

Figure 4.4 illustrates that CFG edges with the source node in

Ph3

(

Ph2

) and the target

node in

Ph2

(

Ph1

) are not allowed. Note that edges in the opposite direction are already

ruled out by definition of the fragmentation. Further note that we intentionally allow

edges connecting nodes of Ph3and Ph1. This substantiates the definition of Ph3.

62 4 Decomposition of a Specification

Ph1

Ph2

Ph3

Figure 4.4: Disallowed control flow edges based on disjointness

Criterion 2: no crossing

The second correctness criterion tackles the previously described aspect of a cut identifying

the lines of intersection of the dependence graph. Since it is generally impossible to

decompose the graph into two completely independent (that is, unconnected) subgraphs,

the cut needs to serve as the link between them. Intuitively, this link should not be

evaded when switching from one subgraph to the other. Therefore, paths of the DG

Swapper

. . .

main c

=store b →move a →

move b →Skip

. . .

effect store b

∆(tmp)

tmp0=b

effect move b

∆(a)

a0=tmp

store_b

move_b

move_a

...

tmp' = b

a' = tmp

Figure 4.5: Motivation for the correctness criterion no crossing

must not circumvent the cut. Based on our fragmentation of the CFG and the criterion

disjointness

, we implicitly ensure this for control flow edges. However, we also need

to guarantee that data dependence edges do not evade the cut as well: on the level of

4.2 Cut of a Dependence Graph 63

the underlying specification, the set of operation schemas of the cut defines the interface

between both resulting specification parts. If the behaviour of the specification parts

depends on each other, these shared operations are responsible for preserving the mutual

influence. This will be achieved by using them as transmitters for the correct values of

modified state variables. If a data dependence circumvents the cut, it would be impossible

to transmit the influence of one component on the other.

As an example, recall the small specification for a number swapper from Chapter 2,

Figure 2.8. The modification of tmp within store b and the reference to tmp within move b

yields a direct data dependence from the first to the latter operation node. Choosing the

set

{

move a

}

as the set of cut nodes is not reasonable: the modified value of tmp cannot

be transmitted. In this case, the data dependence edge circumvents the cut as illustrated

in Figure 4.5.

In general, we have to disallow data dependence edges connecting the different

fragments of the dependence graph if neither of the involved nodes is an element of

the cut. These edges cross the cut in the sense that there exists a direct link between

different sides of the cut. This motivates the following definition of a predicate called

no crossing, which we will subsequently use with respect to (Ph1∪Ph3)and Ph2:

Definition 4.2.5. (no crossing)

Let G= (N,−→)be a graph, and let N1,N2⊆N. Then, noCr(N1,N2,G), if, and only if,

@n1∈N1@n2∈N2•n1−→ n2∨n2−→ n1

This condition will be called no crossing between N1and N2.

For the definition of the cut, we require

noCr((Ph1∪Ph3),Ph2,DDGS)

. The disallowed

data dependence edges are illustrated in Figure 4.6.

Ph1

Ph2

Ph3

Figure 4.6: Disallowed data dependences based on no crossing

64 4 Decomposition of a Specification

Criterion 3: no reaching back

The next constraint needs to be defined with respect to the DG of a specification since

here, we explicitly need to refer to operation nodes and CSP operator nodes.

First, we consider the control flow graph and its fragmentation: the two lines of

intersection, namely

and

, dissect the graph into several fragments. We require that

paths of the control flow graph need to comply to the ordering of the segments as follows:

any path of the CFG starts in

start

and either remains in

Ph1

or subsequently reaches

Consecutively, the path remains in the respective segment or advances to either

Ph2

directly to

. Next, the path may reach

Ph3∪Ph1

or immediately

. Following up on

this, all paths need to comply with the ordering

Ph1,C1,Ph2,C2,Ph3

, possibly repeated.

Phases are potentially skipped in between.

Thus, we generally allow the control flow to advance with respect to the ordering of

the segments or to remain in a segment. However, a path must not directly return to a

previous fragment.

Swapper

. . .

main c

=store b →move a →

move b →main

. . .

effect store b

∆(tmp)

tmp0=b

effect move a

∆(b)

b0=a

store_b

move_b

move_a

...

tmp' = b

b' = a

Figure 4.7: Motivation for the correctness criterion no reaching back

The application of the following criterion is two-folded: besides the fact that paths of

the control flow graph should comply with the ordering of its segments, we also consider

data dependences. For them, the motivation for this constraint is similar to

no crossing

which already excludes a skipping of the cut sets. In addition, we need to exclude data

dependences, returning to a previous segment.

Recall the example from Figure 2.8 with a small modification: we replace

Skip

with

a recursive call of

main

. The modification of bwithin move a and the reference to b

within store b yields a direct data dependence from the first to the latter operation node.

Choosing the sets

{

store b

}

and

{

move b

}

as the sets of cut nodes is not reasonable: in

this case, the data dependence edge reaches back to the first cut as illustrated in Figure

4.2 Cut of a Dependence Graph 65

4.7. The modified value of bcannot be transmitted in between.

Ph1

Ph2

Ph3

Figure 4.8: Disallowed edges based on no reaching back

It is sufficient to disallow edges reaching back to a cut segment: control flow edges

reaching back from the cut to the previous phase are already excluded by definition

of the fragmentation and the criterion

disjointness

. Moreover, corresponding data

dependences do not need to be excluded. Figure 4.8 shows the additionally disallowed

edges of the DG.

In order to formally express that a CFG path or a data dependence edge must not

return to a previous segment, we define a predicate

no reaching back

which inputs two

sets of operation nodes: the first set denotes the source nodes, the second set the target

nodes. Data dependence edges must not connect the first to the latter set of nodes, the

same needs to hold for control flow edges. As CFG paths from one operation node to

another possibly comprise CSP operator nodes in between, we need to rule out those

paths from the first to the latter set of nodes without operation nodes in between. Recall

that

n•

−→ n’, if, and only if, (∃π∈pathCFG(n,n’)•π∩op(N) = {n,n’}).

Definition 4.2.6. (no reaching back)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let N

2⊆op(

)

Then, noRB(N1,N2,DGS), if, and only if,

∀n1∈N1•(@n2∈N2•n1

•

−→ n2∧@n’2∈N2•n1999K n’2)

This condition will be called no reaching back from N1to N2.

The definition will be instantiated as

noRB(Ph2,C1,DGS)∧noRB((Ph1∪Ph3),C2,DGS).

66 4 Decomposition of a Specification

Criterion 4: all-or-none

The last correctness criterion restricts the distribution of the set of operation nodes of the

DG. Definition 2.3.4 introduced a labelling function l, mapping an operation node on its

schema name. In our decomposition, we have to require that for any operation schema

op ∈Op,all corresponding nodes opiare assigned to the same graph fragment.

Intuitively, this condition is necessary, since schemas corresponding to operation nodes

occurring in the cut are generally modified. For the different cut sets

and

, this

modification can differ. Moreover, schemas occurring outside of the cut remain unchanged.

A distribution of

{opi∈op(

(opi) =

}

over at least two different segments would

require a duplication of the schema which is undesirable and technically infeasible.

The following predicate defines this

all-or-none

law – it will subsequently be used

with respect to the cut sets C1,C2and the complement of C1∪C2:

Definition 4.2.7. (all-or-none)

Let G= (N,−→)be a graph, and let N1,N2⊆N. Then, AoN(N1,N2,G), if, and only if,

N1⊆N2∨N1⊆(N\N2)

This condition will be called all-or-none law for N1relative to N2.

This completes the definition of the correctness criteria. They will consecutively be

used to define a cut, that is, a correct fragmentation of the DG, and subsequently the

decomposition of a specification.

4.2.3 Definition of a Cut

The previously introduced correctness criteria along with Definition 4.2.2 immediately

lead to the first of two core definitions of this thesis, the definition of a cut:1

Definition 4.2.8. ([General] Cut of the DG)

Let

DGS= (

,−→DG)

be the dependence graph and

CFGS= (

,−→)

the control flow graph

of a specification S, respectively. A fragmentation

C= (C1,C2)

of the CFG according to

Definition 4.2.2 is called a (valid) cut of the DG, if, and only if, the following correctness

criteria are satisfied:

Criterion 1 (disjointness): The following five sets are pairwise disjoint:

•Ph1,Ph2,Ph3, (phases)

•C1,C2. (cut sets)

Criterion 2 (no crossing):

noCr((Ph1∪Ph3),Ph2,DDGS),(no crossing between different components)

In the following definition, allowing a cut set to be empty does not pose a problem: if

C1=∅

, the

fragmentation either yields a trivial decomposition or a contradiction to the criterion

disjointness

C2=∅will subsequently be identified as a special case of the cut definition.

4.2 Cut of a Dependence Graph 67

Criterion 3 (no reaching back):

•noRB(Ph2,C1,DGS)and (no reaching back to first cut set)

•noRB((Ph1∪Ph3),C2,DGS), (no reaching back to second cut set)

Criterion 4 (all-or-none): For all operation nodes op ∈Op:

•AoN(l−1[{op}],C1,DGS)and (no cut-distribution of nodes

•AoN(l−1[{op}],C2,DGS).associated to one operation)

We ultimately aim at the definition of two specification parts S

and S

, resulting

from the decomposition of the dependence graph of S. The previous definition of a cut

identifies a fragmentation of the set of operation nodes of the dependence graph in the

following way: the unification of

and

together with

Ph3

and

Ph1

yields the set of

operations of the first component S

. Accordingly,

and

together with

Ph2

constitute

the second component S

. This is illustrated in Figure 4.9. Operations corresponding to

the first cut set identify the link from S

to S

, whereas the second cut set determines the

opposite link. The precise definition of S1and S2will be given in Section 4.3.

{

determine

operations

of S1

determine

operations

of S2

nodes of Ph2

nodes of Ph and Ph

1 3

nodes of C2

nodes of C1}

Figure 4.9: Fragmentation of the set of operation nodes in general case

In order to establish a well-defined fragmentation of the original dependence graph and

thus well-defined specification components, CSP operator nodes need to be considered

as well. In Section 4.3, we will determine the CSP parts of the components S

and S

resulting from a projection of the CSP part of Sonto the specific sets of operation schemas.

This definition will provide a correct distribution of the CSP operators and thus, operator

nodes of the DG.

Figure 4.10 shows all allowed edges of the DG. Dotted edges depict data dependences,

whereas solid edges represent a unification of both, control flow edges and data depen-

dences.

As we introduced

as the first line of intersection and

as the second, we need to

substantiate that

is located behind

. The following lemma shows that our definition

indeed matches with the intuition. It states that there are no direct CFG paths from the

second cut to the first cut – any such path needs to proceed over

Ph1

via a recursive call.

Recall that

start1:= ({start}to

−→ C1)∩StartNodes.

68 4 Decomposition of a Specification

Ph1

Ph2

Ph3

Figure 4.10: Assignment of DG edges to the subgraphs

Lemma 4.2.9. (No direct CFG paths from second to first cut)

Let

DGS= (

,−→DG)

be the DG of a specification S and let

(C1,C2)

be a cut of the DG. Then,

the following holds:

∀c1∈C1,c2∈C2•(π∈pathCFG(c2,c1)⇒π∩start16=∅).

Proof.

Assume the opposite: let

π∈pathCFG(c2,c1)

with c

−→

and

π∩start1=∅

In this case, by definition of

Ph3

, the node c

1∈(Ph3∩C1)

violates Definition 4.2.8,

correctness criterion disjointness.2

Since the CFG of a specification may include recursive calls, yielding paths from

Ph2

back

Ph1

, we generally need to identify two lines of intersection. The first subgraph thus

contains nodes located before the first cut (

Ph1

) as well as nodes located behind the second

cut (

Ph3

). We will now additionally consider a special case of the segmentation, which

corresponds to the definitions of [MWW08].

Assume that the dependence graph of a specification can be fragmented in such a way

that there are no paths from

Ph2

back to

Ph1

. Intuitively, this means that recursion can

only occur within the same phase. In particular, such a DG does not incorporate “outer”

recursive calls in the sense that a path reaching Ph2never returns to the start-node.

In this case, the dependence graph can reasonably be segmented into two subgraphs

without the need for a second line of intersection: the first subgraph contains the nodes

before the sole line of intersection and the second subgraph the nodes behind it, whereas

both subgraphs include the cut set.

In this specific case, we call the dependence graph sequential based on the possibility

to fragment it without outer recursion. The now simplified fragmentation is illustrated in

Figure 4.11. This leads to the following definition:

Definition 4.2.10. (Single Cut)

Let C= (C1,C2)be a cut. We call Casingle cut, if, and only if, C2=∅.

4.2 Cut of a Dependence Graph 69

}

{

nodes of Ph2

nodes of Ph1

nodes of C1

determine

operations

of S1determine

operations

of S2

Figure 4.11: Fragmentation of the set of operation nodes in the special case

In the case of a single cut, we synonymously write

and

. The restriction

C2=∅

incorporates several repercussions. First of all, the fragmentation yields

Ph2= (C1

→

∅)∩op(

)

from which we can deduce that no CFG paths from

Ph2

back to

are allowed

at all. Moreover, no paths from

Ph2

Ph1

can exist. Finally,

Ph3=∅

holds. We will

summarise and proof these claims in the following lemma:

Lemma 4.2.11. (Properties of single cut)

Let Cbe a single cut. Then, the following holds:

1. Ph2= (C1

−→ ∅)∩op(N),

2. ∀n∈Ph2,n’ ∈C1•pathCFG(n,n’) = ∅,

3. ∀n∈Ph2,n’ ∈Ph1•pathCFG(n,n’) = ∅,

4. Ph3=∅,

Proof:

1. Obvious. X

Assume that there exist

n∈Ph2,n’ ∈C1

such that

π∈pathCFG(n,n’)

. We distinguish

two cases for

: if

π∩Ph1=∅

, there exist some nodes

l∈Ph2,m∈C1

such that

l•

−→ m

. This yields a contradiction to the correctness criterion

no reaching back

Otherwise, let

be the first node of

which is an element of

Ph1

. Then,

either reaches

via some direct edge from

Ph2

, violating the correctness criterion

disjointness

(

m∈Ph2∩Ph1)

. Otherwise, there is an indirect connection via

which again violates no reaching back at some point within π.X

Now assume there exist some

n∈Ph2,n’ ∈Ph1

such that

π∈pathCFG(n,n’)

According to the previous case, second part, this path violates one of the correctness

criteria disjointness and no reaching back.X

Since, in particular,

∅to

→

=∅

for any set M, we immediately deduce the equation.

Table 4.1 summarises the differences between a general cut and a single cut. Based on

our case study from Chapter 2, we consecutively illustrate the definition for the special

case of a single cut.

70 4 Decomposition of a Specification

General Cut Single Cut

Number of Cut Sets two one

disjointness Ph1,C1,Ph2,C2,Ph3

are pairwise disjoint

Ph1,C1,Ph2

are pairwise disjoint

First Subgraph comprises

Ph1,C1,C2and Ph3

comprises

Ph1and C1

Second Subgraph comprises

C1,Ph2and C2

comprises

C1and Ph2

Allowed Recursion within one segment,

between Ph3and Ph1within one segment

Table 4.1: Comparison between the general cut and the single cut

4.2.4 Candy Machine Revisited: Cut of the Dependence Graph

Chapter 2 introduced the specification CandyMachine. We illustrate the previous defini-

tions of a fragmentation and a cut by means of this particular example. The example

complies to the general restrictions for a single cut and thus allows a demonstration of

the special case. Section 4.4 additionally illustrates the general case.

Here, we will neglect three specific data dependences, namely the three initial data

dependences originating from the

Init

predicate items

=h i

to the respective operation

nodes order,term and deliver. The reason why we are allowed to do this will precisely

be given in Section 4.3.7, where we will deal with the neglect of specific initial data

dependences. Intuitively, these dependences originate from a predicate restricting a

variable which is never modified or referenced in any of the schemas pay,payout,abort

and switch. We will show that the source of this dependence can safely be moved to the

second subgraph.

We start the illustration of the cut definition with the fragmentation of the CFG,

according to Definition 4.2.2. Figure 2.9 from Section 2.3.2 depicts the control flow graph

of the candy machine. Let

C1:= {switch}

and, according to the definition of a single cut,

C2:= ∅. This leads to the following fragmentation:

Ph1={pay,payout,abort},

C1={switch}and

Ph2={select,order,term,deliver}.

For showing that this fragmentation satisfies the constraints of Definition 4.2.8, recall

4.2 Cut of a Dependence Graph 71

the DG of the candy machine specification as given in Figure 2.13, and consider the four

correctness criteria for the decomposition:

Criterion 1 (disjointness): Ph1

and

Ph2

are disjoint. In particular, this is due to

the non-existent recursive calls from Ph2to Ph1.

Criterion 2 (no crossing):

In case we neglect the previously identified initial data

dependences,

noCr(Ph1,Ph2,DDGS)

holds. No data dependences connect a node of

Ph1and Ph2.

Criterion 3 (no reaching back): noRB(Ph2,C1,DGS)

holds as well. There are no CFG

paths or data dependences originating from Ph2targeting {switch}.

Criterion 4 (all-or-none):

Obvious, since there are no multiple occurrences of an opera-

tion within the CSP part of CandyMachine.

The fragmentation based on

C1={switch}

thus yields a valid (single) cut. This is

illustrated in Figure 4.12. The left hand side depicts the first subgraph, and the right

hand side displays the second subgraph. Note that for the reduced parts of the graphs,

we applied a simplification on the sets of CSP operators and control flow edges. The

precise definition of the modified CSP part is given in the next section.

start

pay

switch

call.Payout

call.main

start.Payout

abortpayout

call.Payout Skip1

extch

init

Skip2

switch

start.Order

call.Order

start.Deliver

call.Select

start.Select

call.Select

call.Deliver

Skip2call.Deliver

order term deliver

select

extch

start

extch

Skip1

Figure 4.12: Cut of the dependence graph for the candy machine

This concludes the illustration of a (single) cut. So far, we considered the dependence

graph of a specification which represents its dependence structure. We defined the cut of

72 4 Decomposition of a Specification

the DG, separating it into two parts. Next, we need to transfer the fragmentation of the

graph DGSto the decomposition of the specification S.

4.3 Decomposing CSP-OZ Specifications

Acut of the dependence graph of a specification Sas defined in the previous section

determines a fragmentation of the DG, resulting in several clusters of nodes. This

segmentation serves as the cornerstone for the identification of two specifications S

and

S2, representing a correspondent decomposition of S.

I[interface definition]

main [CSP part]

State [Object-Z part: state schema]

Init [Object-Z part: initial state schema]

enable op [Object-Z part: enable-schemas]

effect op [Object-Z part: effect-schemas]

Figure 4.13: Constituents of a CSP-OZ class specification

In this section, we transfer the previous definitions from the graph level to the spec-

ification level. Again, we do not distinguish between specifications consisting of one

and several classes. The decomposition of a specification is defined with respect to

the fragmentation of the DG and is thus independent of the class structure. Therefore,

throughout this thesis, we will synonymously refer to class and specification.

Recall the structure of a CSP-OZ class specification as given in Figure 4.13. At first, we

have to identify the different constituents of S

and S

, namely its interface definition,

its CSP part and its Object-Z part. Subsequently, we assemble both specifications by

identifying a synchronisation alphabet A, employed for the definition of S

1kA

. The

construction has to make sure that Sand S1kAS2have the same observable behaviour.

A first fingerpost for the definition of S

and S

is directly given by the fragmentation

of the DG: the sets of operation nodes corresponding to

and

take the role of

connecting the different specification parts where

is responsible for preserving the

influence of S

on S

whereas

identifies the opposite link. Additionally, the cut is the

basis for the definition of the synchronisation alphabet A. Moreover, nodes of

Ph1,Ph2

and

Ph3

represent the operations local to S

(

Ph1,Ph3

) and S

(

Ph2

). This is illustrated

in Figure 4.14.

In order to construct two well-defined specifications S

∈ {1,2}

, we start with a first,

intermediate definition of a decomposition in Section 4.3.1, where we need to deal with

the following subtasks:

Definition of the Interfaces of Si:

Identifying the set of operations of a component, the

4.3 Decomposing CSP-OZ Specifications 73

nodes of Ph2

nodes of Ph1

nodes of C2

nodes of C1

nodes of Ph3

operations local to S1

operations local to S2

operations local to S1

shared operations,

link from S to S

1 2

shared operations,

link from S to S

2 1

Figure 4.14: Correspondence between graph nodes and specification operations

fragmentation of the dependence graph immediately yields the set of channel

declarations of Si.

Definition of the CSP Parts Si.main:

According to its interface, the CSP part of S

needs

to be restricted to the component’s set of channels. For that purpose, we define a

projection of the original CSP part on the remaining operations of a component,

according to [Brü08].

Definition of the State Schemas of Si:

One of the decisive aspects for an effective ap-

plication of compositional reasoning is the size of the state space of the involved

components. As the set Vof state variables of a specification’s Object-Z part deter-

mines the size of the Object-Z state space, the sets S

Vand S

Vnecessarily need

74 4 Decomposition of a Specification

to be smaller than S

V. Hence, we need to identify two subsets of S

V, forming the

sets of required state variables for the specification parts. Additionally, we need to

deal with the state invariants of the state schema.

Definition of the Initial State Schemas Si.Init:

Following up on the restriction of the

sets of state variables, we accordingly need to restrict the original initial state

schema. Moreover, an optimisation for this definition, as already indicated in the

last section, will be given in Section 4.3.7.

Definition of the Operation Schemas for Si:

According to the definition of the set of

channels, we use the fragmentation of the dependence graph in order to identify

the sets of operation schemas of a component. The determination of their respective

declaration parts and predicate parts is straightforward.

Definition of the Synchronisation Alphabet:

The definition of both specification parts

leads to the overall system S

1kA

. The assembly requires a definition of the

synchronisation alphabet A.

Carrying out the previous considerations will result in two well-defined specifications

and S

and an assembly of S

and S

into S

. However, the pure definition of two

specification parts, resulting from a cut, is insufficient. Additionally, we need to preserve

the behaviour of the specification. To this end, we have to modify part of the generated

components, mainly by adding parameters to some operations:

Preservation of Data Dependences:

Even though we do not allow data dependences

to circumvent the cut based on the correctness criterion

no crossing

, we still

have to transmit the allowed influence of one on the other specification part. Data

dependences may indeed target the set of cut operation nodes as well as originate

from them. From a specification level, this means that modifications of state

variables within one component influence state variables of the other component.

In order to preserve these dependences, we introduce additional transmission

parameters, passing the relevant state variable modifications of one to the other

component. Section 4.3.2 deals with this aspect.

Preservation of CSP Part:

The definition of the CSP parts for S

and S

based on a

projection does not automatically yield an equivalence of the original CSP part and

the CSP part of S

. In particular, the synchronisation of both CSP processes

may introduce additional sequences of events which are infeasible for the original

specification. For ensuring the equivalence of both, the CSP parts of Sand S1kS2,

we introduce additional address parameters, ensuring a correct synchronisation of

both resulting CSP processes in Section 4.3.3.

Renaming of Events:

Based on the introduction of additional parameters to some of

the specification’s channels, Sand S

are solely equivalent modulo different

channel types. In Section 4.3.4, we introduce an event renaming relation, linking

the modified to the original channels.

4.3 Decomposing CSP-OZ Specifications 75

These are the crucial aspects which we will deal with in the upcoming sections. We

proceed in two steps: first, in Section 4.3.1, we introduce a decomposition of Swith

respect to a cut into two well-defined specification parts S

and S

. Subsequently, we

modify the decomposition to achieve a thorough decomposition by modifying part of

the components elements. The complete definition of the thorough decomposition of

Sinto S

and S

will be given in Section 4.3.5, incorporating all the definitions and

considerations of the previous sections. After illustrating the approach on our candy

machine specification in Section 4.3.6, Section 4.3.7 gives an improvement for the

decomposition by pointing out an optimisation for dealing with initial state predicates.

4.3.1 Intermediate Definition of the Decomposition

The current section stepwise introduces the different constituents of two specifications S

and S

, resulting from a valid cut of

DGS

. As of now, we are interested in developing a well-

defined decomposition. Some of the subsequent definitions are marked as intermediate,

as the corresponding specification elements will later by modified to ensure a semantics-

preserving decomposition.

We start the definition of the components S

and S

by identifying their respective

interfaces and CSP parts. In order to bridge the gap between the set of operation nodes,

resulting from a cut and the corresponding set of operations, we use Definition 2.3.4:

Definition 4.3.1. (Sets of operations of components)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The sets of operation schemas for the decomposition of S are defined as

•Op1:= l[(Ph1∪Ph3)\ {init}],

•Op2:= l[Ph2],

•OpC1:= l[C1]and

•OpC2:= l[C2].

We let OpC:= OpC1∪OpC2.

We exclude

init

from the definition since we will separately deal with the initial state

schema. It is important to note that in general, Op

and Op

are not disjoint, as a multiple

occurrence of an operation may lead to one occurrence being assigned to

Ph1∪Ph3

and

another to

Ph2

. However, the three sets Op

,Op

and Op

1∪

are indeed disjoint

based on the correctness criterion all-or-none.

Next, we deduce the interfaces of the components S

and S

from the previous defini-

tion, where I|Odenotes the restriction of the interface Ion the operations of O:

Definition 4.3.2. (Interfaces of components, intermediate definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The interfaces for the decomposition of S into S1and S2are defined as

•S1.I:= I|(Op1∪OpC)and (Interface for S1)

76 4 Decomposition of a Specification

•S2.I:= I|(Op2∪OpC). (Interface for S2)

This definition will slightly be adapted in Section 4.3.3, based on the introduction of

additional parameters to the channels.

For determining the CSP parts of S

, the process S

.main

is restricted on the sets of

events corresponding to the component’s sets of operations. To this end, we define the

projection of a CSP process on a subset of its events according to [

Brü08

]. The definition

also applies, if the specification is composed of several classes:

Definition 4.3.3. (Projection of CSP processes, [Brü08])

Let P be the right-hand side of a CSP process definition and E

⊆

Events. The projection of P

on E, denoted by P|E, is inductively defined:

1. Skip|E:= Skip and Stop|E:= Stop,

2. (e→P)|E:= (P|E,e6∈ E

e→P|E,otherwise,

3. (P◦Q)|E:= (P|E)◦(Q|E)for ◦∈{;,|||,2,u},

4. (P||AQ)|E:= (P|E)||A∩E(Q|E).

According to [

Brü08

], we can apply several simplifications to the resulting CSP pro-

cesses. Such a modification is, for instance, given by replacing a process equation P

by P

=Stop

or P

= (

◦

)

with P

Qfor

◦ ∈ {2,u}

. Note that an equation P

introduces divergence [

Ros98

] into the overall process, that is, an infinite loop without

an execution of an external event. In the semantic model of traces, replacing it with

=Stop

does not influence the behaviour of the process. For more details, see [

Brü08

This definition of the projection allows us to inductively define the processes S

1.main

and S

2.main

. As the definition is applied with respect to a set of events, we use the

extension sets of the respective sets of operations.

Definition 4.3.4. (CSP parts of components, intermediate definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The CSP parts for the decomposition of S into S1and S2are defined as

•S1.main := S.main|{|Op1|}∪{|OpC|} and (CSP part for S1)

•S2.main := S.main|{|Op2|}∪{|OpC|}. (CSP part for S2)

Again, due to the additional parameters, the CSP parts of the components will slightly

be modified in Section 4.3.4 by introducing a renaming function.

Next, we define the Object-Z parts of S

and S

. We have to identify their state schemas,

initial state schemas and operation schemas.

The state schema of Scomprises a set of state variables S

Vwith their respective types,

along with a possibly empty set of state invariants. In order to define the state schemas

of S1and S2, we first identify two subsets of S.V. By setting

4.3 Decomposing CSP-OZ Specifications 77

•S1.V:= all(Op1∪OpC1)and

•S2.V:= all(Op2∪OpC2),

we restrict both state schemas to those variables which are referenced or modified in at

least one of the component’s local operations or operations of one specific cut set. Not

adding Op

and Op

to both sets will become clearer when we define the predicate

parts of the operations and when we deal with transmitting the state space modification

between the components in Section 4.3.2. Note that we do not additionally refer to

variables occurring in S.Init.

As a consequence of invariants influencing the execution of any operation, according

to the previous definition, variables occurring in some invariant need to be represented

in both, S

Vand S

V. This is implicitly guaranteed by the normalisation as introduced

in Section 2.3.3, attaching all state invariants to any effect-schema.

For the complete definition of Si.State, we will use Definition 2.2.1:

Definition 4.3.5. (State schemas of components)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The state schemas for the decomposition of S into S1and S2are defined over

•S1.V:= all(Op1∪OpC1)and

•S2.V:= all(Op2∪OpC2),

•S1.State := {s(S1.V)|s∈S.State}and

•S2.State := {s(S2.V)|s∈S.State}.

Next, we are concerned with the initial state schema of a class, that is, the decom-

position of S

.Init

into S

1.Init

and S

2.Init

. The question arises of how to deal with

predicates referring to elements of both, S1.Vand S2.V.

Consider some initial state predicate p

(

)

with xbeing assigned to S

Vand y

being assigned to S

V. The predicate can neither be assigned to S

1.Init

nor to

2.Init

, since one of the specific variables is not an element of the respective component.

However, an elimination of the predicate is infeasible, since the relation between xand y

would get lost.

Therefore, a simple restriction of S

.Init

onto predicates dealing with S

Vis insuffi-

cient. The general definition of the initial state schemas of S

and S

will refer to S

.Init

and use an existential quantification for a subset of S

V. This leads to the following

definition:

Definition 4.3.6. (Init schemas of components)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. Furthermore, let

(

) = {

1,...,

and let S

1,...,

. The initial

state schemas for the decomposition of S into S1and S2are defined as

78 4 Decomposition of a Specification

•S1.Init := ∃v1,...,vn•S.Init and

•S2.Init := ∃w1,...,wn•S.Init.

Both

Init

-predicates are well-defined, that is, all free variables occurring in S

i.Init

are elements of its respective sets of state variables S

V. Note that for the initial state

schema of S

, shared variables, that is, elements of S

∩

V, are also quantified: these

variables are already restricted in the first specification part.

We use the following abbreviation: variables not occurring in the initial state schema

will not be quantified. Precisely, if pis a predicate referring to variables x1,...,xk,

∃y1,...,ym•p(x1,...,xk)

is abbreviated by

∃z1,...,zn•p(x1,...,xk),

where

{

1,...,

n}={

1,...,

k}∩{

1,...,

. Moreover, we omit trivially satisfied

predicates as, for instance, ∃v•v=nwith n∈tv.

Recall the abstract example from before: the initial state predicate p

(

)

will be

changed to

∃

•

(

)

for S

1.Init

and to

∃

•

(

)

for S

2.Init

. A proof of the

adequateness of this definition will be given in Chapter 5. In addition, Section 4.3.7

indicates that a subset of a specification’s initial data dependences does not need to be

considered when it comes to validating the correctness of a cut.

We remain to define the declaration parts and predicate parts of the component’s

operations. For local operations to S

, we simply keep the original definition as-is. For

the set of cut operations, we solely keep the predicate parts in one of the specifications

parts. In order to ensure corresponding types, we always need to preserve the original

declaration parts. Precisely:

Definition 4.3.7. (Operation schemas of components, intermediate definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The operation schemas for the decomposition of S into S1and S2are defined as

S1.op := (S.op,op ∈(Op1∪OpC1),

[S.op.dec |true],op ∈OpC2.

S2.op := (S.op,op ∈(Op2∪OpC2),

[S.op.dec |true],op ∈OpC1.

Again, this definition needs to be modified, when we are dealing with data dependences

between both components. Finally, we unify all the previous definitions into one, the

intermediate decomposition of Sinto two components S1and S2:

4.3 Decomposing CSP-OZ Specifications 79

Definition 4.3.8. (Decomposition with respect to a cut, intermediate definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. Let

Op1,Op2,OpC1,OpC2,OpC

be defined according to Definition 4.3.1. The (intermediate) decomposition of Swith

respect to (C1,C2)into S1and S2is defined as

S1.I [according to Definition 4.3.2]

S1.main [according to Definition 4.3.4]

S1.State [according to Definition 4.3.5]

S1.Init [according to Definition 4.3.6]

S1.op [according to Definition 4.3.7]

S2.I [according to Definition 4.3.2]

S2.main [according to Definition 4.3.4]

S2.State [according to Definition 4.3.5]

S2.Init [according to Definition 4.3.6]

S2.op [according to Definition 4.3.7]

The system generated from the components is defined as the parallel composition of

both classes, synchronising on the set of cut events, that is,

S1k{|OpC|} S2.

In Section 4.3.6, we carry out the decomposition for the candy machine. For a stepwise

illustration of the decomposition on a simpler example, we consider a trivial CSP-OZ

specification for subsequently increasing three natural numbers l,mand nas given in

Figure 4.15. The set C={change m}defines a valid single cut. We get

•Op1:= {change l},

•Op2:= {change n}and

•OpC:= {change m}.

The intermediate definition of the components Increaser

and Increaser

is given in

Figure 4.16. The overall system is defined as

Increaser1k{|change m|} Increaser2.

Note that currently, Increaser

change m is empty. Moreover, the generated initial state

predicates can be simplified:

80 4 Decomposition of a Specification

Increaser

chan change l : [x! : N]chan change m : [y! : N]chan change n : [z! : N]

main c

=change l?x→change m?y→change n?z→Skip

l,m,n:N

Init

l>n

effect change l

∆(l)

x! : N

l0=l+ 1 ∧x! = l0

effect change m

∆(m)

y! : N

m0=l+ 1 ∧y! = m0

effect change n

∆(n)

z! : N

n0=m+ 1 ∧z! = n0

Figure 4.15: Simple CSP-OZ specification for increasing two natural numbers

Increaser1

chan change l : [x! : N]

chan change m : [y! : N]

main c

=change l?x→

change m?y→Skip

l,m:N

Init

∃n:N•l>n

effect change l

∆(l); x! : N

l0=l+ 1 ∧x! = l0

effect change m

∆(m); y! : N

m0=l+ 1 ∧y! = m0

Increaser2

chan change m : [y! : N]

chan change n : [z! : N]

main c

=change m?y→

change n?z→Skip

m,n:N

Init

∃l:N,m:N•l>n

effect change n

∆(n)

z! : N

n0=m+ 1 ∧z! = n0

Figure 4.16: Intermediate decomposition of Increaser

• ∃ n:N•l>n⇔l>0and

• ∃ l:N,m:N•l>n≡true, respectively.

This completes the intermediate definition of the different constituents of the com-

ponents, resulting in a well-defined decomposition of S. In an optimum way, the de-

4.3 Decomposing CSP-OZ Specifications 81

composition results in two completely independent specification parts S

and S

. In this

case, the previously given intermediate decomposition is final in the sense that no further

modification is required. In the context of assume-guarantee reasoning, this is preferable,

as no supplemental constructs need to be added, ensuring that the size of the components

remains rather small.

However, two completely independent specification parts are far from realistic. This

would, for instance, require the cut to split a graph into two unrelated pieces, not sharing

any ingoing and outgoing data dependences. Along with that, any branching within the

control flow graph would have to be assigned to one component.

In order to ensure a universally valid decomposition in our context, the introduction of

additional parameters and an event renaming is required. These extensions are given

next, yielding a modification of the previously as intermediate marked definitions.

4.3.2 Preservation of the Data Dependences

As a first step, we are interested in preserving the original data flow, that is, the state

space modifications. In particular, both components sharing the same state variables

requires that a modification within one component is visible to the other component.

Even though it is impossible that data dependences circumvent the set of cut operations

based on the criterion

no crossing

, they can indeed target the cut and originate from

it, thus causing mutual influence between both components, based on the data flow.

Figure 4.17 again illustrates the fragmentation of a specification’s dependence graph.

Ph1

Ph2

Ph3

modification of / reference to variable

reference to a variable

modification of a variable

Figure 4.17: Possible data dependences targeting the cut and originating from the cut

82 4 Decomposition of a Specification

Dotted edges denote data dependences between two operation nodes, where the schema

corresponding to the source node modifies a certain state variable, and the target schema

references a variable. Nodes highlighted in grey depict schemas which modify one and

reference another state variable.

The crucial edges are the ones originating from a cut operation and targeting an

operation in the subsequent phase or the other cut: they represent variables modified in

one specification part (within a cut schema and possibly before as well) and referenced

in the other. These modifications must be preserved to not refer to inconsistent values.

In the example Increaser, a particular sequence of two data dependences conforms to

this specific problem: the schema change l modifies the variable l, the schema change m

references land modifies mand change n references m. This sequence of state mod-

ifications is not reflected in the decomposition of Increaser as given in the last sec-

tion. For an illustration, assume that initially, l

= 3

= 2

and n

= 1

holds. Table

4.2 denotes the state valuations of Increaser during the processing of the event trace

change l

.4,

change m

.5,

change n

.6i

. Additionally, assuming the same initial state, the

corresponding traces of the components are given.

Trace of Increaser Trace of Increaser1Trace of Increaser2

h(l= 3,m= 2,n= 1),h(l= 3,m= 2),

change l.4,change l.4,

(l= 4,m= 2,n= 1),(l= 4,m= 2),h(m= 2,n= 1),

change m.5,change m.5,change m.2,

(l= 4,m= 5,n= 1),(l= 4,m= 5),i(m=2,n= 1),

change n.6,change n.3,

(l= 4,m= 5,n= 6)i(m=2,n=3)i

Table 4.2: Comparison of two traces for Increaser and its components

As the modification of mdepends on land is no longer represented in Increaser

the value of mis inconsistent after the operation change m took place. This incon-

sistency is in particular visible to the outside, as the parameter value of the event

change m has changed from

. Even worse, this inconsistency is propagated

to the value of nas well. The inconsistency changes the behaviour of the original

specification as the trace

change l

.4,

change m

.5,

change n

.6i

cannot be restored within

Increaser1k{|change m|} Increaser2

. Since we are interested in the equivalence of traces of

events the specification and its decomposition may perform, this inconsistency must be

prohibited.

The set of cut operations serves as the (sole) link between both specification parts,

and any influence of one component on the other must be transmitted via the cut. A

correspondence of the values of shared variables between both components is achieved

by the introduction of additional parameters. The type of a cut operation is possibly

extended based on this set of transmission parameters, each representing one specific

shared state variable modified in one and referenced in the other specification part.

4.3 Decomposing CSP-OZ Specifications 83

Precisely, these parameters are outputs to the modifying specification part and inputs to

the referencing component, while transmitting the values of the respective state variables.

First, we have to clarify which variables actually need to be transmitted, that is, which

variables exert influence from one on the other component. The following definition

identifies two sets of state variables, namely the ones which need to be transmitted via

the first cut set and the second cut set:

Definition 4.3.9. (Cut variables)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. The modifications of n∈op(N)influencing X ⊆op(N)are defined as

X={v∈S.V| ∃ n’ ∈X•ndd

999K(v)n’ ∨nifdd

999K(v)n’}.

The sets of cut variables for the decomposition of S into S1and S2are given by

•CV(C1) := Sn∈C1Vn

(Ph2∪C2)and

•CV(C2) := Sn∈C2Vn

(Ph1∪Ph3∪C1).

∈

(C1)

holds, if there exists a (direct- or interference-) data dependence by reason

of voriginating from the first set of cut operations and targeting an operation from

Ph2

.CV

(C2)

is analogously defined. The definition is complete in the sense that

all variables exerting influence from one on the other component are included: the

correctness criterion

no crossing

ensures that data dependences must not circumvent

the set of cut nodes.

As we need to refer to operation schemas instead of operation nodes when adding

transmission parameters to an operation, we set

Vop

X=Sn∈l−1(op)Vn

and let

CV1:= Vop

(Ph2∪C2)and CV2:= Vop

(Ph1∪Ph3∪C1).

Even though we might have different sets of cut variables for

n,n’ ∈

−1(

)

, the definition

is reasonable: the correctness criterion

all-or-none

ensures that two different operation

nodes corresponding to one operation schema must not be distributed over a cut set and

its complement.

The previous considerations lead to the following, final definition for the operation

schemas of S1and S2:

Definition 4.3.10. (Operation schemas of components, final definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. For CV1={v1,...,vn}and CV2={w1,...,wm}, let

op.tr in1=trv1? : tv1;. . . ;trvn? : tvn,op.tr in2=trw1? : tw1;. . . ;trwm? : twm,

op.tr out1=trv1! : tv1;. . . ;trvn! : tvn,op.tr out2=trw1! : tw1;. . . ;trwm! : twm.

84 4 Decomposition of a Specification

The operation schemas for the decomposition of S into S1and S2are defined as

S1.op :=











S.op,op ∈Op1,

[S.op.delta;S.op.dec;op.tr out1|op.pred ∧Vv∈CV1trv! = v0],op ∈OpC1,

[∆(w1,...,wm); S.op.dec;op.tr in2|Vw∈CV2w0=trw?],op ∈OpC2.

S2.op :=











S.op,op ∈Op2,

[∆(v1,...,vn); S.op.dec;op.tr in1|Vv∈CV1v0=trv?],op ∈OpC1,

[S.op.delta;S.op.dec;op.tr out2|op.pred ∧Vw∈CV2trw! = w0],op ∈OpC2.

The declaration parts of all cut operations are extended by additional transmission

parameters. For the influence of S

on S

, we add predicates tr

v! =

for each cut variable

∈

to the first cut set and corresponding predicates v

to the second. We

proceed accordingly for variables of S

influencing S

. The delta lists of the receiving

operations need to comprise all modified cut variables. Figure 4.18 illustrates the concept

of these parameters. In Chapter 5, we will show that this technique is sufficient to restore

the data flow of a specification in its decomposition.

v modified in S ,

referenced in S2

w modified in S ,

referenced in S1

tr !

tr ?

p(v)

p(w)

p(v')

p(w')

Figure 4.18: Illustration of the transmission parameters

In our example, due to the data dependence

change m dd

999K(m)change n

, the state

variable mis a cut variable of change m. Thus, we add one transmission param-

eter tr

to change m, serving as an output to Increaser

change m and an input to

4.3 Decomposing CSP-OZ Specifications 85

Increaser1

chan change l : [x! : N]

chan change m : [y! : N;trm! : N]

main c

=change l?x→

change m?y?trm→Skip

l,m:N

Init

∃n:N•l>n

effect change l

∆(l)

x! : N

l0=l+ 1 ∧x! = l0

effect change m

∆(m)

y! : N;trm! : N

m0=l+ 1 ∧y! = m0∧trm! = m0

Increaser2

chan change m : [y! : N;trm? : N]

chan change n : [z! : N]

main c

=change m?y?trm→

change n?z→Skip

m,n:N

Init

∃l:N•l>n

effect change m

∆(m)

trm? : N

m0=trm?

effect change n

∆(n)

z! : N

n0=m+ 1 ∧z! = n0

Figure 4.19: Decomposition of Increaser, modified according to Definition 4.3.10

Increaser

change m. The modified decomposition is shown in Figure 4.19. Note that we

have to modify the specification’s interfaces and CSP parts as well. We deal with this

aspect in Section 4.3.4.

This modification fixes the previously identified inconsistency as shown in Table 4.3.

Next, we deal with the reconstitution of the control flow of the original specification

within its decomposition. The underlying concept similarly uses additional parameters.

Trace of Increaser Trace of Increaser1Trace of Increaser2

h(l= 3,m= 2,n= 1),h(l= 3,m= 2),

change l.4,change l.4,

(l= 4,m= 2,n= 1),(l= 4,m= 2),h(m= 2,n= 1),

change m.5,change m.5,change m.5,

(l= 4,m= 5,n= 1),(l= 4,m= 5),i(m=5,n= 1),

change n.6,change n.6,

(l= 4,m= 5,n= 6)i(m=5,n=6)i

Table 4.3: Comparison of two traces of Increaser and its components after modification

86 4 Decomposition of a Specification

4.3.3 Preservation of the Control Flow

The fact that one specification part influences the other one due to its data flow is

quite intuitive. Additional to that and less obvious, the intermediate decomposition and

reassembly can also cause a modification of the original control flow of a specification.

For instance, it is possible that the CSP part of S

allows for additional traces, thus

causing a violation of the trace equivalence between Sand S1kS2.

As the problem of preserving the control flow of a specification is solely related to the

CSP part of a specification, we entirely omit dealing with the Object-Z part in this section.

Restoring the Original Synchronisation

First, we will deal with ensuring a correct synchronisation between S

and S

. In order to

illustrate the general problem, we give a small example.

Example 4.3.11. Let S be a specification over a set of events {a,b,c,d,e}, and let

S.main := (a→c→d→Skip)2(b→c→e→Skip).

Let C={c}be a valid single cut yielding

•S1.main := (a→c→Skip)2(b→c→Skip)and

•S2.main := (c→d→Skip)2(c→e→Skip).

Let tr := ha,c,ei. Then, tr ∈traces(S1.main k{c}S2.main)but tr 6∈ traces(S.main).

The example points out the following: Definition 4.2.8 allows the cut sets to contain

several nodes with the same operation name - for

n1,n2∈Ci

, the equation op

(n1) =

(n2)

is possible. Let us denote two different occurrences of op within the CSP part of a

specification by op1and op2.

In the decomposition of the specification, op

and op

occur in both parts, S

and

. Obviously, a synchronisation of op must be restricted to originally corresponding

occurrences of op, that is, S

should be synchronised with S

and, accordingly,

S1.op2with S2.op2.

However, the synchronisation alphabet can no longer distinguish between these dif-

ferent occurrences. Therefore, non-corresponding instances of operations can be syn-

chronised as well. This can particularly lead to additional traces for the CSP part of

S1kS2.

In our example, the event coccurs twice within S

.main

and thus twice in S

1.main

and S

2.main

. A synchronisation of cwithin S

1.main k

2.main

can either result in the

joint execution of corresponding occurrences, namely S

synchronising with S

and

synchronising with S

, as shown on the left hand side of Figure 4.20, or to an

invalid synchronisation of S

with S

and S

with S

, as shown on the right

hand side of the same figure. The latter synchronisation triggers the previously identified

path ha,c,ei, which is invalid for S.main.

In Section 2.2.1, we introduced simple parameters [

Fis00

Fis97

] which can be re-

stricted by both, the CSP part and the Object-Z part of a specification. This specific type

4.3 Decomposing CSP-OZ Specifications 87

start

extch

c1c2

start

extch

... ... ... ...

Figure 4.20: Synchronisation of events for external choice

of parameters will be used to define a set of additional address parameters to operations

with a multiple occurrence in the cut. In our case, they will solely be restricted by the CSP

part, and they do not occur in the Object-Z part of a component. We will modify the CSP

parts of S

and S

by fixing the values for some of these parameters. As a synchronisation

of two instances of an operation is only possible if their extension sets are not disjoint,

differently fixed parameters can prevent a false synchronisation.

We illustrate the outcome of this extension on the previous example. For the event c,

we will use one address parameter p1of type {1,2}and redefine

•S1.main := (a→c.1→Skip)2(b→c.2→Skip)and

•S2.main := (c.1→d→Skip)2(c.2→e→Skip).

A synchronisation of c1with c2over different components is now impossible.

In general, if no parallel composition is involved in a process, one additional address

parameter is sufficient to separate two different occurrences of an operation from each

other. However, when dealing with parallel composition, synchronising the operation

under interest, one parameter is no longer adequate, since it would exclude part of the

originally allowed synchronisation.

Recall Example 4.3.11 after replacing the external choice operator with k{c}. We get

S1.main := (a→c→Skip)

k{c}(b→c→Skip),

S2.main := (c→d→Skip)

k{c}(c→e→Skip).

88 4 Decomposition of a Specification

In this case, a joint synchronisation of the event cwithin S

1.main k{c}

2.main

allowed. This requires us to add two fresh parameters, not affecting each other, with one

of them subsequently restricted for one branch of the parallel composition and the other

one restricted for the other branch.

Summarising, we need to preserve and neither extend nor restrict the original synchro-

nisation structure of Swithin S

. The following definitions especially need to ensure

that only corresponding instances of operations can be synchronised between S1and S2.

In order to find a general solution for this problem by identifying a correct addressing

extension for any process, including nesting of different types of branching, we recursively

traverse its CFG with respect to any operation schema with multiple occurrence in the

cut. An algorithm yielding a correct synchronisation is given in Section 5.1. To this end,

we outline the general strategy. In addition, we define and show the required conditions

on a correct addressing, which are realised by the algorithm. The algorithm proceeds as

follows:

Traversing the CFG:

Starting with the unique

start

-node, we recursively traverse the

CFG of the process S.main. Let op ∈Op be the current operation under interest.

Initial parameter:

Initially, we use one address parameter p

of type

{1}

. The type of

any parameter can be extended throughout the traversal.

Active Parameters:

Any branch of the CFG has one dedicated, active address parameter.

The underlying idea is that this parameter possibly needs to be assigned with a

specific value to prevent a false synchronisation within the associated branching.

Initially, p

is declared active for the sole initial branch and assigned with the value

. All assigned values are possibly modified during an execution of the algorithm.

Besides, one parameter can be active for more than one branch.

No Branching:

In case we proceed over a CFG operator which does not introduce

branching, no changes to the parameters are committed.

Branching for cfop ∈ {extch,intch,interleave,parX}and op 6∈ X:

Branching without par-

allel composition of the operation under interest can lead to two occurrences of

op within the cut, which need to be separated. In this case, the currently active

parameter is declared active for both, the left and right branch. For the left branch,

we keep the originally assigned value whereas for the right branch, we increase it

by one, and we add the new value to the parameter’s type. This ensures that an

operation occurring in both branches cannot wrongly be synchronised.

Branching for parXand op ∈X:

Branching with a synchronisation of op possibly leads

to two occurrences of op, which still need to be able to be synchronised. In this

case, the active parameter p

, which belongs to the branch entering the parallel

composition, can no longer be used: it may already be used to prevent a wrong syn-

chronisation within a previous branching. The algorithm introduces two additional,

fresh parameters p

i+1

and p

i+2

. The first parameter is declared active for the left

branch, the second parameter is declared active for the right branch. As we solely

4.3 Decomposing CSP-OZ Specifications 89

restrict each parameter on one side, a synchronisation of occurrences within the left

branch and the right branch is always possible, independent of further restrictions

of pi+1 and pi+2.

Figure 4.21 illustrates the two different cases for branching.

cfop parS

active(pi)

pi=x

active(pi)

pi=y

active(pj)

pj= x

pk= ?

active(pk)

pj= ?

pk= y

e1e2e1e2

matches with any

do not match

e.x e.y e.x?pke?pj.y

x ≠ y

Figure 4.21: Addressing extension for CFG branching

In order to exemplify the necessity for introducing additional parameters in the case of

a parallel composition and to clarify the general idea, we give an example. Figure 4.22

shows an extract of a possible control flow graph, for which we consider one operation

b, element of a valid cut. The CFG proceeds over an external choice, followed by a

parallel composition with bbeing synchronised and, finally, a two-sided external choice.

As boccurs multiple times in the cut, an addressing extension is required. Based on our

strategy, we introduce three additional parameters:

•

is responsible for ensuring that no false synchronisation with respect to the outer

external choice is possible, that is, b

must not be synchronised with any element of

{

. This is achieved by fixing p

to the value of

for the left branch and

to 2for the right branch.

•

is responsible for excluding a wrong synchronisation within the left inner external

choice, that is, between b2and b3.

•

forbids a synchronisation within the right inner external choice, that is, between

b4and b5.

•

Finally, p

and p

are indeed necessary to ensure that any two elements of

{

and {b4,b5}can still be synchronised.

90 4 Decomposition of a Specification

start

extch

par{b}

extch

b.1?p2?p3b.2.1?p3b.2.2?p3b.2?p2.1 b.2?p2.2

matches with any

do not match

active(p3)

p1 = 2

p2 = ?

p3 = 2

active(p1)

p1 = 1

p2 = ?

p3 = ?

active(p3)

p1 = 2

p2 = ?

p3 = 1

active(p2)

p1 = 2

p2 = 2

p3 = ?

active(p2)

p1 = 2

p2 = 1

p3 = ?

Figure 4.22: Addressing extension for nested branching

Having illustrated and exemplified our general strategy, we now give the details on the

addressing extension. Based on the criterion

all-or-none

, all occurrences of an operation

have to be assigned to one cut set, which we denote by Ci.

We define two conditions on a parameter extension and subsequently show that they

are sufficient to preserve the synchronisation structure of Swithin S

. Here, we omit

dealing with the original parameters of an operation op, since they are irrelevant for the

subsequent proof. Both conditions correspond to the previously identified different cases

for branching with and without a synchronisation of op.

In Definition 2.2.6, we introduced partial events. As the CSP part of a specification

may restrict the set of simple parameters of an operation, any occurrence of an operation

within the CSP part is a partial event. Subsequently,

opp

denotes an arbitrary partial event

for the channel op.

Definition 4.3.12. (Conditions for correct addressing extension)

Let

CFGS= (

,−→)

be the control flow graph of a specification S, and let

C= (C1,C2)

be a

cut. Furthermore, let op

∈

such that

occurs at least twice in either

. Let

opk

denote an arbitrary occurrence of the operation op within

CFGS

and

opk

its corresponding

occurrence within S

.main

. The address requirements for a correct synchronisation are given

by the following two conditions, which need to hold for any i 6=j:

4.3 Decomposing CSP-OZ Specifications 91

Branching without Synchronisation:

opi

and

opj

are located inside different branches

of either an external choice operator, internal choice operator, interleaving operator or

a parallel composition operator

parX

with op

6∈

opp

needs to comprise one parameter

such that its type includes x

∈N

with x

y. This parameter is fixed to x for

opi

and to y for opj

pin both, S1.main and S2.main :

opi

pbecomes opi

p.x and opj

pbecomes opj

p.y.

This corresponds to the left hand side of Figure 4.21.

Branching with Synchronisation:

opisd

L999K opj

, the (partial) event

opp

needs to com-

prise two parameters p

and p

, such that the type of p

includes x

∈N

and the type

of p

includes y

∈N

for arbitrary x

y. The first parameter is fixed to x for

opi

whereas

the second parameter is fixed to y for opj

pin both, S1.main and S2.main :

opi

pbecomes opi

p.x?p2and opj

pbecomes opj

p?p1.y.

This corresponds to the right hand side of Figure 4.21.

We give an intuitive description of these conditions. Example 4.3.11 illustrated that

two different occurrences of an operation can spuriously be synchronised over different

branches of an external choice operator. This problem can correspondingly occur for any

CSP operator, which introduces branching into the CFG. In order to prevent this from

happening, the first condition uses a parameter p

for the respective operation, which is

differently fixed in both branches. Thus, a wrong synchronisation is no longer possible,

as the extension sets of the partial events are now disjoint. If any two occurrences of the

same operation were not allowed to synchronise beforehand, our addressing extension

ensures an empty intersection of their extensions, not allowing for a synchronisation

afterwards.

Additionally, we have to ensure that a previous synchronisation is not excluded due

to our extension. Here, the second condition requires that for any parallel composition

including op, two additional parameters are introduced, which can subsequently be

restricted for their corresponding branch without influencing a synchronisation over both

branches.

In order to restore the original synchronisation structure of a specification by the

introduction of additional address parameters, we need to precisely state when two

occurrences of the same operation were previously allowed to synchronise. Beforehand,

we define a condition, stating that a certain synchronisation dependence can be realised

by means of the underlying CSP process: there indeed exist traces, leading to the joint

execution of both events. From now on, we let foot

(

)

denote the last element of the

CSP trace tr according to [Sch99].

Definition 4.3.13. (Realisation of synchronisation dependence)

Let op

∈

Op such that

opi

and

opj

, i

j, are two different occurrences of op within the CSP

part of S. Let

opi

and

opj

denote their corresponding nodes of

CFGS

such that

opisd

L999K opj

92 4 Decomposition of a Specification

For the CFG node

parX

being responsible for

opisd

L999K opj

, let P

and P

denote the CSP

processes corresponding to the first branch and the second branch of

parX

within

CFGS

respectively. If

∃tr1∈traces(P1),tr2∈traces(P2)•

(tr1X=tr2X)∧(foot(tr1) = opi

p)∧(foot(tr2) = opj

p),

we say that the synchronisation dependence connecting opi

pand opj

pcan be realised.

For two events to allow for synchronisation, their corresponding operation nodes of

the CFG must be connected via a synchronisation dependence which can be realised. In

addition, the intersection of the extension sets of the partial events corresponding to

these nodes is non-empty. All conditions combined ensure that

opi

and

opj

can indeed

synchronously be executed.

Definition 4.3.14. (Allowed synchronisation)

Let op

∈

Op such that

opi

and

opj

, i

j, are two different occurrences of op within the CSP

part of S. Let

opi

and

opj

denote their corresponding nodes of the CFG. We say that

opi

and

opj

pallow for synchronisation within S, if, and only if,

a) opisd

L999K opjwithin the CFG of S,

b) opisd

L999K opjcan be realised,

c) {| opi

p|} ∩ {| opj

p|} 6=∅.

Before proving the correctness of the conditions of the previous definition, we show

the following property: if two nodes x

yof are not located in different CFG branches

attached to the same node, they have to be connected by a CFG path.

Lemma 4.3.15. (Non-opposite branching requires CFG path)

Let

CFGS= (

,−→)

be the CFG of a specification S. For any node

cfop ∈

{extch,intch,par,interleave}

, let

fst(cfop)

denote one branch and

snd(cfop)

the other branch

of cfop, before reaching the join-node uncfop. For any n,n’ ∈cf(N), if

@cfop ∈ {extch,intch,par,interleave} •

(n∈fst(cfop) ∧n0∈snd(cfop))∨(n∈snd(cfop) ∧n0∈fst(cfop)),

either n∗

−→ n0or n0∗

−→ n.

Proof.

Let

cfop1

cfop2

denote the innermost operators with

being located inside one

of their respective branches. In case that a node is not located inside of any branching,

cfop1=cfop2=start. Thus, we do not separately need to deal with start.

Case 1: cfop1=cfop2

Based on the assumption,

and

have to be located in the same

branch of the operator. As we chose

cfopi

to be the innermost branching,

and

are both located on the sole path from

cfopi

or from

cfopi

, dependent on

which node is visited first.

4.3 Decomposing CSP-OZ Specifications 93

Case 2: cfop16=cfop2Based on the assumption, there is not outer operator cfopowith n

and

being located in different branches of

cfopo

. Therefore, for i

j, either

cfopi

terminates before

cfopj

, yielding a path from one node to the other one via

uncfopi

Otherwise,

cfopi

is located inside of

cfopj

, also yielding a CFG path from one node

to the other one. 2

The following theorem shows that the previously identified conditions on an addressing

extension are sufficient.

Theorem 4.3.16. (Definition 4.3.12 ensures correct synchronisation of S1and S2)

Let

CFGS= (

,−→)

be the control flow graph of a specification S, and let

C= (C1,C2)

a cut. For any op

∈

with multiple occurrence within the CFG and CSP part of S, let

both conditions of Definition 4.3.12 be satisfied. Then, the original horizontal synchroni-

sation structure of S is preserved within S

, whereas no additional synchronisation is

introduced. Precisely, for opi

p6=opj

(1) Possible synchronisation for duplicated nodes:

S1.opi

pand S2.opi

pallow for synchronisation in S1kS2.

(2) Original synchronisation is preserved within S1and S2:

If S

.opi

and S

.opj

allow for synchronisation in S, then S

1.opi

2.opi

] and S

1.opj

[S2.opj

p] allow for synchronisation in S1[S2].

(3) Original synchronisation is preserved within S1kS2:

If S

.opi

and S

.opj

allow for synchronisation in S, then S

1.opi

1.opj

] and S

2.opj

[S2.opi

p] allow for synchronisation in S1kS2.

(4) No additional synchronisation within S1:

If S

.opi

and S

.opj

do not allow for synchronisation in S, then S

1.opi

and S

1.opj

not allow for synchronisation in S1.2

(5) No additional synchronisation within S1kS2:

If S

.opi

and S

.opj

do not allow for synchronisation in S, then S

1.opi

2.opi

] and

S2.opj

p[S1.opj

p] do not allow for synchronisation in S1kS2.

Proof.

Assume that both conditions of Definition 4.3.12 hold. In case we refer to

opi

p,opj

we implicitly assume i

j. We show the respective properties by applying the conditions

from the definition:

(1)

1.opi

and S

2.opi

result from a duplication of S

.opi

. Let us denote the corresponding

CFG nodes within the CFG of S

opi

and

opi

. We have to show all three

conditions of Definition 4.3.14.

Note that both events might indeed allow for synchronisation within S

. This does not pose a problem as

in this case, a synchronisation over the cut would have to involve all four events S

1.opi

1.opj

2.opi

and S2.opj

pwhich is impossible if S1.opi

pand S1.opj

pcannot be synchronised.

94 4 Decomposition of a Specification

Starting from

parOpC

, there exist paths

parOpC

−→ opi

and

parOpC

π0

−→ opi

and

π0

do not share any additional nodes, as

parOpC

is the outermost operator of the

CFG for S

. This ensures the conditions on a synchronisation dependence, as

given in Definition 2.3.6. X

This dependence can be realised: for the traces tr and tr

corresponding to the

paths

and

π0

, the equation

trOpC=tr0OpC

holds. Traces restricted on the set

of cut operations are preserved by the projection of the CSP process S

.main

i.main

, as cut events occur in both, S

and S

, and as Definition 4.3.3 does not

modify the structure of a process. X

Additionally, since we refer to two nodes corresponding to the same node of

CFGS

and since the addressing extension is identical for both, S

1.main

and S

2.main

, the

inequality

{| S1.opi

p.add |} ∩ {| S2.opi

p.add |} 6=∅

trivially holds for any possible

addressing extension add.X

(2)

Assume that

opi

and

opj

allow for synchronisation in S. Again, we show all three

conditions for allowed synchronisation of Si.opi

pand Si.opj

By assumption,

opi

and

opj

are connected via a synchronisation dependence in S,

and both nodes are elements of

. Corresponding to the previous case, they are

still connected via a synchronisation dependence in S

and in S

, as Definition

4.3.3 does not modify the branching structure of a process. X

Let

parX

be responsible for the synchronisation dependence between

opi

and

opj

and let tr and tr

be the traces realising the dependence. Then,

tr

=tr0

X. As

both paths are correspondingly projected within Si.main, we get

(tr(Opi∪OpC))X= (tr0(Opi∪OpC))X.

Thus, the synchronisation dependence can be realised. X

Finally, the second condition on correct addressing results in

opi

being replaced

opi

and

opj

being replaced by

opj

yin both, S

and S

, for some

x,y∈N. This implies

{| opi

p.x.|} ∩ {| opj

p. .y|} 6=∅

based on the assumption

{| opi

p|} ∩ {| opj

p|} 6=∅.X

(3) Assume that opi

pand opj

pallow for synchronisation in S.

According to (1), we get two paths

and

π0

in the CFG of S

, which start

parOpC

and reach the respective occurrences of

opi

and

opj

without additional

shared nodes, thus yielding a synchronisation dependence. X

This dependence can be realised: the projection of S

.main

on Op

yields the

same traces within S1.main and S2.main.X

4.3 Decomposing CSP-OZ Specifications 95

c) Finally, in correspondence to the previous case,

{| opi

p.x.|} ∩ {| opj

p. .y|} 6=∅.X

(4)

Assume that

opi

and

opj

do not allow for synchronisation in Sdue to a violation of

conditions a), b) or c):

a):

In either case, a missing synchronisation dependence cannot be introduced due

to the projection. X

b):

Let

parX

be responsible for the synchronisation dependence between

opi

and

opj

Let P

and P

denote the CSP processes corresponding, to the first and second

branch of

parX

. Then, there are no traces tr

1∈

traces

(

and tr

2∈

traces

(

such that

tr1

=tr2

X. As op

∈

, the projection of the CSP process S

.main

on S

1.main

preserves the original traces with respect to X: no events of Op

can be involved, thus ensuring that the synchronisation dependence cannot be

realised within S1.main.X

c): {| opi

p|} ∩ {| opj

p|} =∅is preserved by the addressing extension. X

(5) Again assume that one of three conditions for allowed synchronisation is violated:

a): We distinguish between two cases:

Case 1:

Both nodes are located inside different branches of either an external

choice-, internal choice- or interleaving operator or a parallel composition

operator

parX

with op

6∈

X. The first condition on correct addressing results

opi

being replaced by

opi

xand

opj

being replaced by

opi

y,x

y, within

1.main

and S

2.main

. Thus, even though both nodes are possibly connected

via a newly added synchronisation dependence within the CFG of S

, the

events S

1.opi

xand S

2.opj

ydo not allow for synchronisation according to

Definition 4.3.14, since

{| opi

p.x|} ∩ {| opj

p.y|} =∅

holds. The same holds

for S1and S2switched.

Case 2:

The premise of case 1 does not hold. A parallel composition with op

being synchronised is impossible, as there is no synchronisation dependence

connecting both nodes. Thus, branching is ruled out. Based on Lemma

4.3.15, there exists a CFG path

starting in

opi

and reaching

opj

(opposite

direction accordingly). This path does not include any operation nodes

outside of

since otherwise, the cut would be left and re-entered, causing

a violation of the correctness criterion

no reaching back

. In particular, for

any two paths

parOpC

π1

−→ opi

and

parOpC

π2

−→ opj

, the traces tr,tr

and tr

corresponding to the paths

π1

and

π2

yield

tr1OpC6=tr2OpC

, as

opj

is an element of the latter but not the first trace. This violates that the

synchronisation dependence can be realised. The same holds for S

and S

switched. X

b):

Again, let

parX

be responsible for the synchronisation dependence between

opi

and

opj

. A violation of the possible realisation of a synchronisation dependence

96 4 Decomposition of a Specification

yields that there are no tr

1∈

traces

(

and tr

2∈

traces

(

such that

tr1

tr2

X. In particular, as op

∈(

C∩

)

, a synchronisation of op within S

would have to involve all four occurrences of op. However, according to (4,b.),

the projection of S

.main

preserves the traces with respect to Xup to reaching

the cut within S

1.main

. Thus,

opi

and

opj

are not allowed to synchronise within

. A diagonal synchronisation between

opi

and

opj

is impossible as well, as the

synchronisation dependence cannot be realised due to S1.X

c): A violation of Condition c) is trivially preserved within S1kS2.X2

Figure 4.23 illustrates the allowed and forbidden synchronisations due to the three

conditions of the lemma. A solid line depicts an allowed synchronisation, whereas a

dotted lines depicts the opposite.

opiopj

1. 1.

3. 3.

opiopj

5. 5.

1. 1.

Figure 4.23: Illustration of Theorem 4.3.16

Separating Operations Shared between Op1and Op2

Another aspect which we have to deal with tackles the fact that in general, Op

and Op

are not disjoint. This can lead to one operation being assigned to both, S

and S

. We

need to ensure that the projection of a CSP process correctly eliminates the subset of

occurrences of an operation which are no longer part of the respective component. A

projection, keeping the set of all occurrences, is generally insufficient:

Example 4.3.17.

Let S

.main :=

→

→Skip

and

C={

}

be a valid (single)

cut. Then, the first occurrence of a should be an element of S

1.main

whereas the second

one should be an element of S

2.main

. A projection of S

.main

{

}

would result in

S1.main =S2.main =S.main and is therefore infeasible.

4.3 Decomposing CSP-OZ Specifications 97

As Op

and Op

are not disjoint, we need to separate the occurrences of an operation

∈

1∩

within S

from the ones within S

. Corresponding to the previous

section, we will use one additional address parameter p

1:{1,2}

for any operation with

its occurrences distributed over Op

and Op

. The parameter is fixed to

for occurrences

within S1and accordingly fixed to 2for occurrences within S2.

For the event aof Example 4.3.17, we get

•S1.main := a.1→b→Skip and

•S2.main := b→a.2→Skip.

Defining the Sets of Events for S1and S2

Based on the additional parameters and their restrictions, the overall system definition

needs to be adapted. First, we observe the following:

•

For any op

6∈

, there exist one (if op

∈(

1∩

) or zero additional address

parameters. For simplification, we will denote this possible additional parameter by

[

]

denotes that the value of the parameter p

is set to v, if the parameter exists.

•

For op

∈

,any number of parameters is possible. However, for the set of cut

operations, all possible extensions of operations need to be represented in the

synchronisation alphabet. This is due to the correctness criterion

all-or-none

and

the fact that the respective addressing is identical for both, S1and S2.

Both observations allow for the following definition:

Definition 4.3.18. (Event sets of components)

Let

DGS= (

,−→DG)

be the control flow graph of a specification S, and let

C= (C1,C2)

a cut, yielding the four sets Op

and Op

, now possibly comprising additional

address parameters. The event sets for the decomposition of Sinto S

and S

are given by

E1:= Sop∈Op1{| op.[.1] |},E2:= Sop∈Op2{| op.[.2] |},

EC1:= {| OpC1|},EC2:= {| OpC2|}

where

"_"

denotes the original parameters of the channel. Let E

C:=

C1∪

, E

S1:=

1∪

and ES2:= E2∪EC.

The following lemma describes that all events shared between S

and S

are elements

of EC:

Lemma 4.3.19. (Common events of S1and S2solely occur in the cut)

Let E1,E2be defined according to Definition 4.3.18. Then:

E1∩E2=∅.

Proof.

Assume that there exists e

∈(

1∩

. Then, e

∈ {| op |}

holds for some

∈(

1∩

. Based on the addressing extension for shared operations, op is thus

extended by one address parameter of type

{1,2}

. Either this value is set to

implying

e6∈ E2or to 2implying e6∈ E1, contradiction. 2

98 4 Decomposition of a Specification

4.3.4 Renaming for the Decomposition

The previous section introduced additional parameters to operations of S

and S

, required

to ensure an equivalent data flow and control flow between Sand S

. These

parameters modify the original types of the channels of S. In our correctness proof, which

is given in Chapter 5, we thus show that Sand S

are equivalent modulo different

channel types. As we need to refer to the precise sets of events of a specification, we will

from now on write ESto denote the set of events of a specification S.

For describing the difference between ESand ESi, we introduce

•

a function f, mapping a channel of Son the corresponding channel within S

, now

comprising additional parameters and

•

two event renaming relations

S→

and

S→

, applied on the

process S.main, in order to determine S1.main and S2.main.3

We start with the function fmapping channels of Son channels of S

. It implicitly

defines a corresponding extension of the declaration parts of the Object-Z schemas,

now additionally containing transmission parameters.

According to the notation for

transmission parameters, let

op.add =add1:r1;. . . ;addk:rk

denote the set of address parameters of an operation op, and let

op.orig =p1d1:s1;. . . ;pldl:sl

with d

i∈ {?,!, }

(where



denotes the empty decoration used for simple parameters) the

set of original parameters of op, as defined within the interface of S:

Definition 4.3.20. (Renaming of channels)

Let S be a specification, and let

C= (C1,C2)

. The channel renaming for the decomposition

of Sinto S1and S2is given by

f(op : [op.orig]) = 









op : [op.orig;op.tr in1;op.add],op ∈OpC1,

op : [op.orig;op.tr in2;op.add],op ∈OpC2,

op : [op.orig;op.add],otherwise.

Note that, in the last case, op

add comprises zero or one address parameter whereas

in the other cases, the amount is indefinite. Further note that we never leave out any

original parameters, as the types of the shared operations have to coincide.

Note that in CSP-OZ, according to [

Fis00

], and in contrast to pure Z, renaming of CSP processes is not

restricted to functions – relations can be used as well.

As address parameters are not restricted by the Object-Z part, we omit them in the declaration parts of

Object-Z schemas.

4.3 Decomposing CSP-OZ Specifications 99

Next, we introduce two renaming relations, determining two processes, which are

subsequently used for the definition of S

1.main

and S

2.main

. For an operation op

∈

Op,

we let

op.tr in =tr1? : t1;. . . ;trn? : tn

denote the additional transmission parameters of an arbitrary operation. Moreover, let a

denote the possibly fixed value of the address parameter add

according to the restriction

of address parameters. The following event renaming is relational, as it maps an event on

aset of events. We simply write op

pto denote the set

{

. This notation is

motivated by the equivalence between op?p→Pand 2x:tpop.x→P.

Definition 4.3.21. (Renaming of events)

Let S be a specification, and let

C= (C1,C2)

. The (relational) event renaming for the

decomposition of Sinto S1and S2is given by

1:ES→ES1and RC

2:ES→ES2,

defined as

1(op.x) := 









op.x.1,op ∈(Op1∩Op2)\(OpC1∪OpC2),

op.x?tr1. . .?trn.a1. . . ak,op ∈OpC∧|l−1(op)|>1,

op.x?tr1. . .?trn,op ∈OpC∧|l−1(op)|= 1,

op.x,otherwise

and

2(op.x) := 









op.x.2,op ∈(Op1∩Op2)\(OpC1∪OpC2),

op.x?tr1. . .?trn.a1. . . ak,op ∈OpC∧|l−1(op)|>1,

op.x?tr1. . .?trn,op ∈OpC∧|l−1(op)|= 1,

op.x,otherwise.

Graphically explained, the renaming introduces additional transmission and address

parameters to the original events, if required. For operations not represented in the cut,

no transmission parameters are introduced. Shared operations of Op

and Op

receive

one address parameter fixed to

and

, respectively, whereas local operations to one

specification do not receive any additional parameters. For the cut, we introduce a

possibly empty set of transmission parameters. For the address parameters, we separate

operations with multiple occurrence in the cut from the ones with single occurrence: the

first operations receive additional address parameters, whereas the latter ones do not.

The previous definitions allow us to give the final definitions for the interfaces and CSP

parts of S

and S

. We start with a modification of Definition 4.3.2, which now takes the

channel renaming finto account:

Definition 4.3.22. (Interfaces of components, final definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. Let f be the channel renaming function according to Definition 4.3.20. The interfaces

for the decomposition of S into S1and S2are defined as

100 4 Decomposition of a Specification

•S1.I:= f(I)|(Op1∪OpC)and (Interface for S1)

•S2.I:= f(I)|(Op2∪OpC). (Interface for S2)

In order to modify the CSP parts of the components according to Definition 4.3.4, we

apply the event renaming on

main

. Note that the following holds for any renaming

relation R([Sch09]):

(e→P)JRK=e0:R(e)→PJRK.

Definition 4.3.23. (CSP parts of components, final definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. Let

and

be the event renaming relations according to Definition 4.3.21. The CSP

parts for the decomposition of S into S1and S2are defined as

•S1.main := (S.mainJRC

1K)|ES1and (CSP part for S1)

•S2.main := (S.mainJRC

2K)|ES2. (CSP part for S2)

In Figure 4.19, we implicitly modified the channel change m of Increaser after the

introduction of one transmission parameter. As address parameters are not required for

the decomposition, the specification’s decomposition is final.

Summarising the previous definition, we are now able to give the final definition for

the thorough decomposition of Sinto S1and S2.

4.3.5 Definition of the Decomposition

After ensuring a correct data flow within S

based on the introduction of additional

transmission parameters and ensuring a correct control flow based on additional ad-

dress parameters, we finally give the definition of the thorough decomposition of Sinto

components S1and S2by modifying Definition 4.3.8:

Definition 4.3.24. (Decomposition with respect to a cut, final definition)

Let

DGS= (

,−→DG)

be the dependence graph of a specification S, and let

C= (C1,C2)

be a

cut. Let

Op1,Op2,OpC1,OpC2,OpC

be defined according to Definition 4.3.1. The decomposition of Swith respect to

(C1,C2)

into S1and S2is defined as

S1.I [according to Definition 4.3.22]

S1.main [according to Definition 4.3.23]

S1.State [according to Definition 4.3.5]

S1.Init [according to Definition 4.3.6]

S1.op [according to Definition 4.3.10]

4.3 Decomposing CSP-OZ Specifications 101

S2.I [according to Definition 4.3.22]

S2.main [according to Definition 4.3.23]

S2.State [according to Definition 4.3.5]

S2.Init [according to Definition 4.3.6]

S2.op [according to Definition 4.3.10]

The system, generated from the components, is defined according to Definition 4.3.8

as the parallel composition of both classes, synchronising on the set of cut events:

S1kECS2.

For the remainder of this thesis, we let E

S0:=

S1∪

and Op

0:=

1∪

2∪

The following theorem states the main result of this thesis. The correctness proof will be

shifted to the next chapter.

Theorem 4.3.25. (Correctness of the decomposition)

Let S be a specification, and let

C= (C1,C2)

be a cut, yielding a decomposition into S

and

S2according to Definition 4.3.24. Then, the following holds:

S=T(S1||ECS2)JR0K,(4.1)

where R0:ES0→ESis defined as

R0(op.x.t1. . . tn.a1. . . ak) := op.x

with t

denoting the values for the possible transmission parameters of op and a

the values

for its possible address parameters.

Based on several lemmas and some additional prearrangements, the proof is given in

Chapter 5, Section 5.6. The next section illustrates the decomposition on our case study

of a candy machine. It is based on the single cut C:= {switch}.

4.3.6 Candy Machine Revisited: Decomposition

Recall the main case study of this thesis, the specification of a candy machine, as given in

Figure 2.3. We already identified the set

C:= {switch}

to be a valid single cut in Section

4.2.4.

First, the definition for Ph1,C1and Ph2yields

•Op1={pay,payout,abort},

•OpC={switch}and

•Op2={select,order,term,deliver}.

The projections of S.main on the remaining sets of events,

102 4 Decomposition of a Specification

•S1.main := S.main|{|pay,payout,abort,switch|} and

•S2.main := S.main|{|switch,select,order,term,deliver|},

lead to

CandyMachine1

[. . . ]

main c

=pay?coin →main 2Payout 2switch →Skip

Payout c

=payout?coin →Payout 2abort →Skip

[. . . ]

CandyMachine2

[. . . ]

main c

=Skip 2switch →Select

Select c

= (select?ca →(Select 2Order)) 2Deliver

Order c

=order →Select

Deliver c

=deliver?ca →Deliver 2term?rest →Skip

[. . . ]

after applying several simplifications. For the sets of state variables of CandyMachine1

and CandyMachine2, we get

•S1.V={sum,paid,credits}and

•S2.V={credits,items,selected}.

Vand S

Vdetermine the respective state schemas. The initial state schemas are given

S1.Init =∃selected :Candies,items :seqCandies •

(sum = 0 ∧paid =h i ∧ items =h i)

≡(sum = 0 ∧paid =h i)

and

S2.Init =∃sum :N,paid :seqCoins,credits :N•

(sum = 0 ∧paid =h i ∧ items =h i)

≡items =h i.

In order to determine the operation schemas of the components, we first need to

compute the set of cut variables with respect to

C1={switch}

. The operation schema

switch modifies three different variables, namely sum,credits and paid. However, only

one of them is subsequently referenced: credits. Based on the three data dependences by

reason of credits,

4.3 Decomposing CSP-OZ Specifications 103

•switch dd

999K(credits)select,

•switch dd

999K(credits)order and

•switch dd

999K(credits)term,

we get CV

1={

credits

}

. Therefore, switch needs to be extended by one additional

transmission parameter tr

c:N

. We are now able to define CandyMachine

switch and

CandyMachine2.switch:

CandyMachine1

[. . . ]

enable switch

sum ≥2

effect switch

∆(sum,credits,paid); trc! : N

sum0= 0 ∧paid0=h i

credits0=sum ∧trc! = credits0

CandyMachine2

[. . . ]

enable switch effect switch

∆(credits); trc? : N

credits0=trc?

As the sole cut operation switch only occurs once in the specification, no address

parameters are required. We remain to apply the renaming of the channel switch and all

of its occurrences within S

.main

, according to the introduction of the sole transmission

parameter. The final decomposition is depicted in Figures 4.24 and 4.25.

When dealing with the identification of reasonable decompositions, Chapter 6 intro-

duces a bigger case study, consisting of several classes and requiring address parameters

as well as transmission parameters.

4.3.7 Improvement of the Decomposition

Up to now, we defined a valid decomposition of a specification, based on a fragmentation

of its dependence graph. The given correctness criteria exclude invalid decompositions,

thus restricting the set of possible decompositions.

In Section 4.3.1, we defined a restriction of the initial state schema of Son the possible

initial valuations of the generated components S

and S

. The implementation of our

decomposition approach is based on this specific definition and needs to take any initial

104 4 Decomposition of a Specification

CandyMachine1

chan pay : [coin? : Coins]chan payout : [coin! : Coins]

chan abort chan switch : [trc! : N]

main c

=pay?coin →main 2Payout 2switch?trc→Skip

Payout c

=payout?coin →Payout 2abort →Skip

sum,credits :N

paid :seqCoins

Init

sum = 0

paid =h i

enable pay

sum + 2 ≤Max

enable payout

paid 6=hi

enable abort

paid =hi ∧ sum = 0

enable switch

sum ≥2

effect pay

∆(sum,paid)

coin? : Coins

sum0=sum +coin?

paid0=paid ahcoin?i

effect payout

∆(sum,paid)

coin! : Coins

sum0=sum −coin!∧paid0=tail paid

coin! = head paid

effect switch

∆(sum,credits,paid); trc! : N

sum0= 0 ∧paid0=h i

credits0=sum ∧trc! = credits0

Figure 4.24: Decomposition of the candy machine, first component

data dependence into account. The definition can, however, slightly by altered and

improved.

The specification CandyMachine comprises an initial state predicate items

=h i

, which

forms the source of three initial data dependences:

•init idd

999K(items)term, based on enable term = [items =h i],

•init idd

999K(items)deliver, based on (amongst others) enable term = [items 6=h i]and

•

init

idd

999K(items)

order, based on

effect

order comprising item

0= (

items

selected

We identified

{switch}

as a valid single cut in Sections 4.2.4 and 4.3.6 due to the fact

that all of these three initial data dependences do not violate the correctness criterion

no crossing

. The reason is as follows: the variable items is never modified or referenced

in any operation schema of Op

1∪

. In particular, items

6∈

V. Therefore, items

4.3 Decomposing CSP-OZ Specifications 105

CandyMachine2

chan switch : [trc? : N]chan select : [ca? : Candies]chan order

chan deliver : [ca! : Candies]chan term : [rest! : N]

main c

=Skip 2switch?trc→Select

Select c

= (select?ca →(Select 2Order)) 2Deliver

Order c

=order →Select

Deliver c

=deliver?ca →Deliver 2term?rest →Skip

credits :N

items :seqCandies

selected :Candies

Init

items =h i

enable order

credits ≥price(selected)

enable select

credits ≥1

enable deliver

items 6=hi

enable term

items =hi

effect switch

∆(credits)

trc? : N

credits0=trc?

effect order

∆(items,credits)

items0=items ahselectedi

credits0=credits −price(selected)

effect select

∆(selected)

ca? : Candies

selected0=ca?

effect deliver

∆(items)

ca! : Candies

items0=tail items

ca! = head items

effect term

∆(credits)

rest! : N

credits0= 0

rest! = credits

Figure 4.25: Decomposition of the candy machine, second component

does not influence the behaviour of S

at all. In this case, the respective initial state

predicate can completely be eliminated from S

1.Init

and the corresponding initial data

dependence can safely be neglected.

Indeed, this elimination of an initial data dependence is only possible for corresponding

predicates not being related to the variables of S

at all. These observations serve as the

basis for the following definitions.

First, when explicitly dealing with predicates within a CSP-OZ specification, we do not

refer to the single top-level predicate of an operation but rather to its atomic sub-predicates.

This is according to [

Brü08

]. For op

∈

Op, the set Atoms

(op)

depicts the set of all atomic

predicates such that the conjunction of all these predicates yields the predicate part of op.

We use the same notation for the initial state schema:

Vp∈Atoms(op.pred)p=op.pred and Vp∈Atoms(Init)p=Init.

106 4 Decomposition of a Specification

Next, we define an equivalence relation on S

Vand a closure set of a state variable with

respect to this relation. Let vars

(

)

denote the set of state variables, occurring in the

predicate p:

Definition 4.3.26. (Initial closure of state variables)

Let S be a specification. We define an equivalence relation Rover (S.V×S.V)by5

R:= {(x,y)| ∃ a∈Atoms(Init)•x,y∈vars(a)} ∪ IdS.V.

For any x

∈

V, the initial closure of x is inductively defined as the set InitClos

(

)

, satisfying

the following two conditions:

•x∈InitClos(x),

•y1∈InitClos(x)∧(y1,y2)∈R⇒y2∈InitClos(x).

relates any two state variables such that there exists an atomic predicate within

Init

containing both variables. The initial closure of a state variable xis the set of all

state variables, directly or indirectly influencing xwithin the initial state schema.

Example 4.3.27.

Let S be a specification, S

}

with all elements of type

, and

let S

.Init = (

>2) ∧(

)∧(

>5)

. Then,

R={(

),(

)} ∪ Id{x,y,z}

. This yields

InitClos(z) = {z}and InitClos(x) = InitClos(y) = {x,y}.

Now let S

.Init = (

)∧(

)

. Then,

R={(

),(

)} ∪ Id{x,y,z}

. This

yields InitClos(x) = InitClos(y) = InitClos(z) = {x,y,z}.

These considerations do not influence Definition 4.3.6. The correctness proof in Chapter

5 shows the following: we can safely neglect all initial data dependences originating from

an atomic predicate a, such that InitClos(x)⊆(S2.V\S1.V)for all x∈vars(a).

In our specific case, InitClos

(items) = {

items

}

and

{

items

} ⊆ (

)

holds. Thus,

the three previously identified initial data dependences originating from items

=h i

can

indeed be neglected, justifying the correctness of the cut

{switch}

. In particular, the

predicate items

=h i

is already removed from CandyMachine

2.Init

by applying our

definition for a decomposition and further simplifications on CandyMachine2.Init.

We pointed out an optimisation for the decomposition in the following sense: some data

dependences do not need to be considered when the correctness criterion

no crossing

is validated. Thus, a larger set of valid decompositions is possible.

4.4 Decomposition for the General Case: Number Swapper

We recall the small case study of a number swapper from Chapter 2 and slightly adapt it

as displayed in Figure 4.26: the specification swaps two natural numbers aand bwith a

initially possessing the value

and bcontinuously receiving a new value as an input. The

protocol starts by inputting the new value for b, subsequently swaps both numbers and

outputs the new value of b. As Swapper

.main

restarts, the specification does not allow

for the definition of a single cut.

5For any set X, we let IdXdenote the identity on X, that is, IdX:= {(x,x)|x∈X}.

4.4 Decomposition for the General Case: Number Swapper 107

Swapper

chan input : [in? : N]

chan store b,move a,move b

chan result : [out! : N]

main c

=input?in →store b →move a →move b →result?out →main

a,b,tmp :N

Init

a= 1

effect input

∆(b)

in? : N

b0=in?

effect store b

∆(tmp)

tmp0=b

effect move a

∆(b)

b0=a

effect move b

∆(a)

a0=tmp

effect result

out! : N

out! = b

Figure 4.26: CSP-OZ specification for swapping two numbers, extended

A valid (general) cut for this specification is given by

(C1,C2)

with

C1={store b}

and

C2={result}. The definition yields

•Op1={input},

•OpC1={store b},

•Op2={move a,move b}and

•OpC2={result}.

For the sets of state variables, we get

•S1.V={b,tmp}and

•S2.V={a,b,tmp}.

The initial state schemas are given by

S1.Init =∃a:N•(a= 1) ≡true,

S2.Init =∃b:N,tmp :N•(a= 1) ≡a= 1.

108 4 Decomposition of a Specification

Swapper1

chan input : [in? : N]chan store b : [trtmp! : N]chan result : [out! : N]

main c

=input?in →store b?trtmp →result?out →main

b,tmp :N

effect result

out! : N

effect store b

∆(tmp); trtmp! : N

tmp0=b∧trtmp! = tmp0

effect input

∆(b); in? : N

b0=in?

Figure 4.27: Decomposition of the number swapper, first component

Swapper2

chan store b : [trtmp? : N]chan move a,move b chan result : [out! : N]

main c

=store b?trtmp →move a →move b →result?out →main

a,b,tmp :N

Init

a= 1

effect store b

∆(tmp); trtmp? : N

tmp0=trtmp?

effect move a

∆(b)

b0=a

effect move b

∆(a)

a0=tmp

effect result

out! : N

out! = b

Figure 4.28: Decomposition of the number swapper, second component

4.5 Related Work 109

As InitClos

(

) = {

}

and

{

} ⊆ (

)

, the initial data dependence

init idd

999K(a)

move a

is not cut-crossing. Based on the data dependence

store b dd

999K(tmp)move b

, we

get CV

1={

tmp

}

, necessitating one transmission parameter tr

tmp

. As the operation result

does not modify any state variable, CV

2=∅

holds. No addressing extension is required,

thus leading to the final decomposition as given in Figures 4.27 and 4.28.

The correctness property on the specification as described in Figure 4.29 models that

the value received by input corresponds to the output value of result in the next iteration

of the protocol. Model checking this property with

FDR2

yields its validity for Swapper as

well as Swapper1k{|store b,result|} Swapper2.

Prop =2j∈N(input.j→result.1→P(j))

P(j) = 2k∈N(input.k→result.j→P(k))

Figure 4.29: Correctness requirement for Swapper

4.5 Related Work

The technique proposed in this chapter targets the manual decomposition of a given spec-

ification into two components. These subsystems are used in a compositional verification

framework which is based on two assume-guarantee proof rules. The approach is closely

related to several works, with some of them described next.

The dependence analysis, as given in Section 2.3, is based upon the methodology by

Brückner [

Brü08

] for slicing CSP-OZ specifications. Besides applying a similar analysis of

a specification, slicing does not decompose a given specification but rather eliminates

irrelevant parts from it. These irrelevant specification elements depend on a certain

property under interest, the slicing criterion. A correct decomposition in our context is

independent of the verification properties. The decomposition approach is more closely

related to program chopping [

RR95

]: chopping is likewise based on the analysis of a

(program) dependence graph and tries to identify program points affecting a certain

target node based on a specific source node.

Several works in the context of formal specifications present techniques for decom-

posing a given system into several components. Recently, Butler [

But09

] sketched a

technique for composing Event-B models and decomposing them into sub-models. Here,

events can be split, without allowing common variables to different machines. Similar to

our approach dealing with transmission parameters, shared parameters are used to pass

the influence of one to another machine. The technique is not applied in the context of

compositional verification, but rather in the scope of model refinements. In the context

of CSP||B and for separate checking of divergence freedom of a model, Evans, Schneider

and Treharne [

STE05

] developed a methodology to decompose CSP||B specifications

110 4 Decomposition of a Specification

into smaller subsystems, called chunks. They can consist of a set of CSP processes or

contain B machines as well. The decomposition is conducted by examining the existing

subsystems and parallel components of a CSP||B specification.

The technique closest to ours is the one by Alur and Nam [

NA06

AMN05

Nam07

]

dealing with assume-guarantee-based reasoning in the context of symbolic model check-

ing. Using symbolic transition systems (STS) as the semantic model, the authors fully

automatically decompose and verify a system. A decomposition of a STS yields a set of

symbolic modules, now comprising additional boolean input- and output variables which

are similar to our transmission parameters. The choice of the decomposition is carried out

by an automatic partitioning of the set of boolean variables of the STS and it is based on

an equal distribution of the set of variables along with a minimisation of required inputs

and outputs. The approach is also based on the L

∗

algorithm, using a generalised version

of rule

(B-AGR)

in the validation process. In their semantic domain solely dealing with

boolean variables, the authors do not incorporate a dependence analysis based on data

flow and control flow, and they do not tackle communication and synchronisation aspects

of a specification. The decomposition is based on one particular heuristic which does not

take the alphabet size of the assumption into account. As the decomposition is performed

automatically, it is impossible to lead the framework to a superior decomposition by hand

which does not satisfy the constraints for an equal distribution and minimisation.

Another related work discusses the usefulness of assume-guarantee reasoning. The

authors investigate the possible decompositions of a program specified as a labelled

transition system, based on several case studies and model checkers [

CAC06

]. The results

show that assume-guarantee reasoning outperforms monolithic verification in only a few

cases. Two conclusions can be drawn from this work: assume-guarantee reasoning is

not in general more effective than direct model checking. Moreover, its effectiveness

highly depends on the choice of the decomposition. The authors state that analysts need

some guidance to identify those decompositions which are indeed less time- and memory

consuming. Chapter 6 will provide some theory on how this can be achieved.

Beforehand, the next chapter will show correctness of our approach by particularly

proving Theorem 4.3.25.

5Correctness of the Decomposition

Contents

5.1 Ensuring Correct Synchronisation . . . . . . . . . . . . . . . . . . . 113

5.2 Correctness for the CSP Part . . . . . . . . . . . . . . . . . . . . . . . 119

5.2.1 Properties of the Decomposition: CSP Part . . . . . . . . . . . . 119

5.2.2 Correctness of the Decomposition: CSP part . . . . . . . . . . . 132

5.3 Correctness for the Object-Z Part . . . . . . . . . . . . . . . . . . . 138

5.3.1 Properties of the Decomposition: Object-Z Part . . . . . . . . . 140

5.3.2 Correctness of the Decomposition: Object-Z part . . . . . . . . 146

5.4 Correctness of the Renaming for the Decomposition . . . . . . . . . 159

5.5 CSP Laws for Parallel Composition . . . . . . . . . . . . . . . . . . . 164

5.6 Proof of the Main Theorem . . . . . . . . . . . . . . . . . . . . . . . 166

The previous chapter introduced a technique on how to decompose a given CSP-OZ

specification into two components, based on an analysis of the specification’s dependence

graph. Theorem 4.3.25 states the main result of this thesis: in our semantic domain of

the CSP traces model, the original specification and its decomposition are trace-equivalent.

The result is essential and ensures the following: for a property P, specified as a CSP

process,

(PvTS)⇔(P0vT(S1kECS2)).

Here, we need to refer to a process P

, resulting from the process Pafter a renaming

with respect to the set of all additional parameters. Recall that S

and S

already

comprise transmission parameters and address parameters according to Section 4.3.4.

0vT(

can be deduced from A

and P

0vT(

within the compositional

learning framework, introduced in Chapter 3. Thus, correctness of the compositional

proof rules

(B-AGR)

and

(P-AGR)

along with Theorem 4.3.25 yield the overall correctness

of our approach.

Correctness of

(B-AGR)

and

(P-AGR)

were already shown in Chapter 3. The verification

of Theorem 4.3.25 will be carried out in the present chapter. The main strategy for

the proof uses the compositional semantics of CSP-OZ specifications in terms of CSP

according to Figure 2.7: the traces of a CSP-OZ specification Sare given by

traces(S.mainkESS.OZ).

Figure 5.1 illustrates the individual proof steps. Precisely, we show:

112 5 Correctness of the Decomposition

S.main S.OZ

S1||

S .main

1S .main

2S .OZ

1S .OZ

[|R'|]

( ) ( )

S .main

1S .main

2S .OZ

1S .OZ

(( ) ( ))

S .main

1S .main

S .OZ

1S .OZ

)(

(Definition of S)

(Correctness

for CSP part:

Section 5.2)

(Distributivity of inverse renaming: Section 5.4)

( Swapping of CSP processes:

Section 5.5)

(Definition of S and S )

1 2

(Correctness

for Object-Z part:

Section 5.3)

[|R'|]

))

((

( [|R'|]

)

Figure 5.1: Illustration of the steps of the correctness proof

Correctness for the CSP Part, Section 5.2:

Based on the compositional semantics of

CSP-OZ, S

=T(

.main kES

)

holds. In order to refer to the individual parts of

the components S

, we first need to decompose the CSP part and show that the

original CSP part is trace equivalent to its decomposition modulo the (inverse)

renaming relation, that is,

S.main =T(S1.main kECS2.main)JR0K.

Correctness for the OZ Part, Section 5.3:

Accordingly, we have to show correctness for

5.1 Ensuring Correct Synchronisation 113

the decomposition of the Object-Z part. However,

S.OZ =T(S1.OZ kECS2.OZ)JR0K

does not hold in general: traces of the Object-Z part alone do not adhere to the

CSP part. We need to take the orderings of events with respect to the CSP part into

account and show S

=T(S1.OZ kECS2.OZ)JR0K

for the set of traces conforming to

the CSP part.

Distributivity of Inverse Renaming, Section 5.4:

After showing the individual correct-

ness of both decompositions, we have to distribute the inverse renaming relation

over the parallel composition ES. Thus, we show

(S1.main kECS2.main)JR0K]kES(S1.OZ kECS2.OZ)JR0K=T

((S1.main kECS2.main)kES0(S1.OZ kECS2.OZ))JR0K.

Redistribution of CSP Processes, Section 5.5:

Now being able to refer to S

i.main

and

OZ without the need for considering the renaming, we have to swap S

2.main

and S

OZ to step from the parallel composition of the CSP parts and Object-Z parts

to the parallel composition of the components S1and S2. We show

(S1.main kECS2.main)kES0(S1.OZ kECS2.OZ) =T

(S1.main kES1S1.OZ)kEC(S2.main kES2S2.OZ),

which subsequently leads to the overall conclusion, as S

i=T(

i.main kESi

)

holds.

Before getting under way with the individual proof steps, Section 5.1 presents an

algorithm, which satisfies the requirements for correct addressing. Afterwards, we show

correctness of the decomposition of the CSP part and the Object-Z part in Sections 5.2 and

5.3, respectively. The correctness for the distributivity of the inverse renaming is given in

Section 5.4, followed by a lemma, stating the possible redistribution of CSP processes

within a context-specific parallel composition in Section 5.5. The chapter concludes with

the proof of Theorem 4.3.25, now joining together all the individual proof steps.

5.1 Ensuring Correct Synchronisation

In order to ensure an equivalent control flow of the original specification and its de-

composition, Section 4.3.3 introduced the concept of address parameters. In particular,

Definition 4.3.12 presented two conditions on these additional parameters and Theorem

4.3.16 showed that they are sufficient to preserve the original control flow.

In this section, we define an algorithm, realising both conditions of Definition 4.3.12.

The algorithm was successfully implemented in Java as part of a diploma thesis [

Her09

]

focusing on the integration of the decomposition approach into Syspect [

Sys06

], a graph-

ical modelling environment for CSP-OZ. In this thesis, the algorithm will be presented in

pseudo code.

114 5 Correctness of the Decomposition

The root procedure inputs the control flow graph of a specification Salong with the set

of operations Op

0:=

1∪

2∪

. It computes the modified interfaces S

Iand CSP

processes Si.main, according to Definition 4.3.22 and Definition 4.3.23, respectively.

For

CFGS= (

,−→)

being the CFG of the specification under interest, let

denote an

arbitrary node of the CFG and, in case that

introduces branching,

unn

its corresponding

join node. For any op

∈

Op, we do not denote the original type, but solely refer to the

additional address parameters.

procedure ADDRESSMAIN(CFGS,Op0)

for each (op ∈(Op1∩Op2)\OpC)











op ←op : [p1:{1,2}]for the definition of Si.I

if (opi∈(Ph1∪Ph3)) do

opi

p←opi

p.1for the definition of S1.main

if (opj∈Ph2)do

opj

p←opj

p.2for the definition of S2.main

for each (op ∈OpC1such that l−1(op)>1) do ADDRESSCUT(op,C1)

for each (op ∈OpC2such that l−1(op)>1) do ADDRESSCUT(op,C2)

Figure 5.2: Algorithm for the address extension: procedure ADDRESSMAIN

The algorithm comprises four different procedures. The root procedure ADDRESSMAIN

is given in Figure 5.2. It first processes over all shared operations of S

and S

, which are

not located in a cut set. Their corresponding occurrences need to be separated, and they

are addressed by one parameter, according to Section 4.3.3.

procedure ADDRESSCUT(op,Ci)

global Decl(op)← {p1:{1}}

global Val(op)←∅

comment: ADD modifies Decl(op)and Val(op)

ADD(start,op,hp1= 1i,Ci,false)

MODIFYCUT(op,Decl(op),Val(op))

Figure 5.3: Algorithm for the address extension: procedure ADDRESSCUT

The procedure ADDRESSCUT, depicted in Figure 5.3, is successively called for all opera-

tions op with multiple occurrence in either

. For each operation, ADDRESSCUT

holds two global lists:

•

Decl

(op)

comprises the set of additional address parameters of op with their corre-

sponding types. Initially, Decl

(op)

holds one parameter of type

{1}

. The set is used

5.1 Ensuring Correct Synchronisation 115

for the definition of the interfaces Si.I.

•

Val

(op)

contains a set of tuples

(opj

values

)

, where values is a sequence of valuations

with v

, denoting the restriction of the address parameter of p

for the specific

occurrence

opj

of op within S

.main

. Initially, the set is empty. Val

(op)

is used to

define the renaming of Si.main.

ADDRESSCUT calls the core procedure ADD, which recursively traverses the CFG and

modifies the global variables Decl

(op)

and Val

(op)

. This procedure will be explained

below.

procedure MODIFYCUT(op,Decl(op),Val(op))

let {p1:t1,...,pk:tk}=Decl(op)in

op ←op : [p1:t1;. . . ;pk:tk]for the definition of S1.Iand S2.I

for each (opj

p,values)∈Val(op)do

let (if (hpi=wiiinvalues)then vi=wielse vi=?pi)in

opj

p←opj

p.v1.....vkfor the definition of S1.main and S2.main

Figure 5.4: Algorithm for the address extension: procedure MODIFYCUT

After the procedure ADD terminated, ADDRESSCUT calls a procedure MODIFYCUT

(Figure 5.4) which inputs the respective operation and both sets, Decl

(op)

and Val

(op)

MODIFYCUT carries out the actual modification of S

Iand the renaming of S

.main

according to the results of ADD. In particular, the interfaces S

Iare modified based on

the parameter declarations within Decl

(op)

. Each occurrence

opj

of op within S

.main

modified with respect to the tuple

(opj

values

)

. Here, address parameters p

are either

restricted by p

or remain unrestricted, if values does not comprise a restriction on

pi.

Finally, the core procedure ADD, as shown in Figure 5.5, proceeds as follows. It

traverses the CFG and inputs five parameters.

•

The first parameter

denotes the current node visited by the procedure. For the

initial call of ADD, this node is the unique start-node of the CFG.

•The second parameter op denotes the operation under interest.

•

As ADD keeps track of all parameter valuations a subsequent occurrence of op

needs to adhere to, the third parameter comprises the current restrictions for

the address parameters. Initially, according to the singleton of initial parameters,

values

1= 1i

. Corresponding to the explanations of Section 4.3.3, the last

element of values denotes the currently active parameter and its actual restriction.

•Parameter four identifies the cut set, corresponding to the occurrence of op.

116 5 Correctness of the Decomposition

procedure ADD(n,op,values,CS,cutVisited)

case (n=termi.X∧succ(termi.X)=∅)∨n=stopithen exit

case n∈ {skipi,seqi,calli.X,ret.X} ∨ (n=termi.X∧succ(termi.X)6=∅)

then ADD(succ(n),op,values,CS,cutVisited)

case n=start.Pthen

if (start.Palready visited)then exit

else ADD(succ(n),op,values,CS,cutVisited)

case n∈op(N)

then











if (n6∈ CS and cutVisited =false)

then ADD(succ(n),op,values,CS,cutVisited)

if (n6∈ CS and cutVisited =true)then exit

if (n∈CS)

then 









if (@i•n=opi)

then ADD(succ(n),op,values,CS,true)

else Val(op)←Val(op)∪ {(opi

p,values)}

ADD(succ(n),op,values,CS,true)

case ((n=pari

X∧op 6∈ X)∨(n∈ {extchi,intchi,interleavei}))

then











if (CS =Cc∧unniis located behind or inside of Cc)

then let last values =hpk=jiin











Decl(op)←(Decl(op)\ {pk:{1,...,l}} ∪ {pk:{1,...,l+ 1}})

comment: Note that j≤lbut not necessarily j=l.

ADD(succ one(n),op,values,CS,cutVisited)

ADD(succ two(n),op,(front values)ahpk=l+ 1i,CS,cutVisited)

else ADD(unni,op,values,CS,cutVisited)

case (n=pari

X∧op ∈X)

then











if (CS =Cc∧unpari

Xis located behind or inside of Cc)

then let {p1:t1,...,pk:tk}=Decl(op)in











Decl(op)←Decl(op)∪ {pk+1 :{1},pk+2 :{1}}

ADD(succ one(n),op,values ahpk+1 = 1i,CS,cutVisited)

ADD(succ two(n),op,values ahpk+2 = 1i,CS,cutVisited)

else ADD(unpari,op,values,CS,cutVisited)

case (n=uncfopi)

then if (uncfopialready visited)then exit

else ADD(succ(n),op,values,CS,cutVisited)

Figure 5.5: Algorithm for the address extension: procedure ADD

5.1 Ensuring Correct Synchronisation 117

•

Finally, a fifth parameter, initially assigned to false, specifies if ADD has already

reached the respective cut set.

The general idea of ADD is to carry over and realise the requirements on a correct

addressing from Definition 4.3.12. The procedure recursively traverses the CFG. As

already explained, ADD has side effects on the global variables Decl

(op)

and Val

(op)

: it

continuously adds address parameters (in case of parallel composition with op being

synchronised) and modifies their values (in case of any other branching).

Precisely, in case of

not having any successor node, the procedure stops. If

an element of

{skipi,seqi,calli.

,ret.

,termi.

}

with the latter node being followed by a

ret-node, the procedure is recursively called for the sole successor node.

Termination of the algorithm is achieved by the fact that

n=start.

Ponly leads to a

recursive call if

start.

Pwas not already visited before. Otherwise, the respective call of

ADD terminates. Note that for simplification, our pseudo code-algorithm does not explicitly

keep track of the already visited nodes. This can obviously be achieved by adding a global

variable.

Next, if

is an operation node of the CFG, a case differentiation is required: if

does not correspond to an operation of the cut set, the procedure either continues (if

the traversal did not reach the cut set yet) or terminates (in the opposite case, as this

signalises that the cut set is left). Accordingly, if

does not represent an occurrence of the

operation under interest, the procedure is called for its successor node. In the final case

n=opi

for some i, the current tuple

(opi

values

)

is stored in Val

(op)

. This assignment

signalises the modification of opi

pwithin the procedure MODIFYCUT.

The first core case of the procedure handles the case of branching without synchronisa-

tion of op. Here, the type of the currently active parameter p

is modified according to

the first case of Definition 4.3.12. Precisely, it is extended by one additional value within

Decl

(op)

. Additionally, the restriction of p

within one branch is preserved, whereas it

is assigned with the new value within the other branch. An additional

-clause ensures

that the branching indeed reaches the cut set under interest and does not terminate

beforehand. Otherwise, the procedure simply steps over the branching.

In the second core case, the algorithm deals with parallel composition with op being

synchronised. According to the second case of Definition 4.3.12, we introduce two

additional address parameters, with one of them restricted for the first and the other one

for the second branch. This is carried out in this specific case of the procedure: Decl

(op)

is extended by two additional parameters of initial type

{1}

, whereas Val

(op)

is extended

by two additional tuples, denoting the initial restrictions for the first and second branch,

respectively. The procedure is recursively called for both branches. Again we use an

if-clause to prevent proceeding of branching, terminating before the cut set.

The final case deals with joining of branching. Here, we again simply proceed with the

node’s successor. However, as a join node has two incoming edges, we need to ensure

that we only proceed once with the node’s sole successor.

We will now substantiate the termination and correctness of the algorithm.

Proposition 5.1.1. (Termination of ADDRESSMAIN)

The algorithm ADDRESSMAIN terminates for any control flow graph.

118 5 Correctness of the Decomposition

Proof (Sketch).

Obviously, we solely need to show termination of ADD. Let

be a path

of the CFG of an arbitrary specification. We distinguish two cases:

1. π

is a finite path. In accordance to the definition of the CFG, the final node of the

path is either

termi.

Xor

stopi

. However, in both cases, ADD terminates, according

to the first case.

2. π

is an infinite path. Thus, the path must contain a cycle„ since the CFG’s set of

nodes is finite. According to the definition of the CFG and our explanations from

Section 2.3.2, the sole possibility for cycles are combinations of

call.

and

start.

for some process P. However, in case the algorithm visits

start.

Pfor the second time,

it again terminates. 2

Proposition 5.1.2. (Correctness of ADDRESSMAIN)

The algorithm ADDRESSMAIN satisfies both conditions of Definition 4.3.12.

Proof (Sketch). We recall both conditions from Definition 4.3.12.

Branching without Synchronisation:

opi

and

opj

are located inside different branches

of either an external choice operator, internal choice operator, interleaving operator or

a parallel composition operator

parX

with op

6∈

opp

needs to comprise one parameter

, such that its type includes x

∈N

with x

y. This parameter is fixed to x for

opi

and to y for opj

pin both, S1.main and S2.main :

opi

pbecomes opi

p.x and opj

pbecomes opj

p.y.

Let

opi

and

opj

be two according nodes. Consider the first of the two core cases of

ADD: it applies for

opi

and

opj

and thus,

opi

and

opj

will be addressed according to

this case. The addressing sets the value of the parameter p

to the value lin one

and to the value l

+ 1

in the other branch. Any further branching preserves the

inequality of both values. Thus, pksatisfies the first condition of the definition.

Branching with Synchronisation:

opisd

L999K opj

, the (partial) event

opp

needs to com-

prise two parameters p

and p

, such that the type of p

includes x

∈N

and the type of

includes y

∈N

for arbitrary x

y. The first parameter is fixed to x for

opi

, whereas

the second parameter is fixed to y for opj

pin both, S1.main and S2.main :

opi

pbecomes opi

p.x?p2and opj

pbecomes opj

p?p1.y.

Let

opi

and

opj

be two according nodes. Consider the second of the two core

cases of ADD:

opi

and

opj

will be addressed according to this case as both nodes

are located in different branches of a parallel composition

pari

with op

∈

X. Two

additional parameters p

k+1,

k+2

are introduced, with one of them fixed for

opi

and

the other one fixed for

opj

(initially by

and possibly modified later on). Therefore,

the second condition of the definition is satisfied as well. 2

This completes the definition of the algorithm and the motivation for its termination

and correctness. The following sections carry out the individual steps of the proof of

Theorem 4.3.25.

5.2 Correctness for the CSP Part 119

5.2 Correctness for the CSP Part

The operational semantics of CSP-OZ allows for a compositional proof of Theorem 4.3.25

in the following sense: we show that the individual decompositions of the CSP part

.main

and the Object-Z part S

OZ are semantics-preserving in the domain of the CSP

traces model. Subsequently, and by using some additional properties, we combine both

results to deduce the overall correctness of the decomposition.

For both, the CSP part and the Object-Z part, we will show semantic equivalence

modulo renaming. This means, that we relate the original events from ESto events from

ES0, now possibly comprising transmission parameters and address parameters.

In this section, the correctness proof of the CSP part is conducted. We have to show

S.main =T(S1.main kECS2.main)JR0K,

that is, the proof will show the equivalence of both CSP processes, factoring out the

different parameter extensions.

At first sight, this particular proof step seems to be rather

easy, as the CSP process S.main is one-to-one reflected in the CFG of a specification.

However, as a first obstacle, the set of traces of S

.main

does not correspond to the set

of paths of the CFG: in general, the first set is strictly larger due to possible interleaving.

This complicates the proof, as reasoning with respect to the specification’s CFG becomes

impractical.

Another difficulty arises from the projection of CSP processes and traces according to

Definitions 4.3.3 and 2.2.8, respectively. Unfortunately, their definitions do not satisfy the

law

traces(P|X) = traces(P)X

when we are dealing with parallel composition of processes. As we need to bridge the

gap between both definitions, this particularly complicates dealing with this individual

operator.

Before carrying out the actual correctness proof of the decomposition of the CSP part,

we start with some related properties.

5.2.1 Properties of the Decomposition: CSP Part

Showing correctness of the decomposition of the CSP part requires several properties,

which the actual correctness proof uses. They are given next.

Disallowed Distribution of Initial Branching Events

A first property describes that in case of branching within the CFG, the initial events (see

Definition 2.2.9) of both branches are never distributed over E1and E2, that is, over the

sets of local events for the components:

1We explicitly deal with the renaming relation in Section 5.4.

120 5 Correctness of the Decomposition

Lemma 5.2.1. (No distribution of initial events)

For

◦∈{2,u,kS,k| }

, let P

1◦

be a process, occurring within S

.main

. Then, for

any valid decomposition of S according to Definition 4.3.24:

(initials(Q1)∩Ei)6=∅⇒(initials(Q2)∩Ej) = ∅,

for i 6=j, and vice versa.

Proof.

Without loss of generality, assume that e

1∈(

initials

(Q1)∩

and that there exists

some e

2∈(

initials

(Q2)∩

, yielding

e2∈Ph2

for the corresponding DG node. Based on

the definition for Ph1and e1∈E1, there exists a path π, such that

start π

−→ e1

and

π∩C1=∅

. Obviously, any prefix of this path does not intersect with

as well. Let

π0

denote the prefix, leading from

start

to the binary operator

◦

. As e

2∈

initials

(Q2)

, the

path π0can be extended to a path π2not comprising any additional nodes from op(N):

start π2

−→ e2corresponding to start π0

−→ cfop •

−→ e2,

and

π2∩C1=∅

. We deduce that

e2∈(Ph1∩Ph2)

, contradicting the correctness

criterion disjointness for a valid cut. 2

The lemma basically states that a branching introduced within a certain phase yields

that all initial events of both branches are represented in this specific phase or the

subsequent cut set. Figure 5.6 shows one instance of a disallowed distribution of initial

events. Here, ◦=extch, and the violation occurs with respect to the first cut set.

Ph1

Ph2

extch

Figure 5.6: Illustration of a violation of

Lemma 5.2.1

Ph1

Ph2

Figure 5.7: Illustration of a violation of

Lemma 5.2.2

Disallowed Split of Synchronisation

A rather obvious property is the following: in case that two operation nodes are connected

by a synchronisation dependence, they must not be distributed over different elements of

{(Ph1∪Ph3),C1,Ph2,C2}:

5.2 Correctness for the CSP Part 121

Lemma 5.2.2. (No split of synchronisation)

Let CFGS= (N,−→)be the control flow graph of a specification S, and let (C1,C2)be a cut.

Let D={(Ph1∪Ph3),C1,Ph2,C2}. Then:

nsd

L999K n’ ⇒(∀M∈ D • n∈M⇔n’ ∈M)

Proof.

and

n’

are connected by a synchronisation dependence, both nodes have the

same operation name: l

−1(n) =

−1(n’)

holds. The correctness criterion

all-or-none

rules

out that both nodes are either distributed over both cut sets or over one cut set and one

phase. We remain to show that both nodes must not be distributed over

(Ph1∪Ph3)

and

Ph2

. However, if this was the case, the connecting synchronisation dependence would

violate no crossing.2

A possible violation of the lemma, with two synchronised nodes distributed over

Ph1

and Ph2, is illustrated in Figure 5.7.

Redistribution of Processes for Binary Operators

Next, we show a property which we will use throughout the actual proof. The property

states that we can redistribute the component processes with respect to the parallel

composition

kEC

and all binary operators, that is,

◦ ∈ {2,u,o

9,kS,k| }

. Precisely, for

= (

◦

)

|ESi

and U

|ESi

, Figure 5.8 illustrates our proof strategy for

.main

being composed of two processes. The top-down-equivalence will be shown in

the following lemma.

P1P2

(T U )

2 2

(T U )

1 1

(T U)

(U U )

1 2

(T T )

1 2 ||

(Lemma

5.2.3)

Figure 5.8: Illustration of the CSP correctness proof of binary operators

The subsequent lemma uses the LTS semantics of CSP according to Definition 2.2.11.

Here, we will refer to the firing rules or CSP [

Ros98

], which determine the set of possible

transitions and thus the labelled transition system of a process. In addition to the set of

possible events a process may perform, we need to deal with

-transitions, symbolising

invisible events.

In our semantic domain of the CSP traces model, we apply several simplifications: first

of all and according to [

Brü08

], we do not distinguish between the processes

Stop

and

Div

. This is justified by the fact that both processes are incapable of performing any

event, and they are thus trace equivalent. Furthermore, we do not consider the special

122 5 Correctness of the Decomposition

event

, signalising termination of a process. As a consequence, we do not separate

the processes

Skip

and

Stop

. The LTS semantics makes use of an additional symbol

Ω

denoting the end state of the transition system. Here, we do not separately deal with this

symbol and rather refer to the corresponding process

Stop

. These considerations allow

us to simplify and restrict some of the CSP firing rules.

Lemma 5.2.3. (Redistribution of CSP processes within the decomposition)

Let P = (T◦U)for ◦∈{2,u,o

9,k| ,kS}be a reachable state of the LTS of S.main. Then,

(T1kECT2)◦(U1kECU2) =T(T1◦U1)kEC(T2◦U2)

for ◦ 6=kSand

(T1kECT2)kS(U1kECU2) =T(T1kS∩ES1U1)kEC(T2kS∩ES2U2),

where Ti=T|ESiand Ui=U|ESi, i ∈ {1,2}.

Proof.

As we are interested in trace equivalence, external choice and internal choice can

equally be treated. Moreover, being a special case of parallel composition with an empty

synchronisation alphabet, we do not explicitly need to deal with interleaving.

The method of proof, which we choose here, is (weak) bisimilarity [Mil89]: if we can

show that the labelled transition systems of the left hand side and the right hand side

of the equation are bisimilar, we can deduce their trace equivalence [

Pnu85

]. In the

following, let op.x.t.aindicate an event of ES0with the valuations for

•the original parameters according to x,

•the transmission parameters according to tand

•the address parameters according to a.

Subject to the individual operator we refer to, we define a weak bisimulation

R={(A,B)|A= (C1kECC2)◦(D1kECD2),B= (C1◦D1)kEC(C2◦D2)}∪R0,

and we show that

(

1kEC

2)◦(

1kEC

and

(

1◦

1)kEC(

2◦

are the initial

states of

. Here, C

i∈

CSP

i∈

CSP

) denotes any reachable state within the labelled

transition system of Ti(Ui), and R0denotes a case-specific extension of R.

Based on the definition of bisimulation, we have to show two directions:

(1)

(

)∈ R

and A

−→

for e

∈

S0∪ {τ}

, then there exists some B

such that

Bbe

−→ B0and (A0,B0)∈ R.

(2)

(

)∈ R

and B

−→

for e

∈

S0∪ {τ}

, then there exists some A

such that

Abe

−→ A0and (A0,B0)∈ R.

5.2 Correctness for the CSP Part 123

Here, we let Pbe

−→ P0stand for

Pτ

−→ . . . τ

−→ Pk

−→ Pk+1

−→ . . . τ

−→ P0,

that is, Ptransits into P

by e, possibly surrounded by additional

-transitions. We show

the property for

◦ ∈ {2,o

9,kS}

and we construct the bisimulation relations

with respect

to the individual binary operator, instantiating

◦

. In any case, we separate between both

required conditions

(1)

and

(2)

. Within the individual proofs, we additionally distinguish

between (A,B)∈ R0and (A,B)6∈ R0, and we need to consider τ-transitions.

External Choice: For the case of external choice, we extend the relation Rby defining

R0:= IdLCSP ∪ {(A,B)|A= (C1kECC2),B∈X1} ∪

{(A,B)|A= (D1kECD2),B∈X2},

for

X1:= {(C1kEC(C22D2)) |initials(D2)⊆EC} ∪

{((C12D1)kECC2)|initials(D1)⊆EC},

and

X2:= {(D1kEC(C22D2)) |initials(C2)⊆EC} ∪

{((C12D1)kECD2)|initials(C1)⊆EC},

where again, C

i∈

CSP

i∈

CSP

) denotes any reachable state within the labelled

transition system of T

). Here,

IdLCSP := {(

∈

CSP}

, depicting the

identity on L

CSP

. We do not explicitly deal with

(

)∈IdLCSP

, as in this case, the

bisimulation diagram can trivially be completed.

(1) (A,B)∈ R0and Ae

→A0.

τ-case: Let Aτ

−→ A0. We start with the case of (A,B)∈ R0. If

(C1kECC2)τ

−→ (C0

1kECC0

2),

according to the firing rules for parallel composition, the transition is

either performed by C

or C

. We consider the first case, the other case is

analogous. Then, C0

2=C2. From C1

−→ C0

1, we get

C1kEC(C22D2)τ

−→ C0

1kEC(C22D2)

as well as

(C12D1)kECC2

−→ (C0

12D1)kECC2

The following bisimulation diagram illustrates this case. X

124 5 Correctness of the Decomposition

A= (C1kECC2)τ

−→ (C0

1kECC0

2) = A0

R R

B= (C1kEC(C22D2)) τ

−→ (C0

1kEC(C0

22D2)) = B0

Next, we consider A

−→

and

(

)6∈ R0

-transitions do not resolve an

external choice. For the case of C

performing

, based on the firing rules

for external choice and parallel composition, the bisimulation diagram

can be completed as follows. The other cases are similar. X

A= ((C1kECC2)2(D1kECD2)) τ

−→ ((C0

1kECC2)2(D1kECD2)) = A0

R R

B= ((C12D1)kEC(C22D2)) τ

−→ ((C0

12D1)kEC(C22D2)) = B0

op-case:

Next, let A

op.x.t.a

−→

. For the case of

(

)∈ R0

, let A

1kEC

and

op.x.t.a

→

. Obviously, any of the processes from X

can simulate op

resulting in two

-related processes, since the comprised external choice

solely extends the set of possible steps, independent of any restriction on

initials(Di). The case A=D1kECD2and X2is analogous. X

A= (C1kECC2)op.x.t.a

−→ (C0

1kECC0

2) = A0

R R

B= (C1kEC(C22D2)) op.x.t.a

−→ (C0

1kEC(C0

22D2)) = B0

Now consider the case (A,B)6∈ R0, that is,

A= (C1kECC2)2(D1kECD2).

Then, either C

1kEC

op.x.t.a

→

or D

1kEC

op.x.t.a

→

. Without loss of

generality, we assume the first. Two separate cases have to be considered:

op.x.t.a∈EC:

Then, C

and C

have to synchronise on the execution of

op.x.t.a. Thus,

op.x.t.a

→A0

1and C2

op.x.t.a

→A0

for some A

1kEC

, again based on the firing rules of the

operational semantics of CSP. This yields that

(C12D1)op.x.t.a

→A0

1and (C22D2)op.x.t.a

→A0

5.2 Correctness for the CSP Part 125

and therefore,

((C12D1)kEC(C22D2)) op.x.t.a

→(A0

1kECA0

2).

As both successor states are identical, they are related by

. The

bisimulation diagram for this case is given next. X

A= ((C1kECC2)2(D1kECD2)) op.x.t.a

−→ (A0

1kECA0

2) = A0

R R

B= ((C12D1)kEC(C22D2)) op.x.t.a

−→ (A0

1kECA0

2) = B0

op.x.t.a6∈ EC:

Then, either, but exactly one of the four components can

execute op.x.t.a. Without loss of generality, let this component be C1.

((C1kECC2)2(D1kECD2)) op.x.t.a

−→ A0

yields

(C1kECC2)op.x.t.a

−→ A0.

We get C

op.x.t.a

−→

for some process C

, such that A

0= (

1kEC

Furthermore,

(C12D1)op.x.t.a

−→ C0

and thus,

((C12D1)kEC(C22D2)) op.x.t.a

−→ (C0

1kEC(C22D2)).

Finally, initials

(D2)⊆

holds: as op

∈

initials

(C1kECC2)

, the

set of initial events of D

1kEC

and therefore the one of D

needs to

be a subset of E

due to Lemma 5.2.1. D

being a reachable state of

|ES2

yields initials

(D2)⊆

, as no events from E

are possible. Thus,

((C0

1kECC2),(C0

1kEC(C22D2))) ∈ R0,

which concludes this case. X

A= ((C1kECC2)2(D1kECD2)) op.x.t.a

−→ (C0

1kECC2) = A0

R R

B= ((C12D1)kEC(C22D2)) op.x.t.a

−→ (C0

1kEC(C22D2))) = B0

126 5 Correctness of the Decomposition

(2) For the reverse direction, let (A,B)∈ R and Be

→B0.

τ-case: Again, we start with Bτ

→B0. For the case of R0, consider

(C1kEC(C22D2)) τ

−→ (C1kEC(C22D0

2)),

that is, D

−→

. First, as initials

(D2)⊆

, the process D

can solely

perform synchronised events with C

. However, a synchronisation between

and D

is impossible due to Theorem 4.3.16, (5). Therefore, D

incapable of performing any event within C

1kEC(

. This allows us

to simulate the

-transition by

(

1kEC

2)τ

−→ (

1kEC

. In any other

case, including

(

)6∈ R0

, we apply the exact same rules and ideas of

the forward direction. X.

op-case:

In the case of

(

)∈ R0

, we solely consider B

= (

1kEC(

2))

- the other three cases are accordingly shown. Let B

op.x.t.a

→

. Again,

it is impossible that D

performs any event within C

1kEC(

Furthermore, any (local or synchronised) step of C

can be simulated by

C1kECC2.X

B= (C1kEC(C22D2)) op.x.t.a

−→ (C0

1kEC(C0

22D2)) = B0

R R

A= (C1kECC2)op.x.t.a

−→ (C0

1kECC0

2) = A0

Now let B

= ((

1)kEC(

2))

. Here, both sides need to

synchronise on op.x.t.a. Again, two cases need to be considered:

op.x.t.a∈EC:Then, there exist B0

1,B0

2such that

(C12D1)op.x.t.a

→B0

1and (C22D2)op.x.t.a

→B0

for some B

and B

0= (

1kEC

. Based on Theorem 4.3.16,

(5), a synchronisation between C

and D

or C

and D

is impossible,

as Cand Dwere unable to synchronise before the decomposition.

Therefore, without loss of generality, we deduce C

op.x.t.a

→

and

op.x.t.a

→B0

2. Following up,

(C1kECC2)op.x.t.a

→(B0

1kECB0

and thus,

((C1kECC2)2(D1kECD2)) op.x.t.a

→(B0

1kECB0

2).

As both successor states are identical, they are R-related. X

5.2 Correctness for the CSP Part 127

B= ((C12D1)kEC(C22D2)) op.x.t.a

−→ (B0

1kECB0

2) = B0

R R

A= ((C1kECC2)2(D1kECD2)) op.x.t.a

−→ (B0

1kECB0

2) = A0

op.x.t.a6∈ EC:

Again, exactly one of the four components executes op

which we assume to be C1. From

((C12D1)kEC(C22D2)) op.x.t.a

−→ B0

we get

(C12D1)op.x.t.a

−→ C0

for some process C

such that B

0= (

1kEC(

2))

. From this, we

get C1

op.x.t.a

−→ C0

1and thus,

(C1kECC2)op.x.t.a

−→ (C0

1kECC2).

This yields

((C1kECC2)2(D1kECD2)) op.x.t.a

−→ (C0

1kECC2).

Finally, again based on Lemma 5.2.1, we get initials(D2)⊆ECand

((C0

1kECC2),(C0

1kEC(C22D2))) ∈ R0.X

B= ((C12D1)kEC(C22D2)) op.x.t.a

−→ (C0

1kEC(C22D2)) = B0

R R

A= ((C1kECC2)2(D1kECD2)) op.x.t.a

−→ (C0

1kECC2) = A0

Sequential Composition: Here, R0=IdLCSP .

(1) Let (A,B)∈ R and Ae

→A0for

A= ((C1kECC2)o

9(D1kECD2)).

τ-case:

→

yields that C

1=Skip

and C

2=Skip

, based on the firing

rule for sequential composition and thus, A0= (D1kECD2). Therefore,

C1o

9D1

−→ D1and C2o

9D2

−→ D2,

yielding

((

1)kEC(

2)) τ2

−→ (

1kEC

. Both successor states

are related by IdLCSP , that is, R0.X

128 5 Correctness of the Decomposition

((C1kECC2)o

9(D1kECD2)) τ

−→ (D1kECD2)

R R

((C1o

9D1)kEC(C2o

9D2)) bτ

−→ (D1kECD2)

op-case: Let Aop.x.t.a

→A0. Two cases need to be considered:

op.x.t.a∈EC:If (C1kECC2)op.x.t.a

→A0, we have

A0= ((C0

1kECC0

2)o

9(D1kECD2))

for some C0

i∈LCSP and thus,

op.x.t.a

→C0

1and C2

op.x.t.a

→C0

from which can stepwise deduce

((C1o

9D1)kEC(C2o

9D2)) op.x.t.a

→((C0

9D1)kEC(C0

9D2)).

((C1kECC2)o

9(D1kECD2)) op.x.t.a

−→ ((C0

1kECC0

2)o

9(D1kECD2))

R R

((C1o

9D1)kEC(C2o

9D2)) op.x.t.a

−→ ((C0

9D1)kEC(C0

9D2))

(

1kEC

2)op.x.t.a

→

, both, C

and C

, need to have terminated, thus

requiring C1=Skip,C2=Skip, and we proceed analogously. X

((Skip kECSkip)o

9(D1kECD2)) op.x.t.a

−→ ((Skip kECSkip)o

9(D0

1kECD0

2))

R R

((Skip o

9D1)kEC(Skip o

9D2)) op.x.t.a

−→ ((Skip o

9D0

1)kEC(Skip o

9D0

2))

op.x.t.a6∈ EC:

In this case, again, either C

1kEC

or D

1kEC

perform

a, where the latter requires

(

1kEC

2) = Skip

. The proof

is straightforward and according to the previous proof steps. The

bisimulation diagram for the first case, where we assume that C

performs op.x.t.a, is given next. X

5.2 Correctness for the CSP Part 129

((C1kECC2)o

9(D1kECD2)) op.x.t.a

−→ ((C0

1kECC2)o

9(D1kECD2))

R R

((C1o

9D1)kEC(C2o

9D2)) op.x.t.a

−→ ((C0

9D1)kEC(C2o

9D2))

(2) Let (A,B)∈ R and Be

→B0for B= ((C1o

9D1)kEC(C2o

9D2)).

τ-case:

Let B

→

. Then, without loss of generality,

(

1)τ

−→

based on the firing rule for sequential composition. We deduce that

(

1kEC

2)τ

−→ (Skip kEC

holds. The bisimulation diagram is given

next. X

((C1o

9D1)kEC(C2o

9D2)) τ

−→ ((Skip o

9D1)kEC(C2o

9D2))

R R

((C1kECC2)o

9(D1kECD2)) τ

−→ ((Skip kECC2)o

9(D1kECD2))

op-case: Let Bop.x.t.a

→B0. Again, there are two separate cases:

op.x.t.a∈EC:

Theorem 4.3.16, (5), ensures that a synchronisation within

(

1)kEC(

can only occur between C

and C

or between

and D

. In case that D

and D

synchronise on op

a,C

and C

are equivalent to

Skip

. The remainder of this particular proof step

is straightforward. We give the bisimulation diagram for the C-case

next. X

((C1o

9D1)kEC(C2o

9D2)) op.x.t.a

−→ ((C0

9D1)kEC(C0

9D2))

R R

((C1kECC2)o

9(D1kECD2)) op.x.t.a

−→ ((C0

1kECC0

2)o

9(D1kECD2))

op.x.t.a6∈ EC:

From the structure of the process

(

1)kEC(

we know that C

terminates before D

. In addition, we have to show

that C

terminates before D

, which implies that C

terminates before

. Based on that, in order to complete this case, we may safely

use C

1=Skip

and C

2=Skip

, in case that D

performs op

6∈

. Assume that D

performs op

6∈

. Then, by definition,

either op

∈

[Ph1]

or op

∈

[Ph3]

. In the first case, as C

terminates before Dand based on the definition of

Ph1

, the process C

is completely assigned to

Ph1

. Thus, due to

2⊆

can only

perform synchronised events with C

, which need to happen prior to

130 5 Correctness of the Decomposition

a. In the latter case, the set of events for C

are executed before

any event of l

[Ph3]

, again yielding the termination of C

prior to D

The bisimulation diagram for a sole step of D1is given next. X

((Skip o

9D1)kEC(Skip o

9D2)) op.x.t.a

−→ ((Skip o

9D0

1)kEC(Skip o

9D2))

R R

((Skip kECSkip)o

9(D1kECD2)) op.x.t.a

−→ ((Skip kECSkip)o

9(D0

1kECD2))

Parallel Composition:

Again,

R0=∅

. For the case of parallel composition, weak

bisimilarity of the processes

A= (C1kECC2)kS(D1kECD2)and

B= (C1kS∩ES1D1)kEC(C2kS∩ES2D2)

has to be shown. First, we consider the case of a τ-transition for both directions.

(1)

Let

(

)∈ R

and A

−→

. This case is immediate based on the rules for

promoting τ-transitions within a parallel composition. X

(2) For Bτ

−→ B0, we proceed analogously.

For either A

op.x.t.a

−→

or B

op.x.t.a

−→

, several cases need to be separated, making

a case differentiation over all cases rather tedious. As most of these cases refer

to the transition laws for CSP, corresponding to the applications for the external

choice and sequential composition, we precisely deal with the decisive cases and

only sketch the straightforward cases.

Figure 5.9 shows the different cases, which need to be considered for Aor B

performing op.x.t.a. These are:

(a) op.x.t.a∈(S∩EC),

(b) op.x.t.a∈(S∩E1),

(d) op.x.t.a∈(EC\S),

(e) op.x.t.a∈(E1\S)and

(f) op.x.t.a∈(E2\S).

For the bisimulation proof, there is one decisive case for both directions. We give

the intuitive ideas first:

•

= (

1kEC

2)kS(

1kEC

performing an event from S

might cause

a wrong synchronisation between C

and D

or C

and D

. However, as the

event is either an element of E

or E

but never an element of both sets, this is

impossible.

5.2 Correctness for the CSP Part 131

(f)(e)

(d)

(a)(b) (c)

E1E2

Figure 5.9: Case differentiation for Lemma 5.2.3, parallel composition

•

= (

1kS∩ES1

1)kEC(

2kS∩ES2

performing an event from E

Smight

cause a wrong synchronisation between C

and D

or C

and D

as well.

Here, Theorem 4.3.16 shows that the addressing extension prevents this from

happening.

Next, we show the bisimilarity conditions for all six cases:

op.x.t.a∈(S∩EC):

Independent of Condition (1) or (2), all four processes C

and D

have to synchronise on op

a. Showing both conditions is

immediate, based on applying the firing rules for CSP. X

op.x.t.a∈(S∩E1):For implication (1), assume that

((C1kECC2)kS(D1kECD2)) op.x.t.a

−→ ((C0

1kECC0

2)kS(D0

1kECD0

2)).

Based on op

∈

, the synchronisation must be performed by C

and D

Thus, C0

2=C2,D0

2=D2and (C1kS∩ES1D1)op.x.t.a

−→ (C0

1kS∩ES1D0

1). This yields

((C1kS∩ES1D1)kEC(C2kS∩ES2D2)) op.x.t.a

−→ ((C0

1kS∩ES1D0

1)kEC(C2kS∩ES2D2)),

as op.x.t.a6∈ EC.

((C1kECC2)kS(D1kECD2)) op.x.t.a

−→ ((C0

1kECC2)kS(D0

1kECD2))

R R

((C1kS∩ES1D1)kEC(C2kS∩ES2D2)) op.x.t.a

−→ ((C0

1kS∩ES1D0

1)kEC(C2kS∩ES2D2))

Implication (2) is straightforward. X

132 5 Correctness of the Decomposition

op.x.t.a∈(S∩E2):Analogous to the previous case. X

op.x.t.a∈(EC\S):

Here, implication (1) is straightforward. For implication (2),

let

((C1kS∩ES1D1)kEC(C2kS∩ES2D2)) op.x.t.a

−→ ((C0

1kS∩ES1D0

1)kEC(C0

2kS∩ES2D0

2)).

Theorem 4.3.16 yields that only C

and C

or D

and D

are able to synchronise.

We assume the first, thus yielding D

and D

. We get

(

1kEC

C2)op.x.t.a

−→ (C0

1kECC0

2)and finally

((C1kECC2)kS(D1kECD2)) op.x.t.a

−→ ((C0

1kECC0

2)kS(D1kECD2)).X

((C1kS∩ES1D1)kEC(C2kS∩ES2D2)) op.x.t.a

−→ ((C0

1kS∩ES1D1)kEC(C0

2kS∩ES2D2))

R R

((C1kECC2)kS(D1kECD2)) op.x.t.a

−→ ((C0

1kECC0

2)kS(D1kECD2))

op.x.t.a∈(E1\S):

Independent of Condition (1) or (2), exactly one of the four

processes needs to perform op.x.t.a, which is straightforward. X

op.x.t.a∈(E2\S):Analogous to the previous case. X

5.2.2 Correctness of the Decomposition: CSP part

Finally, we show correctness for the decomposition of S

.main

by using the results from

the previous sections. Again, we use weak bisimulation as the method of proof: we

construct a weak bisimulation relation, comprising tuples

(P,PJRC

1K|ES1kECPJRC

2K|ES2),

where Pdenotes any reachable state of the LTS of S

.main

. As we show trace equivalence

modulo the renaming by transmission parameters and address parameters, we accordingly

show bisimilarity not explicitly denoting the renaming.

For simplification, we let P

denote PJRCK.

In the theorem, we will use a lemma from [

Brü08

], namely Lemma 6.1.2. It relates the

possible transitions of a CSP process to transitions of a projection of this process. Next,

we state the main theorem of this section:

Theorem 5.2.4. (Correctness of the decomposition: CSP part)

Let S be a specification, and let

C= (C1,C2)

be a cut, yielding a decomposition into S

and

S2, according to Definition 4.3.24. Then, the following holds:

S.main =T(S1.main kECS2.main)JR0K.

As a matter of course, the renaming is solely syntactically neglected. We still have to use the properties of

the additional parameters, as they ultimately ensure the correctness of the decomposition.

5.2 Correctness for the CSP Part 133

Proof:

We show that S

.main

and S

1.main kEC

2.main

are the initial states of a weak

bisimulation

R:= {(P,PR|ES1kECPR|ES2)|P∈LCSP reachable state of LTS of S.main,PR=PJRCK}.

Again, we need to show two implications:

(1)

(

,PR|ES1kECPR|ES2)∈ R

and P

op.x

−→

for op

∈

−→

], then there exists

some Q0, such that

(PR|ES1kECPR|ES2)\

op.x.t.a

−→ Q0[(PR|ES1kECPR|ES2)bτ

−→ Q0]

for some op.x.t.a∈ES0and (P0,Q0)∈ R.

(2) If (P,PR|ES1kECPR|ES2)∈ R and

(PR|ES1kECPR|ES2)op.x.t.a

−→ Q0[PR|ES1kECPR|ES2)τ

−→ Q0],

then there exists some P

, such that P

op.x

−→

for op

∈

bτ

−→

] and

(

0)∈ R

For the first implication, it is sufficient to show that op.x.t.a∈ES0exists.

(1):

First, let P

−→

. Based on the firing laws for CSP, a

-transition is preserved by a

renaming as well as hiding. Thus, we immediately get

(PR|ES1kECPR|ES2)τ

−→ (P0

R|ES1kECP0

R|ES2).

Now let P

op.x

−→

for op

∈

. First, assume that Pis composed of two parallel

processes, with op being synchronised. Based on Theorem 4.3.16, (2) and (3), if P

performs a synchronised step, the process P

can accordingly perform this step, as

the renaming preserves the synchronisation structure. Thus, we do not separately

need to deal with this particular structure of P. Next, we have to distinguish

between three cases for op.x:

op.x∈EC:

In this case, we apply the first property of Lemma 6.1.2, [

Brü08

]. For

∈

E, it states that performing efor Pand P

leads to corresponding successor

states Qand Q|E:

(Pe

−→ Q∧e∈E)⇒P|E

−→ Q|E.

In our context and based upon the previous observation, the property yields

PR|ES1

op.x.t1.a1

−→ P0

R|ES1and PR|ES2

op.x.t2.a2

−→ P0

R|ES2

for some op

i∈

. In order to deduce that

PR|ES1

and

PR|ES2

can do

asynchronous step, there needs to exist some op

∈

, which both

processes can perform. This is the case: the transmission parameters are not

134 5 Correctness of the Decomposition

restricted by the CSP part at all. Thus, any values are possible for t

and t

For the address parameters, Theorem 4.3.16, (1), showed that their values

are identical for both, S

1.main

and S

2.main

. We deduce that there exists

op.t.x.a∈ES0, such that

(PR|ES1kECPR|ES2)op.x.t.a

−→ (P0

R|ES1kECP0

R|ES2)

and (P0,P0

R|ES1kECP0

R|ES2)∈ R.X

op.x∈E1:Again, we deduce

PR|ES1

op.x.t1.a1

−→ P0

R|ES1.

Based on op.x6∈ ECand the operational semantics of CSP, we get

(PR|ES1kECPR|ES2)op.x.t1.a1

−→ (P0

R|ES1kECPR|ES2).

By using the firing rule for CSP hiding and op.x6∈ E2, we deduce that

PR|ES2

−→ P0

R|ES2

and thus,

(PR|ES1kECPR|ES2)\

op.x.t1.a1

−→ (P0

R|ES1kECP0

R|ES2).

Again, (P0,P0

R|ES1kECP0

R|ES2)∈ R.X

op.x∈E2:Analogous to the second case. X

Pop.x

−→ P0

R R

(PR|ES1kECPR|ES2)\

op.x.t.a

−→ (P0

R|ES1kECP0

R|ES2)

(2):Let

(PR|ES1kECPR|ES2)op.x.t.a

−→ Q0

for some op

∈

. We show that there exists P

0∈

CSP

, such that P

op.x

−→

and

Q0= (P0

R|ES1kECP0

R|ES2),

by induction on the structure of P.

5.2 Correctness for the CSP Part 135

(PR|ES1kECPR|ES2)op.x.t.a

−→ (P0

R|ES1kECP0

R|ES2) = Q0

R R

op.x

−→ P0

Induction Basis:

Let P

→

Qfor some e

∈

and Q

∈

CSP

. Based on Definition

4.3.3, we have

(e→Q)|E:= (Q|E,e6∈ E,

e→Q|E,otherwise.

We have to distinguish between three cases:3

RC(e)⊆EC:Based on (e→P)JRK=e0:R(e)→PJRK([Sch09]),

(PR|ES1kECPR|ES2) = ((e0:RC

1(e)→QR|ES1)kEC(e00 :RC

2(e)→QR|ES2)).

(PR|ES1kECPR|ES2)op.x.t.a

−→

, we get op

∈(RC

)∩RC

))

. Thus,

e=op.x. Moreover,

(PR|ES1kECPR|ES2)op.x.t.a

−→ (QR|ES1kECQR|ES2),

as both processes have to synchronise on op

∈

. Obviously, P

−→

holds, and finally, (Q,QR|ES1kECQR|ES2)∈ R.X

RC(e)∈E1:Let e0=RC(e). In this case,

(PR|ES1kECPR|ES2) = ((e0→QR|ES1)kECQR|ES2) =: X,

as the projection eliminates e

for the right hand side of the parallel

composition. In case that op

holds, the process Xswitches to

QR|ES1kECQR|ES2

, and we reside in the first case. However, we need to

show that Xmust not be able to perform any other event than e

, that is,

QR|ES2

is incapable of performing a non-synchronised step. But this is the

case: from Lemma 5.2.1 and based on e

0∈

, we know that the set of

initial events of

QR|ES2

is a subset of E

and thus E

. Therefore,

QR|ES2

can initially only do a synchronous step which is impossible as the sole

initial event for the parallel composition is an event from E1.X

RC(e)∈E2:According to the previous case. X

Induction Hypothesis: Assume that the property is shown for Tand U.

Here, we need to refer to the renaming

as we have to distinguish between the different sets of events

which eis assigned to in the decomposition.

136 5 Correctness of the Decomposition

Induction Step:

The induction step needs to distinguish between P

◦

Uwith

◦ ∈ {2,u,o

9,kS,k| }

. Both choice operators have the same interpretation in

the CSP traces model. Moreover, interleaving is a special case of parallel

composition with an empty synchronisation alphabet. That leaves a case

differentiation for

◦∈{2,o

9,kS}

. In any of the three cases, we apply Lemma

5.2.3. As the lemma already dealt with

-transitions, we do not need to

consider them again.

P=T2U:Let

((T2U)R|ES1kEC(T2U)R|ES2)op.x.t.a

−→ Q0.

Definition 4.3.3 yields

((TR|ES1

2UR|ES1)kEC(TR|ES2

2UR|ES2)) op.x.t.a

−→ Q0.

Next, we apply Lemma 5.2.3 for the case of external choice and deduce

((TR|ES1kECTR|ES2)2(UR|ES1kECUR|ES2)) \

op.x.t.a

−→ Q0.

Without loss of generality, the left hand side performs a (synchronous

or asynchronous) step. From the induction hypothesis, we deduce the

existence of T

, such that T

op.x

−→

and Q

0= (T0

R|ES1kECT0

R|ES2)

. The

operational semantics of CSP yields (T2U)d

op.x

−→ T0.X

(T2U)R|ES1kEC(T2U)R|ES2

op.x.t.a

−→ T0

R|ES1kECT0

R|ES2=Q0

R R

T2Ud

op.x

−→ T0=P0

P=To

9U:Let

((To

9U)R|ES1kEC(To

9U)R|ES2)op.x.t.a

−→ Q0.

Definition 4.3.3 yields

((TR|ES1

9UR|ES1)kEC(TR|ES2

9UR|ES2)) op.x.t.a

−→ Q0

and the application of Lemma 5.2.3 for the case of sequential composition

((TR|ES1kECTR|ES2)o

9(UR|ES1kECUR|ES2)) \

op.x.t.a

−→ Q0.

First, let

((TR|ES1kECTR|ES2)o

9(UR|ES1kECUR|ES2)) \

op.x.t.a

−→ (Q0

9(UR|ES1kECUR|ES2)).

5.2 Correctness for the CSP Part 137

From the induction hypothesis, we deduce the existence of T

, such that

op.x

−→ T0and

1= (T0

R|ES1kECT0

R|ES2).

The operational semantics of CSP yields (To

9U)d

op.x

−→ (T0o

9U). Finally,

Q0= (T0

R|ES1kECT0

R|ES2)o

9(UR|ES1kECUR|ES2),

which is equivalent to

(T0

R|ES1

9UR|ES1)kEC(T0

R|ES2

9UR|ES2),

according to Lemma 5.2.3. The latter process is equal to

(T0o

9U)R|ES1kEC(T0o

9U)R|ES2,

based on Definition 4.3.3. We conclude that the successor states are

related. A step for the process

UR|ES1kECUR|ES2

is analogous, based on the

fact that in this case, TR|ES1=Skip and TR|ES2=Skip needs to hold. X

((To

9U)R|ES1kEC(To

9U)R|ES2)op.x.t.a

−→ ((T0o

9U)R|ES1kEC(T0o

9U)R|ES2)

R R

(To

9U)d

op.x

−→ (T0o

9U)

P=TkSU:We assume

((TkSU)R|ES1kEC(TkSU)R|ES2)op.x.t.a

−→ Q0.

Applying 4.3.3 and subsequently Lemma 5.2.3 for the case of parallel

composition yields

((TR|ES1kECTR|ES2)kS(UR|ES1kECUR|ES2)) \

op.x.t.a

−→ (Q0

1kECQ0

2).

Two cases for op.x.t.ahave to be considered:

op.x.t.a∈S:

The induction hypothesis yields the existence of two pro-

cesses T

and U

, such that T

op.x

−→

and U

op.x

−→

holds for

1= (T0

R|ES1kECT0

R|ES2)

and Q

2= (U0

R|ES1kECU0

R|ES2)

. The opera-

tional semantics of CSP yields (TkSU)d

op.x

−→ (T0kSU0). Finally,

Q0=Q0

1kECQ0

= (T0

R|ES1kECT0

R|ES2)kS(U0

R|ES1kECU0

R|ES2),

138 5 Correctness of the Decomposition

with the latter process being equivalent to

(T0

R|ES1kS∩ES1U0

R|ES1)kEC(T0

R|ES2kS∩ES2U0

R|ES2),

according to Lemma 5.2.3 and, consecutively, equivalent to

(T0kSU0)R|ES1kEC(T0kSU0)R|ES2

by Definition 4.3.3. We conclude that the successor states are

related. X

((TkSU)R|ES1kEC(TkSU)R|ES2)op.x.t.a

−→ ((T0kSU0)R|ES1kEC(T0kSU0)R|ES2)

R R

(TkSU)d

op.x

−→ (T0kSU0)

op.x.t.a6∈ S:

Analogous to the previous case, except for applying the

induction hypothesis only once for either Tor U.X2

This completes the proof of the correct decomposition of the CSP part. Next, we

accordingly show correctness for the decomposition of the Object-Z part of a specification.

5.3 Correctness for the Object-Z Part

In the introduction of this chapter, we pointed out the general strategy for the correctness

proof. In particular, for showing correctness of the decomposition of a specification’s

Object-Z part, we need to take the traces of its CSP part into account:

S.OZ =T(S1.OZ kECS2.OZ)JR0K

is only satisfied, if the ordering of events for the Object-Z part adheres to the sequences

of the CSP part. We illustrate this with a small example:

Example 5.3.1.

Consider the following specification Simple. Its CSP part subsequently

performs three operations. The operation first assigns the value

to the sole state variable

x. Next, second assigns

to x in case that the precondition x

= 1

is satisfied. Finally, third

outputs the value of x:

Simple

chan first,second chan third : [out? : N]

main c

=first →second →third?out →Skip

x:N

Init

x= 0

enable second

x= 1

5.3 Correctness for the Object-Z Part 139

effect first

∆(x)

x0= 1

effect second

∆(x)

x0= 2

effect third

out! : N

out! = x

The possible (single) cut E

C={| second |}

leads to the following decomposition, requiring

an additional transmission parameter:

Simple1

chan first

chan second : [trx? : N]

main c

=first →

second?trx→Skip

x:N

Init

x= 0

enable second

x= 1

effect first

∆(x)

x0= 1

effect second

trx! : N

x0= 2 ∧trx! = x0

Simple2

chan second : [trx? : N]

chan third : [out? : N]

main c

=second?trx→

third?out →Skip

x:N

effect second

∆(x); trx? : N

x0=trx?

effect third

out! : N

out! = x

Based on the CSP part of Simple, there is only one possible sequence of operations, namely

first

second

third

. However, in sole regard to the specification’s Object-Z part, the ordering

first

third

second

is possible. As the introduction of transmission parameters refers to

the CFG and thus the CSP part of a specification, correct values for the state variables

cannot be ensured. In particular, the event trace

first

third

.1,

second

.2i

is an element of

traces

(

Simple

kEC

Simple

)

, whereas

first

third

.1,

second

.2i

is not an element of

traces

(

Simple

)

: in the decomposition, the value of x needs to be transmitted before third

takes place, which is not the case, if the execution of the final two events is switched.

In the following correctness proof, we refer to the LTS semantics of Object-Z, as intro-

duced in Definition 2.2.3. The proof itself requires us to reason about the intermediate

states of S

OZ, that is, its state valuations, as we are now explicitly dealing with data

dependences. However, the semantic equivalence we aim at, is trace equivalence within

the CSP traces model, disregarding states of the Object-Z part. This allows that the

valuations of the state variables within S

OZ and S

kEC

OZ are possibly inconsistent

if their values do not influence the observable behaviour of the class, that is, the traces of

the CSP part.

140 5 Correctness of the Decomposition

In Section 5.3.2, we clarify what inconsistency between state valuations means. More-

over, we define the assumption that traces of the Object-Z part need to adhere to the CSP

part.

Beforehand, we start by showing some properties related to the decomposition of the

Object-Z part, which the actual correctness proof uses.

5.3.1 Properties of the Decomposition: Object-Z Part

Corresponding to the previous section for the CSP part, we introduce and prove some

properties of the decomposition of the Object-Z part: the first section will summarise some

characteristics of the DG, which the definition for a valid cut necessitates. Afterwards, we

show correctness of the restriction of the initial state schema and its optimisation.

No Dependences between Different Segments

A valid cut rules out several dependence edges between different segments of the DG. In

particular, edges must not reach back to a cut set or circumvent the cut.

As we continuously need to refer to the correctness criteria

no reaching back

and

no crossing

with respect to the phases and cut sets of the fragmented DG, we will now

give a lemma, summarising possible violations of these conditions. Here, we consider

edges with the target node being at an earlier stage than the source node:

Definition 5.3.2. (Earlier stage)

Let

DGS= (

,−→DG)

be the DG of a specification S and let

(C1,C2)

be a cut. We say that

n∈op(N)is at an earlier stage than n’ ∈op(N), if and only if one of the four conditions

1) n∈Ph1and n’ ∈Ph2,

2) n∈C1and n’ ∈Ph2,

3) n∈Ph2and n’ ∈Ph3,

4) n∈C2and n’ ∈Ph3

holds.

The definition is motivated by a property, which we subsequently show: if a DG node

is at an earlier stage with respect to another one, a control flow edge or data dependence

from the latter to the first node causes a violation of one of the correctness criteria

disjointness,no reaching back or no crossing:

Lemma 5.3.3. (No data dependences to an earlier stage)

Let

DGS= (

,−→DG)

be the DG of a specification S and let

(C1,C2)

be a cut. If

n∈op(

)

is at an earlier stage than

n’ ∈op(

)

, there must not be a data dependence from

n’

n’999K nis impossible.

5.3 Correctness for the Object-Z Part 141

Proof.

For the first and the third case of Definition 5.3.2, a data dependence

n’999K n

violates the correctness criterion

no crossing

. For the other cases,

no reaching back

violated. 2

A corresponding lemma considering control flow edges is given next.

Lemma 5.3.4. (No control flow edges to an earlier stage)

Let

DGS= (

,−→DG)

be the DG of a specification S and let

(C1,C2)

be a cut. If

n∈op(

)

is at an earlier stage than

n’ ∈op(

)

, there must not be a control flow edge from

n’

n’ −→ nis impossible.

Proof.

Consider the first case of Definition 5.3.2:

n∈Ph1

and

n’ ∈Ph2

. Assume that

n’ −→ n

. But then,

n∈(Ph1∩Ph2)

, contradicting

disjointness

. The third case is

analogous. For the other cases,

no reaching back

is violated, according to Lemma 5.3.3.

Figure 5.10 illustrates the definition and both lemmas, where edges denote disallowed

control flow edges and data dependences.

Ph1

Ph2

Ph3

Figure 5.10: Illustration of Definition 5.3.2 and Lemmas 5.3.3, 5.3.4

We aim at lifting Lemma 5.3.4 to paths of the CFG, that is, we want to state that the

CFG must not comprise paths connecting a node with another one from an earlier stage.

However, this is not always the case, as recursive calls from the third phase back to

the first one are possible. More generally, our correctness proof will need to distinguish

between paths returning to an earlier stage with recursion (which is possible) and without

recursion (which is impossible). This motivates the following definition:

Definition 5.3.5. (Recursion-free CFG path)

Let

CFGS= (

,−→)

be the CFG of a specification S, and let

π∈pathCFG

. We say that

142 5 Correctness of the Decomposition

is (outer-) recursion-free, if, and only if,

does not comprise two subsequent nodes

call.X∈Ph3and start.X∈Ph1for any X ∈LCSP.

The following lemma bridges the gap between paths of the CFG of Sand traces of the

CSP part by characterising traces of S.main without corresponding CFG paths:

Lemma 5.3.6. (CSP trace to an earlier stage requires interleaving or recursion)

Let

DGS= (

,−→DG)

be the DG of a specification S, and let

(C1,C2)

be a cut. Let

n∈op(

)

be at an earlier stage than

n’ ∈op(

)

, and let n and n

denote their corresponding occurrences

within S

.main

. If there exists tr

∈

traces

(

.main)

and indices i

j, such that

tr.

and

tr.j=n, then one of the following two cases applies:

1) there exists a CFG path from n’ to n, which is not recursion-free, or

2) n

and

n’

are located in different branches of the CFG, attached to the same interleaving

node or parallel composition node.

Proof.

We show the following: if the opposite of 1) holds, that is, if no recursion-free

CFG path from

n’

exists, both nodes must not be connected by a CFG path at all,

based on Lemma 5.3.4. From this, we deduce that the second case needs to apply.

Assume that there exists a CFG path

from

n’

, which is recursion-free. Let

n’ ∈Ph2

and

n∈Ph1

. According to Lemma 5.3.4, it is impossible that

proceeds from

Ph2

over

Ph1

or directly from

Ph2

Ph1

. Therefore,

has to proceed over

and

Ph3

back

to Ph1, which requires a recursion within π, contradiction. The other cases are similar.

Therefore, a CFG path from

n’

does not exist. We conclude the proof by applying

Lemma 6.1.4 from [

Brü08

]: two events with a subsequent execution within S

.main

require a CFG path from the first to the latter node or, if such a path does not exist, they

have to be located in different branches of the CFG, attached to the same interleaving

node or parallel composition node. 2

Correctness of Init-restriction

Chapter 4, Definition 4.3.6, introduced the restriction of S

.Init

to determine the initial

state schemas of S

and S

. In addition, Section 4.3.7 introduced an optimisation for the

decomposition of a specification, allowing us to neglect certain initial data dependences

when checking the correctness criterion no crossing.

In this section, we show that both, the definition and the optimisation, are correct in

the following sense, where we let V:= S.V,V1:= S1.V,V2:= S2.Vand i∈ {1,2}:

1.)

for any state s

∈

.State

such that S

.Init(

)

holds, the restriction s

Vi∈

i.State

satisfies Si.Init and

2.)

two states s

i∈

i.State

, for which S

i.Init(

holds, can appropriately be combined

to a state s∈S.State such that S.Init(s)holds.

Before proving these particular properties, we introduce some notations. First, recall

that the set Atoms

(S.Init)

denotes the set of all atomic predicates for the initial state

schema:

Va∈Atoms(S.Init)a=S.Init.

5.3 Correctness for the Object-Z Part 143

For any such predicate a, let a

[

]

depict the predicate, resulting from replacing any

free occurrence of the variable xin awith the value vof type t

. Henceforth, if ais

defined over a set of state variables {x1,...,xn}and vi:txi, we write

(v1,...,vn)|=a⇔a[xi/vi] = true .

For instance,

(7,3) |=

y. Here, we assume an ordering on the state variables, such

that a unique mapping x

i→

is indeed possible. Moreover, we write s

.Init

instead

of S

.Init(

)

. Finally, let

Init

Vdenote the

Init

-schema of a specification, restricting

only variables from V.

The next lemma states the first of the two properties specified above:

Lemma 5.3.7. (Correctness of Init-restriction, first part)

Let

DGS= (

,−→DG)

be the DG of a specification S, and let

(C1,C2)

be a cut, separating the

set V into V1and V2, according to Definition 4.3.5. Then, for all states s ∈S.State:

s|=S.Init ⇒(sV1|=S1.Init ∧sV2|=S2.Init).

Proof.

Assume s

.Init

for some s

∈

.State

. Let

(

1) = {

1,...,

, and let

V1={w1,...,wm}. We have to show

sV1|=∃v1,...,vn•S.Init

and

sV2|=∃w1,...,wm•S.Init.

Recall that, in general, V1∩V26=∅, and thus, (V\V1)6=V2. Since

S.Init =Va∈Atoms(S.Init)a,

.Init

is equivalent to

∀

∈

Atoms

(S.Init)•

a. Let Free

(

)

be the set of free

state variables within a. Without loss of generality, let

Free(a) = {x1,...,xn,y1,...,ym}

for xi∈V1and yj∈(V\V1). Then,

S1.Init.a=∃y1,...,ym•a(x1,...,xn,y1,...,ym)

and

S2.Init.a=∃x1,...,xn•a(x1,...,xn,y1,...,ym).

We deduce

s|=a⇔a[xi/s.xi][yj/s.yj] = true

⇔sV1|=a[yj/s.yj]and sV2|=a[xi/s.xi]

⇒sV1|=∃y1,...,ym•aand sV2|=∃x1,...,xn•a

⇔sV1|=S1.Init.aand sV2|=S2.Init.a.2

144 5 Correctness of the Decomposition

For the second property, we have to consider the optimisation from Section 4.3.7: as

already mentioned, we aim at neglecting several initial data dependences. These are

the ones originating from an atomic predicate asolely referring to variables x, such that

InitClos

(

)⊆(

holds. It is reasonable to neglect those dependences, because all of

these predicates remain unchanged within S

2.Init

, which we show next. As additionally,

state variables from V

are not modified within S

at all, the initial data dependences

within

DGS= (

,−→DG)

, originating from these predicates, no longer cause a violation of

no crossing. Note that all remaining initial data dependences must not be neglected.

Lemma 5.3.8. (Correctness of optimisation)

Let

DGS= (

,−→DG)

be the DG of a specification S, and let

(C1,C2)

be a cut, separating the

set V into V1and V2, according to Definition 4.3.5. In addition, let

{y1,...,ym}={x|InitClos(x)⊆(V2\V1)}.

Then, the initial state predicate of S restricted to

{

1,...,

is equal to the initial state

predicate of S2restricted to the same set, that is

S.Init{y1,...,ym}=S2.Init{y1,...,ym}.

Proof.

Let InitClos

(

)⊆(

. Then, for any atomic predicate a

∈

Atoms

(S.Init)

, we

get vars(a)⊆(V2\V1). Based on

S2.Init =∃w1,...,wm•S.Init,

for V1={w1,...,wm}, any of these atoms is preserved within S2.Init.2

Next, we complement Lemma 5.3.7 by proving the second of the two properties,

specified above: from two states s

i∈

i.State

satisfying S

i.Init

, we can construct

∈State

satisfying S

.Init

. For finally showing correctness of the optimisation, this

construction necessarily needs to take the previously described subset of

(

into

account.

Lemma 5.3.9. (Correctness of Init-restriction, second part)

Let

DGS= (

,−→DG)

be the DG of a specification S, and let

(C1,C2)

be a cut, separating the

set V into V1and V2, according to Definition 4.3.5. Let V1={x1,...,xn},

{y1,...,ym}={x|InitClos(x)⊆(V2\V1)}and

{z1,...,zl}= (V2\V1)\ {y1,...,ym}.

For all states of S, we use the variable ordering

(

1,...,

. Let

i∈

i.State

, such that s

i|=

i.Init

. Then, there exist c

, i

∈ {1,...,

}

, such that for

s:= (s1.x1,...,s1.xn,s2.y1,...,s2.ym,c1,...,cl),

s|=S.Init.

5.3 Correctness for the Object-Z Part 145

Proof.

Again, let

(

1) = {

1,...,

, and let V

1={

1,...,

. Based on the

definition of Si.Init, we have

1) (s1.x1,...,s1.xn)|=∃v1,...,vn•S.Init and

2) (s2.y1,...,s2.ym,s2.z1,...,s2.zl)|=∃w1,...,wm•Init.

We need to show that there indeed exist ciof type tzi, such that

S.Init[x1/s1.x1]. . . [xn/s1.xn][y1/s2.y1]. . . [ym/s2.ym][z1/c1]. . . [zl/cl]

evaluates to true. First, for all a∈Atoms(S.Init):

vars(a)∩ {x1,...,xn,z1,...,zl}∩{y1,...,ym}=∅.

This is based on Definition 4.3.26: assume the opposite, then there exists an atomic

predicate from S

.Init

, containing a variable y

∈(

, such that InitClos

(

)⊆(

holds. In addition, the predicate either refers to a variable x

∈

or to a variable

∈(

, for which InitClos

(

)*(

. In both cases, we get a contradiction, as

either xitself or some z

0∈

InitClos

(

)

is an element of

(

1∩

InitClos

(

))

. Therefore, any

atomic predicate within S

.Init

is either defined over a subset of

{

1,...,

or a subset of

{

1,...,

.sindeed satisfies S

.Init

: let a

∈

Atoms

(S.Init)

be defined

over {x1,...,xn,z1,...,zl}. As

(s1.x1,...,s1.xn)|=∃v1,...,vn•S.Init,

in particular,

(s1.x1,...,s1.xn)|=∃c1,...,cn•a

holds. Now assume that a∈Atoms(S.Init)is defined over {y1,...,ym}.

(s2.y1,...,s2.ym,s2.z1,...,s2.zl)|=∃w1,...,wm•Init

particularly implies that (s2.y1,...,s2.ym)|=a. As

vars(a)∩ {x1,...,xn,z1,...,zl}∩{y1,...,ym}=∅,

we conclude that s|=S.Init.2

Example 5.3.10. Recall the initial state schema of the candy machine from Figure 2.3:

CandyMachine.Init = (sum = 0) ∧(paid =h i)∧(items =h i).

For the valid single cut

C={switch}

, we get sum, paid

∈

and items

∈(

. Obviously,

InitClos(items)⊆(V2\V1). Thus,

S.Init{items}=S2.Init{items}= (items =h i).

In addition, any state s

= (

sum

paid

items

)

. such that s

i|=

i.Init

, yields

s|=S.Init.

146 5 Correctness of the Decomposition

Note, that the previous lemmas showed the correctness of the optimisation from

Section 4.3.7 but not ultimately of the

Init

-restriction. It remains to be shown that the

existential quantification does not violate the initial correlation between several state

variables. For instance, one could assume that a split-up of a predicate x

≥

yinto two

predicates

∃

•

≥

yand

∃

•

≥

ymay cause an observable difference between Sand

1kEC

. The correctness proof of the decomposition of the Object-Z part in Section 5.3.2

will show that this is not the case, mainly by using the correctness criterion

no crossing

with respect to initial data dependences.

5.3.2 Correctness of the Decomposition: Object-Z part

Next, we show correctness for the decomposition of S

OZ by using the previous results of

this section. We start by clarifying the restriction that traces of the Object-Z part need to

adhere to the ones of the CSP part. Instead of showing that

S.OZ =T(S1.OZ kECS2.OZ)JR0K

holds, we show the weaker property

∀tr such that (trOp)∈traces(S.main)Op •(5.1)

tr ∈traces(S.OZ)⇔tr ∈traces((S1.OZ kECS2.OZ)JR0K),

It describes that any trace, for which we assume the ordering of operations to be

determined by the CSP part, is an element of traces(S.OZ), if, and only if, it is contained

in traces((S1.OZ kECS2.OZ)JR0K).

The crucial point considering the renaming is as follows: addressing parameters are

not restricted by the Object-Z part, and we can entirely omit dealing with them. However,

we have to consider the set of transmission parameters, as they are necessary to restore

the original data flow within the decomposition. In correspondence to the correctness

proof of the CSP part and for simplification, we omit denoting the additional parameters,

which are introduced by the renaming relation.

We sketch the main strategy for showing Equation 5.1: for any trace of S

OZ, we

define a trace of S

kEC

OZ and vice versa, such that both traces are equivalent.

Recall Section 2.2.2 and the definition of Traces

(S.OZ)

: according to the LTS semantics

from Definition 2.2.3, an Object-Z trace consists of an alternating sequence of states

and events. As we ultimately aim at showing trace equivalence with respect to the CSP

traces model, we solely have to require trace equivalence over the set traces

(OZ)

, the

set of Object-Z traces projected on events. In particular, we will observe that the trace

equivalence with respect to Traces

(S.OZ)

cannot be shown: some state variables do not

need to have corresponding values within

π∈

Traces

(S.OZ)

and its analogon

πi

within

Traces(S1.OZ k{EC}S2.OZ).

In general, the decomposition of a specification eliminates a subset of the original set of

operations. Therefore, a trace of

πi∈

OZ is a projection of a trace of

π∈

OZ. In order

to simplify reasoning about their correspondence and the usage of indices, we assume an

event

noev

, depicting stuttering [

CGP99

] in

πi

: it substitutes for any event eof

, not

5.3 Correctness for the Object-Z Part 147

occurring in

πi

. Thus, both traces have a corresponding length. Furthermore, for any

noev-step in a trace, the succeeding state is identical to the one before noev, that is

snoev

−→ s0⇒s=s0.

When dealing with traces

π∈

Traces

(S.OZ)

, we use s

i:= π[

]

to denote the ith state of

the trace

and e

i:= π.

ito denote its ith event. Furthermore, we let e

sim

out

We proceed accordingly for

πi∈

Traces

(Si.OZ)

, where we use an additional top index.

Based on the usage of

noev

, we can always refer to corresponding positions within

and πi. Summarising, traces are referred to as

π=hs0,e0,s1,e1, . . . i,

π1=hs1

0,e1

0,s1

1,e1

1, . . . iand

π2=hs2

0,e2

0,s2

1,e2

1, . . . i.

Before carrying out the actual proof, we illustrate our general strategy and the possible

inconsistencies in the state space valuations by an example.

Example 5.3.11.

Consider the extended number swapper from Figure 4.26 and its de-

composition from Figures 4.27 and 4.28. The following table compares three valid traces

π∈

Traces

(Swapper.OZ)

π1∈

Traces

(Swapper1.OZ)

and

π2∈

Traces

(Swapper2.OZ)

. Here,

"_"

denotes an arbitrary value. We choose the value

for the input parameter of the

operation input.

π π1π2

h h h

s0: (a= 1,b=,tmp = ),s1

0: (b=,tmp = ),s2

0: (a= 1,b=,tmp = ),

e0:input.2,e1

0:input.2,e2

0:noev,

s1: (a= 1,b= 2,tmp = ),s1

1: (b= 2,tmp = ),s2

1: (a= 1,b=,tmp = ),

e1:store b,e1

1:store b.2,e2

1:store b.2,

s2: (a= 1,b= 2,tmp = 2),s1

2: (b= 2,tmp = 2),s2

2: (a= 1,b=,tmp = 2),

e2:move a,e1

2:noev,e2

2:move a,

s3: (a= 1,b= 1,tmp = 2),s1

3: (b=2,tmp = 2),s2

3: (a= 1,b= 1,tmp = 2)

e3:move b,e1

3:noev,e2

3:move b,

s4: (a= 2,b= 1,tmp = 2),s1

4: (b=2,tmp = 2),s2

4: (a= 2,b= 1,tmp = 2)

e4:result.1,e1

4:result. , e2

4:result.1,

s5: (a= 2,b= 1,tmp = 2) s1

5: (b=2,tmp = 2) s2

5: (a= 2,b= 1,tmp = 2)

i i i

As move a and move b do not occur in S

and as input is not represented in S

, these events

are replaced by noev within π1and π2, respectively.

148 5 Correctness of the Decomposition

Within the decomposition, the parameter value for result is solely determined by S

result.

Therefore, the event has an arbitrary parameter value within

π1

, the synchronisation ensures

that exclusively the value from π2is possible.

Five cells are highlighted in gray: for these states, the value for b is inconsistent between

either

and

π1

or between

and

π2

. However, these inconsistent values do not influence the

equivalence between πESand the joint execution of π1ES0and π2ES0: in both cases, we

get

hinput.2,store b[.2],move a,move b,result.1i,

where store b receives an additional transmission parameter within the parallel composition

of π1ES0and π2ES0.

As we will show in this section, inconsistent values for some state variables never affect

the trace equivalence in the CSP traces model.

The decomposition of Sleads to a partitioning of Vinto V

and V

. In the remainder of

this proof, we need to distinguish between four different sets of state variables:

V1\V2:the set of state variables solely represented in S1,

V2\V1:the set of state variables solely represented in S2,

CV := CV1∪CV2:the set of cut variables, according to Definition 4.3.9,

CV := (V1∩V2)\CV:the set of remaining shared state variables.

The latter set can be characterised as the set of state variables occurring in both, S

and S

, which are either not modified within

(

) or which do not influence

Ph2

(

Ph3∪Ph1

). As we will see later, this is the sole set of state variables, for which values in

πand πiare possibly inconsistent.

We start the proof with the forward direction of Equation 5.1.

Left-to-Right Implication

Let tr ∈traces(S.OZ), such that (trOp)∈traces(S.main)Op. We have to show

tr ∈traces((S1.OZ kECS2.OZ)JR0K).

Let

π=h

1, . . . i ∈

Traces

(S.OZ)

, such that

πES=

tr holds. Recall that

ei=opi.ini.simi.outi. We proceed in three steps: based upon π, we define two traces

πi=hsi

0,ei

0,si

1,ei

1, . . . i(Step 1),

with possibly ei

j=noev for some events. Next, we inductively show

πi∈Traces(Si.OZ)(Step 2).

Finally, we deduce

tr =πES∈(π1ES0kECπ2ES0)JR0K(Step 3).

5.3 Correctness for the Object-Z Part 149

Here, we refer to the definition of [Ros98] for the parallel composition of two traces.

Step 1:

For the definition of

πi∈

Traces

(Si.OZ)

, we need to consider events and states.

Obviously, as we aim at showing equivalence within the CSP traces model, the definition

for

πi

on events needs to match with the trace tr, except for events replaced by

noev

This gives rise to the following definition:4

j:= (ej.t,opj6∈ Ph2,

noev,otherwise,(5.2)

j:= (ej.t,opj6∈ (Ph1∪Ph3),

noev,otherwise,

where tdenotes the values for the additional transmission parameters. Note that these

are uniquely defined, based on Definition 4.3.10.

The definition of the states is more complicated. The initial states of

π1

and

π2

are

simply defined as the restrictions of s0on V1and V2, respectively:

0:= s0V1and s2

0:= s0V2.(5.3)

Next, we define s

for k

≥1

. The states for

πi

mostly correspond to the states of

restricted to the remaining set of state variables. Therefore, in most cases, we simply set

k:= skVi

. However, in some cases, the state valuations do not match. This is the case,

if some modification of a state variable within

is not represented in

πi

, thus causing

an inconsistency between the values of the respective state variable, which is possibly

preserved afterwards.

Precisely, there are three different cases, for which the value for a state variable x

within πimust not be modified, that is si

k:= si

k−1, instead of si

k:= sk.

(1)

In Example 5.3.11, consider the transition s

move a

−→

within

. The event is replaced

noev

within

π1

. As the modification for bto the value

gets lost within the trace

for S

OZ, setting s

bto s

bwould contradict

π1∈

Traces

(S1.OZ)

and is therefore

unreasonable. Instead, we have to define s

b– the original value is preserved

in case that an event is replaced by noev within πi.

(2)

Now consider the transition s

result.1

−→

. As the value for bis not modified within

result, the equation s

= 1

holds. The corresponding call of result within

π1

does not change bas well. Therefore, we again need to preserve the (inconsistent)

value s1

4.b= 2.

(3)

For the final case, assume that in the example, the predicate part of the operation

store b additionally comprises a modification of b. As store b

∈

and as bis not a

cut variable, this modification is solely conducted in S

. The old value for bneeds to

be preserved within π2.

Here, we refer to the specific occurrence of the DG node

opj

corresponding to the uniquely related

occurrence opjof the operation op.

150 5 Correctness of the Decomposition

The previous considerations motivate the following definition. Let i

∈ {1,2}

. For any

k≥1and x∈Vi, we define the value of si

k.xwithin πias:

k.x:= 









k−1.x,ei

k−1=noev or

(x∈(V1∩V2)and x6∈ ref(opk−1)and x6∈ mod(opk−1)) or

(x6∈ CVjand x∈mod(opk−1)and ei

k−1∈ECj, for j6=i),

sk.x,otherwise.

(5.4)

The three cases for s

k−1.

xcorrespond to the previous explanations. The definition can

be summarised as follows: any modification of xwithin

πi

results in corresponding values

sk.xand si

k.x. In any other case, the pre-state value for the variables is kept.

Step 2:

In a next step, we have to show

πi∈

Traces

(Si.OZ)

. Based on the previous

definition, the values for the state variables within

and

πi

are possibly diverse. However,

the following, crucial lemma shows that if some state variable xis referenced by the

operation opi

k, the pre-state value of xis identical in πand πi, that is, sk.x=si

k.xholds:

Lemma 5.3.12. (Equality of values for referenced state variables, left-to-right)

Let π∈Traces(S.OZ), and let πibe defined according to Equations 5.2, 5.3 and 5.4. Then:

∀n≥0,∀x∈Vi,∀opi∈Si.Op •x∈ref(opi

n)⇒sn.x=si

n.x.

Proof.

The property obviously holds for n

= 0

, as s

0=s0Vi

. Let n

∈

ref

(op1

and thus, x

∈

ref

(opn)

, for some x

∈

.State

. Assume that s

x. The case i

= 2

analogous. Initially, s

xholds. Therefore, there exist some

0≤

nand op

par

such that x

∈

mod

(opk)

, but x

6∈

mod

(op1

. This is due to Equation 5.4: if some state

variable is modified within

π1

, the modification is identical for

and

π1

. Assume that kis

the latest such position, that is, there is no further modification of xbetween s

k+1

and

. For the transition sequence

k,...,

, we apply Lemma 6.1.4 from [

Brü08

]: either,

there exists a CFG path, connecting both corresponding DG-nodes

and

or they are

located in different CFG branches, attached to the same interleaving node or parallel

composition node. As xis not modified in between, we deduce that there either exists

a direct data dependence (in the first case) or an interference data dependence (in the

latter case) from ekto en.

This particular dependence will now be used to deduce a contradiction. Here, several

different cases have to be considered. Figure 5.11 illustrates the current situation, where

the DG nodes corresponding to ekand enare connected by a data dependence.

As x

∈

mod

(opk)

and s

k+1.

x, either e

k=noev

or e

k∈

according to

Equation 5.4.

k=noev:

In this case, the corresponding DG node

is an element of

Ph2

, as only

operations corresponding to nodes from

Ph2

are eliminated from S

. We need to

consider four cases for en:

5.3 Correctness for the Object-Z Part 151

s0.x. . . sk

−→ sk+1.x. . . sn.xen

−→ sn+1.x

=6=6=

0.x. . . s1

−→ s1

k+1.x. . . s1

n.xe1

−→ s1

n+1.x

Figure 5.11: Illustration of Lemma 5.3.12

en∈(Ph1∪Ph3):

The data dependence from from

violates condition

no crossing.X

en∈C1:

The data dependence from

violates Lemma 5.3.3 (and particularly

condition no reaching back). X

en∈C2:

In this case, the original predicate part of op

is eliminated for the defini-

tion of S

and solely replaced by the transmission parameter predicates.

Thus, x∈ref(op1

n)is impossible. X

en∈Ph2:

is eliminated from S

in its entirety and again, x

∈

ref

(op1

impossible. X

k∈EC2:

In particular, x

6∈

needs to hold, according to the third case of Equation

5.4.

en∈(Ph1∪Ph3):

The data dependence

causes xto be contained in the set

of cut variables of EC2, contradicting x6∈ CV2.X

en∈C1:

According to the previous case, as the referencing of x

∈C1

still causes x

to be a cut variable. X

en∈C2:Analogous to the corresponding case for e1

k=noev.X

en∈Ph2:Analogous to the corresponding case for e1

k=noev.X2

Next, we show a corresponding lemma for the values of local state variables:

Lemma 5.3.13. (Equality of values for local state variables, left-to-right)

Let

π∈

Traces

(S.OZ)

, and let

πi

be defined according to Equations 5.2, 5.3 and 5.4. Let

j6=i. Then:

∀n≥0,∀x∈Vi,∀opi∈Si.Op •x∈(Vi\Vj)⇒sn.x=si

n.x.

Proof.

Again, the property holds for n

= 0

. As x

∈(

, none of the first three cases

from Equation 5.4 ever applies: an event replaced by

noev

within

πi

is solely represented

in S

and never refers to local variables from S

. The remaining two cases only apply for

x∈(V1∩V2). Therefore, sn.x=si

n.xalways holds. 2

The previous lemmas will be used throughout the following theorem, which shows that

πiis indeed an element of Traces(Si.OZ):

152 5 Correctness of the Decomposition

Theorem 5.3.14. (Correctness of the decomposition: Object-Z part, first part)

Let πibe defined according to Equations 5.2, 5.3 and 5.4. Then, πi∈Traces(Si.OZ).

Proof.

The proof is conducted by induction on the length of

πi

. In the induction base, we

show s

0|=

i.Init

. In the induction step, based on the assumption that

0,...,

an element of Traces(Si.OZ), we show

−→ si

k+1,

where si

k+1 complies to the conditions of Equation 5.4.

Induction Base:

0|=Si.Init directly follows from Equation 5.3 and Lemma 5.3.7.

Induction Step:

We start by considering the guard of op

, which needs to be satisfied. Furthermore,

the operation must be executable with parameter values corresponding to e

. Finally,

performing op

needs to allow for the successor state s

k+1

to comply to the conditions of

Equation 5.4.

In the following proof, we use the predicate interpretation of an

enable−

and

effect

schema in terms of Z:

sop.in.sim.out

−→ s0⇔(enable op(s,in,sim)∧effect op(s,in,sim,out,s0))

Furthermore, we write s

⊕

tto denote that the state t overrides the state s. Precisely, for s

defined over Vand tdefined over a subset V0, let s⊕tbe defined over Vas follows:

(s⊕t).x:= (t.x,x∈V0,

s.x,otherwise.

Let ek=opk.ink.simk.outk. By assumption,

enable opk(sk,ink,simk)∧effect opk(sk,ink,simk,outk,sk+1)

holds. Besides, by using Lemma 5.3.12, we know that s

xfor all referenced

variables within opi

Guard is Satisfied:

We need to show

enable

sim

. For op

k=noev

, there

is obviously nothing to show. Moreover, if op

k∈

for j

i, then

enable

true

. In any other case,

enable

k=enable

holds, according to Definition

4.3.10. We deduce:

5.3 Correctness for the Object-Z Part 153

enable opk(sk,ink,simk)

(1)

⇒enable opi

k(skVi,ink,simk)

(2)

⇒enable opi

k((skVi)⊕(si

kref(opk)),ink,simk)

(3)

⇒enable opi

k(si

k,ink,simk).

Implication

(1)

is due to

enable

k=enable

and the fact that any operation

from S

solely refers to variables from V

. Implication

(2)

is due to s

on ref

(opk)

(induction hypothesis and Lemma 5.3.12). The last implication,

(3)

, follows by the

fact that non-referenced variables within

enable

do not affect the truth-value

of the associated predicate.

Operation is Executable with Compatible Successor State: We will now show

effect opi

k(si

k,ink,simk,outk,si

k+1)

by distinguishing the three cases

1. opi

k=noev,

2. opi

k∈OpCjfor i6=jand

3. all remaining possibilities.

opi

k=noev:

Again,

noev

does not pose a problem, as in this case, s

k+1 =

k+1

corresponding to Equation 5.4.

opi

k∈OpCjfor i6=j:

In this case, the predicate part of op

is replaced by

Vw∈CVjw0=trw?within opi

k. We deduce:

effect opk(sk,ink,simk,outk,sk+1)

(1)

⇒effect opi

k(skVi,ink,simk,outk,(skVi)⊕(sk+1CVj))

(2)

⇒effect opi

k((skVi)⊕s0,ink,simk,outk,((skVi)⊕s0)⊕(sk+1CVj))

(3)

⇒effect opi

k(si

k,ink,simk,outk,si

k⊕(sk+1CVj)),

for

s0:= (si

k(ref(opk)∪Vi\Vj)).

The first implication is based on the fact that solely cut variables are modified

by op

, that is, the pre-state value needs to be kept for all remaining variables.

Moreover, as the value for the output parameters are not restricted within

, the output value out

can indeed be used. Implication

(2)

follows by

xon ref

(opk)

and all local variables (induction hypothesis, Lemma

5.3.12 and Lemma 5.3.13). As all other variables do not affect the execution

of the operation, implication (3) is immediate.

The state s

k+1 =si

k⊕(sk+1CVj)

satisfies the conditions of Equation 5.4 for any

x∈V:

154 5 Correctness of the Decomposition

x6∈ (V1∩V2):

Impossible, as for op

k∈

, all variables occurring within op

are shared variables. X

x∈CVj:Here, si

k+1 =sk+1, according to Equation 5.4. X

x∈(V1∩V2)\CVj:

For x

∈

mod

(opk)

, we get s

k+1 =

, according to Equation

5.4, third case. Otherwise, the variable is not modified within op

. If it is

referenced, s

, which is preserved by the operation and thus, s

k+1 =

k+1

, again matching with Equation 5.4. Otherwise, x

6∈ (

mod

(opk)∪

ref(opk)), and si

k+1 =si

kmatches with Equation 5.4, second case. X

All remaining cases:

Now,

effect

k=effect

holds according to Defini-

tion 4.3.10, and we get:

effect opk(sk,ink,simk,outk,sk+1)

(1)

⇒effect opi

k(skVi,ink,simk,outk,sk+1Vi)

(2)

⇒effect opi

k((skVi)⊕s0,ink,simk,outk,sk+1Vi)

(3)

⇒effect opi

k(si

k,ink,simk,outk,(sk+1Vi)⊕(si

kX)),

for i6=j,

s0:= (si

k(ref(opk)∪Vi\Vj)),

and

X:= (V1∩V2)\(mod(opk)∪ref(opk)).

For implication

(1)

, we use

effect

k=effect

. Implication

(2)

follows by s

xon ref

(opk)

and all local variables (induction hypothesis,

Lemma 5.3.12 and Lemma 5.3.13).

For the final implication,

(3)

, we use

effect

k=effect

and s

x, yielding that any modification of a variable within op

is correspondingly

possible within op

. We are left to deal with non-modified variables: for these,

as all local state variables and referenced state variables have consistent values

in the pre-state, they have consistent values in the post state as well. The

remaining state variables are exactly those described by the set X: variables

neither modified nor referenced within op

, which are not local to S

. For

these, the pre-state value must be preserved within the post state.

Finally, the state

(sk+1Vi)⊕(si

kX)

indeed satisfies the conditions of Equation

5.4 (where only the second and fourth case can apply), as for any state variable,

the pre-state value is kept for

(

1∩

2)\(

ref

(opk)∪

mod

(opk))

and otherwise,

the value from sk+1 is used. 2

Step 3:

So far, we constructed two traces

πi

out of

π∈

Traces

(S.OZ)

for which we showed

πi∈

Traces

(Si.OZ)

. It remains to be shown that tr

=πES∈(π1ES0kECπ2ES0)JR0K

5.3 Correctness for the Object-Z Part 155

holds. This is an immediate deduction due to

πiESi=trESi

modulo renaming and the

definition for the parallel composition of two traces ([

Ros98

]). This completes the proof

of the left-to-right implication.

Right-to-Left Implication

Let tr

∈

traces

((S1.OZ kECS2.OZ)JR0K)

, such that

(tr Op)∈traces(S.main)Op

have to show tr

∈

traces

(S.OZ)

. Based on tr

∈

traces

((S1.OZ kECS2.OZ)JR0K)

, there exist

πi∈Traces(Si.OZ), such that tr ∈(π1ES0kECπ2ES0)JR0K.

Again, we proceed in three steps: we define a trace

π=hs0,e0,s1,e1, . . . i

out of

πi=h

1, . . . i

(

Step 1

). In

(Step 2)

, we inductively show

π∈

Traces

(S.OZ)

Finally, we deduce tr =πES∈traces(S.OZ)(Step 3).

Step 1: For the definition of πon events, we obviously choose the events from tr:

ej:= tr.j.(5.5)

For the definition of the states of tr, we start by defining s

. Here, we use the result

from Lemma 5.3.9: in the following, let V1={x1,...,xn},

VY:= {y1,...,ym}={x|InitClos(x)⊆(V2\V1)}

and

VZ:= {z1,...,zl}= (V2\V1)\ {y1,...,ym}.

Furthermore, let c1,...,cl, with ci:tzi, such that

S.Init[x1/s1

0.x1]. . . [xn/s1

0.xn][y1/s2

0.y1]. . . [ym/s2

0.ym][z1/c1]. . . [zl/cl]

holds. Then:

s0:= (s1

0.x1,...,s1

0.xn,s2

0.y1,...,s2

0.ym,c1,...,cl).(5.6)

Note that we can freely choose any values c

for z

, as long as they extend s

and

to a valid initial valuation. Lemma 5.3.9 showed that such values for z

indeed

exist. Intuitively, the freedom of choice is substantiated by the fact that for the set V

, the

initial values within S

2.Init

are irrelevant for the specification S

: in case that any such

variable is referenced, it must have been modified before, as otherwise, an initial data

dependence would violate the condition

no crossing

. Thus, these values never become

relevant within S2, and we can safely refrain from using them within s0.

Based on the correctness for the CSP part from Section 5.2, tr can equally refer to both, traces

(

.main)

traces((S1.main kECS2.main)JR0K).

156 5 Correctness of the Decomposition

The definition for sk,k≥1, is given next:

sk.x:=











k.x,x∈(V1\V2),

k.x,x∈(V2\V1),

k.x,x∈(V1∩V2),x∈(mod(op1

k−1)∩mod(op2

k−1)),

k.x,x∈(V1∩V2),x∈(mod(op1

k−1)\mod(op2

k−1)),

k.x,x∈(V1∩V2),x∈(mod(op2

k−1)\mod(op1

k−1)),

sk−1.x,x∈(V1∩V2),x6∈ (mod(op1

k−1)∪mod(op2

k−1)).

(5.7)

Summarising, for state variables local to S

, we choose the value of s

. For shared

variables, we adopt modifications from the respective traces and keep the pre-state value,

if no modification is conducted. If a variable is modified in both traces, the modification

must be corresponding. This is based on the usage of transmission parameters, ensuring

that shared state variables must not distinctly be modified by the same operation. Thus,

for the third case, we could equally define sk.x:= s2

k.x.

Step 2:

In accordance with the left-to-right implication, we show a property describing

that state variables referenced by an operation op

always have identical values within

and πi:

Lemma 5.3.15. (Equality of values for referenced state variables, right-to-left)

Let πi∈Traces(Si.OZ), and let πbe defined according to Equations 5.5, 5.6 and 5.7. Then:

∀n≥0,∀x∈Vi,∀opi∈Si.Op •x∈ref(opi

n)⇒sn.x=si

n.x.

Proof.

We first show that the property holds for n

= 0

. For the sets V

and V

, the states

and s

are identically defined. This is not the case for the set V

. However, z

∈

ref

(opi

would yield that e

0∈

, as the set V

solely comprises variables local to S

. This is

impossible: any event, which can initially be executed within a trace of S

.main

, is an

element of E

. Otherwise, the corresponding DG-node

would violate the correctness

criterion disjointness, based on ei

0∈Ph2∩(Ph1∪C1).

Let n

∈

ref

(opi

and thus, x

∈

ref

(opn)

for some x

∈

.State

. Based on Equation

5.7, any modification conducted within

πi

is identical within

. This allows us to apply

the same ideas from Lemma 5.3.12 for op

. In particular, if x

∈(

mod

(opk)\

mod

(op1

k))

for some op

, either op

k=noev

or it is an element of E

, resulting in the exact same

case differentiation as in Lemma 5.3.12.

For op

, we have to consider one additional case: for x

∈

, we cannot assume

x. If xis modified somewhere in

π2

, the modification is identical to the one

, and we reside in the previous case. Now assume that x

∈

ref

(opn)

, and xis never

modified in

π2

. In this case, there exists an initial data dependence from S

.Init

to the

corresponding DG node

. Since op

references x

∈

,op

is an element of Op

and

thus,

is an element of

Ph2

. This yields a contradiction, as the connecting initial data

dependence violates no crossing.

Figure 5.12 illustrates the proof idea of the lemma. Here,

(∗)

denotes that

s0.x=s2

0.x

only holds for V\VZ.

5.3 Correctness for the Object-Z Part 157

0.x. . . s1

−→ s1

k+1.x. . . s1

n.xe1

−→ s1

n+1.x

=6=6=

s0.x. . . sk

−→ sk+1.x. . . sn.xen

−→ sn+1.x

(∗)6=6=

0.x. . . s2

−→ s2

k+1.x. . . s2

n.xe2

−→ s2

n+1.x

Figure 5.12: Illustration of Lemma 5.3.15

The corresponding lemma for local state variables is immediate:

Lemma 5.3.16. (Equality of values for local state variables, right-to-left)

Let

πi∈

Traces

(Si.OZ)

, and let

be defined according to Equations 5.5, 5.6 and 5.7. Let

j6=i. Then:

∀n≥1,∀x∈Vi,∀opi∈Si.Op •x∈(Vi\Vj)⇒sn.x=si

n.x.

Proof. The property holds based on Equation 5.7. 2

Note that the previous property does not hold for n

= 0

, as the initial states do not

correspond on the set {z1,...,zl}. Next, we show that πis an element of Traces(S.OZ):

Theorem 5.3.17. (Correctness of the decomposition: Object-Z part, second part)

Let πbe defined according to Equations 5.5, 5.6 and 5.7. Then, π∈Traces(S.OZ).

Proof. Again, the proof is conducted by induction on the length of π.

Induction Base:

s0|=S.Init directly follows by Equation 5.6 and Lemma 5.3.9.

Induction Step:

Again, let ek=opk.ink.simk.outk. By assumption,

enable opi

k(si

k,ini

k,simi

k)∧effect opi

k(si

k,ini

k,simi

k,outi

k,si

k+1)

holds. By using Lemma 5.3.15, we know that s

xholds for all referenced variables

within opi

Guard is Satisfied:

In order to show

enable

sim

, we start with op

k∈

that is, op

is a non-cut operation:

enable

k=enable

holds according to

Definition 4.3.10. We deduce:

158 5 Correctness of the Decomposition

enable opi

k(si

k,ini

k,simi

(1)

⇒enable opk(sk⊕si

k,ini

k,simi

(2)

⇒enable opk(sk⊕(skVi),ini

k,simi

(3)

⇒enable opk(sk,ini

k,simi

k).

Implication

(1)

is due to

enable

k=enable

and the fact that only variables

of V

are referenced in

enable

. The second implication follows by the induction

hypothesis and Lemma 5.3.15, again using that non-referenced variables within

enable

do not affect the truth-value of the associated predicate. The last

implication is immediate.

If we assume op

k∈

, the equation

enable

k=enable

holds as well,

and we proceed accordingly.

Operation is Executable with Compatible Successor State: Next, we show

effect opk(sk,ini

k,simi

k,outi

k,sk+1),

by distinguishing the two cases

1. opk∈Opiand

2. opk∈OpCi.

opk∈Opi:

Here,

effect

k=effect

and op

k=noev

i, according to

Definition 4.3.10. We get:

effect opi

k(si

k,ini

k,simi

k,outi

k,si

k+1)

(1)

⇒effect opk(sk⊕si

k,ini

k,simi

k,outi

k,sk⊕si

k+1)

(2)

⇒effect opk(sk⊕(skVi),ini

k,simi

k,outi

k,sk⊕s0)

(3)

⇒effect opk(sk,ini

k,simi

k,outi

k,sk⊕s0),

for

s0:= (si

k+1(ref(opk)∪mod(opk))).

The first implication is analogous to the considerations for the

enable

-schema,

and the last implication is obvious. For implication

(2)

, the value s

k+1.

xcan

solely be used in case that either xis correspondingly modified by op

and op

or the identical pre-state values is kept. For the remaining variables, the value

sk.xneeds to be used.

The state s

k+1 =sk⊕s0

satisfies the conditions of Equation 5.7 for any x

∈

the sole case of s

k+1

and Equation 5.7 differing is x

∈(

ref

(opi

k)\

mod

(opi

k))

But then, sk.x=si

k.x=si

k+1.

5.4 Correctness of the Renaming for the Decomposition 159

opk∈OpCi:

Again,

effect

k=effect

, according to Definition 4.3.10.

In addition,

effect

for j

isolely comprises

Vw∈CVj

. The

proof is corresponding to the previous case, except for the fact that now,

∈

mod

(opi

k)∩

mod

(opj

is possible. However, in this case, the modification

is identical based on Definition 4.3.10, which corresponds to Equation 5.7,

where we choose the modification from op1

k.2

Step 3:

π∈

Traces

(S.OZ)

and

πES=

tr hold, we immediately deduce tr

∈

traces

(S.OZ)

This completes the proof of the right-to-left implication and thus, the correctness proof of

the decomposition of the Object-Z part.

5.4 Correctness of the Renaming for the Decomposition

The previous sections showed correctness for the decomposition of both, the CSP part and

the Object-Z part of S. Preservation of control flow and data flow can only be achieved

by the introduction of additional parameters. One drawback of these parameters is the

required modification of the types of operations from S: equivalence of Sand S

can

only be shown modulo a renaming of events.

According to Section 4.3.4, the addition of parameters requires a channel renaming f.

As the interface of a specification declares the types of operations, the set of additional

parameters is identical for the CSP part and the Object-Z part. However, according to

Section 4.3, transmission parameters are solely restricted by the Object-Z part, whereas

the restriction of address parameters is limited to the CSP part.

For the definition of the CSP parts of S

and S

, we already introduced two renaming

relations

1:ES→ES1and RC

2:ES→ES2.

These relations determine the possible events the CSP parts of S

can communicate,

and they fix the values for the address parameters, whereas transmission parameters

remain unrestricted. Subsequently, in case that no restriction on either the transmission

parameters or address parameters is conducted, we write

tr and

add, respectively. If

the number of additional parameters is irrelevant, we write op

ato denote an event of

, according to Section 5.2. Note that none of these parameters have to exist. We recall

the definitions of RC

1and RC

i(op.x) := 









op.x.i,op ∈(Op1∩Op2)\(OpC1∪OpC2),

op.x?tr.a,op ∈OpC∧|l−1(op)|>1,

op.x?tr,op ∈OpC∧|l−1(op)|= 1,

op.x,otherwise.

The definition of S

OZ implicitly defines two renaming relations for the Object-Z parts

as well. The roles for restricting the different types of added parameters are switched: for

an event op

∈

, the Object-Z part of S

is able to communicate any event op

add,

160 5 Correctness of the Decomposition

as address parameters are unrestricted for the Object-Z part. Precisely, we get a renaming

relation for the Object-Z part, given as:

i(op.x) := 









op.x?add,op ∈(Op1∩Op2)\(OpC1∪OpC2),

op.x.t?add,op ∈OpC∧|l−1(op)|>1,

op.x.t,op ∈OpC∧|l−1(op)|= 1,

op.x,otherwise.

The renaming needs to be considered, when it comes to showing trace equivalence

between the original system and the decomposition. We use several notations for the

combinations of the four renaming relations RC

1,RC

2,RO

1and RO

•Ridenotes the union of RC

iand RO

•RCdenotes the union of RC

1and RC

2and, accordingly, ROthe union of RO

1and RO

•

Finally,

denotes the union of all renaming relations, that is, the union of

and

ROor, accordingly, R1and R2.

For achieving a comparison between both, the original system and its decomposition,

we consider the – in regard of

–inverse relation

, which removes the additional

transmission parameters and address parameters. More precisely, R0:ES0→ESand

R0(op.x.t.a) := op.x.

We are now able to relate Sto

(

1kEC

by means of

. Correctness for the

decomposition of the Object-Z part and the CSP part was carried out modulo

, and we

showed the equivalences

•S.main =T(S1.main kECS2.main)JR0Kand

•S.OZ =T(S1.OZ kECS2.OZ)JR0Kfor the set of traces conforming to the CSP part.

In order to facilitate reasoning about the individual component’s parts S

i.main

and S

OZ,

we show that

can be distributed over the parallel composition operator. Precisely, we

show the following equivalence in the semantic domain of the CSP trace model:

(S1.main kECS2.main)JR0KkES(S1.OZ kECS2.OZ)JR0K=T

((S1.main kECS2.main)kES0(S1.OZ kECS2.OZ))JR0K.

Here, the crucial aspect is that the synchronisation alphabet for the outer parallel compo-

sition changes from E

to E

, as the right hand side now synchronises over events after

the renaming took place.

We start the proof by showing a property about the composition of a general relation

and its inverse: if a relation

is total and injective, the composition

Re−1◦Re

is the

identity relation.

5.4 Correctness of the Renaming for the Decomposition 161

Lemma 5.4.1. (Composition law for injective and total relations)

Let Re ⊆ A × B be a relation, and let

Re−1:= {(b,a)|(a,b)∈Re}

be its inverse relation. If Re is total and injective, then

(Re−1◦Re) = IdA.

Proof.

We recall the definitions for a relation being total and injective and the one for

the composition of two relations:

•Re is total, if, and only if, ∀a∈ A ∃(a,b)∈ A × B • (a,b)∈Re.

•Re is injective, if, and only if, ∀(a,b),(a0,b0)∈Re •b=b0⇒a=a0.

•Re−1◦Re ={(x,y)∈ A × A | ∃ z∈ B • (x,z)∈Re ∧(z,y)∈Re−1}.

Based on the fact that

is total,

IdA⊆(Re−1◦Re)

holds. Now assume some

(

)∈

(Re−1◦Re)

and x

y. But then, there exists z

∈ B

, such that

(

)∈Re

and

(

)∈Re−1

The definition of Re−1yields (x,z),(y,z)∈Re, contradiction to Re being injective. 2

For an application of this property on our renaming relation, we show that

and

are both, total and injective:

Lemma 5.4.2. (Properties of event renaming)

The following properties for R,RCand ROare satisfied:

a) R,RCand ROare total.

b) R,RCand ROare injective.

c) (R0◦R)=(R0◦RC)=(R0◦RO) = IdESand for any CSP process Q:

•Q=Q0JRKfor some process Q0implies QJ(R◦R0)K=Q.

•Q=Q0JRCKfor some process Q0implies QJ(RC◦R0)K=Q.

•Q=Q0JROKfor some process Q0implies QJ(RO◦R0)K=Q.

Proof.

As the renaming relations are defined with respect to the whole set E

, we immediately

deduce this property. X

b) Immediately follows by the implication

(op1.x1.t1.a1=op2.x2.t2.a2)⇒(op1.x=op2.x).X

c) Based on Lemma 5.4.2, the combination of a) and b) yields

(R0◦R)=(R0◦RC)=(R0◦RO) = IdES.

Thus, (R◦R0◦R) = R,(RC◦R0◦RC) = RCand (RO◦R0◦RO) = RO.X2

162 5 Correctness of the Decomposition

We use these properties in the following theorem, showing the already mentioned

distributivity law for the inverse renaming. The core idea for its proof is the following:

both additional parameter types are either restricted by the decomposition’s Object-Z part

(transmission parameters) or by its CSP part (address parameters), but neither of them

by both. Therefore, if a synchronisation of some op

xbetween

(

1.main kEC

2.main)

and

(

kEC

)

is possible after removing the additional parameters, there exists

some op

aon which both parts can synchronise beforehand: the intersection of the

newly constructed event sets of the CSP part and the Object-Z part is non-empty.

Theorem 5.4.3. (Distributivity law for inverse renaming)

The inverse renaming relation R0distributes over the parallel composition kES, that is:

(S1.main kECS2.main)JR0K]kES(S1.OZ kECS2.OZ)JR0K=T

((S1.main kECS2.main)kES0(S1.OZ kECS2.OZ))JR0K.

Proof.

First, note that E

S=R0(

S0)

holds as

is total (Lemma 5.4.2, a)) and thus,

is surjective. Let P

1.main kEC

2.main

and Q

kEC

OZ. We prove the

theorem by showing that

(PkES0Q)JR0K

and P

JR0KkR0(ES0)

JR0K

are the initial states of a

strong bisimulation [Mil89]

R:= {(A,B)|A= (CkES0D)JR0K,B=CJR0KkR0(ES0)DJR0K},

where Cdepicts any reachable state within the labelled transition system of P, and D

denotes any reachable state within the labelled transition system of Q. Based on the

definition of bisimulation, we need to show two directions:

(1)

(

)∈ R

and B

→

for e

∈(

S∪ {τ})

, then there exists some A

, such that

→A0and (A0,B0)∈ R.

(2)

(

)∈ R

and A

→

for e

∈(

S∪ {τ})

, then there exists some B

, such that

→B0and (A0,B0)∈ R.

Based on the firing rules for CSP, renaming has no effect on

-transitions [

Ros98

]. Thus,

for the τ-case, both directions are immediate.

(1):

Let

(

)∈ R

and B

op.x

→

. Since

R0(

S0) =

, both processes C

JR0K

and D

JR0K

need

to synchronise on op

x. Based on the operational semantics of CSP, there exist

1,B0

2, such that B0=B0

1kR0(ES0)B0

2and

CJR0Kop.x

−→ B0

1and DJR0Kop.x

−→ B0

From 5.4.2, c), we deduce B0

1=B0

1J(R0◦RC)Kand B0

2=B0

2J(R0◦RO)K. Thus,

CJR0Kop.x

−→ B0

1J(R0◦RC)Kand DJR0Kop.x

−→ B0

2J(R0◦RO)K.

By applying Rand the firing rule for relational renaming from [Ros98], we get

Cop.x.t1.a1

−→ B0

1JRCKand Dop.x.t2.a2

−→ B0

2JROK

5.4 Correctness of the Renaming for the Decomposition 163

for all op

1∈RC(

)

and op

2∈RO(

)

. Here, we again apply Lemma

5.4.2, c), as C

J(RC◦R0)K=

Cand D

J(RO◦R0)K=

Dholds. The following observation

is the crucial point in this proof: the intersection of

RC(

)

and

RO(

)

is non-

empty, since the CSP part solely restricts the address parameters, whereas the

Object-Z part solely restricts the transmission parameters of an operation. Precisely,

•RC(op.x) = {op.x.?tr.a|aaddressing extension for op}and

•RO(op.x) = {op.x.t?add |ttransmission parameters for op}.

Thus, there exists some op

∈(RC(

)∩RO(

))

on which Cand Dcan

synchronise on. We deduce

(CkES0D)op.x.t.a

−→ (B0

1JRCKkES0B0

2JROK).

Again applying the firing rule for relation renaming, we get

(CkES0D)JR0Kop.x

−→ (B0

1JRCKkES0B0

2JROK)JR0K,

based on R0(op.x.t.a) = op.x. Finally,

(A0,B0) = ((B0

1JRCKkES0B0

2JROK)JR0K,(B0

1J(R0◦RC)KkR0(ES0)B0

2J(R0◦RO)K)) ∈ R.

The bisimulation diagram for this case is given next.

B=CJR0KkR0(ES0)DJR0Kop.x

−→ B0

1J(R0◦RC)KkR0(ES0)B0

2J(R0◦RO)K=B0

R R

A= (CkES0D)JR0Kop.x

−→ (B0

1JRCKkES0B0

2JROK)JR0K=A0

(2):For the second implication, assume that (A,B)∈ R and Aop.x

→A0, that is,

(CkES0D)JR0Kop.x

→A0.

Again, based on Lemma 5.4.2, we have the identity (R◦R0), yielding

(CkES0D)op.x.t.a

→A0JRK

for any op

∈R(

)

. Based on the operational semantics of CSP, there need to

exist some A0

1and A0

2, such that

A0JRK=A0

1kES0A0

Following up, we get

Cop.x.t.a

→A0

1and Dop.x.t.a

→A0

164 5 Correctness of the Decomposition

Application of R0leads to

CJR0Kop.x

→A0

1JR0Kand DJR0Kop.x

→A0

2JR0K

and finally,

CJR0KkR0(ES0)DJR0Kop.x

→A0

1JR0KkR0(ES0)A0

2JR0K.

This concludes the left-to-right implication, as

(A0,B0) = ((A0

1kES0A0

2)JR0K,A0

1JR0KkR0(ES0)A0

2JR0K)∈ R

holds. 2

A= (CkES0D)JR0Kop.x

−→ (A0

1kES0A0

2)JR0K=A0

R R

B=CJR0KkR0(ES0)DJR0Kop.x

−→ A0

1JR0KkR0(ES0)A0

2JR0K=B0

The previous theorem showed that the renaming relation can be distributed over the

parallel composition

kES

, allowing us to reason about S

i.main

and S

OZ and its parallel

composition, without considering the renaming relation.

5.5 CSP Laws for Parallel Composition

The last step in the chain of proof steps is the easiest one: we need to show that within

the parallel composition

(S1.main kECS2.main)kES0(S1.OZ kECS2.OZ),

OZ and S

2.main

can be redistributed, such that the resulting parallel composition

constitutes the assembly of S

and S

. In particular, the respective synchronisation

alphabets need to be correctly adapted.

The following lemma shows a generalisation of this property for arbitrary processes

with certain restrictions on their alphabets. Afterwards, we instantiate the lemma for our

specific case:

Lemma 5.5.1. (Redistribution of CSP processes, alphabetised parallel)

Let Pi,Qibe CSP processes and Ai,Bialphabets. Then,

(P1A1kA2P2)A1∪A2kB1∪B2(Q1B1kB2Q2)=(P1A1kB1Q1)A1∪B1kA2∪B2(P2A2kB2Q2).

5.5 CSP Laws for Parallel Composition 165

Proof. We use rules (2.4) XkY−sym

PXkYQ=QYkXP

and (2.5) XkY−assoc

(PXkYQ)X∪YkZR=PXkY∪Z(QYkZR)

from [Ros98] and incrementally deduce the equation:

(P1A1kA2P2)A1∪A2kB1∪B2(Q1B1kB2Q2)

=P1A1kA2∪B1∪B2(P2A2kB1∪B2(Q1B1kB2Q2)) ( XkY−assoc)

=P1A1kB1∪B2∪A2((Q1B1kB2Q2)B1∪B2kA2P2) ( XkY−sym)

=P1A1kB1∪A2∪B2(Q1B1kB2∪A2(Q2B2kA2P2)) ( XkY−assoc)

=P1A1kB1∪A2∪B2(Q1B1kA2∪B2(P2A2kB2Q2)) ( XkY−sym)

= (P1A1kB1Q1)A1∪B1kA2∪B2(P2A2kB2Q2) ( XkY−assoc)

In order to use the previous lemma in our context, we have to apply it with respect

to interface parallel. This can only be achieved, if all participating processes never

communicate outside their respective synchronisation alphabets:

Corollary 5.5.2. (Redistribution of CSP processes, interface parallel)

Let P

be CSP processes and A

their respective alphabets, that is, P

never communicates

outside of Ai, and Qinever communicates outside of Bi, respectively. Then:

(P1kA1∩A2P2)k(A1∪A2)∩(B1∪B2)(Q1kB1∩B2Q2) =

(P1kA1∩B1Q1)k(A1∪B1)∩(A2∪B2)(P2kA2∩B2Q2).

Proof.

Follows immediately from Lemma 5.5.1 and the fact that P

kX∩Y

XkY

holds„ if P,Qnever communicate outside Xand Y([Ros98]). 2

In the following section, the corollary will be instantiated by setting

•Pi:= Si.main,

•Qi:= Si.OZ,

•Ai:= ESiand

•Bi:= ESi.

166 5 Correctness of the Decomposition

5.6 Proof of the Main Theorem

Finally, we show Theorem 4.3.25 by subsuming the results of the previous sections:

Theorem 5.6.1. (Correctness of the decomposition)

Let S be a specification, and let

C= (C1,C2)

be a cut, yielding a decomposition into S

and

S2, according to Definition 4.3.24. Then, the following holds:

S=T(S1kECS2)JR0K,

where R0:ES0→ESis defined as

R0(op.x.t.a) := op.x,

with x depicting the original parameter values, t denoting the valuation for the possible

transmission parameters and a the valuation for the possible address parameters.

Proof.

=TS.main kESS.OZ (Def. of S)

=T(S1.main kECS2.main)JR0KkES(S1.OZ kECS2.OZ)JR0K

(Theorem 5.2.4, Theorems 5.3.14 and 5.3.17)

=T[(S1.main kECS2.main)kES0(S1.OZ kECS2.OZ)]JR0K(Theorem 5.4.3)

=T[(S1.main kES1∩ES2S2.main)kES0(S1.OZ kES1∩ES2S2.OZ)]JR0K(Lemma 4.3.19)

=T[(S1.main kES1S1.OZ)kES1∩ES2(S2.main kES2S2.OZ)]JR0K(Corollary 5.5.2)

=T[(S1.main kES1S1.OZ)kEC(S2.main kES2S2.OZ)]JR0K(Lemma 4.3.19)

=T(S1kECS2)JR0K(Def. of S1and S2)

Note that an application of Lemma 5.5.2 is indeed possible, as S

i.main

and S

OZ never

communicate outside of ESi.

This completes the proof of the main result of this thesis, Theorem 4.3.25. The theorem

allows us to apply the assume-guarantee-based proof rules from Chapter 3: as Sand

1||EC

are trace equivalent modulo renaming, we can safely replace S

by Sin an

application of (B-AGR) and (P-AGR).

After showing correctness of our decomposition approach, the next chapter will deal

with the question on how to identify reasonable decompositions, that is, correct decompo-

sitions, which most likely result in efficient compositional verification.

6Finding Reasonable Decompositions

Contents

6.1 Decomposition Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 168

6.1.1 First Heuristic: Cut Size . . . . . . . . . . . . . . . . . . . . . . 169

6.1.2 Second Heuristic: Even Distribution . . . . . . . . . . . . . . . 170

6.1.3 Third Heuristic: Few Transmission . . . . . . . . . . . . . . . . 170

6.1.4 Fourth Heuristic: Few Addressing . . . . . . . . . . . . . . . . . 172

6.2 Evaluation of Decomposition Heuristics . . . . . . . . . . . . . . . . 172

6.3 Candy Machine Revisited: Evaluation of Cuts . . . . . . . . . . . . . 174

6.4 Case Study: Two Phase Commit Protocol . . . . . . . . . . . . . . . 175

6.5 Discussion ................................ 180

6.6 RelatedWork................................181

The overall goal of our decomposition technique is an application within the com-

positional verification framework, as introduced in Chapter 3. So far, we showed the

correctness of our approach: the decomposition does not change the behaviour of the

specification in terms of our semantic domain. This allows us to apply assume-guarantee-

based proof rules with respect to the decomposed system and to infer a global result for

the original system.

However, for compositional verification to have a practical impact, the technique

needs to provide an advantage over monolithic, that is, non-compositional verification.

Therefore, it is essential to evaluate the effectiveness of the decomposition as, in general,

compositional verification does not automatically result in comparatively small time and

memory consumption during model checking.

Example 6.0.2.

Recall the specification of a candy machine from Figure 2.3. The set

C={

term

}

defines a valid (single) cut of the specification. A decomposition with respect

is impractical, as it results in S

1=T

S. Yet, even though we consider compositional

verification, the need to deal with the full state space of S remains.1

The question is how to describe and detect reasonable decompositions. In [

CAC06

the authors investigate the usefulness of assume-guarantee reasoning by evaluating all

possible decompositions on five different case studies. The overall results are not very

encouraging as, in terms of the size of the explored state spaces, monolithic verification

often succeeds over compositional verification. This leads the authors to the following

statements:

1From now on, as a valid cut uniquely defines a decomposition, we will synonymously use both terms.

168 6 Finding Reasonable Decompositions

Deciding how to partition the subsystems into S

and S

is not easy and can have a

significant impact on the time and memory needed for verification. [...] Thus, randomly

selecting decompositions would likely not yield a decomposition better than monolithic

verification. [CAC06]

As a possible solution to this problem, the authors recommend to investigate heuris-

tics to guide the software engineer towards the best possible decompositions: in this

case, assume-guarantee-based verification most often outperforms non-compositional

verification.

These considerations motivate the following strategy: in order to evaluate the valid de-

compositions which our technique generates, we define several context-specific heuristics,

focusing on the underlying verification framework and the definition of the decomposition

itself. These heuristics serve as the basis for a classification of all correct decompositions:

those, which are unreasonable or dominated by other ones (see Section 6.2), are no

longer considered - the remaining decompositions can be further compared by prioritising

specific heuristics.

This chapter is organised as follows: in Section 6.1, we motivate and define our context-

specific heuristics. The following section discusses an evaluation of the results by giving a

very brief introduction into the topic of multi-valued optimisation [

Ehr00

]. In Sections

6.3 and 6.4, respectively, we illustrate and apply the heuristics and evaluate them for the

candy machine specification and a second, slightly bigger, case study. The final sections

discuss the approach and related work.

6.1 Decomposition Heuristics

Several factors influence the effectiveness of compositional reasoning in general. In

[

dRHH+01

], the authors elaborate on the question of when to use a compositional

style of proof and when to use a non-compositional one. For instance, they argue that

compositional verification becomes infeasible, if a system is tightly-coupled, that is, any

decomposition will result in a lot of common elements and shared behaviour, or if the

system comprises global invariants, which cannot be split up.

Choosing the most effective decompositions cannot be established in an automatic

manner. Due to the context-specific verification frameworks, the usage of different model

checkers or the structure of the specifications and verification properties, there is no

universally optimal decomposition. However, one particular issue exerts the dominating

influence on the efficiency of compositional verification and model checking in general:

the size of the state space, which needs to be explored. Thus, according to [

CAC06

], we

state that one decomposition is better than another one, if the number of states explored

during model checking is comparatively smaller. We need to define heuristics, favouring

decompositions with a relatively small state space.

The evaluation of our approach will use an implementation of the learning-based

framework from Section 3.2.3 and compare it to direct model checking of the original

system. We derive our heuristics from the following two requirements:

Small Interface:

The size of E

within the system S

1kEC

should be small. In general,

6.1 Decomposition Heuristics 169

the smaller the interface between both components, the less shared behaviour and

fewer communication between them, and the looser the components are coupled.

This results in a smaller number of states, which have to be explored during

model checking. In the context of AGR and according to [

CS07

], the smaller the

assumption alphabet, the more efficient the L

∗

algorithm in the learning-based

framework from Section 3.2.3. More precisely, the number of L

∗

membership

queries directly depends on the assumption alphabet, which itself closely depends

on the size of EC.

Equal Size of Components:

The size of the components S

and S

within S

1kEC

should approximately be the same. The question of how to find a good partitioning

of a system is discussed in [

Nam07

]. The author argues that an even distribution

of the number of system variables over the components leads to a more effective

compositional verification. Moreover, in [

GMF07

], the authors state that the

execution time of the L

∗

algorithm is exponential in the size of S

and S

. If we

assume s

to denote the size of S

and s

the size of S

2s1+ 2s2

is minimal for

, in case that s

is fixed. This justifies the requirement that both

components should have about the same size.

Based on these two requirements, we derive four different heuristics, with one of them

related to Equal Size of Components and the remaining three based on Small Interface.

These heuristics will be given as functions, mapping a specific decomposition on a certain

value within the natural numbers. A comparatively better decomposition has a lower

value, that is, we aim at a minimisation of the function values. For each heuristic, we start

by stating the principal characteristic and give an intuitive description. Subsequently, we

introduce the mathematical definition.

6.1.1 First Heuristic: Cut Size

The first heuristic, which we call

cut size

, is related to the requirement that the interface

between both components should be relatively small. A small number of nodes within

the cut is preferable, as the size of E

depends on the number of corresponding operation

nodes, that is,

EC={| OpC|} ={| l[C1]∪l[C2]|}

holds. This leads to the following objective for the first heuristic:

hCS: Minimise the number of cut nodes.

The fewer nodes contained in the cut, the smaller the common elements to both

specification parts and thus, the smaller the shared behaviour and the assumption

alphabet. A mathematical definition for this heuristic obviously maps a cut on its number

of elements. We summarise the first heuristic in Table 6.1.

170 6 Finding Reasonable Decompositions

Notation Name of Heuristic Description Motivation

hCS cut size

Minimise number of cut

nodes.

Small Interface.

Mathematical Definition

hCS(C) := #C

Table 6.1: Heuristic hCS:cut size

6.1.2 Second Heuristic: Even Distribution

The second heuristic,

even distribution

, targets the Equal Size of Components. In order to

measure the size of a component, we count the number of operation nodes corresponding

to S1and S2, leading to the following objective:

hED: Minimise the difference between the number of operation nodes corresponding to S1

and S2.

Based on Definition 4.3.1, we get

•Ph1∪Ph3∪C1∪C2for the set of nodes according to S1and

•Ph2∪C1∪C2for the set of nodes according to S2.

The mathematical definition for the second heuristic from Table 6.2 computes the

absolute value of the difference between these sets. As the set of cut nodes is contained

in both of them, it can be neglected.

Notation Name of Heuristic Description Motivation

hED even distribution

Minimise size difference be-

tween both components.

Equal Size of Com-

ponents.

Mathematical Definition

hED(C) :=|#(Ph1∪Ph3)−#Ph2|

Table 6.2: Heuristic hED:even distribution

6.1.3 Third Heuristic: Few Transmission

The final two heuristics are again related to the requirement Small Interface. In Section

4.3.2, we introduced the concept of transmission parameters to ensure a preservation of

a specification’s data flow within the decomposition. These parameters are required to

6.1 Decomposition Heuristics 171

ensure the correctness of the technique. Unfortunately, they increase the set of cut events,

that is, the set EC.

In order to measure the additional amount of cut events, we need to refer to the types

of these parameters: simply counting the number of parameters would be too coarse.

For instance, one additional parameter of type

{1,...,10}

causes the size of E

to be

increased by the factor of

, whereas two parameters of type

{1,2}

only increase it by

the factor of 4. In order to define the third heuristic hFT, we proceed as follows:

•

The number of elements of

{| op |}

(see Definition 2.2.5) increases by the amount

of possible parameter extensions with respect to all transmission parameters. Thus,

for any cut operation op, we compute the product over the cardinality of each

transmission parameter type.

•

An operation can have multiple occurrences within the cut. Even though this is not

reflected in the size of E

, we still need to deal with it by multiplying the previous

result with the number of cut-occurrences of the operation.

•Finally, we compute the sum over the results for all cut operations.

Henceforth, tr i denote transmission parameters, and ty

depicts the type of the

parameter pof the operation op. We illustrate the weight computation for the third

heuristic with an example:

Example 6.1.1.

Let

C={

be a valid cut for some specification S, such that op

occurs once, and op

occurs twice within S

.main

. Let op

comprise two transmission param-

eters of types

and

{1,2,3}

. Furthermore, let op

comprise one transmission parameter

of type

P(B)

. For the first operation, we get

op1

tr 1∗#

op1

tr 2= 2 ∗3 = 6

. Moreover,

op2

tr 1= 22= 4

. As op

occurs twice within S

.main

, we multiply the second value by

which results in the overall weight of hFT(C) = 6 + 8 = 14 for the third heuristic.

Another question is how to deal with infinite data types. One solution could be the

definition h

FT(C) := ∞

in case that there exists at least one operation within

with one

transmission parameter of infinite type. However, in this case, any number of transmission

parameters of infinite types would result in the same value for the given heuristic. During

model checking, infinite data types need to be abstracted to some finite subset - either

by the model checker or the user itself. Therefore, we follow a different approach:

in our cardinal arithmetic, we assume that

∞

can be mapped to some bound

MaxInf

Based on the actual cardinality of

∞

for the model checker,

MaxInf

can appropriately be

instantiated.

Subsuming, we require:

hFT: Minimise the amount and the type cardinality of the transmission parameters.

The third heuristic is summarised in Table 6.3. According to the previous considerations,

#tyop

p=MaxInf is possible.

172 6 Finding Reasonable Decompositions

Notation Name of Heuristic Description Motivation

hFT few transmission

Minimise amount and type car-

dinality of transmission pa-

rameters.

Small Interface.

Mathematical Definition

hFT(C) := let Top := (#l−1(op)∗#tyop

tr 1∗ · · · ∗ #tyop

tr n)in Pop∈l[C]Top

Table 6.3: Heuristic hFT:few transmission

6.1.4 Fourth Heuristic: Few Addressing

In correspondence to transmission parameters, Section 4.3.3 introduced the concept of

address parameters to preserve the control flow within the decomposition. Again, these

parameters increase the size of EC.

Contrary to transmission parameters, address parameters never have an infinite type.

Thus, we can precisely determine the weight for these parameters, motivating separate

measurements for both parameter types. We introduce a new heuristic, which mainly

corresponds to the previous one, and we set the following objective:

hFA: Minimise the amount and the type cardinality of the address parameters.

Notation Name of Heuristic Description Motivation

hFA few addressing

Minimise amount and type car-

dinality of address parame-

ters.

Small Interface.

Mathematical Definition

hFA(C) := let Aop := (#l−1(op)∗#tyop

ad 1∗ · · · ∗ #tyop

ad n)in Pop∈l[C]Aop

Table 6.4: Heuristic hFA:few addressing

The mathematical definition for this heuristic corresponds to the one for

few trans-

mission

, except that now

p=MaxInf

is impossible. In the definition, ad i denote

address parameters.

6.2 Evaluation of Decomposition Heuristics

The previous section introduced several individually defined heuristics, which are possibly

conflicting with each other. In order to evaluate the set of valid decompositions (or

6.2 Evaluation of Decomposition Heuristics 173

solutions, as we will call them in the context of this chapter), the joint application

of all heuristics is required. This obviously results in a trade-off between the specific

requirements for good decompositions: for instance, assigning a high priority to heuristic

will result in a set of cuts with potentially high value for heuristic h

. The general

problem is well known as the task of multi-objective optimisation [Ehr00, Zel74].

Besides this trade-off and despite allowing the specific heuristics to be scaled and thus

prioritised, some decompositions or solutions can be neglected entirely. These are the

ones for which one resulting component is on the scale of the original specification:

here, compositional verification needs to deal with at least the same state space as

non-compositional one.

Definition 6.2.1. (Unreasonable decomposition)

Let S be a CSP-OZ class specification, and let

denote the set of all valid cuts of S. We say

that C∈ C is unreasonable, if, and only if,

Ph1∪Ph3∪C=op(N)or Ph2∪C=op(N).

Regarding our heuristics, we immediately deduce that a decomposition is unreasonable,

if, and only if, the sum over the values for the heuristics h

and h

is equal to the size

of all operation nodes of the DG:

Lemma 6.2.2. (Connection between unreasonable decompositions and heuristics)

Let S be a CSP-OZ class specification, and let

denote the set of all valid cuts of S.

C∈ C

unreasonable, if, and only if,

hCS(C) + hED(C)=#op(N).

Proof.

Immediate: any operation node is uniquely assigned to one of the sets

Ph1

Ph2

Ph3and C. Furthermore, hCS(C)=#Cand hED(C) =|#(Ph1∪Ph3)−#Ph2|holds. 2

Unreasonable decompositions will generally not be considered within our evaluation. For

the further restriction of the set of valid cuts, we reason about dominated decompositions.

Intuitively, they are outmatched by some other decomposition in any heuristic. In the

context of multi-objective optimisation, the remaining solutions are called Pareto-optimal

[

Par71

]. We will introduce the definition for our context, where we refer to the one from

[DW04]. Let h1,...,h4denote the heuristics, as introduced in Section 6.1:

Definition 6.2.3. (Weakly dominated decomposition [DW04])

Let S be a CSP-OZ class specification, and let

denote the set of all valid cuts of S. We say

that

C∈ C

is (weakly) dominated by

C0∈ C

(with respect to

{

), if, and only if,

(∀i∈ {1,2,3,4} • hi(C0)≤hi(C)) ∧(∃i∈ {1,2,3,4} • hi(C0)<hi(C)).

We illustrate the definition by an example.

Example 6.2.4.

Recall the candy machine specification from Section 2.2.1. Both,

{

switch

abort

}

and

C0={

switch

}

denote valid cuts. For the evaluation of the different

heuristics, we get:

174 6 Finding Reasonable Decompositions

hCS(C)=2 hCS(C0)=1

hED(C)=2 hED(C0)=1

hFT(C) = MaxInf hFT(C0) = MaxInf

hFA(C) = 0 hFA(C0) = 0

Here, h

FT(C) =

FT(C0) = MaxInf

, due to one transmission parameter of type

. As

i(C0)≤

i(C)

for any of the four heuristics and as strictly smaller holds for the first two,

{switch,abort}is weakly dominated by {switch}.

Independent of the scaling, a weakly dominated cut never achieves the relatively best

results. In the implementation of our decomposition approach, solutions dominated by

other ones will thus accordingly be marked and can be suppressed. Note that even if

highly unlikely, a dominated solution might still be the most efficient one. This is due to

the respective property under interest, the specific characteristics of the model checker

and the general nature of a heuristic approach, which is experience-based and only points

the direction.

For the remaining near-optimal solutions, no general classification is possible. Yet, an

elimination of all dominated cuts results in a smaller set of possible decompositions,

which can then be further interpreted, according to the priority for each heuristic.

6.3 Candy Machine Revisited: Evaluation of Cuts

Next, we are interested in the evaluation of the set of all valid cuts of a specification

based on our heuristics. We recall the case study of a candy machine from Chapter 2.

Here, we restrict ourselves to the special case of a single cut from Definition 4.2.10 due to

two reasons:

•The set of all possible general cuts is too large for an effective comparison.

•

Defining two different cut sets is impractical, as the specification does not comprise

any outer recursion.

Subsuming, there are

valid (single) cuts, which are depicted in Table 6.5. We

additionally denote if the respective cut is, according to Definitions 6.2.1 and 6.2.3,

non-reasonable or weakly dominated by another one.

No. Cut Reasonable? Non-Dominated?

1{abort,deliver,order,pay,payout,select,switch}No No

2{abort,deliver,order,payout,select,switch,term}No Yes

3{abort,deliver,order,payout,select,switch}Yes No

4{abort,deliver,order,payout,select,term}No Yes

5{abort,deliver,order,select,switch,term}No Yes

6{abort,deliver,order,select,switch}Yes No

7{abort,deliver,order,select,term}No Yes

8{abort,deliver,payout,term}No Yes

9{abort,deliver,term}No Yes

6.4 Case Study: Two Phase Commit Protocol 175

10 {abort,order,pay,payout,select,switch}No No

11 {abort,order,payout,select,switch}Yes No

12 {abort,order,select,switch}Yes Yes

13 {abort,pay,payout,switch}No No

14 {abort,payout,switch}Yes No

15 {abort,payout,term}No Yes

16 {abort,payout}No Yes

17 {abort,switch}Yes No

18 {abort,term}No Yes

19 {abort}No Yes

20 {deliver,order,select,switch,term}No Yes

21 {deliver,order,select,switch}Yes No

22 {deliver,order,select,term}No Yes

23 {deliver,term}No Yes

24 {order,select,switch}Yes No

25 {switch}Yes Yes

26 {term}No Yes

Table 6.5: Set of valid cuts for the candy machine

Even though the set of valid cuts is rather large, only two solutions are reasonable and

non-dominated. These are

{

abort

order

select

switch

}

and

{

switch

}

. In Chapter 7, we

will compare both cuts.

6.4 Case Study: Two Phase Commit Protocol

In order to further illustrate and exemplify our decomposition technique, we introduce

a second case study: a specification of the Two-Phase-Commit Protocol (TPCP) [

BHG87

dRHH+01

]. The purpose of the protocol is to guarantee consistency of Nlocal sites (or

pages) of a distributed database. Instructed by a coordinator process, the protocol results

in either all pages committing their transaction or all pages aborting it. The basic system

structure and communication is illustrated in Figure 6.1. As the name says, the protocol

works in two phases:

Phase 1 - Commit-Request:

The protocol starts with the coordinator process informing

all participating pages about a request to commit the current transaction. Next,

all pages execute the transaction and send a vote to the coordinator, dependent on

whether the local transaction succeeded (YES) or failed (NO). The coordinator

collects the votes and decides to either COMMIT, in the case that all votes agree on

YES, or to ABORT the transaction. Figure 6.2 illustrates the workflow of phase one

for the coordinator and, for simplification, for one instance of Page.

Phase 2 - Commit:

The coordinator informs all pages about the decision. All participat-

ing sites behave accordingly: an abort leads to an undo of the transaction, while

a commit leads to completion. In any case, the sites output the result and send an

acknowledgement to the coordinator. An illustration is given in Figure 6.3.

176 6 Finding Reasonable Decompositions

Page3

Page1

Page4

Page2

Database Pages

result of

transaction

commit or

abort

Coord

Coordinator Process

Figure 6.1: Illustration of the Two Phase Commit Protocol

Page.main

Coord.main

Page.PhaseTwo

Coord.PhaseTwo

YES,

request

execute vote

vote decide

Figure 6.2: Phase one of the Two Phase Commit Protocol

Let Nbe the number of pages participating in the protocol, and let Votes and Trans be

the following two base types:

Votes == {YES,NO}

Trans == {COMMIT,ABORT}

Here, Votes represents the possible votes of the pages, dependent on whether the

transaction succeeded or not, whereas Trans describes the actual decision to either

commit or abort the transaction.

The specification, as given in Figure 6.4, is the CSP-OZ class for the central coordinator.

The ordering of events within the CSP part corresponds to Figures 6.2 and 6.3.

For the Object-Z part, the class’ state space comprises two variables: decC of type Trans,

for holding the final decision and votes of type

Votes, for storing the votes of the different

pages. The operation vote comprises an input parameter of type Votes, and its value is

6.4 Case Study: Two Phase Commit Protocol 177

COMMIT,

ABORT

Page.PhaseTwo

Coord.PhaseTwo

Page.Result

Skip

inform

inform acknowledge

Skip

acknowledge

result

complete

undo

Figure 6.3: Phase two of the Two Phase Commit Protocol

Coord

chan request chan vote : [vo? : Votes]chan decide

chan inform : [in! : Trans]chan acknowledge

main c

=k| 0<i≤N(request →Skip);

k| 0<i≤N(vote?vo →Skip); decide →PhaseTwo

PhaseTwo c

=k| 0<i≤N(inform?in →Skip);

k| 0<i≤N(acknowledge →Skip)

decC :Trans

votes :PVotes

Init

decC =ABORT

effect request

∆(votes)

votes0=∅

effect vote

∆(votes)

vo? : Votes

votes0=votes ∪ {vo?}

effect inform

in! : Trans

in! = decC

effect decide

∆(decC)

if (NO ∈votes)then decC0=ABORT else decC0=COMMIT

Figure 6.4: Two Phase Commit Protocol: Coord specification

added to the set votes.decide evaluates the set by assigning decC to ABORT in case that

at least one page votes with NO and to COMMIT otherwise. Finally, inform sends the

evaluation result to all participating pages by using an output parameter of type Trans.

The class Coord operates in parallel with Ninstantiations of the class Page, as given in

Figure 6.5. The state space of the Object-Z part of Page holds two variables decP of type

Trans, corresponding to Coord

decC, and stable of type

, for representing a successful

(true) or unsuccessful (false) execution of the transaction. execute nonderministically

178 6 Finding Reasonable Decompositions

Page

chan request chan execute chan vote : [vo! : Votes]

chan inform : [in? : Trans]chan undo chan complete

chan result : [r! : Trans]chan acknowledge

main c

=request →execute →vote?vo →PhaseTwo

PhaseTwo c

=inform?in →Result

Result c

= (undo →result?r→acknowledge →Skip

2complete →result?r→acknowledge →Skip)

decP :Trans

stable :B

Init

decP =ABORT

stable

effect execute

∆(stable)

stable0∈ {true,false}

effect vote

vo! : Votes

stable ⇒vo! = YES

¬stable ⇒vo! = NO

effect inform

∆(decP)

in? : Trans

decP0=in?

enable complete

decP =COMMIT

effect result

r! : Trans

r! = decP

enable undo

decP =ABORT

Figure 6.5: Two Phase Commit Protocol: Page specification

assigns a value to stable, dependent on which vote decides to either vote YES or NO.inform

receives the decision to commit or abort the transaction, after which the specification

either conducts a rollback (undo) or a permanent write (complete). Finally, the result of

the transaction is communicated.

The full system is specified as

System =CoordkI(k| 0<i≤NPage),

where I

={| request,vote,inform,acknowledge |}

denotes the synchronisation alphabet

for both classes.

Again, we are interested in an evaluation of the set of all valid cuts. For simplicity, we

again solely deal with single cuts. Independent of the number of pages,

valid cuts

can be identified. These are given in Table 6.6, where an operation name is abbreviated

by its first four letters. Whether a certain cut is dominated by another one depends on

the value of N. Thus, within the following table, we assume N

≥3

. Overall, there exist

reasonable and non-dominated cuts for the specification of the Two Phase Commit

Protocol.

6.4 Case Study: Two Phase Commit Protocol 179

No. Cut Reasonable? Non-Dominated?

1{ack,comp,deci,exec,info,resu,undo,vote}No No

2{ack,comp,deci,info,resu,undo,vote}No No

3{ack,comp,deci,info,resu,undo}No No

4{ack,comp,info,resu,undo}No No

5{ack,comp,resu,undo}No No

6{ack,comp,resu}No No

7{ack,resu,undo}No No

8{ack,resu}No Yes

9{ack}No Yes

10 {comp,deci,exec,info,requ,resu,undo,vote}No No

11 {comp,deci,exec,info,requ,undo,vote}No No

12 {comp,deci,exec,info,requ,vote}No No

13 {comp,deci,exec,info,resu,undo,vote}Yes No

14 {comp,deci,exec,info,undo,vote}Yes No

15 {comp,deci,exec,info,vote}Yes No

16 {comp,deci,info,resu,undo,vote}Yes Yes

17 {comp,deci,info,resu,undo}Yes Yes

18 {comp,deci,info,undo,vote}Yes No

19 {comp,deci,info,undo}Yes Yes

20 {comp,deci,info,vote}Yes No

21 {comp,deci,info}Yes No

22 {comp,info,resu,undo}Yes Yes

23 {comp,info,undo}Yes Yes

24 {comp,info}Yes Yes

25 {deci,exec,info,requ,undo,vote}No No

26 {deci,exec,info,requ,vote}No No

27 {deci,exec,info,undo,vote}Yes No

28 {deci,exec,info,vote}Yes No

29 {deci,exec,requ,vote}No No

30 {deci,exec,vote}Yes No

31 {deci,info,undo,vote}Yes No

32 {deci,info,undo}Yes No

33 {deci,info,vote}Yes No

34 {deci,info}Yes No

35 {deci,vote}Yes Yes

36 {exec,requ,vote}No No

37 {exec,requ}No No

38 {exec,vote}Yes No

39 {info,undo}Yes Yes

40 {info}Yes Yes

41 {requ}No No

42 {vote}Yes No

Table 6.6: Set of valid cuts for the TPCP

180 6 Finding Reasonable Decompositions

Some of the valid cuts are unreasonable. For instance, the decomposition corresponding to

{

acknowledge

}

results in an equal size of the first component and the original specification.

It is interesting to note that some cuts, which one would intuitively expect to result

in a decomposition effective for compositional reasoning, are dominated and thus ruled

out. One example is the cut

{

vote

}

, which is dominated by

{

inform

}

. Dependent on the

number of pages N, we get

hCS({vote})=2∗N hCS({inform})=2∗N

hED({vote})=6∗N+ 1 hED({inform})=2∗N−1

hFT({vote}) = 8 ∗N hFT({inform}) = 4 ∗N

hFA({vote}) = 2 ∗N3hFA({inform}) = 2 ∗N3

The values for h

and h

are identical. However,

{

inform

}

results in a distribution of

the set of operation nodes closer to an even distribution than the one for

{

vote

}

. Addition-

ally,

{

vote

}

requires one transmission parameter of cardinality

Votes

= 4

, reflecting

the variable Coord

votes, whereas

{

inform

}

sufficiently uses one additional parameter of

cardinality #Trans = 2, corresponding to Page.decP within the decomposition.

In contrast to the specification of a candy machine, the evaluation does not yield a

small set of possible solutions. A thorough evaluation and comparison of the remaining

set of reasonable and non-dominated cuts will be conducted in Chapter 7, where we

introduce our implementation framework and give the experimental results for both case

studies.

6.5 Discussion

As the name implies, a heuristic approach, setting up context-specific rules-of-thumb,

cannot be expected to precisely and completely cover all aspects of the underlying

problem, neither can it generate a single optimal solution. Hence, we keep the approach

as least restrictive as possible by still guiding the engineer to head into the right direction.

First, our aim for introducing the described heuristics is a classification of the set

of valid cuts or decompositions of a specification. Even though the implementation of

our approach focusses on the model checker

FDR2

, we do not define the heuristics by

exploiting its specific characteristics. By doing so, we keep the approach independent of a

specific model checker.

Second, in contrast to the slicing technique, as introduced in [

Brü08

], we do not

consider the property under interest. As the alphabet of the generated assumption during

learning not only depends on the set of cut events but also on the set of events occurring

in the verification property, it could be reasonable to integrate the alphabet of the property

as well. However, we choose not to do so, as we want to keep the decomposition approach

independent of a certain verification property.

Finally, the previously introduced heuristics can be applied in any compositional

verification setting – they are not limited to the learning based framework, which we

consider. This is due to the fact that we try to keep the state space of the decomposition

(and thus the interdepences between both components) small, which is a reasonable

strategy, independent of any compositional verification framework.

6.6 Related Work 181

Yet, the following question remains: why do the previously defined heuristics most

likely result in a set of practical solutions?

We investigated the different possibilities, causing a large state space, which needs to

be explored during model checking. Here, we referred to two certain paradigms, which

are generally valid for compositional verification [

CAC06

dRHH+01

GL91

CGP03

]: a

strong connection between both components results in a high memory consumption

and an increased run-time during verification. In addition, large components cause

a large state space, which needs to be built up during model checking. The previous

heuristics are closely related to both paradigms, as they investigate the definition of

our decomposition technique and evaluate different possibilities to keep the cohesion

between the components and their individual state spaces relatively small.

The different heuristics cannot be seen as equally important for any kind of specification.

In addition, they conflict with each other. For instance, often, the larger the cut size for a

decomposition, the smaller the size difference between both components, simply because

the cut is neglected for the second heuristic.

Therefore, the actual evaluation of the set of valid decompositions must not be restricted

to the specific values, given by the mathematical definitions of the heuristics. In fact, as

we will see in Chapter 7, our implementation framework allows the user to prioritise

certain heuristics by computing the weighted sum over all values.

However, in order to not mislead the user, several solutions can be neglected. We

discussed this topic in Section 6.2: an evaluation of valid decompositions comparatively

worse than other ones, that is, weakly dominated ones, is unnecessary. The same applies

to unreasonable decompositions.

Summarising, the approach presented in this chapter automatically restricts the set of

valid solutions as much as possible. This is done by eliminating those decompositions,

which are impractical with respect to our heuristics or the generated state space size.

Due to the nature of a heuristics-based approach, human intervention is still required

for an evaluation of the remaining set of valid decompositions. However, this set is

comparatively small in relation to the set of all valid cuts.

6.6 Related Work

Several works from different areas investigate heuristic approaches to cope with the

state explosion problem during model checking. The work closest to ours is presented

in [

Nam07

]. For learning-based compositional verification for models, described as

symbolic transition systems (STS), the author chooses to partition a given system into

several components, based on an algorithm for hypergraph partitioning [

KK99

]. The

approach follows the general idea for an even distribution of the state variables of the

STS and also aims at a minimisation of the interdependences between the components.

The decomposition is performed fully automatically, not allowing the user to guide the

framework to a potentially better partitioning, not complying to the static requirements.

In addition, the author does not consider the control flow or a dependence analysis, and

the approach does not take the alphabet of the generated assumptions into account.

182 6 Finding Reasonable Decompositions

In order to cope with the state explosion problem during model checking of systems

already composed of several components, in [

SLU89

], the authors present several alterna-

tive heuristic rules to reduce the state space of the system, focusing on the LTS semantics

of a system. The work presented in [

TJ02

] follows a similar approach by, for instance,

developing heuristics to fusion states or transitions or eliminating redundant states.

In the context of the L

∗

algorithm, in [

GP09

], the authors present a strategy for

interface generation of software components. They implemented their approach for Java

PathFinder (JPF) [

NAS

], a verification framework for Java byte code. Based on their

learning framework for interface specifications, the authors also implemented assume-

guarantee reasoning in JPF. JPF itself uses different search heuristics for an effective

identification of possible bugs, eventually complementing compositional verification.

Further away from our approach, Dirks and Olderog [

OD08

] investigate the specifi-

cation and the model checking of real-time systems. In their semantic domain, the first

author developed an approach for heuristics-based planning and model checking [

Die05

Another heuristics-based approach, in order to more efficiently direct a model checker

to potential counterexamples, is directed model checking [

ESB+09

]. Edelkamp et. al

investigate directed model checking for SPIN [Hol03].

Multicriteria optimisation is an extensively researched area with a lot of different

textbooks and articles giving a profound overview and insight on the topic [

Ehr00

DW04

SNT85

]. We concentrate on the definition of Pareto-optimality which was introduced in

[

Par71

] and we restrict ourselves to discrete optimisation, that is, we do not consider real

values within our heuristics.

This concludes the current chapter. The next chapter will introduce the implementation

of our approach, including the modelling, the heuristics-based decomposition of a system

and a subsequent direct or learning-based compositional verification. In addition, we

evaluate the non-dominated and reasonable decompositions for both case studies and

provide some significant experimental results.

7Implementation and Experimental Re-

sults

Contents

7.1 Syspect ...................................184

7.1.1 ClassDiagrams........................... 184

7.1.2 StateMachines........................... 186

7.1.3 Component Diagrams . . . . . . . . . . . . . . . . . . . . . . . 187

7.1.4 Export to CSP-OZ . . . . . . . . . . . . . . . . . . . . . . . . . . 187

7.2 Decomposition Framework for Syspect . . . . . . . . . . . . . . . . 188

7.2.1 Decomposition Plug-In . . . . . . . . . . . . . . . . . . . . . . . 189

7.2.2 MassValidation........................... 191

7.2.3 Model Checking with FDR2 and the CSPLChecker . . . . . . . . 192

7.2.4 Counterexample Analysis . . . . . . . . . . . . . . . . . . . . . 196

7.2.5 Overall Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 198

7.3 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.3.1 Overview .............................. 200

7.3.2 Verification Results for the Candy Machine . . . . . . . . . . . . 201

7.3.3 Verification Results for the Two Phase Commit Protocol . . . . . 204

7.3.4 Verification Results for the Number Swapper . . . . . . . . . . . 207

7.3.5 Discussion.............................. 207

The previous chapters introduced an approach for the decomposition of formal spec-

ifications, allowing for an application of compositional verification. Furthermore, we

presented several heuristics for a classification of all valid decompositions. In order

to substantiate our method and to measure its effectiveness, the technique has been

implemented, and several case studies have been evaluated.

The present chapter describes the implementation framework for the theory of the

previous chapters. Section 7.1 introduces Syspect [

Sys06

], a graphical modelling envi-

ronment for CSP-OZ specifications, developed by the research group “Correct System

Design” in Oldenburg. By using one of our case studies, we give a short overview on

Syspect’s different diagram types for modelling different aspects of a specification. The

following Section 7.2 presents our context-specific extensions, realised to integrate the

decomposition approach into Syspect. In the last section, the experimental results for

three case studies, the candy machine from Section 2.2, the Two Phase Commit Protocol

from Section 6.4 and the number swapper from Section 4.4, are given. We measure the

different optimal and reasonable cuts by comparing direct model checking with

FDR2

and compositional (learning-based) model checking. Finally, we discuss the results and

184 7 Implementation and Experimental Results

draw some conclusions: some context-specific characteristics for good decompositions

are pointed out, and we comment on when the application of our technique most likely

results in a speed-up of model checking.

7.1 Syspect

The underlying platform for the implementation of our decomposition approach is the

stem

Spec

ification

ool (Syspect, [

Sys06

]). Syspect is a graphical and UML-based

modelling environment for specifications, written in the integrated formalism CSP-OZ-DC

[

Hoe06

]. By extending the language of CSP-OZ with the formalism Duration Calculus (DC)

[

ZH04

], CSP-OZ-DC additionally allows to reason about real time aspects of a software

model. Within this thesis, we do not consider DC. However, as CSP-OZ is naturally

embedded into CSP-OZ-DC by simply declaring the DC-part to be empty, we can use

Syspect to model CSP-OZ specifications as well.

Syspect has been developed within a student project, carried out at the research group

“Correct System Design” in Oldenburg. The basis for their work is a specific UML profile

for CSP-OZ, described in [

MORW08

]. A UML model can then be translated into a CSP-OZ

specification. One focus for the definition of the UML model is the choice of a suitable

subset of the UML, which is expressive enough to represent a significant part of CSP-OZ.

In order to achieve this, the profile uses three different diagrams of the UML, namely

•class diagrams,

•state machines and

•component diagrams.

Next, we will shortly introduce the Syspect representation of the different diagram

types by modelling the specification of the Two Phase Commit Protocol from Section 6.4.

For a more detailed introduction into Syspect and the underlying UML profile, we refer

to [Sys06, MORW08, Brü08].

7.1.1 Class Diagrams

In order to describe the static behaviour of a system specification, UML class diagrams

[

Obj05

] can be used. Such a diagram comprises the specification’s classes including their

attributes: data variables (according to the state variables of the Object-Z part of a class)

and methods (corresponding to the operations of the CSP-OZ class). Additionally, the def-

inition of relationships between classes is possible: for the purpose of connecting classes

and class-interfaces, different associations, such as aggregation or composition, can be

used. These relationships represent the specification’s composition- and synchronisation

structure.

For the specification of the Two Phase Commit Protocol, the class diagram contains both

classes Coord and Page. An interface ISyncCoordPage describes the set of synchronised

7.1 Syspect 185

operations of both classes. One additional class System is defined, representing the

composition of Coord and Page, without defining additional attributes.

Figure 7.1 displays a screenshot of Syspect, showing the class diagram of the TPCP

within the Syspect class diagram editor.

Figure 7.1: Syspect class diagram for the TPCP

Within a certain class, its set of variables and operations can be defined. The types of

the variables and the behaviour of an individual operation can be described within the

associated property view. In our example, both base types Votes and Trans are represented

, the set of boolean variables. Figure 7.2 shows the property view, associated with

the operation Page.inform.

Figure 7.2: Syspect property view for the operation Page.inform

186 7 Implementation and Experimental Results

7.1.2 State Machines

UML state machines are defined for representing the CSP parts of the individual classes of

a CSP-OZ specification. Transitions of a state machine are labelled with an event corre-

sponding to the associated class, or they are unlabelled for representing non-determinism.

States are either

•ordinary states, representing a CSP process,

•initial states, representing the specific initial process main,

•final states, representing successful termination, that is, the process Skip, or

•

complex states, containing a number of regions for modelling concurrency, that is,

interleaving of several processes in terms of CSP.

In order to describe (non-deterministic- or deterministic-) choice, branching can be

used.

Figure 7.3: Syspect state machine for the class Page of TPCP

For the TPCP, there are two state machines, one corresponding to Page

.main

and one

describing Coord

.main

. Figure 7.3 shows the state machine for Page

.main

. As the process

Coord

.main

comprises interleaving of several processes, complex states are required.

Here, we set N

:= 2

, that is, the specification comprises two instances of class Page.

Therefore, two regions are used, corresponding to the processes

k| i∈{1,2}(op →Skip)

for op

∈ {

request

vote

inform

acknowledge

}

. The according state machine is given in

Figure 7.4.

7.1 Syspect 187

Figure 7.4: Syspect state machine for the class Coord of TPCP

7.1.3 Component Diagrams

The component diagram of a specification complements the class diagram and describes

the composition and instantiations of its different constituents. Intuitively, it represents

the overall system composition, that is,

System =CoordkI(k| i∈{1,2}Page)

for the overall specification of the TPCP in the case of N

= 2

. Complementary to the

class diagram, the number of instances of Page is specified, along with the associations

between all class instances, based on the interface connections.

Figure 7.5 shows the component diagram for the Two Phase Commit Protocol. It

describes that both instances of Page synchronise with the sole instance of Coord via the

interface ISyncCoordPage. Conjointly, this synchronisation yields the System-class.

7.1.4 Export to CSP-OZ

Syspect provides an export functionality for the translation of an UML model into a

CSP-OZ representation of the model. Here, a translation into various formats can be

carried out. In this thesis, we are solely concerned with the L

X-export of a CSP-OZ

specification: Syspect allows the generation of L

X mark-up, conforming to [

ISO00

] and

the style file

csp-oz.sty

, as documented in [

Fis99

]. Within our verification framework,

the export will be further processed and translated into the input language of the model

checker FDR2.

188 7 Implementation and Experimental Results

Figure 7.5: Syspect component diagram for the TPCP

7.2 Decomposition Framework for Syspect

After a brief introduction into Syspect, we will now describe the various additional

features and extensions of Syspect, which have been developed in order to provide tool

support for our decomposition technique. Namely, we present

•

an implementation for the decomposition of a specification, based on the selection

and validation of a (single) cut, the fragmentation of the specification’s dependence

graph and the subsequent decomposition of the specification itself, both according

to Chapter 4 (Section 7.2.1),

•

amass validation framework to efficiently compute the set of all valid cuts, sort-

ing out unreasonable and (weakly) dominated decompositions and scaling the

remaining decompositions, based on the definitions from Chapter 6 (Section 7.2.2),

•

an integration of the model checker

FDR2

[

For05

] into Syspect, including a compiler

from the Syspect export to the input language of

FDR2

, along with an interface to

an implementation of the learning-based compositional verification framework as

presented in Chapter 3 (Section 7.2.3) and

•

acounterexample analysis for visualising error traces, possibly generated by

FDR2

within the Syspect model (Section 7.2.4).

Figure 7.6 sketches the overall workflow. Given a Syspect specification of the software

model, a user can choose

•

to generate the dependence graph of a specification, manually select a cut and – in

case of a valid cut – accordingly decompose the specification or

7.2 Decomposition Framework for Syspect 189

Syspect

Model

Property

(optional)

Decomposition

Export and

Translation

(direct or

compositional)

Model Checking

Counter

Example

Visualisation

YES

Figure 7.6: Toolchain for the verification framework

•

initiate a computation of the set of all valid cuts, evaluate them with respect to our

heuristics, select a specific cut and accordingly decompose the specification or

•not to decompose the specification at all.

As a next step, an export and subsequent compilation of the (decomposed) specifica-

tion to the input language of the model checker

FDR2

can be carried out. Afterwards,

either compositional model checking or direct model checking can be applied, addi-

tionally requiring the definition of the verification property under interest. A possible

counterexample is visualised within the Syspect model.

Next, we give a survey over the specific extensions of Syspect. We close this section

with a more detailed description of the verification framework by using UML activity

diagrams [Obj05].

7.2.1 Decomposition Plug-In

In Chapter 4, we defined a cut of a dependence graph, yielding a decomposition of the

underlying specification. The foundation for the corresponding integration into Syspect

is the decomposition plug-in, developed by Klaus Herbold as part of his diploma thesis

[

Her09

]. The plug-in can optionally be used within Syspect, allowing the user to visualise

the dependence graph of a specification and select a set of operation nodes. Afterwards,

the selected cut-candidate is validated against the different correctness criteria from Sec-

tion 4.2.2. To this end, the decomposition plug-in comprises the selection and validation

of a single cut. In case of an invalid cut, the responsible set of violations is displayed.

Otherwise, the user can proceed to decompose the specification. The decomposition is

190 7 Implementation and Experimental Results

Figure 7.7: Screenshot of a selected invalid cut

carried out by applying the definitions from Section 4.3 and the addressing algorithm

from Section 5.1.

Figure 7.7 shows a screenshot of an excerpt of the DG of the Two Phase Commit

Protocol, as it is displayed within Syspect. For illustration purposes, we refer to the

specification solely comprising one instance of the class Page. The visualisation builds up

on the implementation of Brueckner’s definition of the DG, which was carried out within

the slicing plug-in, developed by Sven Linker [

Brü08

]. The graph is defined according to

our modifications of the DG, as given in Section 2.3.4.

In general, a user can interact with the displayed DG and select a set of operation

nodes. In the example, as displayed in the screenshot, the single node Coord

decide is

selected. According to the correctness criteria,

{

Coord

decide

}

does not define a valid

(single) cut: no nodes within the DG of Page are selected. Thus, its set of operation nodes

is assigned to

Ph1

, and several synchronisation edges, connecting nodes from the DGs of

Page and Coord, violate the correctness criterion

no crossing

. In line with the selected

cut, these violations are indicated.

In the event of the selection of a valid cut, the validity is displayed, and a further

decomposition with respect to the cut can be carried out. Here, several options are

7.2 Decomposition Framework for Syspect 191

Figure 7.8: Screenshot of the decomposition options after selection of a valid cut

possible. Figure 7.8 displays the dialogue box after the selection of the correct single

cut

{

Coord

inform

Page

inform

}

. The various options regarding the export and model

checking will be explained in Section 7.2.3. A decomposition of Sresults in L

X mark-

up for S

, which can then further be processed. In order to generate a valid

decomposition, transmission parameters and addressing parameters are added.

Within the plug-in, several features and optimisations are implemented. For instance,

according to the correctness criterion

all-or-none

from Section 4.2.2, either all or no

nodes with the same operation name have to be contained in a cut. Thus, to facilitate

a cut selection, in case that a user picks an operation node, all correspondingly named

nodes are automatically selected. For more details on the implementation, we refer to

[Her09].

7.2.2 Mass Validation

The previous section introduced the general functionality of the Syspect decomposition

plug-in. A user can select and deselect operation nodes within a specification’s DG, until

he identified a valid cut, for which he chooses to carry out a decomposition.

192 7 Implementation and Experimental Results

The larger the DG of a specification, the more tedious becomes a manual search for

a cut. Moreover, according to Chapter 6, a valid cut must not automatically yield a

decomposition suitable for an application of compositional reasoning.

In order to facilitate the choice of a valid cut and to guide the user to a decomposition

most likely outmatching the original model in terms of model checking run-times, Meik

Piepmeyer developed an extension of the decomposition plug-in, called the mass valida-

tion framework. Within his diploma thesis [

Pie10

], he mainly investigated the following

question.

Given the DG of a specification, how can the set of all valid cuts efficiently be computed?

This question particularly becomes relevant if the DG comprises a large set of operation

nodes: assuming

#op(

) =

k, the number of cut-candidates is

. Piepmeyer showed

that the general problem of identifying all valid cuts is NP-complete [

Coo71

]. However,

he developed and implemented several strategies and algorithms to efficiently validate a

set of operation nodes against the various correctness criteria. One of his strategies uses

a SAT solver [PBG05].

Additionally, Piepmeyer implemented the different heuristics from Chapter 6, along

with the identification of all unreasonable and dominated cuts. In the latter case, one of

the dominating cuts is displayed. Unreasonable cuts and dominated cuts can be removed

from the set of all valid cuts, and the remaining cuts can be scaled according to the

different heuristics.

Figure 7.9 shows a screenshot of the mass validation framework after choosing to

compute all valid cuts for the TPCP for three instances of Page. Unreasonable cuts are

marked with a minus, whereas a plus signalises reasonable cuts. In addition, optimal cuts

are indicated by a small histogram. Furthermore, the amounts of valid cuts, optimal cuts

and reasonable cuts are displayed. According to the results of Chapter 6, the amount of

cuts which are both, optimal and reasonable, is equal to 9.

In order to further classify the set of optimal and reasonable cuts, to this end, the

weighted sum over all heuristics is used as the scaling function. In the example, in case

that all heuristics are equally rated, {inform}obtains the smallest value.

After scaling the different heuristics to identify a subjectively optimal cut, the user can

proceed to decompose the specification and model check the result. For more details on

the mass validation, see [Pie10].

7.2.3 Model Checking with FDR2 and the CSPLChecker

Following up on the selection of a valid cut and a corresponding decomposition of

the model, we aim at an evaluation of direct model checking in comparison to the

compositional one. The decomposition approach of this thesis is not restricted to a

particular model checker. Yet, we require an existing translation from CSP-OZ to the

respective input language.

In order to evaluate the effectiveness of our theory, we choose the CSP model checker

FDR2

(

ailure

ivergence

efinement [

For05

]), developed by Formal Systems (Europe)

Ltd. Several reasons substantiate this choice. First,

FDR2

is the most commonly used

7.2 Decomposition Framework for Syspect 193

Figure 7.9: Screenshot of the mass validation framework

CSP model checker: at the time of writing his book [

Ros98

], Roscoe called it the chief

proof and analytic tool for CSP, and this fact did not change over the recent years. Second,

Wonisch [Won08] implemented the assume-guarantee-based learning framework based

upon

FDR2

. Finally,

FDR2

is well suited for our purpose, due to an already existing

translation from CSP-OZ to the input language of FDR2 [FW99].

The tool inputs process specifications, written in a machine-readable dialect of CSP,

called CSP

. As the underlying verification concept,

FDR2

uses refinement checks: given

two CSP-processes Sand Prop, the refinement Prop

Scan be evaluated within CSP’s

different semantic models. In this thesis, we are solely concerned with checking trace

inclusion and do not consider any other refinement checks. For more details on

FDR2

we refer to [

Ros98

For05

], with the latter reference comprising a full documentation of

FDR2 along with the syntax of CSPM.

Already, several works investigated a translation from either CSP-OZ or a related

formalism to the input language of

FDR2

. For instance, in [

MS01

], the authors present

a translation from CSP-Z to CSP

. In her diploma thesis and simultaneously to the

development of Syspect, Stamer [

Sta06

] investigated a translation to CSP

for models

194 7 Implementation and Experimental Results

N = {1 ,2}

pages = card (N)

PROP = PC( pages )

PC(0) = ||| x :N @ ( complete −> SKIP )

PC( i ) = vote . true −> PC( i −1)

[] vote . f a l s e −> PU( i −1)

PU(0) = ||| x :N @ (undo −> SKIP)

PU( i ) = vote? j −> PU( i −1)

SPEC = (S_1

[ {| request , execute , vote , decide , inform|} ||

{|inform , undo complete , result , acknowledge|} ]

S_2)

\ {| request , execute , decide , inform , result , acknowledge|}

assert PROP [T= SPEC

Figure 7.10: Correctness requirement for the TPCP in terms of CSPM

specified in the UML profile for CSP-OZ [

MORW08

]. Obviously, such a translation has

certain limits: it is clearly restricted by the expressiveness of the input language of the

model checker. Moreover, as CSP-OZ exemplary allows to use infinite and underspecified

data types, such as basic type definitions, a translation is limited to a subset of the

integrated formalism.

In our context, we target the translation of the Syspect-L

X-export to CSP

. As part

of his work as a student assistant, Wonisch implemented a corresponding compiler. The

translation builds up on the definition from [

FW99

] and thus, the CSP

semantics, as

given in Section 2.2.4. Some of the accomplishments in the compiler development include

the support to translate finite sequences and various mathematical tool kit functions,

along with axiomatic definitions.

Some restrictions have to be applied in order to model the different case studies within

Syspect and to allow for a translation to CSP

. For the case study of a candy machine,

we require sequences of finite length, for which we define a corresponding constant.

For specifying the Two Phase Commit Protocol, both base types are mapped to

. For

a translation of the Syspect export, a user needs to specify the maximal value for an

element of

. By default, this value is set to

, meaning that

is mapped onto the set

{−5,...,5}

within the CSP

-script (and, accordingly,

mapped onto

{0,...,5}

). The

maximal integer is consistently used within the mass validation framework, where we

implicitly set MaxInf to this specific value.

Besides the actual specification, model checking additionally requires a verification

property. Currently, the user manually needs to define this property in terms of CSP

7.2 Decomposition Framework for Syspect 195

Syspect

model of S

LaTeX mark-up

of S || S

1 2

pre-processed

LaTeX mark-up

of S || S

1 2

CSP code

of S || S

1 2

and Prop

CSP code

of Prop

export preprocessing

compilation

max.

integer

value

ompil n

catio

ompil n

c atio

Figure 7.11: Compilation from L

TEX to CSPM

Moreover, he needs to declare an assertion, specifying the individual trace refinement

under investigation. Figure 7.10 defines a CSP process Prop, specifying a correctness

requirement Prop for the TPCP. Intuitively, the property states:

“ If, and only if, at least one page votes NO, all pages will undo the transaction. ”

More technically, the process PC

(

)

allows for ivotes (and thus Prop for Nvotes, where

= 2

) and - if the control flow has not left the process before - an amount of Nsubsequent

events complete. As soon as one vote has the value NO,PC switches to a process PU.PU

(

)

also allows for ivotes, independent of the parameter value, but always terminates with

undos. Thus, as soon as one event vote

NO occurs, the final events of PROP will be undo.

Subsequently to the definition of the property, we define an assertion, stating that the

individual specification SPEC refines the property PROP. Here, we additionally need to

consider the respective decomposition we are dealing with: in the example, we evaluate

the decomposition with respect to the cut

{

inform

}

. Thus, SPEC needs to be accordingly

defined.

Figure 7.11 illustrates the compilation framework. First, the export is preprocessed,

mainly to adapt CSP-OZ-DC specific syntax according to the one for CSP-OZ. Subsequently,

the CSP

-code for the specification, including the one for the verification property, is

generated.

Recall the different options for exporting and verifying a specification against a certain

requirement, as displayed in Figure 7.8. In order to apply non-compositional model

checking, the first option can be selected, yielding a direct verification of Prop

S. In

this case, Sis not decomposed at all. In any of the following options, the specification is

decomposed according to the selected cut. Here, the second option again initiates direct

model checking, this time to prove or contradict Prop

vT(

, whereas the last option

solely exports the resulting specification to CSPM.

For the remaining options, compositional verification based on the learning-based

approaches from [

CGP03

] and [

BGP03

] can be carried out. As part of his bachelor’s

thesis, Wonisch [

Won08

] implemented the approach by using the CSP model checker

FDR2

as the teacher. The tool is called CSPLChecker [

Won

] and supports an assumption

196 7 Implementation and Experimental Results

Figure 7.12: Screenshot of the CSPLChecker

generation, according to the learning frameworks for both assume-guarantee proof rules,

(B-AGR)

and

(P-AGR)

(see Section 3.3). Various optimisations as, for instance, different

caching strategies, are implemented. During and after model checking, several statistics,

such as the amount of membership queries or equivalence queries, can be displayed. For

direct model checking with

FDR2

, the CSPLChecker is likewise called, forwarding the

FDR2 output and showing several statistics.

The screenshot of the CSLChecker from Figure 7.12 shows the verification result for

the decomposition of the TPCP. The decomposition is carried out with respect to the

cut

{

inform

}

, model checking refers to the property from Figure 7.11. At run-time, six

intermediate assumptions are generated, the second one is displayed on the bottom left

hand side. Overall, model checking takes approximately two seconds. The tool can freely

be downloaded [Won], a more detailed description can be found in [Won08].

7.2.4 Counterexample Analysis

Independent of a direct call of

FDR2

or a compositional verification, model checking a

specification against a requirement possibly results in a counterexample. Such an error

trace comprises a sequence of events, constituting a violation of the respective verification

property. As part of the CSPLChecker output, this trace is displayed within the Syspect

console. However, a purely textual representation of a counterexample is difficult to

analyse. In particular, recovering the counterexample within the model can become

tedious.

In order to guide the user to the specific behaviour of the model which violates the

verification property, Micus [

Mic10

] developed an additional extension to Syspect, the

countertrace plug-in. By evaluating the textual representation of a counterexample and

linking it back to the specification’s state machines, the error trace is visualised within

7.2 Decomposition Framework for Syspect 197

Figure 7.13: Screenshot of the counterexample visualisation

the Syspect model.

Consider a modification of the verification property from Figure 7.10: if we replace

pages = card(N)

pages = card(N)+1

, for N

= 1

, a verification will result in

the following error trace:1

tr =hrequest,execute,vote.false,decide,inform.false,undoi.

This is due to the fact that Prop requires the execution of two votes before the first

undo, which is clearly impossible for the TPCP with one instance of Page.

tr comprises events, solely executed by one class, along with synchronised events

between the classes Coord and Page. A visualisation of tr thus requires its events to be

distributed over both state machines.

Figure 7.13 shows a screenshot of the visualisation of the error trace tr within both state

machines. Here, the synchronised operation inform is selected, yielding the corresponding

state machine triggers to be highlighted in red. Along with this, a visualisation of the

complete error trace is possible.

Up to now, only the CSP part of the specification is analysed. In case there is more

than one visualisation of the error trace, all of them are displayed. More details on the

countertrace plug-in can be found in [Mic10].

1Recall, that Votes and Trans are mapped onto B.

198 7 Implementation and Experimental Results

7.2.5 Overall Workflow

After introducing the several context-specific extensions of Syspect, we concludingly

assemble and summarise them. Figure 7.14 shows the decomposition framework by using

an UML activity diagram [Obj05].

Given a specification Sand a property P, a user can either choose to apply direct model

checking or compositional verification. In the first case, Sis exported to

TEX

-mark-up

(Syspect export plug-in, Section 7.1.4) and both, Sand Pare translated into a CSP

-script

(CSP

-export, Section 7.2.3). Here, Pis simply forwarded, as it is already specified in the

input language of

FDR2

. In the latter case, Sis decomposed into some S

- either by

using the manual choice of a cut (Section 7.2.1) or the mass validation framework (Section

7.2.2), both realised within the Syspect decomposition plug-in. The property Ppossibly

needs to be adapted to some property P

, according to the respective decomposition: P

needs to comply to the specification in terms of transmission parameters and address

parameters. Along with that, a modified assertion now refers to the decomposed system.

Again, a compilation of S

and P

can be carried out, resulting in corresponding

CSPM-code.

Next, the actual model checking takes place. Direct,

FDR2

-based, model checking

with respect to Sor S

is generally possible. Compositional verification using the

CSPLChecker (Section 7.2.3) requires the system to be composed of two components.

This is clearly the case for S

and, if Sitself is already assembled of two parts, for S

as well. In any case, if the model checking yields an error trace, the counterexample is

visualised within the Syspect model (Syspect countertrace plug-in, Section 7.2.4).

7.2 Decomposition Framework for Syspect 199

Figure 7.14: Verification framework

200 7 Implementation and Experimental Results

7.3 Experimental Results

Within this thesis, we specified several case studies, serving as an illustration of the main

concepts, definitions and algorithms. The present section provides the experimental

results for three specifications: the candy machine from Section 2.2, the Two Phase

Commit Protocol from Section 6.4 and the number swapper from Section 4.4. In order to

evaluate our approach, the examples have been specified within Syspect, decomposed

and exported, after which the run-times during model checking were investigated. For

all three case studies, we stepwise enlarged the size of the specification, namely, by

increasing the maximal value for

and, for the Two Phase Commit Protocol, the amount

of participating pages. This allows us to estimate how the approach scales with an

increasing size of the model.

We start this section with an overview on the technical conditions for our evaluation.

Afterwards, we separately analyse the candy machine, the TPCP and the number swapper,

and we draw some first conclusions. Finally, we discuss the evaluation results.

7.3.1 Overview

In order to accomplish an experimental evaluation of our approach, we analysed our case

studies on a Dell PC, equipped with an Intel Core 2 Duo CPU, 4 GB RAM and openSUSE

Linux 11.1. Besides that, we used Syspect version 1.4.0 with an integration of the various

extensions, as described in Section 7.2. For model checking, we employed

FDR

in version

2.83.

All case studies have been modelled within Syspect. The tool is available from its public

subversion directory [

Cor

], the various extensions and the case studies along with the

corresponding exports are freely accessible from [Res].

We provide some more background information on the conducted experimental studies.

•

Up to now, the implementation of our approach within Syspect does not allow

for a decomposition with respect to a general cut. Thus, for the case study of

the number swapper, we manually decomposed the model, before proceeding

with model checking. For the remaining case studies, we evaluated those sets of

decompositions, which correspond to the set of optimal and reasonable single cuts,

as given in Chapter 6.

•

According to the two different proof rules,

(B-AGR)

and

(P-AGR)

, we used two

learning strategies, which will from now on be called basic reasoning (

) and

parallel reasoning (

). In general, an assertion must be formed as Prop

vT(

, where S

denotes the first component of the decomposed system and S

the

second.

•

Some manual modifications of the export were necessary to achieve a fair compar-

ison between the model checking results for the different systems. For instance,

parameters were ordered such that the original ones are denoted first, followed by

address parameters and transmission parameters.

7.3 Experimental Results 201

•

Instead of comparing the sizes of the generated state spaces during model checking,

we choose to compare verification run-times along with the amount of equivalence

queries and membership queries during learning. This is owed to the model checker

FDR2

, not allowing for the computation of the size and visualisation of the overall

state space, generated during model checking. In fact, it is possible to display the

state space of the final generated transition system. However, in order to compare

the amount of states constructed and visited during model checking, the transition

systems of the intermediate processes would have to be considered as well. In our

context, comparing run-times along with the amount of the different L

∗

-queries, is

a satisfactory way of an evaluation.

•

In general, we specified verification properties, which turn out to be valid for the

respective specification. Model checking is carried out, until either the system ran

out of memory or the verification result is true.

Besides direct model checking of the original system and compositional, learning-based

verification of the decomposition, we also evaluated direct model checking with respect

to our generated decompositions. Therefore, our evaluation will investigate run-times for

three different systems:

Original System:

Given a specification Sand a requirement Prop, we consider direct

model checking of Prop vTS.

Decomposed System, no AGR:

For a valid decomposition of Sinto S

, we investi-

gate direct model checking of Prop vT(S1kS2).

Decomposed System, AGR based on Learning:

For a valid decomposition of Sinto

, model checking of Prop

vT(

with respect to the proof rules

(B-AGR) and (P-AGR) is examined.

Section 7.3.5 will comment on the most likely reasons for the verification results. Next,

we present the experimental results for the three investigated examples in detail.

7.3.2 Verification Results for the Candy Machine

Our experimental evaluation starts with the specification of a candy machine, as defined

in Section 2.2. In Chapter 6, we already filtered all valid (single) cuts according to the

criteria unreasonable (Definition 6.2.1) and dominated (Definition 6.2.3). The remaining

two cuts are

•C1:= {switch}and

•C2:= {abort,order,select,switch}.

Therefore, we will investigate three different systems: the undissected candy machine

specification and two decompositions, according to the single cuts

and

. Direct

model checking is conducted for all three systems. In addition, for both decomposed

systems, we consider basic reasoning and parallel reasoning.

202 7 Implementation and Experimental Results

PROP = Paying (0)

Paying ( i ) = ( i f ( i+2 <= MAX) then P( i ) else Collecting ( i ) )

P( i ) = [] j : Coins @ (pay . j −> Paying ( i+j ) )

Collecting ( i ) = ( i f i >= 0 then D( i ) else STOP)

D( i ) = C( i ) [] Terminate ( i )

C( i ) = deliver .CHOC −> Collecting ( i −1)

[] deliver . COOKIE −> Collecting ( i −2)

[] deliver . CRISPS −> Collecting ( i −3)

Terminate ( i ) = term . i −> SKIP

SPEC = (S_1

[ {| abort , pay , payout , switch |} ||

{| deliver , order , select , switch , term|} ]

S_2)

\ {|payout , abort , switch , select , order |}

assert PROP [T= SPEC

Figure 7.15: Correctness requirement for the candy machine in terms of CSPM

The verification property, which we consider, is the one defined in Figure 2.6. Rephrased

in terms of CSP

, the property is denoted in Figure 7.15. Here, we additionally need to

to disallow the usage of integer values greater than MAX and smaller than

, which is

specified within the property. The definition also contains an assertion for the decomposed

system with respect to the cut {switch}.

In the following, we scale the size of the evaluated model by increasing the maximal

integer value

MaxInf

within the CSP

-code. Precisely,

MaxInf

equal to nmeans that

is mapped to

{−

,...,

}

whereas

is mapped to

{0, . . .

}

. The value for

MaxInf

determines a corresponding value for the constant Max (see Section 2.2.1).

We denote the run-times in seconds and, in case of learning, the membership queries

and equivalence queries. The amount of equivalence queries is identical to the number of

generated intermediate assumptions during learning.

The symbol

(*)

indicates that the memory limit was exceeded during model checking,

causing

FDR2

to cancel the verification process with the message

std::bad alloc

In addition,

(-)

denotes that the respective verification was not conducted, as model

checking for the same system already failed for a smaller value of

MaxInf

. Finally,

n/a

denotes that compositional verification was not applicable, as the original system is not

composed of two components.

7.3 Experimental Results 203

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1n/a n/a n/a n/a n/a n/a

{switch}<1<1 1 8 1 8 6

{abort,order,select,switch}<1<1 1 20 5 16 2000

(a) Results for MaxInf = 1

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None 17 n/a n/a n/a n/a n/a n/a

{switch}<1 2 3 25 7 18 448

{abort,order,select,switch}53 62 2 188 1916 92 156K

(b) Results for MaxInf = 2

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None (*) n/a n/a n/a n/a n/a n/a

{switch}12 107 5 88 162 23 944

{abort,order,select,switch}(*) (*) (-) (-) (*) (-) (-)

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None (-) n/a n/a n/a n/a n/a n/a

{switch}183 (*) (-) (-) 3044 25 1527

{abort,order,select,switch}(-) (-) (-) (-) (-) (-) (-)

(d) Results for MaxInf = 4

Table 7.1: Experimental results for the candy machine

The improvement from Section 4.3.7, allowing for a neglect of specific initial data

dependences, was not yet implemented in Syspect. Therefore, the cut

{

switch

}

is not

indicated as a valid cut. In order to cope with this problem, we removed the initial

predicate items =h i from the model and manually re-added it within the CSPM-code.

Finally, we give the experimental evaluation for the candy machine specification. Table

7.1 displays the results for

MaxInf = 1

MaxInf = 4

. Most importantly, in case that

the machine did not exceed its memory limit, we denote the amount of seconds until

the verification terminated with the result true.

indicates direct model checking, and,

as already mentioned,

and

indicate basic reasoning and parallel reasoning. The

number of equivalence queries and membership queries are given in the columns marked

with EQ and MQ, respectively. For

MaxInf = 5

, the two remaining evaluations for the cut

{switch}lead to an out-of-memory exception.

204 7 Implementation and Experimental Results

It turns out that direct model checking of the original system can only be carried

out for

MaxInf ∈ {1,2}

. The same applies for the cut

C2={

abort

order

select

switch

}

independent of monolithic or compositional verification. For this specific cut, run-times

are even worse compared to model checking of the undissected model. The best results are

achieved for the cut

C1={

switch

}

. Quite surprisingly, direct model checking outperforms

the compositional one.

Summing up, due to the decomposition of the model, we can verify the investigated

property on larger systems. Even though learning-based reasoning already outperforms

monolithic verification of the original system, the best results are achieved for direct

model checking of the decomposed systems according to one specific cut. This particularly

shows that effective model checking for a decomposed system not automatically requires

compositional, assume-guarantee-based strategies. We will further elaborate on these

particular results in Section 7.3.5.

7.3.3 Verification Results for the Two Phase Commit Protocol

The next case study under investigation is the Two Phase Commit Protocol, specified in

Section 6.4. Again, we only consider the set of optimal and reasonable cuts, as given

in Table 6.6. In order to refer to the different cuts, we occasionally use the according

numbers from the respective table. We verify the system against the property, given in

Figure 7.10.

According to Section 6.4, there are nine optimal and reasonable cuts. As already argued,

a heuristics-based approach solely points the direction, but it does not automatically

determine the (set of) qualified cut(s). Instead of comparing all nine cuts, we filter the

set by further analysing its elements:

•

The cuts numbered as 24 and 39 result in two symmetric decompositions, which

only differ in the two different operation names undo and complete. Therefore, we

select one of these cuts for the evaluation, namely the one numbered as 39, that is,

{inform,undo}.

•

The sole reason why the cut

{

complete

inform

result

undo

}

does not dominate

the cuts numbered as 16 and 17, is the value for the heuristic

even distribution

However, as the first cut is a subset of the latter two cuts, the difference appears

simply due to a shift of node(s) into the cut. Clearly, this does not improve the

decomposition, and we solely consider the first of these three cuts.

•

The same argument applies in case we compare the cuts numbered as 23 and 19

with {inform,undo}.

The remaining four (single) cuts will be evaluated. These are

•C1:= {inform},

•C2:= {vote,decide},

•C3:= {inform,undo}and

7.3 Experimental Results 205

•C4:= {complete,inform,result,undo}.

Along with them, we will also consider the dominated cut

C5:= {

vote

}

: even though

this cut seems to be a sensible one, our heuristics reject it. In order to draw some

further conclusions on the plausibility of the heuristics, we exemplify an evaluation of a

dominated cut on C5.

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1 4 9 464 5 33 973

{inform}<1 2 6 194 16 28 4050

{vote,decide}<1 2 5 230 3 16 464

{inform,undo}<1 76 11 5011 29 28 6611

{complete,inform,result,undo}<1 308 16 18K 2 5 416

{vote}<1 4 3 226 7 13 976

(a) Results for two pages

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1 19 14 1071 25 52 3248

{inform}7 10 8 567 192 52 38K

{vote,decide}<1 11 7 933 9 23 1875

{inform,undo}7 1459 21 38K 567 61 97K

{complete,inform,result,undo}5 8449 23 148K 8 6 1403

{vote}1 43 4 1218 40 19 4265

(b) Results for three pages

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None 17 319 18 1839 6807 67 46K

{inform}3657 42 10 1251 1970 83 205K

{vote,decide}47 52 9 2672 74 29 5040

{inform,undo}3142 (*) (-) (-) (*) (-) (-)

{complete,inform,result,undo}1796 (*) (-) (-) 781 7 3614

{vote}57 336 6 4721 161 20 10K

Table 7.2: Experimental Results for the TPCP, first part

Tables 7.2 and 7.3 show the evaluation results for the TPCP, comprising two to seven

pages. The table is correspondingly configured to the one for the candy machine, and it

uses the same symbol to indicate an out-of-memory failure during model checking. As

the specification itself is composed of two components Coord and Pages, we can apply

compositional verification for the original system as well.

206 7 Implementation and Experimental Results

The evaluation yields the following results: first of all, direct verification for the

undissected system and for the decompositions according to

and

can be carried

out for an amount of five pages, before the memory limit exceeded. For the remaining

decompositions, direct verification is only possible for an amount of four pages.

Compositional verification results in comparatively worse run-times for two and three

pages. However, the larger the model, the more effective becomes compositional reason-

ing and, in particular, basic reasoning. The best results are achieved for the decomposition

according to

, that is,

{

vote

decide

}

. Here, model checking can be carried out for up to

seven pages, before the memory limit exceeds. Regarding the dominated cut

{

vote

}

, it is

outmatched by basic reasoning with respect to the cuts

{

inform

}

and

{

vote

decide

}

. Thus,

even though one might intuitively assume

{

vote

}

to declare a better decomposition than

{

vote

decide

}

, the heuristics prove this conjecture wrong. A more detailed discussion will

be part of Section 7.3.5.

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None 926 8696 23 2926 (*) (-) (-)

{inform}(*)571 12 2342 (*) (-) (-)

{vote,decide}3584 241 11 6174 11K 35 11K

{inform,undo}(*) (-) (-) (-) (-) (-) (-)

{complete,inform,result,undo}(*) (-) (-) (-) (*) (-) (-)

{vote}4220 1877 7 11K 10K 17 20K

(a) Results for five pages

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None (*) (*) (-) (-) (-) (-) (-)

{inform}(-) (*) (-) (-) (-) (-) (-)

{vote,decide}(6 pages) (*)1738 13 12K (*) (-) (-)

{vote,decide}(7 pages) (-) 5846 15 22K (-) (-) (-)

{inform,undo}(-) (-) (-) (-) (-) (-) (-)

{complete,inform,result,undo}(-) (-) (-) (-) (-) (-) (-)

{vote}(*) (*) (-) (-) (*) (-) (-)

(b) Results for six and seven pages

Table 7.3: Experimental Results for the TPCP, second part

Summing up, contrary to the evaluation results for the candy machine, direct verifica-

tion of the decomposed system results in higher run-times than basic reasoning. Moreover,

basic reasoning performs significantly better than parallel reasoning. The example shows

that assume-guarantee-based compositional verification can indeed lead to a significant

speed-up during model checking.

7.3 Experimental Results 207

PROP = [] j : Nat @ ( input . j −> re s u lt .1 −> P( j ) )

P( j ) = [] k : Nat @ ( input . k −> r e s u lt . j −> P(k) )

SPEC = (S_1

[ {| input , storeB , r e s ul t |} ||

{| storeB , moveA , moveB , r e s ul t |} ]

S_2)

\ {|moveA ,moveB , storeB |}

assert PROP [T= SPEC

Figure 7.16: Correctness requirement for the number swapper in terms of CSPM

7.3.4 Verification Results for the Number Swapper

The final case study under investigation is the (extended version of the) number swapper

from Section 4.4, defined in Figure 4.26. Here, due to the specific recursive structure of

the CSP part, a decomposition with respect to a single cut is impossible. Moreover, based

on the different data dependences, there is only one reasonable general cut, namely

C= (C1,C2)

, for

C1={

store b

}

and

C2={

result

}

. Thus, we manually decomposed the

specification according to

, and we compared run-times for direct verification of the

original system and the decomposed system with the ones for compositional verification

of the decomposed system.

In order to carry out the model checking, we refer to the verification property, as given

in Figure 4.29. Rephrased in terms of CSP

with an additional assertion in regard of the

decomposed system, the property is specified in Figure 7.16. It states:

“ The parameter value, received by input, corresponds to the output value of result in the

next iteration of the protocol. ”

According to the experimental evaluation of the candy machine, we scale the specifica-

tion by stepwise increasing the maximal integer value

MaxInf

. The individual results are

given in Tables 7.4 and 7.5, respectively.

Compositional reasoning, particularly with respect to the proof rule

(B-AGR)

, results

in drastically worse run-times than non-compositional one. The comparison between

direct verification of the original system and the decomposed one mainly yields a draw.

Thus, for this case study, decomposing the specification does not yield an advantage over

model checking of the undissected system.

7.3.5 Discussion

In this section, we evaluated three case studies, and we compared direct model checking

with the compositional one with diverse results:

208 7 Implementation and Experimental Results

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1n/a n/a n/a n/a n/a n/a

{store b},{result}<1 26 22 2740 3 32 591

(a) Results for MaxInf = 1

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1n/a n/a n/a n/a n/a n/a

{store b},{result}<1 249 40 15K 13 57 2243

(b) Results for MaxInf = 2

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None <1n/a n/a n/a n/a n/a n/a

{store b},{result}<1 1888 66 56K 58 97 5883

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None 1 n/a n/a n/a n/a n/a n/a

{store b},{result}1 11K 98 155K 230 147 12K

(d) Results for MaxInf = 4

Cut DC BR PR

sec sec EQ MQ sec EQ MQ

None 3 n/a n/a n/a n/a n/a n/a

{store b},{result}3 62K 136 355K 779 207 25K

(e) Results for MaxInf = 5

Table 7.4: Experimental results for the (extended) number swapper, first part

1.)

For the specification of a candy machine, direct model checking based on the cut

{

switch

}

outmatches learning-based verification along with direct verification of the

original system.

2.)

Regarding the Two Phase Commit Protocol, the learning-based method performs best,

particularly for the decompositions according to the cuts

{

vote

decide

}

and

{

inform

}

3.)

The evaluation of the final case study, the number swapper, showed that a decompo-

sition of the system does not always improve the run-times during model checking in

a significant way.

7.3 Experimental Results 209

Cut DC / PR DC / PR DC / PR DC / PR

MaxInf = 6 MaxInf = 7 MaxInf = 8 MaxInf = 9

None 10 23 52 108

{store b},{result}10 / 2498 24 / 7209 52 / 19K 10 / (-)

(a) Results for MaxInf ∈ {6,7,8,9}

Cut DC DC DC

MaxInf = 10 MaxInf = 11 MaxInf = 12

None 209 379 (*)

{store b},{result}207 372 (*)

(b) Results for MaxInf ≥10

Table 7.5: Experimental results for the (extended) number swapper, second part

A summary of the results is given in Table 7.6. They will lead us to some context-specific

conjectures, which we will discuss next. In order to draw some conclusions and develop

an intuition on when decomposing a system plus applying compositional verification

might pay off, we investigate the specific model checker

FDR2

and the structure of the

different case studies. Note that the following interpretations and considerations are

mostly educated guesses and conjectures: neither can we precisely estimate the model

checking procedure of

FDR2

, nor can we draw detailed and irrefutable conclusions from

a heuristics-based technique.

Verification Technique Case Study

Candy Machine TPCP Number Swapper

Direct, original system - - +

Direct, decomposition + - +

Compositional, decomposition ◦+ -

Table 7.6: Summary of the experimental results

General Conclusions

Based on the experimental results, we discuss some general observations. First, we

experienced that the order of both components within the assertion is relevant for basic

reasoning and – due to the nature of the symmetric proof rule – irrelevant for parallel

reasoning. For basic reasoning, model checking of Prop

vT(

generally performed

better than the one of Prop

vT(

. The previous tables thus always refer to the

case of Prop vT(S1kS2).

Next, we observed that two particular criteria were most relevant for the measured

210 7 Implementation and Experimental Results

run-times of model checking. The first one is related to the additional address- and

transmission parameters: parameters of high cardinality significantly increase the run-

times. As the type of transmission parameters is arbitrary, decompositions without

transmission parameters or, at least, transmission parameters of small type-cardinality

should be favoured. As a second, closely related criterion, the amount of cut nodes highly

influences the duration of model checking. For our case studies, we experienced that

cuts with a size of more than two nodes generally lead to comparatively bad results.

As both criteria determine the number of events, which have to be synchronised in the

decomposition, both observations substantiate the claim from Section 6.1: the interface

between both components needs to be small.

Another observation is related to the specific model checker we used for the evalua-

tion: the behaviour of

FDR2

in the context of the learning based approach is generally

non-deterministic, and it is nearly impossible to draw conclusions on how the amount

of membership queries and equivalence queries can be reduced [

Won08

]. For instance,

a reordering of the specification’s parameters changes the number of intermediate as-

sumptions. However, there is no general rule which orderings should generally be

favoured.

Regarding the comparison of parallel reasoning and basic reasoning, basic reasoning

mostly outmatched the parallel one. This might be related to the specific case studies

which we investigated: the candy machine and the Two Phase Commit Protocol can be

seen as sequential systems without outer recursion, thus favouring the specific sequential

structure of the rule

(B-AGR)

. Yet, for the case study of the number swapper, even though

parallel reasoning performed better that the basic one, run-times were significantly higher

compared to direct model checking. This raises doubts on the usefulness of parallel

reasoning in general.

Finally, we want to substantiate the claim that not only the final transition graph,

generated during model checking, is relevant for the number of explored states. We

illustrate this by an example.

Example 7.3.1. Let us consider the following simple CSP-OZ specification.

Simple

chan a,b,c

main c

=a→b→c→Skip

a guard,b guard,c guard :B

Init

a guard,b guard,c guard =true

enable a

a guard =true

enable b

b guard =true

enable c

c guard =true

effect a

∆(a guard)

a guard0=false

effect b

∆(b guard)

b guard0=false

effect c

∆(c guard)

c guard0=false

7.3 Experimental Results 211

The CSP process of the class solely allows for the trace

. For the Object-Z part, any

ordering of operations is possible, as long as each operation is only called once. Thus, in

order to analyse the specification, the parallel composition of the two transition systems

•c//•

•

b33

•b//•

•c//•

•a//•b//•c//•and •

{

{b//

C•

a44

•a//•

•b//•

•

a33

•a//•

needs to be computed (without denoting the state variables of the Object-Z part). Even

though the transition system of the overall process is identical to the one for the CSP part,

the much bigger transition system of the Object-Z part must be computed as well before the

parallel composition can be carried out.

Now assume we decompose the specification based on the valid single cut

C={

}

. In this

case, the transition system for the first component is a parallel composition of

•b//•

•a//•b//•and •

a44

•a//•

For the transition system of the second component, the event b is simply replaced by the

event c. The final transition systems for the original specification and the decomposed one

are identical and according to the one of the original CSP part. However, the size of the

intermediate system differs: for the original system, there are 19 states and 18 transitions,

the decomposed systems needs to cope with only 16 states and 12 transitions. Thus, (direct)

model checking with respect to the original model needs to explore more states than the

compositional one.

The example particularly shows that direct model checking of a decomposed system

can indeed outmatch direct model checking of the original specification. This can be the

case if the decomposition results in smaller intermediate transition systems due to, for

instance, a significant reduction of interleaving or an effective distribution of the set of

state variables.

Evaluation Analysis: Candy Machine

We quote some further case-study-specific observations, and we start by analysing the

results for the candy machine. The state space of the specification particularly comprises

two sequences paid and items. Even though

FDR2

supports the specification of sequences,

generating the set over all possible sequences of finite length nfor some specific data

type with cardinality kresults in k

elements. This is further substantiated by the fact

212 7 Implementation and Experimental Results

that

FDR2

mainly applies explicit model checking techniques and generally needs to deal

with the full state space of a system.

Consider the decomposition of the specification with respect to the cut

{

switch

}

, as

given in Section 4.3.6. It results in a distribution of the state variables paid and items

over both components – paid is assigned to CandyMachine

, and items is assigned to

CandyMachine

. Thus, the individual state spaces of the Object-Z parts of the specification

are significantly smaller than the state space of the original system. Hence, it is most

likely that model checking with respect to

C1={

switch

}

performs comparatively better

than the one for the original system.

Regarding the cut

C2={

abort

order

select

switch

}

, the corresponding decomposition

requires a transmission parameter of type

seq

Candies. In addition, the number of cut

nodes is equal to four. Thus, model checking with respect to

leads to comparatively

poor results.

Yet, the question remains why direct model checking outperforms the compositional

one. As already mentioned, the performance of learning-based compositional reasoning

depends on the number of intermediate assumptions. According to [

Won08

] and due to

the black-box character of FDR2, it seems quite difficult to pre-estimate this number.

Evaluation Analysis: Two Phase Commit Protocol

In [

dRHH+01

], the motivation for introducing and specifying the Two Phase Commit

Protocol is its particular structure, allowing for an appliance of the Communication-Closed-

Layers law (CCL) [

EF82

]. Our way of decomposing a specification is one particular way

of adopting the CCL, which leads to a transformation of a specification with a distributed

or concurrent structure – such as the parallel composition of several processes – to a

sequential or layered structure, consisting of several phases.

The evaluation of this specific case study shows that the structure of the TPCP facilitates

an application of compositional techniques. In particular, the protocol itself consists of

two phases, which are nearly independent.

Quite surprisingly, the cut yielding the minimal run-times during model checking is

C={

vote

decide

}

. Figures 7.17 and 7.18 show the decomposition of the specification

according to

. In order to address specific instances of Page

and Page

, we adopt

CSP-OZ’s concept of constant parameters ([Fis00]).

This specific cut reflects the loose connection between the commit-request-phase and

the commit-phase: the corresponding decomposition only requires one transmission

parameter of type Trans

COMMIT

ABORT

}

for the operation decide. This parameter

represents the final decision to either commit or abort a transaction and thus, the point of

intersection between both phases. As decide only occurs once within the specification, this

parameter of type cardinality 2 is only used once as well. Contrary, the cut

{

vote

}

requires

a transmission parameter of type

Votes for the operation vote. Thus, the cardinality of

the type of this operation is larger than the one for the parameter of decide. Moreover

and more importantly, vote occurs once in each instance of Page and Ntimes within Coord.

This requires the transmission parameter to be added to all Noccurrences within Coord.

Therefore, even though the cut

C5={

vote

}

only comprises one operation schema, model

7.3 Experimental Results 213

Coord1

chan request chan decide : [trdecC! : Trans]

chan vote : [vo? : Votes;add1:{1. . . N};add2:{1. . . N}]

main c

=k| 0<i≤N(request →Skip);

k| 0<i≤N(vote?vo.i?add2→Skip); decide?trdecC →Skip

decC :Trans

votes :PVotes

effect request

∆(votes)

votes0=∅

effect vote

∆(votes)

vo? : Votes

votes0=votes ∪ {vo?}

effect decide

∆(decC)

trdecC! : Trans

if (NO ∈votes)then decC0=ABORT

else decC0=COMMIT

trdecC! = decC0

Coord2

chan vote : [vo? : Votes;add1:{1. . . N};add2:{1. . . N}]

chan acknowledge chan decide : [trdecC? : Trans]chan inform : [in! : Trans]

main c

=k| 0<i≤N(vote?vo.i?add2→Skip); decide?trdecC →PhaseTwo

PhaseTwo c

=k| 0<i≤N(inform?in →Skip);

k| 0<i≤N(acknowledge →Skip)

decC :Trans

Init

decC =ABORT

effect inform

in! : Trans

in! = decC

effect decide

∆(decC)

trdecC? : Trans

decC0=trdecC?

Figure 7.17: Decomposition of the TPCP: Coord specification

checking needs to cope with comparatively more events than the one of the decomposition

according to {vote,decide}. Figure 7.19 illustrates the predominance of {vote,decide}.

Similarly, for the decomposition with respect to the cut

C1={

inform

}

, one additional

transmission parameter of type Trans is required, and inform occurs multiple times within

the specification. The larger the amount of pages, the more occurrences of vote and

inform and thus, the more cut events for

and

. This is reflected in the evaluation

results: the larger the model, the better performs

{

vote

decide

}

in comparison to the

214 7 Implementation and Experimental Results

Page1(i:{1. . . N})

chan request chan execute

chan vote : [vo! : Votes;add1:{1. . . N};add2:{1. . . N}]

main c

=request →execute →vote?vo?add1.i→Skip

stable :B

Init

stable

effect execute

∆(stable)

stable0∈ {true,false}

effect vote

vo! : Votes

stable ⇒vo! = YES

¬stable ⇒vo! = NO

Page2(i:{1. . . N})

chan vote : [vo? : Votes;add1:{1. . . N};add2:{1. . . N}]

chan inform : [in? : Trans]chan undo chan complete

chan result : [r! : Trans]chan acknowledge

main c

=vote?vo?add1.i→PhaseTwo

PhaseTwo c

=inform?in →Result

Result c

= (undo →result?r→acknowledge →Skip

2complete →result?r→acknowledge →Skip)

decP :Trans

Init

decP =ABORT

effect inform

∆(decP)

in? : Trans

decP0=in?

effect result

r! : Trans

r! = decP

enable complete

decP =COMMIT

enable undo

decP =ABORT

Figure 7.18: Decomposition of the TPCP: Page specification

other cuts.

Still, within the mass validation framework, the cut

{

inform

}

receives the minimal

value, if we set an equal weight for all heuristics. This is due to the comparatively smaller

values for the heuristics

cut size

and

even distribution

. The example substantiates to

offer a possibility of scaling the different heuristics: a higher weight for

few transmission

will cause {vote,decide}to pass {inform}in terms of the overall value.

7.3 Experimental Results 215

decide

... votevote

Bool

... votevote

...

inform inform

...

inform inform

decide

... votevote ... votevote

... votevote

decide

... votevote

...

inform inform

...

inform inform

... votevote ... votevote

Votes

2Votes

Figure 7.19: Justification for predominance of cut {vote,decide}

Evaluation Analysis: Number Swapper

The results for the number swapper showed that the decomposition of a system does not

generally lead to a significant improvement in regard of model checking run-times. In this

specific case, the structure of the system does not allow for a decomposition beneficial for

compositional verification: the CSP part of the specification itself comprises five events

and only allows for a general cut. Thus, one of the components inevitably comprises

four events. Moreover, store b requires an additional transmission parameter, increasing

the size of the interface between both components. In conclusion, learning-based model

checking results in poor run-times.

Still, by decomposing the number swapper, the structure of the specification is mainly

maintained. There is no advantage in the application of direct model checking of the

original system over direct model checking of the decomposed system.

Summary

The evaluation results for the different case studies of this thesis highly differ. Summing

up, we can conclude that there is no universal best strategy which type of verification one

should choose. Still, we identified some rules-of-thumb for when to apply which strategy:

in general, applying the decomposition technique can be promising, if the underlying

system can be distributed in a reasonable way. This can either mean a split-up of the CSP

part into two phases without a large intersection between both parts (as, for instance,

the Two Phase Commit Protocol and the cut

{

vote

decide

}

) or a reasonable distribution

of its set of state variables (as, for instance, the candy machine and the cut {switch}).

The decomposition approach will not always be beneficial. In particular, if the system

is tightly coupled, a decomposition might not significantly reduce run-times during

(compositional) verification. However, the technique is generally applicable and for none

of the case studies did direct model checking of the original system perform best. Even

though one of our case studies represents a tightly coupled system, direct model checking

of its decomposition results in run-times, which are comparable to the ones for the model

checking of the undissected system.

8Conclusion

Contents

8.1 Summary ..................................217

8.2 FutureWork ................................219

The present chapter concludes this thesis with a summary. Subsequently, we discuss

some topics for future research.

8.1 Summary

Within this thesis, we introduced a decomposition technique for software models, specified

in an integrated formalism. The primary motivation for this approach arose from the

major challenge of automated software verification: the state explosion problem. In order

to allow model checking to scale to complex systems, appropriate measures need to be

taken. Compositional verification is one possible way of dealing with the state explosion.

The technique follows a “divide and conquer” approach: instead of verifying the system

as a whole, the components of the system are independently verified. An appropriate

combination of the verification results yields the correctness of the system. Compositional

reasoning avoids the state explosion problem to a certain extent, if the overall state space

of the components is comparatively smaller than the one of the original system.

After a short introduction to the topic, Chapter 2 provided background information

on the modelling and the analysis of software models. First, we surveyed the field of

integrated formal methods. Next, we presented the syntax and the semantics of the

underlying integrated formalism of this thesis, CSP-OZ, and we exemplified it by means of

a case study. Furthermore, a dependence analysis for CSP-OZ specifications was introduced.

Here, we defined the specification’s dependence graph, reflecting the control flow and the

data flow of a software model. The dependence graph provides the basis for a further

analysis and, eventually, a decomposition of a specification.

The second background chapter, Chapter 3, focussed on strategies for the automated

verification of a software model and, in particular, compositional verification. We provided

an overview on related and complementary techniques to cope with the state explosion

problem. The assume-guarantee paradigm of compositional reasoning was introduced,

along with two inference proof rules. Both proof rules are applied within our implementa-

tion framework, and they use the L

∗

algorithm for an automatic detection of intermediate

assumptions during model checking.

The first core chapter of this thesis, Chapter 4, described the actual decomposition of a

CSP-OZ specification. The general idea for the approach is the definition of a cut of the

218 8 Conclusion

specification’s dependence graph. In order to ensure the validity of the decomposition,

that is, the semantic equivalence of the decomposed system and the original system,

a cut needs to comply with four correctness criteria. We separated the general case

from the specific case of a single cut, mainly to allow a certain class of systems to be

decomposed in a more effective way. Subsequently, we defined a model’s decomposition

with respect to a valid cut. In order to guarantee the equivalence between the original

and the decomposed system, additional modifications of the resulting components had

to be introduced. Mainly, these modifications required the introduction of additional

parameters in order to restore the specification’s original control flow and data flow.

Chapter 5 showed correctness of the decomposition technique in terms of the trace

equivalence of the original and the generated model. The proof employed the opera-

tional semantics of CSP-OZ. We compositionally showed the correctness of both, the

decomposition of the CSP part and the one of the Object-Z part. For the CSP part, we

showed bisimilarity of the considered CSP processes, taking into account the additional

address parameters within the CSP part of the decomposition. For the correctness proof of

the Object-Z part, we showed trace equivalence by explicitly constructing the respective

transition paths and by using transmission parameters. Finally, both individual results

were used to deduce the overall correctness of the decomposition, additionally requiring

several CSP-related laws for renaming and for a redistribution of CSP processes.

As the validity of a decomposition does not automatically yield a system for which

model checking can effectively be carried out, Chapter 6 introduced several context-

specific heuristics to measure the quality of a decomposition. A classification of all valid

cuts is carried out in two steps: first, all unreasonable and dominated cuts are sorted out.

Second, the remaining cuts can be scaled, according to the heuristics.

Finally, Chapter 7 evaluated the approach on three case studies. As the underlying

platform, we chose the UML-based modelling environment Syspect and the CSP model

checker

FDR2

. In order to integrate the decomposition technique into the existing

framework, several extensions to Syspect were carried out. We compared run-times for

direct and compositional model checking for the original systems and the decompositions.

In summary, within this thesis, we developed a technique to effectively apply composi-

tional verification for software models, specified in an integrated formalism. We mainly

answered the following two questions:

1. How can we determine the set of all valid decompositions of a specification?

How can these decompositions be classified and measured regarding their effective-

ness for compositional model checking?

We further implemented the approach by integrating it into an existing tool for the

modelling and the analysis of software specifications. Based on the results obtained, we

observed that the decomposition technique can lead to a considerable speed-up of both,

compositional verification and direct verification.

8.2 Future Work 219

8.2 Future Work

The present work opened several perspectives and ideas for future research, which we

will discuss next. Particularly, we detail some further extensions and some possibilities on

how to combine the approach of this thesis with complementary techniques.

Target Area of Application:

The decomposition technique of this thesis has been carried

out with respect to the integrated formal method CSP-OZ. Yet, the approach presents

the major benefit of being independent from a specific formalism: the theory

of Chapter 4 used the (program) dependence graph (DG) of a specification in

order to decompose a software model. DGs are a commonly-used and language-

independent way of representing a software system [

HR92

]. Thus, the technique

can be transformed to fit to any language with an underlying dependence graph

representation for its models. The general idea behind the decomposition of the

model in terms of restoring the original control flow and the data flow can be used

accordingly. The correctness criteria need to be adapted, according to the context

specific semantic model and the equivalence requirements.

Semantic Model:

As the semantics of CSP-OZ are given in terms of CSP alone [

Fis00

our correctness proof referred to the semantic domain of CSP. Within the general

context of learning-based model checking of safety properties, we were interested

in analysing the observable behaviour of a specification. This allowed us to restrict

ourselves to the semantic model of traces, that is, the sequences of communication

events: the trace semantics is sufficient for showing the observable equivalence

of two systems [

CGP03

Weh00

]. In order to analyse liveness properties as, for

instance, deadlock or livelock freedom, the decomposition technique could as well

be extended to the more discriminating failures-divergences model of CSP. This

semantic model additionally takes the refusals of events and infinite sequences of

internal actions into account. The extension would require a modification of the cor-

rectness proof and, possibly, some additional correctness criteria in order to ensure

the failure-divergence equivalence of the original system and its decomposition.

Evaluation with ProB:

An evaluation of the decomposition technique was carried out

by using the CSP model checker

FDR2

. The choice was justified by several aspects,

which were given in Section 7.2.3. In order to realise a more profound analysis,

as a meaningful measure, the approach could be evaluated for a second model

checker. Recently, ProB [

Leu

], an animator and model checker for the B-Method

[

Abr96

], was extended to support CSP

as the input language [

LF08

]. Thus, an

implementation of the learning framework from Chapter 3 for ProB and a further

comparison of evaluation results for ProB and FDR2 could be advisable.

Weakening of Correctness Criteria:

One correctness criterion for a valid fragmentation

of the DG states that data dependences must not circumvent the set of cut operations.

The criterion was justified by the fact that the influence from one specification part

on the other one needs to be preserved. Our decomposition approach ensured this

220 8 Conclusion

by using transmission parameters. A possible weakening of the cut definition could

be a neglect of this criterion. In this case, transmission parameters would have to

be used for state variables which are modified before the cut as well. In general,

these considerations result in a trade-off between, on the one hand, the growing

amount of valid cuts and, on the other hand, the more complex evaluation of the

set of all valid cuts. Yet, we observed that a large set of additional parameter values

considerably slows down model checking, raising doubts on whether this strategy

is a way to success.

Recursive Learning:

Previous works [

GGP07

PGB+08

] extended the learning frame-

work to systems with an arbitrary number of components. Here, the specification

is stepwise decomposed, using a recursive application of the learning algorithm.

Wonisch already integrated the method into the CSPLChecker [

WW09

]. His ex-

tension allows to recursively apply both assume-guarantee-based proof rules with

respect to a specific split-ratio and systems which are parallel composed of ncom-

ponents. The theory of our thesis implicitly supports the recursive decomposition of

a system, as the two resulting specification components are CSP-OZ specifications

as well. In order to integrate this extension into Syspect, a re-import of the decom-

posed model and, in particular, a computation of the respective dependence graphs

is necessary.

Arbitrary Amount of Cut Sets:

According to Definition 4.2.8, a general cut refers to

two cut sets, and it yields a fragmentation of the DG into two parts. Clearly,

this approach might be extended to an arbitrary amount of lines of intersection,

yielding a decomposition of a model into a corresponding number of components.

However, within this thesis, we restricted ourselves to two cut sets: as previously

explained, the approach supports a recursive decomposition, already allowing for

a decomposition into an arbitrary amount of components without the need to

generalise and further complicate Definition 4.2.8.

Combination with other Techniques:

Another motivation for the re-import of a CSP-OZ

class specification into Syspect is given by the possibility to combine two techniques,

the slicing approach from [

Brü08

] and the decomposition method of this thesis:

if the verification requirement is at hand, an obvious strategy is to first slice the

original model with respect to the given requirement, re-import the slice and

decompose it according to our technique. Moreover, the presented technique is

generally compatible to other approaches to the state explosion problem.

Decomposition Implementation:

Chapter 7 presented the implementation of the de-

composition approach within the UML-based modelling tool Syspect. Here, several

future extensions are possible, mainly for closing the gaps between the theory and

the implementation and for facilitating the tool handling.

•

Implementation of General Cut Theory: The implementation of the decompo-

sition technique within Syspect is currently restricted to the special case of a

single cut. In order to allow the tool to support the decomposition of arbitrary

8.2 Future Work 221

specifications, an extension of the according plug-in is required. Here, the

main aspect to deal with is to allow the definition of two separate cut sets,

with each of them complying to the implemented theory for one cut set.

•

Implementation of Decomposition Improvement: In Section 4.3.7, we discussed

an improvement of the decomposition approach in terms of reducing the set

of initial data dependences. This optimisation is not yet implemented within

Syspect and thus, several valid cuts are currently rejected. An implementation

of this improvement, dependent on the respective specification, would lead to

larger set of valid cuts.

•

Modelling of Verification Properties: Currently, a manual specification of verifi-

cation properties in terms of CSP

is required. As a facilitation, a modelling of

the system requirements as a transition system is imaginable. Such an editor

could be similar to the existing Syspect state machine editor.

•

Extension of Counter Trace Plug-In: Section 7.2.4 introduced the countertrace

plug-in, a Syspect extension for visualising counterexamples. Currently, the

analysis only considers the CSP part of a specification. Thus, the set of detected

error traces is possibly too large. An additional analysis of the Object-Z part

would yield an exact counterexample analysis.

•

Elimination of System Classes: As a more technical aspect, the L

X-export of a

Syspect specification, comprising more than one class, requires the definition

of an additional class for describing the overall system composition. These

classes may be replaced by a simple CSP process, as they comprise an empty

Object-Z part. In order to speed-up model checking, the definition of the

overall system within Syspect should be given by a CSP process instead of a

CSP-OZ class.

Glossary of Symbols

CSP-OZ (Section 2.2)

S.Ithe interface definition of a specification S

S.Events the global set of events of a specification S

S.OZ the Object-Z part of a CSP-OZ specification S

S.main the CSP part of a CSP-OZ specification S

Object-Z part (Section 2.2)

State the state schema of OZ

Init the initial state schema of OZ

Op the set of operation schemas of OZ

enable op the precondition of the operation schema op

effect op the effect of the the operation schema op

op.delta the delta list of the operation schema op

op.dec the parameter declaration part of the operation schema op

op.pred the predicate part of the operation schema op

In(op)the set of possible values for the input parameters of op

Simple(op)the set of possible values for the simple parameters of op

Out(op)the set of possible values for the output parameters of op

ref(op)the set of referenced variables of the operation schema op

mod(op)the set of modified variables of the operation schema op

all(op)the union of the sets of referenced and modified variables of op

sVthe state s, projected onto the set of state variables V

MOZ the labelled transition system of OZ

Traces(OZ)the set of traces of the Object-Z part

π[i]the i-th state of π∈Traces(OZ)

π.ithe i-th event of π∈Traces(OZ)

traces(OZ)the set of traces of OZ, projected onto events

traces(OZ)Op the set of traces of OZ, projected onto operation names

224 8 Conclusion

CSP part (Section 2.2)

Skip termination

Stop deadlock

a→P a then P

P12P2P1external choice P2

P1uP2P1internal choice P2

P1kAP2P1parallel on A P2

P1A1kA2P2P1parallel on A1,A2P2

P1k| P2P1interleave P2

P1\A P hide A

PJRKPrenamed by R(relational renaming )

main the initial CSP process of a CSP-OZ specification

LCSP the set of all CSP terms

MCSP the labelled transition system of main

trEthe restriction of the trace tr on events in E

traces(main)Op the set of traces of main, projected onto operation names

tr.ithe i-th event of the trace tr

initials(P)the initial events of the process P

foot(tr)the last event of the trace tr

P|Ethe projection of the process Pon events in E

PvTQ Q is a trace refinement of P

P=TQ P and Qare trace equivalent

αPthe alphabet of the process P

{| C|} the extension set for the set of channels C

cpa partial event for the channel c

8.2 Future Work 225

Dependence Graphs (Section 2.3)

DGS= (N,−→DG)the dependence graph of a specification S

CFGS= (N,−→)the control flow graph of a specification S

DDGS= (op(N),999K)the data dependence graph of a specification S

op(N)the set of operation nodes of a dependence graph

cf(N)the set of CSP operator nodes of a dependence graph

−→ a control dependence

999K a direct data dependence

999K(v)a direct data dependence by reason of v

idd

999K an initial data dependence

L999K a synchronisation dependence

sdd

999K a synchronisation data dependence

ifdd

999K an interference data dependence

ifdd

999K(v)an interference data dependence by reason of v

pathDG /CFG the paths of the DG / CFG

pathDG /CFG(n,n’)the paths of the DG / CFG from nto n’

succ(n) the sole successor of the node n

succ one(n) the first successor of the node n

succ two(n) the second successor of the node n

Compositional Reasoning (Sections 3.2 and 3.3)

(B-AGR) the basic assume-guarantee proof rule

(P-AGR) the parallel assume-guarantee proof rule

(C-AGR) the circular assume-guarantee proof rule

L(A)the language of the assumption A, given as a DFA

L(A)Cthe complement of the language L(A)

Σ∗the set of finite words over Σ

Σωthe set of infinite words over Σ

226 8 Conclusion

Cut of a Dependence Graph (Section 4.2)

C= (C1,C2)a (general) cut of a dependence graph

C= (C1,∅)a single cut of a dependence graph

Phithe i-th phase of a fragmentation of a dependence graph

−→ N2the interval of nodes from N1to N2of a dependence graph

disjointness the first correctness constraint on a valid cut

no crossing the second correctness constraint on a valid cut

no reaching back the third correctness constraint on a valid cut

all-or-none the fourth correctness constraint on a valid cut

Decomposition of a Specification (Section 4.3)

S1the first component of a decomposition of S

S2the second component of a decomposition of S

CV the set of cut variables

op.orig the set of original parameters of the operation op

op.add the set of address parameters of the operation op

op.tr in the set of transmission parameters of the operation op,

decorated with “?”

op.tr out the set of transmission parameters of the operation op,

decorated with “!”

Opithe set of local operation schemas of the component Si

OpCthe set of cut operation schemas

Op0the union Op1∪Op2∪OpC

ESithe set of events of the component Si

ES0the union ES1∪ES2

RCthe (relational) event renaming for a decomposition of S

R0the inverse renaming relation

InitClos(x)the initial closure of the state variable x

8.2 Future Work 227

Correctness Proof (Chapter 5)

noev a special event to denote stuttering

CV the shared state variables, excluding cut variables

s⊕tthe state toverrides the state s

Decomposition Heuristics (Section 6.1)

hCS the heuristic for minimising the cut size

hED the heuristic for minimising the size difference

hFT the heuristic for minimising the transmission

hFA the heuristic for minimising the addressing

Predicate Logic

Free(p)the set of free variables occurring in the predicate p

p[x/a]the predicate pwith all free occurrences of x

replaced with a

Atoms(p)the set of atomic sub-predicates of the predicate p

vars(p)the set of variables occurring in the predicate p

Miscellaneous

IdXthe identity on X, that is, the set {(x,x)|x∈X}

Bibliography

[Abr96]

J.-R. Abrial. The B Book - Assigning Programs to Meanings. Cambridge University

Press, 1996.

[Abr06]

J.-R. Abrial. Formal methods in industry: achievements, problems, future. In ICSE

’06: Proceedings of the 28th international conference on Software engineering, pages

761–768, New York, NY, USA, 2006. ACM.

[ACHH92]

R. Alur, C. Courcoubetis, T. A. Henzinger, and P.-H. Ho. Hybrid automata: An

algorithmic approach to the specification and verification of hybrid systems. In

Hybrid Systems, volume 736 of Lecture Notes in Computer Science, pages 209–229.

Springer, 1992.

[Aˇ

CMN05]

R. Alur, P. ˇ

Cerný, P. Madhusudan, and W. Nam. Synthesis of interface specifications

for Java classes. ACM SIGPLAN Notices, 40(1):98–109, 2005.

[AD94]

R. Alur and D. L. Dill. A theory of timed automata. Theoretical Computer Science,

126(2):183–235, 1994.

[AH06]

J.-R. Abrial and S. Hallerstede. Refinement, decomposition, and instantiation of

discrete models: Application to Event-B. Fundamenta Informaticae, XXI, 2006.

[All70] F. E. Allen. Control flow analysis. SIGPLAN Not., 5(7):1–19, 1970.

[AMN05]

R. Alur, P. Madhusudan, and W. Nam. Symbolic compositional verification by

learning assumptions. In Computer Aided Verification, 17th International Conference,

CAV 2005, Edinburgh, Scotland, UK, July 6-10, 2005, Proceedings, volume 3576 of

Lecture Notes in Computer Science, pages 548–562. Springer, 2005.

[Ang87]

D. Angluin. Learning regular sets from queries and counterexamples. Information

and Computation, 75:87–106, 1987.

[APR+01]

T. Arons, A. Pnueli, S. Ruah, J. Xu, and L. D. Zuck. Parameterized verification with

automatically computed inductive assertions. In CAV ’01: Proceedings of the 13th

International Conference on Computer Aided Verification, pages 221–234, London,

UK, 2001. Springer-Verlag.

[BBK+04]

M. Balser, S. Bäumler, A. Knapp, W. Reif, and A. Thums. Interactive verification of

UML state machines. In Formal Methods and Software Engineering, 6th International

Conference on Formal Engineering Methods, ICFEM 2004, Seattle, WA, USA, November

8-12, 2004, Proceedings, volume 3308 of Lecture Notes in Computer Science, pages

434–448. Springer, 2004.

[BCC98]

S. Berezin, S. Campos, and E. M. Clarke. Compositional reasoning in model checking.

Lecture Notes in Computer Science, 1536:81–102, 1998.

[BCCZ99]

A. Biere, A. Cimatti, E. Clarke, and Y. Zhu. Symbolic model checking without BDDs.

In Tools and Algorithms for the Construction and Analysis of Systems. Part of European

Conferences on Theory and Practice of Software, ETAPS’99, Amsterdam, volume 1579

of LNCS, pages 193–207. Springer-Verlag, 1999.

230 Bibliography

[BGH+05]

S. Burmester, H. Giese, M. Hirsch, D. Schilling, and M. Tichy. The FUJABA real-time

tool suite: Model-driven development of safety-critical, real-time systems. In Proc. of

the 27th International Conference on Software Engineering (ICSE), St. Louis, Missouri,

USA, pages 670–671. ACM Press, 2005.

[BGL+00]

S. Bensalem, V. Ganesh, Y. Lakhnech, C. Muñoz, S. Owre, H. Rueß, J. Rushby,

V. Rusu, H. Saïdi, N. Shankar, E. Singerman, and A. Tiwari. An overview of SAL. In

LFM 2000: Fifth NASA Langley Formal Methods Workshop, pages 187–196, 2000.

[BGP03]

H. Barringer, D. Giannakopoulou, and C. S. Pasareanu. Proof rules for automated

compositional verification through learning. In International Workshop on Specifica-

tion and Verification of Component Based Systems, Finland, 2003.

[BHG87]

P. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in

Database Systems. Addison-Wesley, 1987.

[BJR99]

G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language User Guide.

Addison-Wesley, 1999.

[Bow09] J. Bowen. Formal Methods Wiki. http://formalmethods.wikia.com, 2009.

[Brü08]

I. Brückner. Slicing Integrated Formal Specifications for Verification. PhD thesis,

Universität Paderborn, 2008.

[Bry86]

R. Bryant. Graph-Based Algorithms for Boolean Function Manipulation. IEEE

Transactions on Computers, C-35(8):677–691, 1986.

[BS03]

E. Börger and R. Stärk. Abstract State Machines: A Method for High-Level System

Design and Analysis. Springer-Verlag, Berlin, 2003.

[But09]

M. Butler. Decomposition structures for event-B. In Integrated Formal Methods, 7th

International Conference, IFM 2009, Düsseldorf, Germany, February 16-19, 2009. Pro-

ceedings, volume 5423 of Lecture Notes in Computer Science, pages 20–38. Springer,

2009.

[CAC06]

J. Cobleigh, G. Avrunin, and L. Clarke. Breaking up is hard to do: an investigation

of decomposition for assume-guarantee reasoning. In ISSTA ’06: Proceedings of the

2006 international symposium on Software testing and analysis, pages 97–108, New

York, NY, USA, 2006. ACM.

[CBRZ01]

E. M. Clarke, A. Biere, R. Raimi, and Y. Zhu. Bounded model checking using

satisfiability solving. Formal Methods in System Design, 19(1):7–34, 2001.

[CC77]

P. Cousot and R. Cousot. Abstract interpretation: A unified lattice model for static

analysis of programs by construction or approximation of fixpoints. In Fourth ACM

Symposium on Principles of Programming Language, Los Angeles, pages 238–252.

ACM Press, New York, 1977.

[CCST05]

S. Chaki, E. M. Clarke, N. Sinha, and P. Thati. Automated assume-guarantee

reasoning for simulation conformance. In CAV, volume 3576 of Lecture Notes in

Computer Science, pages 534–547. Springer, 2005.

[CES86]

E. Clarke, E. Emerson, and A. Sistla. Automatic verification of finite-state concurrent

systems using temporal logic specifications. ACM Transactions on Programming

Languages and Systems, 8(2):244–263, 1986.

[CGJ+03]

E. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexample-guided

abstraction refinement for symbolic model checking. J. ACM, 50(5):752–794, 2003.

Bibliography 231

[CGK97]

S. C. Cheung, D. Giannakopoulou, and J. Kramer. Verification of liveness properties

using compositional reachability analysis. In Proceedings of the Sixth European

Software Engineering Conference (ESEC/FSE 97), pages 227–243. Lecture Notes in

Computer Science Nr. 1013, Springer–Verlag, 1997.

[CGL94]

E. Clarke, O. Grumberg, and D. Long. Model checking and abstraction. ACM

Transactions on Programming Languages and Systems, 16(5):1512–1542, 1994.

[CGP99] E. Clarke, O. Grumberg, and D. Peled. Model checking. MIT Press, 1999.

[CGP03]

J. Cobleigh, D. Giannakopoulou, and C. P

areanu. Learning assumptions for

compositional verification. In TACAS, pages 331–346, 2003.

[CJEF96]

E. M. Clarke, S. Jha, R. Enders, and T. Filkorn. Exploiting symmetry in temporal

logic model checking. Formal Methods in System Design, 9(1/2):77–104, 1996.

[CMP94]

E. Chang, Z. Manna, and A. Pnueli. Compositional verification of real-time systems.

In Logic in Computer Science (LICS ’94), pages 458–467, Los Alamitos, Ca., USA,

1994. IEEE Computer Society Press.

[Coo71]

S. A. Cook. The complexity of theorem-proving procedures. In Conference record

of third annual ACM symposium on theory of Computing, pages 151–158, Shaker

Heights, Oh., 1971. ACM.

[Cor]

Correct System Design Group. Syspect subversion repository.

https://homer.

informatik.uni-oldenburg.de/svn/syspect.

[CS07]

S. Chaki and O. Strichman. Optimized L*-based assume-guarantee reasoning. In

TACAS, volume 4424 of Lecture Notes in Computer Science, pages 276–291. Springer,

2007.

[CS08]

S. Chaki and O. Strichman. Three optimizations for assume-guarantee reasoning

with L∗.Formal Methods in System Design, 32(3):267–284, 2008.

[CW96]

E. M. Clarke and J. M. Wing. Formal methods: state of the art and future directions.

ACM Computing Surveys, 28(4):626–643, 1996.

[Den74]

J. B. Dennis. First version of a data flow procedure language. In Colloque sur la

Programmation. Springer-Verlag, Berlin, DE, 1974.

[Die05]

H. Dierks. Time, Abstraction and Heuristics – Automatic Verification and Planning

of Timed Systems using Abstraction and Heuristics. Habilitation thesis, 2005.

[Dij72]

E. W. Dijkstra. Notes on structured programming. In Structured Programming.

Academic Press, London, 1972.

[DNS08]

J. Derrick, S. North, and A. J. H. Simons. Z2SAL - building a model checker for Z. In

Abstract State Machines, B and Z, First International Conference, ABZ 2008, London,

UK, September 16-18, 2008. Proceedings, volume 5238 of Lecture Notes in Computer

Science, pages 280–293. Springer, 2008.

[DP60]

M. Davis and H. Putnam. A computing procedure for quantification theory. Journal

of the ACM, 7(3):201–215, 1960.

[dRHH+01]

W. de Roever, U. Hanneman, J. Hooiman, Y. Lakhneche, M. Poel, J. Zwiers, and

F. de Boer. Concurrency Verification. Cambridge University Press, Cambridge, UK,

2001.

232 Bibliography

[DW04] O. L. De Weck. Multiobjective optimization : history and promise. 2004.

[DW07]

J. Derrick and H. Wehrheim. On using data abstractions for model checking refine-

ments. Acta Inf, 44(1):41–71, 2007.

[DWQQ01]

W. Dong, J. Wang, X. Qi, and Z. Qi. Model checking UML statecharts. In APSEC,

pages 363–370. IEEE Computer Society, 2001.

[EC80]

E. A. Emerson and E. M. Clarke. Characterizing correctness properties of parallel

programs using fixpoints. In Proceedings of the 7th International Colloquium on

Automata, Languages and Programming, ICALP’80, volume 85 of LNCS, pages 169–

181. Springer-Verlag, Berlin-Heidelberg-New York-London-Paris-Tokyo-Hong Kong,

1980.

[EDK89]

E.M. Clarke, D.E. Long, and K.L. McMillan. Compositional Model Checking. In

Proceedings of Fourth Annual Symposium on Logic in Computer Science, pages 353–

361, Washington D.C., 1989. IEEE Computer Society Press.

[EF82]

T. Elrad and N. Francez. Decomposition of distributed programs into communication-

closed layers. Science of Computer Programming, 2(3):155–173, 1982.

[Ehr00]

M. Ehrgott. Multicriteria optimization. Lecture Notes in Economics and Mathematical

Systems. Springer-Verlag, 2000.

[ESB+09]

S. Edelkamp, V. Schuppan, D. Bošnaˇ

cki, A. Wijs, A. Fehnker, and H. Aljazzar. Survey

on directed model checking. pages 65–89, 2009.

[Fis97]

C. Fischer. CSP-OZ: A combination of Object-Z and CSP. In Formal Methods for Open

Object-Based Distributed Systems (FMOODS’97), volume 2, pages 423–438. Chapman

& Hall, 1997.

[Fis99]

C. Fischer. Printing CSP-OZ documents with latex; documentation for csp-oz.sty.

Technical report, University of Oldenburg, 1999.

[Fis00]

C. Fischer. Combination and Implementation of Processes and Data: from CSP-OZ to

Java. PhD thesis, University of Oldenburg, 2000.

[FMS01]

A. Farias, A. Mota, and A. Sampaio. Java translator from CSP-Z to CSPM notation.

http://www.di.ufpe.br/~acf/translator/CSPZtoCSPM.html, 2001.

[For05]

Formal Systems (Europe) Ltd. Failure divergence refinement: FDR2 user manual.

http://www.fsel.com/documentation/fdr2/fdr2manual.pdf, 2005.

[FOW87]

J. Ferrante, K. J. Ottenstein, and J. D. Warren. The program dependence graph and

its use in optimization. ACM Transactions on Programming Languages and Systems,

pages 319–349, 1987.

[FP78]

N. Francez and A. Pnueli. A proof method for cyclic programs. Acta Informatica,

9(2), 1978.

[FW99]

C. Fischer and H. Wehrheim. Model-checking CSP-OZ specifications with FDR. In

IFM, pages 315–334, 1999.

[Gal04]

D. Galin. Software quality assurance. Pearson Education Limited, Harlow, England,

2004.

[GGP07]

M. Gheorghiu, D. Giannakopoulou, and C. S. P

areanu. Refining interface alphabets

for compositional verification. In TACAS, pages 292–307, 2007.

Bibliography 233

[GL91]

O. Grumberg and D. E. Long. Model checking and modular verification. In CONCUR

’91: Proceedings of the 2nd International Conference on Concurrency Theory, pages

250–265, London, UK, 1991. Springer-Verlag.

[GMF07]

A. Gupta, K. L. McMillan, and Z. Fu. Automated assumption generation for composi-

tional verification. In CAV, pages 420–432, 2007.

[God96]

P. Godefroid. Partial-Order Methods for the Verification of Concurrent Systems.

Springer, Berlin, 1996.

[GP08]

D. Giannakopoulou and C. S. P˘

as˘

areanu. Special issue on learning techniques for

compositional reasoning. Form. Methods Syst. Des., 32(3):173–174, 2008.

[GP09]

D. Giannakopoulou and C. S. Pasareanu. Interface generation and compositional

verification in Java PathFinder. In Fundamental Approaches to Software Engineer-

ing, 12th International Conference, FASE 2009, Held as Part of the Joint European

Conferences on Theory and Practice of Software, ETAPS 2009, York, UK, March 22-29,

2009. Proceedings, volume 5503 of Lecture Notes in Computer Science, pages 94–108.

Springer, 2009.

[GPB02]

D. Giannakopoulou, C. S. P

areanu, and H. Barringer. Assumption generation

for software component verification. In ASE ’02: Proceedings of the 17th IEEE

international conference on Automated software engineering, pages 3–12, Washington,

DC, USA, 2002. IEEE Computer Society.

[GPY02]

A. Groce, D. Peled, and M. Yannakakis. Adaptive model checking. In TACAS

’02: Proceedings of the 8th International Conference on Tools and Algorithms for the

Construction and Analysis of Systems, pages 357–370, London, UK, 2002. Springer-

Verlag.

[Gri97]

A. Griffiths. Modular reasoning in Object-Z. In Proceedings: 4th Asia-Pacific Software

Engineering and International Computer Science Conference, pages 140–149. IEEE

Computer Society Press, 1997.

[Gri98]

A. Griffiths. A formal semantics to support modular reasoning in Object-Z. PhD thesis,

University of Queensland, 1998.

[Har87]

D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer

Programming, 8(3):231–274, 1987.

[Her09]

K. Herbold. Konzeption & Implementierung eines Dekompositions-Werkzeugs für

kompositionelle Verifikation. Diploma’s thesis, Universität Paderborn, 2009.

[HJ98]

C. A. R. Hoare and H. Jifeng. Unifying Theories of Programming. Prentice Hall,

London, 1998.

[Hoa78] C. Hoare. Communicating sequential processes. CACM, 21:666–677, 1978.

[Hoa85] C. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.

[Hoe06]

J. Hoenicke. Combination of Processes, Data, and Time. PhD thesis, University of

Oldenburg, 2006.

[Hol03] G. J. Holzmann. The SPIN Model Checker. Pearson Education, 2003.

[HR92]

S. Horwitz and T. Reps. The use of program dependence graphs in software

engineering. In ICSE ’92: Proceedings of the 14th international conference on Software

engineering, pages 392–411, New York, NY, USA, 1992. ACM.

234 Bibliography

[ISO89]

ISO - International Standards Organization. Information processing systems – open

systems interconnection – LOTOS – A formal description technique based on the

temporal ordering of observational behaviour. Technical report, 1989. ISO/IEC

8807.

[ISO00]

ISO - International Standards Organization. Information technology – Z formal

specification notation – syntax, type system and semantics. Technical report, 2000.

ISO/IEC 13568.

[ISO01]

ISO - International Standards Organization. Information technology – enhancements

to LOTOS (E-LOTOS). Technical report, 2001. ISO/IEC 15437.

[JEK+90]

J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, and L.J. Hwang. Symbolic Model

Checking:

1020

States and Beyond. In Proceedings of the Fifth Annual IEEE Symposium

on Logic in Computer Science, pages 1–33, Washington, D.C., 1990. IEEE Computer

Society Press.

[Jon83]

C. Jones. Specification and design of (parallel) programs. In IFIP Congress, pages

321–332, 1983.

[KK99]

G. Karypis and V. Kumar. Multilevel k -way hypergraph partitioning. In DAC, pages

343–348, 1999.

[KP88]

S. Katz and D. Peled. An efficient verification method for parallel and distributed

programs. In Workshop on Linear Time, Branching Time and Partial Order in Logics

and Models for Concurrency, number 354 in LNCS, pages 489–507, Noordwijkerhout,

The Netherlands, 1988. Springer-Verlag.

[KS01]

G. Kassel and G. Smith. Model checking Object-Z classes: Some experiments with

FDR. In APSEC, pages 445–452. IEEE Computer Society, 2001.

[Kur94]

R. P. Kurshan. Computer-aided Verification of Coordinating Processes – The Automata-

Theoretic Approach. Princeton Univ. Press, 1994.

[Leu]

M. Leuschel. ProB homepage.

http://www.stups.uni-duesseldorf.de/

ProB.

[LF08]

M. Leuschel and M. Fontaine. Probing the depths of CSP-M: A new fdr-compliant

validation tool. In Formal Methods and Software Engineering, 10th International

Conference on Formal Engineering Methods, ICFEM 2008, Kitakyushu-City, Japan,

October 27-31, 2008. Proceedings, volume 5256 of Lecture Notes in Computer Science,

pages 278–297. Springer, 2008.

[LMC01]

M. Leuschel, T. Massart, and A. Currie. How to make FDR spin - LTL model

checking of CSP by refinement. In FME 2001: Formal Methods for Increasing Software

Productivity, International Symposium of Formal Methods Europe, Berlin, Germany,

March 12-16, 2001, Proceedings, volume 2021 of Lecture Notes in Computer Science,

pages 99–118. Springer, 2001.

[LZ74] Liskov and Zilles. Programming with abstract data types. Sigplan Notices, 9, 1974.

[Mai03]

P. Maier. Compositional circular assume-guarantee rules cannot be sound and

complete. In FoSSaCS, pages 343–357, 2003.

[MC81]

J. Misra and K. M. Chandy. Proofs of networks of processes. IEEE Trans. Softw. Eng.,

7(4):417–426, 1981.

Bibliography 235

[McM93]

K. L. McMillan. Symbolic Model Checking: An Approach to the State Explosion Problem.

Kluwer Academic Publishers, 1993.

[MDA] OMG model driven architecture. http://www.omg.org/mda.

[MG07]

N. Moffat and M. Goldsmith. Assumption-commitment support for CSP model

checking. Electron. Notes Theor. Comput. Sci., 185:121–137, 2007.

[Mic10]

S. Micus. Rückführung und Visualisierung von Gegenbeispielen aus einem Model

Checker. Bachelor’s thesis, Universität Paderborn, 2010.

[Mil89] R. Milner. Communication and Concurrency. Prentice-Hall, 1989.

[Mil99]

R. Milner. Communicating and Mobile Systems: The

Calculus. Cambridge University

Press, Cambridge, England, 1999.

[Moo90]

A. P. Moore. The specification and verified decomposition of system requirements

using CSP. IEEE Transactions on Software Engineering, 16:932–948, 1990.

[MORW08]

M. Möller, E.-R. Olderog, H. Rasch, and H. Wehrheim. Integrating a formal method

into a software engineering process with UML and Java. Formal Apsects of Computing,

20:161–204, 2008.

[MS98] A. Mota and A. Sampaio. Model-checking CSP-Z. In FASE, pages 205–220, 1998.

[MS01]

A. Mota and A. Sampaio. Model-checking CSP-Z: strategy, tool support and industrial

application. Sci. Comput. Program, 40(1):59–96, 2001.

[MWW08]

B. Metzler, H. Wehrheim, and D. Wonisch. Decomposition for compositional verifica-

tion. In Formal Methods and Software Engineering, 10th International Conference on

Formal Engineering Methods, ICFEM 2008, Kitakyushu-City, Japan, October 27-31,

2008. Proceedings, volume 5256 of Lecture Notes in Computer Science, pages 105–125.

Springer, 2008.

[NA06]

W. Nam and R. Alur. Learning-based symbolic assume-guarantee reasoning with

automatic decomposition. In ATVA, pages 170–185, 2006.

[Nam07]

W. Nam. Synthesis and Compositional Verification Using Language Learning. PhD

thesis, University of Pennsylvania, 2007.

[NAS]

NASA Ames Research Center. Java PathFinder.

http://babelfish.arc.nasa.

gov/trac/jpf.

[Obj05]

Object Management Group. OMG unified modeling language 2.0.

http://www.

omg.com/uml, 2005.

[OD08]

E.-R. Olderog and H. Dierks. Real-Time Systems: Formal Specification and Automatic

Verification. Scientific and Engineering Computation Series. Cambridge University

Press, New York, NY, 2008.

[OL82]

S. Owicki and L. Lamport. Proving liveness properties of concurrent programs. ACM

Transactions on Programming Languages and Systems, 4(3), 1982.

[OW05]

E.-R. Olderog and H. Wehrheim. Specification and (property) inheritance in CSP-OZ.

Science of Computer Programming, 55(1-3):227–257, 2005.

[Par71]

V. Pareto. Manual of Political Economy. Kelley, New York, 1971. Originally published

1927. Translated from the Italian by A. S. Schwier, edited by A. S. Schwier and A. N.

Page.

236 Bibliography

[PBG05]

M. R. Prasad, A. Biere, and A. Gupta. A survey of recent advances in SAT-based

formal verification. International Journal on Software Tools for Technology Transfer

(STTT), 7(2):156–173, 2005.

[PGB+08]

C. S. Pasareanu, D. Giannakopoulou, M. G. Bobaru, J. M. Cobleigh, and H. Barringer.

Learning to divide and conquer: applying the L* algorithm to automate assume-

guarantee reasoning. Formal Methods in System Design, 32(3):175–205, 2008.

[Pie10]

M. Piepmeyer. Effiziente Validierung und Bewertung von Modellzerlegungen.

Diploma’s thesis, Universität Paderborn, 2010.

[Pnu84]

A. Pnueli. In transition from global to modular temporal reasoning about programs.

In Logics and Model of Concurrent Systems, volume 13 of NATO ASI, pages 123–144.

Springer-Verlag, Berlin, New York, 1984.

[Pnu85]

A. Pnueli. Linear and branching structures in the semantics and logics of reactive

systems. Lecture Notes Comp. Sci., 194:15–32, 1985.

[Rei85] W. Reisig. Petri Nets: An Introduction. Springer-Verlag, 1985.

[Res]

Research Group Specification and Modelling of Software Systems. Syspect extensions

subversion repository. https://svn-serv.cs.upb.de/syspect-plugins.

[Ros98] W. A. Roscoe. Theory and Practice of Concurrency. Prentice-Hall, 1998.

[RR95]

T. Reps and G. Rosay. Precise interprocedural chopping. In SIGSOFT FSE, pages

41–52, 1995.

[RW94]

A. Rensink and H. Wehrheim. Weak sequential composition in process algebras. In

Proceedings of the Fifth International Conference on Concurrency Theory CONCUR’94,

Uppsala (Sweden), pages 226–241, Berlin-Heidelberg-New York, 1994. Springer.

[Sch99]

S. Schneider. Concurrent and Real Time Systems: The CSP Approach. John Wiley &

Sons, Inc., New York, NY, USA, 1999.

[Sch02]

P. Schnoebelen. The complexity of temporal logic model checking. In Advances in

Modal Logic, pages 393–436. King’s College Publications, 2002.

[Sch05]

S. Schneider. Non-blocking data refinement and traces-divergences semantics.

Technical report, University of Surrey, 2005.

[Sch09] S. Schneider. Personal communication, 2009.

[SGT+03]

W. Schäfer, H. Giese, M. Tichy, S. Burmester, and S. Flake. Towards the compositional

verification of real-time UML designs. In ESEC/SIGSOFT FSE, pages 38–47. ACM,

2003.

[SLU89]

K. K. Sabnani, A. M. Lapone, and M. U. Uyar. An algorithmic procedure for checking

safety properties of protocols. IEEE Trans. Communications, 37(9):940–948, 1989.

[Smi95]

G. Smith. A fully abstract semantics of classes for Object-Z. Formal Aspects of

Computing, 7(3):289–313, 1995.

[Smi00] G. Smith. The Object-Z Specification Language. Kluwer Academic Publisher, 2000.

[SNT85]

Y. Sawaragi, H. Nakayama, and T. Tanino. Theory of multi-objective optimization.

Academic Press, Inc., Orlando, FL, 1985.

[Spi92]

J. M. Spivey. The Z notation: a reference manual. Prentice Hall International (UK)

Ltd., Hertfordshire, UK, 1992.

Bibliography 237

[ST02]

S. Schneider and H. Treharne. Communicating B machines. In ZB ’02: Proceedings

of the 2nd International Conference of B and Z Users on Formal Specification and

Development in Z and B, pages 416–435, London, UK, 2002. Springer-Verlag.

[ST04]

S. Schneider and H. Treharne. Verifying controlled components. In IFM, pages

87–107, 2004.

[ST05]

S. Schneider and H. Treharne. CSP theorems for communicating B machines. Formal

Asp. Comput., 17(4):390–422, 2005.

[Sta06]

A. Stamer. Integration von CSP-OZ in die OO-Softwareentwicklung für die automa-

tische Verifikation. Diploma’s thesis, Universität Oldenburg, 2006.

[STE05]

S. Schneider, H. Treharne, and N. Evans. Chunks: Component verification in CSP||B.

In IFM’2005, pages 89–108, 2005.

[SW05]

G. Smith and L. Wildman. Model checking Z specifications using SAL. In ZB, pages

85–103, 2005.

[SWC02]

A. Sampaio, J. Woodcock, and A. Cavalcanti. Refinement in Circus. In FME 2002:

Formal Methods - Getting IT Right, volume 2391 of Lecture Notes in Computer Science,

pages 451–470. Springer-Verlag, 2002.

[Sys06]

Syspect. Endbericht der Projektgruppe Syspect. Technical report, Carl von Ossietzky

University of Oldenburg, 2006.

[TA97]

K. Taguchi and K. Araki. The state-based CCS semantics for concurrent Z specifica-

tion. In ICFEM, pages 283–292, 1997.

[TJ02]

J. J. P. Tsai and E. Y. T. Juan. Model and heuristic technique for efficient verification

of component-based software systems. In IEEE ICCI, pages 59–68. IEEE Computer

Society, 2002.

[TS99]

H. Treharne and S. Schneider. Using a process algebra to control B operations. In

IFM ’99: Proceedings of the 1st International Conference on Integrated Formal Methods,

pages 437–456, London, UK, 1999. Springer-Verlag.

[WC02]

J. Woodcock and A. Cavalcanti. The semantics of Circus. In ZB 2002: Formal

Specification and Development in Z and B, volume 2272 of Lecture Notes in Computer

Science, pages 184–203. Springer-Verlag, 2002.

[Weh00]

H. Wehrheim. Data abstraction techniques in the validation of CSP-OZ specifications.

Formal Aspects of Computing, 12, 2000.

[Wei81]

M. Weiser. Program slicing. In Proceedings of the 5th International Conference on

Software Engineering, pages 439–449. IEEE Computer Society Press, 1981.

[Wik06]

Wikipedia. Retrieved from

http://en.wikipedia.org/wiki/Wikipedia

2006.

[Won]

D. Wonisch. CSPLChecker homepage.

http://www.cs.uni-paderborn.de/

index.php?id=8967&L=1.

[Won08]

D. Wonisch. Automatisiertes kompositionelles Model Checking von CSP Spezifikatio-

nen. Bachelor’s thesis, Universität Paderborn, 2008.

[WS03]

K. Winter and G. Smith. Compositional verification for Object-Z. In ZB, pages

280–299, 2003.

238 Bibliography

[WW09]

H. Wehrheim and D. Wonisch. Compositional CSP traces refinement checking. In

Proceedings of the Eighth International Workshop on Automated Verification of Critical

Systems (AVoCS 2008), volume 250, Issue 2, pages 135–151. Elsevier B.V., 2009.

[Xie96]

M. Xie. Handbook of Software Reliability Engineering. McCraw Hill, New York, 1996.

[Zel74]

M. Zeleny. Linear Multiobjective Programming, volume 95 of Lecture Notes in Eco-

nomics and Mathematical Systems. Springer, Berlin/New York, 1974.

[ZH04]

C. Zhou and M. R. Hansen. Duration Calculus: A Formal Approach to Real-Time

Systems. EATCS: Monographs in Theoretical Computer Science. Springer, 2004.

List of Figures

1.1 Decomposition of a specification Sinto S1and S2.............. 4

1.2 Illustration of the overall approach of this thesis . . . . . . . . . . . . . . . 4

2.1 Structure of a CSP-OZ specification . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Structure of the Object-Z part of a CSP-OZ specification . . . . . . . . . . . 12

2.3 Candy machine specification . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Illustration of the CSP part of the candy machine specification . . . . . . . 16

2.5 Simplified grammar of CSP . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Correctness requirement for the candy machine specification . . . . . . . . 24

2.7 Translation of a CSP-OZ specification into a CSP process . . . . . . . . . . 25

2.8 Simple CSP-OZ class specification for swapping two numbers . . . . . . . . 28

2.9 Control flow graph (CFG) for the candy machine specification . . . . . . . 31

2.10 Simple CSP-OZ class specification for a ticket machine . . . . . . . . . . . 35

2.11 Data dependence graph (DDG) for the ticket machine specification . . . . 36

2.12 Extract of DDG for the candy machine specification . . . . . . . . . . . . . 37

2.13 Dependence graph (DG) for the candy machine specification . . . . . . . . 39

3.1 Basic assume-guarantee proof rule (B-AGR) ................. 44

3.2 Parallel assume-guarantee proof rule (P-AGR) ................ 44

3.3 Circular assume-guarantee rule (C-AGR) .................. 45

3.4 Illustration of the L∗algorithm ........................ 46

3.5 Illustration of the L∗based learning framework . . . . . . . . . . . . . . . 47

3.6 Rule (B-AGR) rephrased in terms of CSP trace refinement . . . . . . . . . 49

3.7 Rule (P-AGR) rephrased in terms of CSP trace refinement . . . . . . . . . 49

3.8 CSP specification of a simple elevator system . . . . . . . . . . . . . . . . 50

4.1 Overview of the cut identification and the decomposition . . . . . . . . . . 57

4.2 Illustration of Definition 4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Fragmentation of the DG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Disallowed control flow edges based on disjointness . . . . . . . . . . . . . 62

4.5 Motivation for the correctness criterion no crossing ............ 62

4.6 Disallowed data dependences based on no crossing ............ 63

4.7 Motivation for the correctness criterion no reaching back ......... 64

4.8 Disallowed edges based on no reaching back ................ 65

4.9 Fragmentation of the set of operation nodes in general case . . . . . . . . 67

4.10 Assignment of DG edges to the subgraphs . . . . . . . . . . . . . . . . . . 68

4.11 Fragmentation of the set of operation nodes in the special case . . . . . . . 69

4.12 Cut of the dependence graph for the candy machine . . . . . . . . . . . . 71

4.13 Constituents of a CSP-OZ class specification . . . . . . . . . . . . . . . . . 72

240 List of Figures

4.14 Correspondence between graph nodes and specification operations . . . . 73

4.15 Simple CSP-OZ specification for increasing two natural numbers . . . . . . 80

4.16 Intermediate decomposition of Increaser ................... 80

4.17 Possible data dependences targeting the cut and originating from the cut . 81

4.18 Illustration of the transmission parameters . . . . . . . . . . . . . . . . . . 84

4.19 Decomposition of Increaser, modified according to Definition 4.3.10 . . . . 85

4.20 Synchronisation of events for external choice . . . . . . . . . . . . . . . . 87

4.21 Addressing extension for CFG branching . . . . . . . . . . . . . . . . . . . 89

4.22 Addressing extension for nested branching . . . . . . . . . . . . . . . . . . 90

4.23 Illustration of Theorem 4.3.16 . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.24 Decomposition of the candy machine, first component . . . . . . . . . . . 104

4.25 Decomposition of the candy machine, second component . . . . . . . . . . 105

4.26 CSP-OZ specification for swapping two numbers, extended . . . . . . . . . 107

4.27 Decomposition of the number swapper, first component . . . . . . . . . . . 108

4.28 Decomposition of the number swapper, second component . . . . . . . . . 108

4.29 Correctness requirement for Swapper .....................109

5.1 Illustration of the steps of the correctness proof . . . . . . . . . . . . . . . 112

5.2 Algorithm for the address extension: procedure ADDRESSMAIN ......114

5.3 Algorithm for the address extension: procedure ADDRESSCUT .......114

5.4 Algorithm for the address extension: procedure MODIFYCUT ........115

5.5 Algorithm for the address extension: procedure ADD ............116

5.6 Illustration of a violation of Lemma 5.2.1 . . . . . . . . . . . . . . . . . . . 120

5.7 Illustration of a violation of Lemma 5.2.2 . . . . . . . . . . . . . . . . . . . 120

5.8 Illustration of the CSP correctness proof of binary operators . . . . . . . . 121

5.9 Case differentiation for Lemma 5.2.3, parallel composition . . . . . . . . . 131

5.10 Illustration of Definition 5.3.2 and Lemmas 5.3.3, 5.3.4 . . . . . . . . . . . 141

5.11 Illustration of Lemma 5.3.12 . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.12 Illustration of Lemma 5.3.15 . . . . . . . . . . . . . . . . . . . . . . . . . . 157

6.1 Illustration of the Two Phase Commit Protocol . . . . . . . . . . . . . . . . 176

6.2 Phase one of the Two Phase Commit Protocol . . . . . . . . . . . . . . . . 176

6.3 Phase two of the Two Phase Commit Protocol . . . . . . . . . . . . . . . . 177

6.4 Two Phase Commit Protocol: Coord specification . . . . . . . . . . . . . . 177

6.5 Two Phase Commit Protocol: Page specification . . . . . . . . . . . . . . . 178

7.1 Syspect class diagram for the TPCP . . . . . . . . . . . . . . . . . . . . . . 185

7.2 Syspect property view for the operation Page.inform .............185

7.3 Syspect state machine for the class Page ofTPCP...............186

7.4 Syspect state machine for the class Coord ofTPCP..............187

7.5 Syspect component diagram for the TPCP . . . . . . . . . . . . . . . . . . 188

7.6 Toolchain for the verification framework . . . . . . . . . . . . . . . . . . . 189

7.7 Screenshot of a selected invalid cut . . . . . . . . . . . . . . . . . . . . . . 190

7.8 Screenshot of the decomposition options after selection of a valid cut . . . 191

List of Figures 241

7.9 Screenshot of the mass validation framework . . . . . . . . . . . . . . . . 193

7.10 Correctness requirement for the TPCP in terms of CSPM..........194

7.11 Compilation from L

TEX to CSPM........................195

7.12 Screenshot of the CSPLChecker . . . . . . . . . . . . . . . . . . . . . . . . 196

7.13 Screenshot of the counterexample visualisation . . . . . . . . . . . . . . . 197

7.14 Verification framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.15 Correctness requirement for the candy machine in terms of CSPM. . . . . 202

7.16 Correctness requirement for the number swapper in terms of CSPM. . . . 207

7.17 Decomposition of the TPCP: Coord specification . . . . . . . . . . . . . . . 213

7.18 Decomposition of the TPCP: Page specification . . . . . . . . . . . . . . . . 214

7.19 Justification for predominance of cut {vote,decide}.............215

List of Tables

1.1 Contributions of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Comparison between the different semantics for CSP-OZ . . . . . . . . . . 27

2.2 Table of nodes of the control flow graph . . . . . . . . . . . . . . . . . . . 30

2.3 Table of edges of the data dependence graph . . . . . . . . . . . . . . . . . 33

4.1 Comparison between the general cut and the single cut . . . . . . . . . . . 70

4.2 Comparison of two traces for Increaser and its components . . . . . . . . . 82

4.3

Comparison of two traces of Increaser and its components after modification

6.1 Heuristic hCS:cut size .............................170

6.2 Heuristic hED:even distribution .......................170

6.3 Heuristic hFT:few transmission .......................172

6.4 Heuristic hFA:few addressing ........................172

6.5 Set of valid cuts for the candy machine . . . . . . . . . . . . . . . . . . . . 175

6.6 Set of valid cuts for the TPCP . . . . . . . . . . . . . . . . . . . . . . . . . 179

7.1 Experimental results for the candy machine . . . . . . . . . . . . . . . . . 203

7.2 Experimental Results for the TPCP, first part . . . . . . . . . . . . . . . . . 205

7.3 Experimental Results for the TPCP, second part . . . . . . . . . . . . . . . 206

7.4 Experimental results for the (extended) number swapper, first part . . . . 208

7.5 Experimental results for the (extended) number swapper, second part . . . 209

7.6 Summary of the experimental results . . . . . . . . . . . . . . . . . . . . . 209

Index

Symbols

Skip ...............................20

Stop ...............................20

A1kA2..............................20

2...................................20

u...................................20

k| ...................................20

kA..................................20

RunA................................21

9....................................20

CSPM..............................193

L∗.............................45,182

SPIN .............................182

abstract interpretation.. .... ... ... ...42

address algorithm. ... ... ... ... ... ..114

correctness....................118

termination....................117

allowed synchronisation.. ... ... ... ..92

assume-guarantee reasoning .. ... . 3, 43

basic proof rule . ... ... ... ... ... . 44

circular proof rule.. ... ... ... ....44

parallel proof rule. .. .... ... ... ..44

soundness of basic proof rule. ...50

soundness of parallel proof rule . 51

black box checking ... ... ... ... ... ... 54

bounded model checking. ... ... ... ..43

CCS.................................10

CCS-Z...............................10

CFG.............see control flow graph

Circus...............................11

Communicating Sequential Processessee

CSP

Communication Closed Layers law . 212

compositional verification.. ... ... .3, 43

learning........................45

cone-of-influence reduction.. ... ... ..42

control flow analysis .. ... .... ... ... . 29

control flow graph . ... ... ... ... ... .. 29

fragmentation...................59

completeness.................60

labelling of nodes .. ... ... .... ... 32

paths...........................30

recursion-free.. .. .... ... ... ..141

phase...........................59

CSP.............................11,20

compositional verification . .. ... . 53

failures-divergences model .. ... . 22

semantics.......................22

set of CSP terms.. .. ... .... ... ...21

stable failures model .. ... ... ... . 22

CSP||B .............................10

compositional verification . .. ... . 53

CSP process

alphabetised parallel .. ... .. ... .. 20

channel.........................20

extensionset..................21

channeltype....................20

choice..........................20

guarding of events .. ... .... ... .. 25

hiding..........................20

indexedchoice..................21

indexed parallel composition ... . 21

interface parallel. .... ... ... .... .20

interleaving.....................20

partialevent....................22

prefix...........................20

prefixchoice....................21

processcall.....................20

projection.......................76

redistribution laws.. ... ...164, 165

renaming.......................20

traces...........................22

initials........................23

246 Index

projection.....................23

CSPZ...........................24,194

CSP-OZ

∆list.......................15,17

effect schema.. .... ... ... .15, 17

enable schema.. .... ... ... .15, 17

classstructure...................12

constant parameters .. ... .... .. 212

dependence analysis ... ... ... ... 27

failures-divergences semantics. ..25

initial state schema. ... ... ...13, 17

input parameter. ... ... ... ... ... .13

interface........................12

operation schema .. ... .... .. 12, 16

declaration part. ... ... ... ... ..18

deltalist......................18

modified variables .. ... ... ... . 17

predicate part.... ... ... .... ...18

referenced variables. ... ... ....17

output parameter .. ... .... ... ... 13

parameter......................13

semantics.......................24

setofevents....................16

simple parameter .. ... .... ... ... 13

state............................17

projection.....................17

state invariants. ... .... ... ... ....17

state schema .. ... .... ... ... . 13, 16

statevariable...................16

initial closure. ... ... ... .... ..106

CSP-OZ-DC..........................11

CSP-Z..........................10,193

CSPLChecker .. ... ... ... ... ... 192, 195

cut..................................66

comparison of single and general70

correctness criteria

all-or-none....................66

disjointness...................61

nocrossing...................63

no reaching back. ... ... ... ... .65

general.........................66

interval between cut sets .. .... .. 58

single...........................68

properties.....................69

data abstraction . .. .... ... ... .... . 3, 42

datadependence....................33

direct...........................34

direct by reason. ... ... ... .... ...34

initial...........................33

interference.....................34

interference by reason... .... ... .34

synchronisation .. ... ... ... ... ... 34

data dependence graph... ... ... .... .33

decomposition.....................100

correctness....................101

no distribution of initial events120

no split of synchronisation .. . 121

redistribution of CSP processes122

correctness proof .. ... .... ... .. 166

correctness proof of CSP part . . 132

correctness proof of Object-Z part

152, 157

Pareto-optimal. ... ... ... ... ... .173

unreasonable..................173

connection to heuristics. ... ..173

weakly dominated .. ... .... ... . 173

decomposition components

Init schemas..................77

correctness .. ... ... ... .. 143, 144

State schemas.................77

conditions for correct synchronisa-

tion.........................90

correctness proof .. ... .... ... . 93

CSPparts......................100

cutvariables....................83

eventsets.......................97

interfaces.......................99

operation schemas .. ... .... ... .. 83

renaming of channels . ... ... ... . 98

renaming of events.. .. .... ... ...99

distributivity law . ... ... ... .. 162

properties...................161

sets of operations . ... ... ... ... .. 75

decomposition heuristics

cutsize........................169

even distribution. ... ... ... ... ..170

few addressing. ... ... ... ... ... .172

Index 247

few transmission.. ... ... ... ....170

dependence graph.. ... ... ... ... ... ..37

DG..............see dependence graph

directed model checking ... ... .... . 182

Duration Calculus .. ... .... ... ... .... 11

E-LOTOS............................11

earlierstage.......................140

equivalence relation . ... .... ... ... . 106

Event-B.............................10

compositional verification . .. ... . 53

FDR2 ......................25,53,192

formalmethods....................2,9

formal verification. ... ... ... ... ... ... .2

hypergraph partitioning . .. ... .. .. .. 181

identity relation.. ... ... .... ...106, 123

integrated formal methods .. .... ... 2, 9

JavaPathFinder....................182

labelled transition system .. ... ... ... 18

CSPpart........................23

language........................43

Object-Zpart....................19

parallel composition .. ... ... ... . 26

path............................19

liveness property . . .. .. . .. . . .. . . .. .. . 48

LOTOS..............................10

LTS.......see labelled transition system

model checking .. ... ... ... ... . 3, 41, 42

model driven development (MDD) .. .. 1

multicriteria optimisation ... .. 173, 182

NP completeness.. ... ... .... ... ... .192

Object-Z.........................11,16

compositional verification . .. ... . 53

history semantics . ... ... .... ... . 18

semantics.......................18

structure........................12

operational semantics

CSPpart........................22

CSP-OZ.........................24

Object-Zpart...................18

partial order reduction. .. ... .... ..3, 42

PDG.............see dependence graph

π-calculus...........................10

program dependence graph .. ... ... . see

dependence graph

real-time systems . ... ... ... ... .... . 182

refinement..........................23

safety properties .. ... .... ... ... .... . 22

safetyproperty......................48

SAL.................................53

SATsolving........................192

software quality assurance (SQA) . ... . 1

softwaretesting......................1

software verification. ... ... ... .... ... .2

state explosion. ... ... ... ... ...3, 41, 42

symbolic model checking ... ... ... 3, 43

symbolic transition systems . .. 110, 181

symmetry reduction . .. ... .. .. ... ... . 42

synchronisation dependence.. ... ... .34

realisationof....................91

Syspect............................184

classdiagram..................184

component diagram... ... ... ...187

countertrace plug-in .. ... .... .. 196

decomposition framework .. .. . 188

decomposition plug-in .. ... .... 189

export to L

TEX.................187

mass validation .. ... .... ... ... . 191

propertyview..................185

248 Index

statemachine..................186

timedautomata.....................10

trace equivalence.. ... ... .... ... ... ..23

tracerefinement....................23

Two Phase Commit Protocol... ... ..175

Unified Modelling Language. .. ... ..1, 9

activity diagram .. ... .... ... ... 198

compositional verification . .. ... . 53

Znotation...........................11

axiomatic definition... ... ... .... 12

basictype.......................11

freetype........................11