formalising interface speciﬁcations - alexandria.tue.nlalexandria.tue.nl/extra2/200612247.pdf ·...

Formalising Interface Specifications

Louis van Gool

This research was financially supported by the Dutch Technology Foundation STW(EES.5141).

The work in this thesis has been carried out under the auspices of the researchschool IPA (Institute for Programming research and Algorithmics).

IPA dissertation series 2006-19

Cover design by Paul Verspaget

Copyright c© 2006 Louis van Gool

CIP-DATA LIBRARY TECHNISCHE UNIVERSITEIT EINDHOVEN

Gool, Louis C.M. van

Formalising interface specifications / door Louis C.M. van Gool. -

Eindhoven : Technische Universiteit Eindhoven, 2006.

Proefschrift. - ISBN 90-386-0814-4. - ISBN 978-90-386-0814-3

NUR 993

Subject headings: formal languages / software ; specifications /

object-oriented modelling / object-oriented programming /

semantics / set theory / recursion theory

CR Subject Classification (1998) : F.4.3, F.4.1, F.3.3, F.3.1

Formalising Interface Specifications

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de

Technische Universiteit Eindhoven, op gezag van de

Rector Magnificus, prof.dr.ir. C.J. van Duijn, voor een

commissie aangewezen door het College voor

Promoties in het openbaar te verdedigen

op maandag 27 november 2006 om 16.00 uur

door

Louis Clemens Martinus van Gool

geboren te Venlo

Dit proefschrift is goedgekeurd door de promotoren:

prof.dr. J.C.M. Baeten

en

prof.dr. A. de Bruin

Copromotor:

dr. R. Kuiper

Preface

To properly balance the finishing of your Ph.D. thesis with your full-time job andsocial life appears to be not that easy. Because you always have less and need moretime than you think, the final date keeps on being postponed. This cannot go onforever though. There are members of a doctorate committee waiting for that onefinal version, who you keep bothering with new partial versions. There are alsofamily, friends and colleagues waiting for that party, who you keep telling that itis almost finished. Then there is the author of the thesis, who finally wants tospend a holiday on the beach instead of one behind paper and a computer screen.One should also be aware of the fact that science is not waiting for you to finishand research might be severely outdated before copies of your thesis are printed.However, more than two years late, here it finally is.

There are several people without whom this thesis would have never been written.First of all, I want to thank Jos Baeten and Ruurd Kuiper for accepting me as aPh.D. student. After my master’s, there could not have been a better opportunityfor me to do the kind of research that I liked to do. This is for a large part thanksto the freedom that Ruurd gave me. I thank him for that and also for the fact thathe knew when to restrict this freedom.

One person that was the source of many of the ideas that are formalised in thisthesis, is ‘the father of ISpec’ Hans Jonkers. In the many discussions that we hadand the research that initiated and followed from these discussions, I really learnedto appreciate the careful thought that went into the conception of ISpec. I thankHans for his patience during our many hours of discussion where I often tried tomake things simpler than they were.

For many theoretical ideas in this thesis, it seems impossible to trace them back tothe person that should be accredited for them. All I can do is name the person thattaught me most of these ideas, being the supervisor of my master’s thesis, Jaap vander Woude. Several of these ideas were undoubtfully his own original ones. Muchof the formal theory in this thesis is no more than an elaboration of things that hetaught me, but that have, to the best of my knowledge, never been written downin articles. I also thank Jaap for pointing me to this Ph.D. position.

Also the Systematic Object-Oriented Programming (SOOP) group of the Technische

v

Universiteit Eindhoven, in which I participated, was the source of several ideas. Ithank all members of that group for the interesting sessions.

Creation of tool support for ISpec was one of the primary goals of our project. Ilike to thank all people that worked on this: Ella Roubtsova, Sergei Roubtsov, ErikLuit and the Callisto team. I especially thank Ella for the fact that, without her, Iwould probably not have published a single article during my Ph.D. period.

I thank all members of the core committee, Jos Beaten, Arie de Bruin, RuurdKuiper, Roland Backhouse and Hans Jonkers for their more-than-two-year patienceand careful reading of an ever-growing number of pages. I also thank Mark van denBrand, Loe Feijs and Wim Hesselink for joining the doctorate committee.

Then there are colleagues that enable you to go to your work with pleasure. I thankall colleagues of the (Eindhoven) Embedded Systems Institute (E)ESI and formalmethods (FM) group for this. I especially thank Harm van Beek for the ‘deep’discussions during lunch and for enhancing my table-tennis skills. For the samereasons, I also thank Koos van Gogh who did his master’s within our project.

Finally I want to thank my family and friends that, during my four-year Ph.D.period, enabled me to not spend time on thinking about my work outside workinghours. I’m convinced that without them, I would not have been able to avoid theinfamous ‘AIO-dip’. I thank Werner and Barry for being my paranimphs.

vi

Contents

Preface v

Contents vii

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 ISpec 32.1 Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Suite diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Semantic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2 Roles, interfaces and methods . . . . . . . . . . . . . . . . . 172.3.3 Parameters and results . . . . . . . . . . . . . . . . . . . . . 182.3.4 Global state . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.5 This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1 Suite diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.4 Bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.1 Required interfaces . . . . . . . . . . . . . . . . . . . . . . . 272.5.2 Parallellism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.3 Object existence . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.4 Renaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.5 Black-box semantics . . . . . . . . . . . . . . . . . . . . . . . 29

vii

2.5.6 Activation specifications . . . . . . . . . . . . . . . . . . . . 292.5.7 Keeping parent roles . . . . . . . . . . . . . . . . . . . . . . 29

2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Relations 313.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Predicate calculus . . . . . . . . . . . . . . . . . . . . . . . . 313.1.2 Omission of brackets . . . . . . . . . . . . . . . . . . . . . . 323.1.3 Omission of quantifications . . . . . . . . . . . . . . . . . . . 323.1.4 Basic elements . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.5 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.6 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.7 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.8 Emptiness and fullness . . . . . . . . . . . . . . . . . . . . . 343.1.9 Functionality and totality . . . . . . . . . . . . . . . . . . . . 353.1.10 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.11 Tuples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.12 Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.13 Fix notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.14 Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.15 Application relation . . . . . . . . . . . . . . . . . . . . . . . 373.1.16 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.17 Binary predicates . . . . . . . . . . . . . . . . . . . . . . . . 383.1.18 Equalilty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.19 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.20 Element-of and owner-of . . . . . . . . . . . . . . . . . . . . 383.1.21 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.22 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1.23 Comprehension . . . . . . . . . . . . . . . . . . . . . . . . . 413.1.24 Non-strict evaluation . . . . . . . . . . . . . . . . . . . . . . 433.1.25 Feijen notation . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.26 Axiom of choice . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.27 Point-wise against point-free . . . . . . . . . . . . . . . . . . 45

3.2 Collection operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.2 Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.3 Binary intersection and union . . . . . . . . . . . . . . . . . 473.2.4 Then and when . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.5 Removed-from and without . . . . . . . . . . . . . . . . . . . 473.2.6 Same and other . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.7 Empty and full collection . . . . . . . . . . . . . . . . . . . . 483.2.8 Complement . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.9 Arbitrary intersection and union . . . . . . . . . . . . . . . . 493.2.10 Notational considerations . . . . . . . . . . . . . . . . . . . . 49

3.3 Relation operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.1 Sequential composition . . . . . . . . . . . . . . . . . . . . . 503.3.2 Over and under . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii

3.3.3 Identity relation . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.4 Domain and range . . . . . . . . . . . . . . . . . . . . . . . . 513.3.5 Converse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.6 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.7 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.8 Spick and spack . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.9 Constant function . . . . . . . . . . . . . . . . . . . . . . . . 523.3.10 Doubling function . . . . . . . . . . . . . . . . . . . . . . . . 533.3.11 Everywhere and somewhere . . . . . . . . . . . . . . . . . . 53

3.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.1 Emptiness and fullness . . . . . . . . . . . . . . . . . . . . . 543.4.2 Uniqueness and singleness . . . . . . . . . . . . . . . . . . . 553.4.3 Functionality, injectivity, totality and surjectivity . . . . . . 553.4.4 Sets, conditions and squares . . . . . . . . . . . . . . . . . . 553.4.5 Reflexivity, transitivity and symmetry . . . . . . . . . . . . . 563.4.6 Monotonicity . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.7 Closedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.8 Disjointness and conjointness . . . . . . . . . . . . . . . . . . 583.4.9 Domain equalness . . . . . . . . . . . . . . . . . . . . . . . . 583.4.10 Idempotency, commutativity and associativity . . . . . . . . 583.4.11 Zeros and units . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.12 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.13 Commutation . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.14 Abidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.15 Comparability, chains and continuity . . . . . . . . . . . . . 60

3.5 Galois connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.5.2 More cancellation laws . . . . . . . . . . . . . . . . . . . . . 613.5.3 Uniqueness and existence of adjoints . . . . . . . . . . . . . 623.5.4 Exploiting Galois connections . . . . . . . . . . . . . . . . . 62

3.6 Fixed points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.7 Relators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.8 Some theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.8.1 Shunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.8.2 Complementing things . . . . . . . . . . . . . . . . . . . . . 683.8.3 Distribution of sequential composition over intersection . . . 683.8.4 Extreme point-freeness . . . . . . . . . . . . . . . . . . . . . 70

3.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 Types 734.1 Cylindric typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2 Type operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2.1 Cylindric-type operator . . . . . . . . . . . . . . . . . . . . . 754.2.2 Functionality and totality . . . . . . . . . . . . . . . . . . . . 754.2.3 Restrictedness . . . . . . . . . . . . . . . . . . . . . . . . . . 764.2.4 Combining type operators . . . . . . . . . . . . . . . . . . . 774.2.5 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

ix

4.2.6 Bidirectional-type operator . . . . . . . . . . . . . . . . . . . 774.2.7 Set-preservingness . . . . . . . . . . . . . . . . . . . . . . . . 774.2.8 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.2.9 Type diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.10 Twelve type operators . . . . . . . . . . . . . . . . . . . . . . 79

4.3 Type-generalising some other concepts . . . . . . . . . . . . . . . . 824.3.1 Emptiness and fullness . . . . . . . . . . . . . . . . . . . . . 824.3.2 Reflexivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.3.3 Shunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4 Properties of the cylindric-type operator . . . . . . . . . . . . . . . 834.4.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4.2 Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4.3 Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.4.4 Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.4.5 Sequential composition . . . . . . . . . . . . . . . . . . . . . 854.4.6 Identity relation . . . . . . . . . . . . . . . . . . . . . . . . . 854.4.7 Converse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5 Products 915.1 Cylindric product . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2 Constrained cylindric products . . . . . . . . . . . . . . . . . . . . . 945.3 Constrained cylindric packs . . . . . . . . . . . . . . . . . . . . . . . 965.4 Properties of the binary constrained cylindric products . . . . . . . 100

5.4.1 Cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.4.2 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.4.3 Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.4.4 Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.4.5 Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.4.6 Sequential composition . . . . . . . . . . . . . . . . . . . . . 1035.4.7 Identity relation . . . . . . . . . . . . . . . . . . . . . . . . . 1085.4.8 Converse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.5 Arbitrary products . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.6 Conjoint sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.7 Properties of the constrained cylindric packs . . . . . . . . . . . . . 1125.8 Loose product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6 Expressions 1176.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.1.3 Strict unary operators . . . . . . . . . . . . . . . . . . . . . . 1196.1.4 Loose binary operators . . . . . . . . . . . . . . . . . . . . . 1206.1.5 Loose unary operators . . . . . . . . . . . . . . . . . . . . . 121

6.2 Non-strict evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 122

x

6.3 Single-valuedness and typing . . . . . . . . . . . . . . . . . . . . . . 1266.4 Theorem lifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.5 Assignment and substitution . . . . . . . . . . . . . . . . . . . . . . 1286.6 Collection-comprehension operator . . . . . . . . . . . . . . . . . . . 1306.7 Set-comprehension operator . . . . . . . . . . . . . . . . . . . . . . 1316.8 Connectional expressions . . . . . . . . . . . . . . . . . . . . . . . . 132

6.8.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326.8.2 Constructing connectional expressions . . . . . . . . . . . . . 1336.8.3 Assignment and substitution . . . . . . . . . . . . . . . . . . 1336.8.4 Some relationships . . . . . . . . . . . . . . . . . . . . . . . . 134

6.9 Notational conventions . . . . . . . . . . . . . . . . . . . . . . . . . 1356.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7 Specifications 1377.1 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377.2 Post and pre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.3 Partial correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7.3.1 Conjunctivity of post . . . . . . . . . . . . . . . . . . . . . . 1397.3.2 Disjunctivity of pre . . . . . . . . . . . . . . . . . . . . . . . 1407.3.3 Binary union . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407.3.4 Sequential composition . . . . . . . . . . . . . . . . . . . . . 1407.3.5 Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417.3.6 Identity relation . . . . . . . . . . . . . . . . . . . . . . . . . 1427.3.7 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427.3.8 If-then-else . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437.3.9 While . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437.3.10 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.3.11 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

7.4 Type, declarative and operational . . . . . . . . . . . . . . . . . . . 1507.5 Structural hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557.6 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587.7 Aspects and invariants . . . . . . . . . . . . . . . . . . . . . . . . . 161

7.7.1 Aspect operator . . . . . . . . . . . . . . . . . . . . . . . . . 1617.7.2 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637.7.3 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647.7.4 Proving invariants . . . . . . . . . . . . . . . . . . . . . . . . 1647.7.5 Type, declarative and operational invariants . . . . . . . . . 166

7.8 Totality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667.8.1 Total refinement . . . . . . . . . . . . . . . . . . . . . . . . . 1677.8.2 Proving totality . . . . . . . . . . . . . . . . . . . . . . . . . 1677.8.3 Total correctness . . . . . . . . . . . . . . . . . . . . . . . . . 1687.8.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717.8.5 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

8 Statements 175

xi

8.1 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758.2 Statement operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

8.2.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768.2.2 Binary intersection and union . . . . . . . . . . . . . . . . . 1768.2.3 Empty and universal statement . . . . . . . . . . . . . . . . 1768.2.4 Sequential composition . . . . . . . . . . . . . . . . . . . . . 1768.2.5 Identity statement . . . . . . . . . . . . . . . . . . . . . . . . 1768.2.6 Pick and pack . . . . . . . . . . . . . . . . . . . . . . . . . . 1778.2.7 Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778.2.8 Constrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778.2.9 Preservation of monotonicity . . . . . . . . . . . . . . . . . . 1778.2.10 Other operators . . . . . . . . . . . . . . . . . . . . . . . . . 1778.2.11 Correspondence with expressions . . . . . . . . . . . . . . . . 1788.2.12 Theorem lifting . . . . . . . . . . . . . . . . . . . . . . . . . 1788.2.13 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

8.3 Call expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798.4 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

8.4.1 Statement-refinement . . . . . . . . . . . . . . . . . . . . . . 1828.4.2 Behavioural refinement . . . . . . . . . . . . . . . . . . . . . 1838.4.3 Simple refinement rules . . . . . . . . . . . . . . . . . . . . . 1838.4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1838.4.5 A ‘strange’ refinement . . . . . . . . . . . . . . . . . . . . . . 185

8.5 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1868.5.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1868.5.2 Statement-intersection . . . . . . . . . . . . . . . . . . . . . 1868.5.3 Behavioural intersection . . . . . . . . . . . . . . . . . . . . 1878.5.4 Statement-component composition . . . . . . . . . . . . . . . 1878.5.5 Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1888.5.6 Statement-refinement . . . . . . . . . . . . . . . . . . . . . . 1908.5.7 Behavioural refinement . . . . . . . . . . . . . . . . . . . . . 1908.5.8 Independence . . . . . . . . . . . . . . . . . . . . . . . . . . 193

8.6 Totality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.6.1 Total statement-refinement . . . . . . . . . . . . . . . . . . . 1998.6.2 Total behavioural refinement . . . . . . . . . . . . . . . . . . 1998.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.6.4 Conservative users . . . . . . . . . . . . . . . . . . . . . . . . 201

8.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

9 Protocols 2099.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

9.1.1 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2099.1.2 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2109.1.3 Connection traces . . . . . . . . . . . . . . . . . . . . . . . . 2119.1.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2139.1.5 Connection protocols . . . . . . . . . . . . . . . . . . . . . . 213

9.2 Protocol operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2149.2.1 Sequential composition . . . . . . . . . . . . . . . . . . . . . 214

xii

9.2.2 Identity protocol . . . . . . . . . . . . . . . . . . . . . . . . . 2149.2.3 Domain and range . . . . . . . . . . . . . . . . . . . . . . . . 2149.2.4 Pick and pack . . . . . . . . . . . . . . . . . . . . . . . . . . 2159.2.5 Universal dark protocol . . . . . . . . . . . . . . . . . . . . . 2159.2.6 Show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2159.2.7 Spec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2169.2.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

9.3 Visual independence . . . . . . . . . . . . . . . . . . . . . . . . . . . 2169.4 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2189.5 Protocol statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

9.5.1 Sequential composition . . . . . . . . . . . . . . . . . . . . . 2199.5.2 Identity protocol statement . . . . . . . . . . . . . . . . . . . 2199.5.3 Pick and pack . . . . . . . . . . . . . . . . . . . . . . . . . . 2209.5.4 Universal statement-dark statement . . . . . . . . . . . . . . 2209.5.5 Show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2209.5.6 Spec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

9.6 Visual-independent statements . . . . . . . . . . . . . . . . . . . . . 2209.7 Visibility of calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

9.7.1 Invisible calls . . . . . . . . . . . . . . . . . . . . . . . . . . . 2219.7.2 Visible input/output . . . . . . . . . . . . . . . . . . . . . . 2219.7.3 ‘Fake’ visible calls . . . . . . . . . . . . . . . . . . . . . . . . 222

9.8 Genuine statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 2239.8.1 Introspectivity . . . . . . . . . . . . . . . . . . . . . . . . . . 2239.8.2 Genuineness . . . . . . . . . . . . . . . . . . . . . . . . . . . 2249.8.3 Continuity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

9.9 Refinement of protocol statements . . . . . . . . . . . . . . . . . . . 2299.9.1 Simple refinement rules . . . . . . . . . . . . . . . . . . . . . 2299.9.2 A ‘strange’ refinement revisited . . . . . . . . . . . . . . . . 2309.9.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 2319.9.4 Invisible calls . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

9.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

10 Variables 23510.1 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23510.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

10.2.1 Variable expressions . . . . . . . . . . . . . . . . . . . . . . . 23610.2.2 Modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23610.2.3 Declared variables . . . . . . . . . . . . . . . . . . . . . . . . 23710.2.4 Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23710.2.5 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

10.3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24010.3.1 Global states . . . . . . . . . . . . . . . . . . . . . . . . . . . 24010.3.2 Field selection . . . . . . . . . . . . . . . . . . . . . . . . . . 24110.3.3 Field-modify . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

10.4 Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24310.4.1 Global state . . . . . . . . . . . . . . . . . . . . . . . . . . . 24310.4.2 This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

xiii

10.4.3 Field selection . . . . . . . . . . . . . . . . . . . . . . . . . . 24410.4.4 Field-modify . . . . . . . . . . . . . . . . . . . . . . . . . . . 24410.4.5 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24510.4.6 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24510.4.7 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

10.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

11 Suites 24711.1 Some more operators . . . . . . . . . . . . . . . . . . . . . . . . . . 247

11.1.1 Over and under . . . . . . . . . . . . . . . . . . . . . . . . . 24711.1.2 Arbitrary intersection . . . . . . . . . . . . . . . . . . . . . . 24911.1.3 Aspect operator . . . . . . . . . . . . . . . . . . . . . . . . . 250

11.2 Formal ISpec language . . . . . . . . . . . . . . . . . . . . . . . . . 25111.2.1 Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25311.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25411.2.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25411.2.4 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25411.2.5 Posts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25511.2.6 Action clauses . . . . . . . . . . . . . . . . . . . . . . . . . . 25511.2.7 Post-conditions . . . . . . . . . . . . . . . . . . . . . . . . . 25511.2.8 Result types . . . . . . . . . . . . . . . . . . . . . . . . . . . 25511.2.9 Pres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25611.2.10Pre-conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 25611.2.11Parameters types . . . . . . . . . . . . . . . . . . . . . . . . 25611.2.12Role invariants . . . . . . . . . . . . . . . . . . . . . . . . . . 25711.2.13Action invariants . . . . . . . . . . . . . . . . . . . . . . . . 25711.2.14Post invariants . . . . . . . . . . . . . . . . . . . . . . . . . . 25711.2.15State invariants . . . . . . . . . . . . . . . . . . . . . . . . . 25811.2.16Attribute types . . . . . . . . . . . . . . . . . . . . . . . . . 25811.2.17Primitive types . . . . . . . . . . . . . . . . . . . . . . . . . 25811.2.18Sequential composition . . . . . . . . . . . . . . . . . . . . . 25911.2.19Modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25911.2.20Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

11.3 Plug pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.3.1 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.3.2 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.3.3 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26311.3.4 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26411.3.5 A trace of insertInto . . . . . . . . . . . . . . . . . . . . . . . 268

11.4 Observer pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27311.4.1 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27311.4.2 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27411.4.3 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27411.4.4 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27511.4.5 A trace of insertInto . . . . . . . . . . . . . . . . . . . . . . . 27711.4.6 Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

11.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

xiv

12 Conclusions 28312.1 Our work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28312.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28412.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Summary 287

Samenvatting 289

Curriculum vitae 291

Bibliography 293

Index 298

xv

Make things as simple as possible, but not simpler.

Albert Einstein

xvii

Chapter 1

Introduction

At Philips Research the specification approach ISpec has been developed for thespecification of interfaces of component-based systems. The main idea behind ISpecis that specifications are a kind of design patterns [20], called “suites” in ISpec. Todescribe suites, ISpec uses several academic notions like invariants, pre-conditions,post-conditions and abstract operational descriptions called “action clauses”. Inthis thesis, several fundamental concepts of ISpec are formally investigated and aformal language for suites is defined.

1.1 Motivation

Why should we formalise an approach that is already successful? From an academicpoint of view, trying to formalise ISpec is interesting because it is an approach that isactually used in practice, forcing one to think about real-life concepts like ‘object’,‘role’, ‘interface’ and ‘design pattern’. A mathematical foundation also helps tobetter understand ISpec and can act as a solid basis for the construction of toolsupport. Relatively simple tool support that is based on a solid basis can alreadybe very helpful in improving consistency of specifications. Tool support for ISpecis currently under development.

1.2 Overview

Chapter 2 starts with an informal description of ISpec to sketch the context of theformalisation that follows. The main mathematical formalism that is used for theformalisation, is the calculus of relations. In chapter 3 we introduce the basis of thiscalculus. Chapter 4 systematically investigates different ways of typing, introducinga rich collection of type operators. A key role is played by the cylindric-type oper-ator whose algebraic properties are investigated in detail. Using the cylindric-type

1

operator, we define and investigate in chapter 5 a new construct called the cylindricproduct and several constrained forms of this construct, including the product andsum of allegory theory. These products are used in the construction of a model forexpressions that evaluate in several different ways: strictly, non-strictly and evennon-deterministically. This is the subject of chapter 6. In chapter 7 we apply thetheory developed thus far by showing how several fundamental concepts like re-finement, correctness, mixing of declarative and operational descriptions, structuralhierarchy, components, aspects and invariants can be formalised. In that chapter weobserve that recursion needs some extra attention. This subject is treated in chap-ter 8. There we observe that the abstraction level of relations is too high to capturesemantically visible calls. Chapter 9 addresses this issue by the introduction of pro-tocols. In all above-mentioned chapters we abstracted from the particular shape ofstates. Chapter 10 shows how states can be structured such that common variable-concepts of object-oriented programming are captured. In chapter 11 we show howthe concepts developed thus far relate to ISpec by defining a formal language forsuites. Chapter 12 concludes the thesis.

2

Chapter 2

ISpec

In this chapter we give an overview of ISpec’s main concepts.

2.1 Suites

The core observation from which ISpec originated, is that interaction patterns(called suites in ISpec) are a better unit of specification than individual classes. Aninteraction pattern describes the interaction between objects by means of rolesthat the objects can play. A role represents a certain task that an object has in aninteraction and is comparable to the notion of abstract class in object-orientedprogramming. An object can play multiple roles and multiple objects can play thesame role, all this at one point in time.

A classical example of an interaction pattern is the observer pattern that describesthe interaction between subjects and observers. Each subject has a number ofobservers and each observer observes at most one subject. A subject has a stateof which all its observers have a copy. Proper interaction between the subject andits observers should ensure that its observers’ copies are updated when necessary.Although it is possible to describe the class of subjects and the class of observersin isolation and see it as a coincidental choice of a programmer that both classesinteract, it is more natural to describe the two classes as part of one coherentinteraction pattern.

Although we agree that building systems by means of interaction patterns is apowerful approach, this thesis is not about the motivations behind this approach.For this we refer the reader to [34]. The intention of this thesis is to provide aformal ground for the main concepts that play a role in such an approach and inISpec in particular. As proof of the pudding, we present in chapter 11 a completelyformal specification of the observer pattern (restricted to at most one observer persubject to simplify things a little).

3

2.2 Syntax

In [35] ISpec’s syntax for suites is defined by means of an object-oriented class model,called the ISpec metamodel. The classes in a metamodel are called metaclasses.In [35] the ISpec metamodel is described by means of several UML-like class dia-grams. The following subsections introduce a slightly adjusted version of the ISpecmetamodel step by step.

2.2.1 Suite diagrams

We start with the syntax of suite diagrams. It is described by the following UMLclass diagram:

Suite SuiteMember

Role Interface Method

Attribute

Type

0..*

0..*

0..* 0..*

0..*

1

providedInterface

requiredInterface

Name 1 0..*

1..*

1 1

1 1

1

ValueType ObjectType

NamedItem name

member

method TypedItem

attribute

type

We first describe what the above UML class diagram expresses and then explainthe notation in general. A NamedItem has exactly one Name as name. A Suite is aNamedItem and has SuiteMembers as members. A SuiteMember is also a NamedItem

and is member of exactly one Suite. Roles, Interfaces, Methods, Attributes and Typesare all SuiteMembers. Each Interface is providedInterface of exactly one Role andrequiredInterface of at least one Role. Each Method is method of exactly one Interface.An Attribute is attribute of exactly one Role and is a TypedItem. A TypedItem hasexactly one Type as type and a Type is type of exactly one TypedItem. ValueTypesand ObjectTypes are Types.

Each “ X ” in the diagram represents the metaclass with name X (metaclasses

have unique names). An instance of a metaclass X is simply called “an X”. A

“ Y −−−� Z ” means that metaclass Y is a subclass of metaclass Z: all instances

of metaclass Y are also instances of metaclass Z, or “a Y is a Z”. A “ Ym⋄−−−xn Z ”

means that each Y has n Zs as x and each Z is x of m Y s, where “0..*” means “zeroor more”, “0..1” means “zero or one”, “1..*” means “at least one” and “1” means“exactly one”. If a metaclass name X is written in italics, the metaclass is abstractand otherwise it is concrete. A concrete metaclass can have direct instances(an abstract metaclass cannot). A direct instance of a (concrete) metaclass is aninstance of that metaclass and an instance of any metaclass is a direct instance of

4

exactly one (concrete) metaclass.

To keep text readable, we from now on omit “as x” if we think that it is clear fromthe context which x is meant. We write for example “an Interface has Methods”instead of “an Interface has Methods as methods”. We also talk about “the X n”instead of “the X that has Name n (as name)”, writing for example “the Suite

ObserverPattern” instead of “the Suite that has the Name ObserverPattern asname”.

The fact that each Type is type of exactly one TypedItem may look strange at firstsight. Why could two items not have the same type? An instance of the metaclassType is not a type however, but a placeholder for a Name that represents a type.This is the reason why we talk about a “Type” instead of a “type”. Two ValueTypescould for example both have “bool” as Name. Both ValueTypes then represent thetype of the booleans.

An example of a suite diagram is the diagram of what we shall call the plug pat-tern:

IFill fillWith empty

IInsert insertInto remove

hasPlug : bool plug : Plug

Hole

inHole : bool hole : Hole

Plug Main

PlugPattern

The Suite PlugPattern has three Roles: Hole, Plug and Main. The Interface IFill

is a providedInterface of Role Hole (represented by the “

”) and a requiredInterface

of Role Plug (represented by the “

”). The Interface IInsert is a providedInterface

of Role Plug and a requiredInterface of Role Main. The use of dotted lines for Mainis explained in section 2.5.6. Interface IFill has Methods fillWith and empty andInterface IInsert has Methods insertInto and remove. Role Hole has AttributeshasPlug and plug and Role Plug has Attributes inHole and hole. The AttributeshasPlug and inHole both have a ValueType bool, Attribute plug has an ObjectType

Plug and Attribute hole has an ObjectType Hole (underlining is used to distinguishValueTypes from ObjectTypes).

It could be tempting to think that the two occurrences of bool in the above picturerefer to one and the same instance of ValueType. This cannot be the case howeverbecause, as explained earlier, a Type is type of exactly one TypedItem. In general wepostulate that different occurrences in a suite-diagram picture represent differentinstances of metaclasses, with the exception of Names. This enables us to drawpictures where two different instances of the same metaclass have the same name.This is different from the way we interpret metamodel pictures. There we do assume

5

that two rectangles with the same name represent the same metaclass (as mentionedbefore, metaclasses have unique names). This enables one to scatter the picture ofthe metamodel over multiple pages.

Using the tree structure that the 1 . . .

. . .⋄−−−s of the metamodel constitute, we can construct

a BNF-like representation of the syntax (X∗ represents the set of all lists of Xs):

Suite ::= suite NameRole∗

Role ::= role NameInterface∗Attribute∗

Interface ::= interface NameMethod∗

Method ::= method Name

Attribute ::= attribute NameType

Type ::= valueType Name

| objectType Name

The representation of Names (Name) is left unspecified.

The Interfaces of the BNF-like representation of the syntax correspond to theprovidedInterfaces of the metamodel. The requiredInterfaces are missing. These arediscussed in section 2.5.1.

In terms of the above syntax, the plug-pattern example can be written as

6

PlugPattern = suite PlugPattern

<Hole,Plug ,Main>

Hole = role Hole

<HIFill><HHasPlug ,HPlug>

Plug = role Plug

<PIInsert><PInHole,PHole>

Main = role Main

<><>

HIFill = interface IFill

<HFillWith ,HEmpty>

PIInsert = interface IInsert

<PInsertInto,PRemove>

HFillWith = method fillWith

HEmpty = method empty

PInsertInto = method insertInto

PRemove = method remove

HHasPlug = attribute hasPlug

valueType bool

HPlug = attribute plug

objectType Plug

PInHole = attribute inHole

valueType bool

PHole = attribute hole

objectType Hole

2.2.2 Invariants

In ISpec several kinds of invariants exist, although not described in [35]. We restrictto the most commonly found invariants: the ones that are attached to roles, calledrole invariants. We distinguish three kinds of role invariants: action invariants,post invariants and state invariants. The following diagram shows how the

7

metamodel is extended to deal with these invariants:

Role

RoleInvariant

ActionInvariant PostInvariant StateInvariant

0..*

1

Name 1 0..*

excludedInterfaceName invariant

The excludedInterfaceNames of a RoleInvariant are not an ISpec concept. Theirmeaning is explained in section 2.4.2.

In our BNF-like notation, the extension of the metamodel with invariants is reflectedby the following adjustment:

Role ::= role NameInterface∗Attribute∗(RoleInvariant Name∗)∗

RoleInvariant ::= actionInvariant . . .

| postInvariant . . .

| stateInvariant . . .

The language that is used to describe RoleInvariants is left open in ISpec. We use alanguage that should be understandable for most people that know object-orientedprogramming. For our plug-pattern suite we define some StateInvariants:

Hole = role Hole

<HIFill><HHasPlug ,HPlug><HSInv1 <>,HSInv2 <>>

Plug = role Plug

<PIInsert><PInHole,PHole><PSInv1 <>,PSInv2 <>>

Main = role Main

<><><>

8

HSInv1 = stateInvariant hasPlug ⇒ plug.inHole

HSInv2 = stateInvariant hasPlug ⇒ plug.hole = this

PSInv1 = stateInvariant inHole ⇒ hole.hasPlug

PSInv2 = stateInvariant inHole ⇒ hole.plug = this

The StateInvariant HSInv2 expresses for example that if a hole has a plug in it,the plug’s attribute hole should point to this hole. Details about the meaning ofRoleInvariants are given in section 2.4.2.

2.2.3 Methods

In ISpec a Method has several Parameters, each of which has a Name and a Type.It also has a Result with a Type and it has several Effects. Each Effect has aPreCondition, an ActionClause and a PostCondition. The following class diagramshows how the metamodel is extended to enable this more detailed description ofMethods:

Method

Parameter Result

TypedItem PreCondition ActionClause

Effect

PostCondition

0..*

1 1 1

1 0..*

1

1

NamedItem

parameter result effect

preCondition actionClause postCondition

or in our BNF-like notation:

9

Method ::= method NameParameter∗ResultEffect∗

Parameter ::= parameter NameType

Result ::= result Type

Effect ::= effect PreConditionActionClausePostCondition

PreCondition ::= preCondition . . .

ActionClause ::= actionClause . . .

PostCondition ::= postCondition . . .

The language that is used to specify PreConditions, ActionClauses and PostConditionsis left open in ISpec. For the plug-pattern suite we define the Methods fillWith,empty, insertInto and remove by


<HFiParameter>HFiResult<HFiEffect>

HFiParameter = parameter p

objectType Plug

HFiResult = result valueType void

HFiEffect = effect HFiPreConditionHFiActionClauseHFiPostCondition

HFiPreCondition = preCondition ¬hasPlug∧ p.inHole∧ p.hole = this

HFiActionClause = actionClause modify{hasPlug, plug}

HFiPostCondition = postCondition hasPlug

∧ plug = p

10


<>HEmResult<HEmEffect>

HEmResult = result valueType void

HEmEffect = effect HEmPreConditionHEmActionClauseHEmPostCondition

HEmPreCondition = preCondition hasPlug

HEmActionClause = actionClause modify{hasPlug, plug}

HEmPostCondition = postCondition ¬hasPlug


<PInParameter>PInResult<PInEffect>

PInParameter = parameter h

objectType Hole

PInResult = result valueType void

PInEffect = effect PInPreConditionPInActionClausePInPostCondition

PInPreCondition = preCondition ¬inHole∧ ¬(h.hasPlug)

PInActionClause = actionClause modify{inHole, hole}; hole.fillWith(this)

PInPostCondition = postCondition inHole

∧ hole = h

11


<>PRmResult<PRmEffect>

PRmResult = result valueType void

PRmEffect = effect PRmPreConditionPRmActionClausePRmPostCondition

PRmPreCondition = preCondition inHole

PRmActionClause = actionClause hole.empty(); modify{inHole, hole}

PRmPostCondition = postCondition ¬inHole

The Method PInsertInto expresses for example that if parameter h is a Hole that(see the PreCondition) has no plug in it and the Plug on which method insertInto

is called, is not inserted into a Hole, then this Plug is inserted into Hole h (see theActionClause and PostCondition). Details about the meaning of Methods are givenin section 2.4.3.

2.2.4 Bases

In ISpec it is possible to base a suite (called child in this context) on other suites(called parents). The idea behind it is that the child suite combines and spe-cialises the behaviour of its parent suites. Connections between Roles of the childSuite and those of its parent Suites define where the behaviour of the parent suitesoccurs in the child suite. The following class diagram shows how the metamodel isextended to support bases:

Suite

RoleConnection

Base

Name

0..*

1

1

Name

1

0..*

1 1

1 baseSuiteName

parentRoleName childRoleName

base

roleConnection

or in terms of our BNF-like notation:

12

Suite ::= suite NameBase∗Role∗

Base ::= base NameRoleConnection∗

RoleConnection ::= roleConnection NameName

A main idea of ISpec is that a suite can be built by basing it on (combining andspecialising) other suites that can again be built in this manner. The followingpicture, that we took from [34], illustrates this idea:

In case the rectangle of a suite s is completely included in the rectangle of anothersuite s′, then s′ is (directly or indirectly) based on s. The inheritance arrows (thearrows with a triangular head) represent the RoleConnections. The outer rectanglerepresents the one suite that is the result of all this combining and specialising.

When examining this picture, several questions arise like: “What does it mean thata role r inherits from two roles r1 and r2 of one suite s?”, “Is this the same ordifferent from r inheriting from r1 and r2 that belong to different occurrences of s?”and “What happens with the roles of a parent suite that are not inherited from?”.Unfortunately we have to leave the exact answers to these questions for futureresearch (see also sections 2.5.4 and 2.5.7). We only model the simple case wherefor each Base of a Suite there exists exactly one RoleConnection for each parent role.

An example of a suite that is based on another suite is the observer pattern. Theobserver pattern is based on the plug pattern:

13

orig : void

Subject

copy : void

Observer


IUpdate update

IInsert insertInto

remove


Hole


Plug Main

PlugPattern

ObserverPattern

Using our BNF-like notation, we can fill in the details:

14

PlugPattern = suite PlugPattern

<><Hole,Plug,Main>

ObserverPattern = suite ObserverPattern

<Base><Subject ,Observer>

Base = base PlugPattern

〈Subject2Hole,Observer2Plug〉

Subject2Hole = roleConnection Subject

Hole

Observer2Plug = roleConnection Observer

Plug

Subject = role Subject

<SIFill><SOrig><SSInv <>>

Observer = role Observer

<OIUpdate><OCopy><OSInv <IUpdate>>

SIFill = interface IFill

<SFillWith>

OIUpdate = interface IUpdate

<OUpdate>

SOrig = attribute orig

valueType void

OCopy = attribute copy

valueType void

SSInv = stateInvariant hasPlug ⇒ plug.copy = orig

OSInv = stateInvariant inHole ⇒ copy = hole.orig

15

SFillWith = method fillWith

<HFiParameter>HFiResult<SFiEffect>

SFiEffect = effect HFiPreConditionSFiActionClauseHFiPostCondition

SFiActionClause = actionClause modify{hasPlug, plug}; plug.update()

OUpdate = method update

<>OUpResult<OUpEffect>

OUpResult = result valueType void

OUpEffect = effect OUpPreConditionOUpActionClauseOUpPostCondition

OUpPreCondition = preCondition inHole

OUpActionClause = actionClause modify{copy}

OUpPostCondition = postCondition copy = hole.orig

The plug pattern is extended with an interface IUpdate and attributes orig andcopy. The type of these attributes is not restricted (the ValueType void representsthis fact). Method update of interface IUpdate is used to update an Observer’scopy of the state of the Subject it is inserted into. Method fillWith is adaptedsuch that if an Observer is inserted into a Subject, update is called to ensure thatthe Observer’s state is updated.

In the above specification we borrowed several parts of the plug pattern. The defini-tion of Method fillWith (re)uses HFiParameter , HFiResult , HFiPreCondition andHFiPostCondition . We call this syntactic inheritance. More on this in section2.4.4.

16

2.3 Semantic model

In this section we describe the semantic model for suites.

2.3.1 Traces

During the study of object-oriented design patterns like the observer pattern, webecame aware of the fact that a relational model is not sufficient to cope withan essential aspect of these kinds of design patterns: communication (see also[10]). ISpec addresses communication by means of its action clauses, in which itis possible to write calls. To capture communication, a semantic model for suitesshould be richer than a relational model. Where a relational model only capturesthe ‘outermost’ calls and returns of a system, we use a model that can also capturecalls and returns that occur ‘in between’. This thesis only discusses ‘single threaded’systems. Parallellism is left for future research (see section 2.5.2). We define themodel of a suite to be a set of (finite) traces where, at a high level of abstraction,a trace consists of a call, a (finite) trace sequence and a return:

Trace ::= trace CallTrace∗Return

Call ::= call . . .

Return ::= return . . .

Now that we have chosen which points ‘in time’ can be observed, we have to definewhat information is observed at these points (the “. . .”s). This is addressed in thefollowing subsections.

2.3.2 Roles, interfaces and methods

To distinguish the different methods that can be called, a trace should containan identification of the called method. In our case a method is identified by thecombination of a role name, an interface name and a method name:


Call ::= call NameNameName. . .

Return ::= return . . .

17

A “call r i m . . .” means that method m of the interface i provided by role r iscalled.

2.3.3 Parameters and results

In ISpec parameters can be sent along with a call and a result along with areturn. We describe the values of the parameters by means of a total function fromparameter names to values (represented by “Value 7→Name”):


Call ::= call NameNameNameValue 7→Name. . .

Return ::= return Value. . .

We leave the set Value unspecified.

Notice that we postulate that a parameter value is given for each possible parametername and that a return always has a result. The main idea is to read “has no value”as “has no specific value”. If in a specification, a call to a method does not mentiona parameter p, it means that the semantics contains a trace for every possible valueof p at that call. This is a natural view in the context of specialisation and makesit for example straightforward to add parameters when specialising a call.

2.3.4 Global state

In an object-oriented system there are of course also things that are called objects.An object consists of a number of attributes each of which has a value. Thecollection of all objects constitutes the global state in which methods execute.For each call and return in a trace, a snapshot of the global state is included. Forthe outermost call and return of a trace, these snapshots are called the initialglobal state and final global state respectively. We model a global state as atotal function from (object name, attribute name)-pairs, called fields, to values.The field (o, a) is referred to as “attribute a of object o”.

18


Call ::= call NameNameNameValue 7→NameGlobalState. . .

Return ::= return ValueGlobalState

GlobalState ::= globalState Value 7→Name×Name

This model does not capture information about the existence of objects. Weassume that all objects ‘always exist’. Creation and deletion of objects is an essentialfeature of ISpec that we do not model in this thesis and leave for future research(see section 2.5.3).

2.3.5 This

In object-oriented languages (non-static) methods are always called ‘on a specificobject’. This object then becomes the ‘currently active object’, usually called “this”or “self”. We make the name of the ‘this’ object part of the call:


Call ::= call NameNameNameValue 7→NameGlobalStateName

Return ::= return ValueGlobalState

GlobalState ::= globalState Value 7→Name×Name

19

2.4 Semantics

In this section we informally describe the relation between the syntax of suites andthe semantic model of the previous section.

2.4.1 Suite diagrams

A suite diagram determines the structure of a suite. This structure consists of thename of the suite, the names of its roles, for each of these roles, the names of itsattributes and interfaces and for each of these interfaces, the names of its methods.The suite diagram of the plug pattern




Hole


Plug Main

PlugPattern

defines for example the following suite structure:

( PlugPattern, {Hole, Plug, Main}, {(Hole, hasPlug), (Hole, plug), (Plug, inHole), (Plug, hole)}, {(Hole, IFill), (Plug, IInsert)}, {(Hole, IFill, fillWith), (Hole, IFill, empty)

, (Plug, IInsert, insertInto), (Plug, IInsert, remove)})

One might expect that we use this structure to restrict the set of traces that is thesemantics of the suite. This is however not the approach that we take. If we do notexclude traces with calls that fall outside the structure of a suite, the introductionof new roles, interfaces and methods in a specialisation becomes straightforward asshown in section 7.5. This cylindric view is one of the main topics of this thesis.

For the definition of a semantics for suites it is helpful to assume that all Interfaceshave different names. We can then identify an interface by means of one nameinstead of the combination of a role name and an interface name. This fact isexploited in section 11.2.19.

The signature of a suite consists of the names of its attributes and interfaces. Theplug pattern has for example the following signature:

({hasPlug, plug, inHole, hole}, {IFill, IInsert})

20

The signature of a suite determines the attributes and interfaces the suite ‘talksabout’. The signature is needed for the meaning of statements that occur in actionclauses and action invariants. Take for example method empty of the plug pattern:








The statement of the action clause (modify{hasPlug, plug}) states that, with re-spect to the signature, only the attributes hasPlug and plug of the ‘this’ objectpossibly change and no calls are performed. What this exactly means is that, fromthe attributes hasPlug, plug, inHole and hole of any object, only the attributeshasPlug and plug of the ‘this’ object possibly change. Furthermore, no calls areperformed on the interfaces IFill and IInsert. The specification does not tellanything about attributes and interfaces outside the signature. Anything may hap-pen to them. This means that if we construct a specialisation of this action clause,we may change these attributes and call methods of these interfaces in any possiblemanner.

Next to the structure of a suite, a suite diagram also specifies types for attributes:if an Attribute named a of a Role named r has a Type representing some type T ,then in every trace of the suite, attribute a of the ‘this’ object has type T for everycall and return of every method of every interface of role r.

Associating a type t with an attribute a has the same meaning as adding a stateinvariant that states that attribute a of the ‘this’ object has type t. The semanticsof state invariants is discussed in the following subsection.

2.4.2 Invariants

As mentioned in section 2.2.2, three kinds of invariants are considered in this thesis:action invariants, post invariants and state invariants. Each of these invariants is aspecial kind of role invariant. In general, a role invariant is something that holds for

21

all methods of the role to which the invariant is attached. This includes methodsthat are added in specialisations.

A role invariant is always formulated in the context of a ‘this’ object. For a roleinvariant C and an object o, we say that “C holds for o” or “o adheres to C” if Cholds where o is the ‘this’ object.

Action invariants and post invariants can be seen as action clauses and post-conditions respectively that are added to all methods, except for the fact that,whereas an action clause and post-condition only need to hold if their correspondingpre-condition holds, action invariants and post invariants always hold, irrespective ofpre-conditions. The semantics of pre-conditions, action clauses and post-conditionsis discussed in section 2.4.3. In the remainder of this section we discuss the specificrestrictions that state invariants impose.

A state invariant talks about a single state. Similar to the attribute-type case, ifa Role named r has a StateInvariant representing some constraint C, then in everytrace of the semantics, C holds for every call and return of every method (of everyinterface) of role r.

We do not explicitly model the association of objects with roles. The fact that anobject plays a certain role is a derivable property from (the attributes of) thatobject: an object plays a certain role if it adheres to the role’s attribute(typing)sand state invariants. A consequence of our semantics of state invariants is thatfor each call and return of a method of a role r, the ‘this’ object plays role r bydefinition. This approach of not explicitly modeling which roles an object plays,results in a significantly simpler semantic model.

Sometimes it is necessary that a method of a role r is called, but the object onwhich it is called, does not adhere to a particular state invariant of role r. Forthese cases we made it possible to exclude certain interfaces from a role invariant.Excluding an interface from an invariant means that the methods of that interfacedo not necessarily adhere to the invariant. An example where this is needed, is theobserver pattern of section 2.2.4. After a call to method insertInto on an objecto, method update needs to re-enter o to update attribute copy of o for the purposeof re-establishing state invariants SSInv and OSInv . However, when o is re-entered,state invariant OSInv does not hold in general. This is the reason why interfaceIUpdate is excluded from invariant OSInv .

In ISpec the interpretation of state invariants is different from ours. We postulatethat a state invariant holds at the beginning (call) and end (return) of each methodof a role. In ISpec the interpretation is that if a state invariant holds at thebeginning of a method then it holds at the end of that method. In section 7.7 thistopic is discussed in detail.

This is not the only point where we deviate from ISpec. In ISpec state invari-ants are not allowed to constrain the behaviour of a suite more than already doneby pre-conditions, action clauses and post-conditions. The reason for this is prag-

22

matic. Programmers often forget adhering to the state invariants of a role. Thepre-conditions and post-conditions of the methods of a role are therefore strength-ened such that each state invariant of the role is implied by them. In practice thisdoes not seem to cause much overhead. With proper tool support however it canbe ensured that programmers do not forget invariants. Invariant aspects of a roleshould in our opinion then be localised in role invariants. Details can again be foundin section 7.7.

2.4.3 Methods

A Method consists of Parameters, a Result and a number of Effects where each Effect

consists of a PreCondition, an ActionClause and a PostCondition. With respect to thesemantic model that was presented in section 2.3, Parameters and PreConditions talkabout first calls of traces, Results talks about last returns of traces, PostConditionsrelate first calls and last returns of traces and ActionClauses can in principle talkabout all calls and returns of traces.

Similar to the correspondence between attribute types and state invariants, associ-ating a parameter with a type has the same meaning as stating in the pre-conditionthat the parameter is an element of that type. The same goes for results: it doesnot matter whether we use the natural numbers as result type or use integers andadd to the post-condition that the result is at least zero. The semantics of a methodspecification is that for each of its effects, if the parameters have the specified typesand the pre-condition of the effect holds, then the action clause and post-conditionof the effect hold and the result is of the specified type.

Our intended semantics of a method specification cannot be defined in a decentdenotational manner for the syntactic structure that was defined in section 2.2.3:

Method

Parameter Result

PreCondition ActionClause

Effect

PostCondition

The problem is that a PreCondition, ActionClause and PostCondition are first com-bined into an Effect before they are combined with Parameters and a Result. Fora Method with Parameters p1, . . . , pn, a Result r and an Effect consisting of aPreCondition pre, an ActionClause action and a PostCondition post , its denotationalsemantics should be given with a formula of the form

M.([[p1]], . . . , [[pn]], [[r]], E.([[pre]], [[action ]], [[post ]]))

23

It is however not possible to get the intended semantics in a decent manner usinga formula of this form. To allow for a decent denotational semantics, the syntax ofmethods is for the formal language of chapter 11 restructured as follows:

Method

Parameter Result PreCondition ActionClause

Post

PostCondition

Pre

To cope with the fact that a method can have multiple Effects, we allow multi-ple Methods with the same name. When a method with name m is called, thebehaviours of all Methods with name m are realised.

Action clauses are a kind of abstract programs. In this thesis we discuss three fun-damental constructs for building action clauses: modify statements, call state-ments and sequential composition of statements. An example where all threeconstructs are used, is method insertInto of the plug pattern (see section 2.2.3).

Modify statements

A modify statement specifies fields of the global state that are possibly modified.Which fields are possibly modified, is indicated by a set of field expressions.The modify statement modify{a, o.b} means for example that, with respect to thesignature, only attribute a of the ‘this’ object and attribute b of the object referredto by attribute o of the ‘this’ object are possibly modified and no calls are performed.As mentioned in section 2.4.1, anything may happen with attributes and interfacesoutside the signature.

In object-oriented programs, attributes of objects other than ‘this’ are usuallyonly modified by means of method calls on those objects. This helps to preventfalsification of state invariants for those other objects. In an implementation ofmodify{a, o.b}, attribute b of the object referred to by attribute o of the ‘this’ ob-ject should then be modified by means of a call to a method of an additionallyintroduced interface.

Call statements

A call statement has several ingredients. First of all there is an expression thatspecifies on which object a method is called. Next to this, there is an identification ofthe method that is called. A list of expressions specifies the values of the parametersthat are passed. Finally, the possibility exists to specify a variable where the resultof the call is stored.

Also for calls, the signature of a suite is of importance. Before and after a call,anything may happen with attributes and interfaces outside the signature.

24

Sequential composition of statements

The sequential composition of two statements is a generalisation of traditional re-lational composition. The generalisation ensures that trace sequences are appropri-ately pasted together.

Details about these three constructs can be found in chapter 9.

2.4.4 Bases

In section 2.2.4 we used the plug pattern as a base for the observer pattern. Thismeans that the observer pattern specialises the plug pattern in some way. In thissection we discuss what it exactly means for a suite to specialise another one.

A simplification we make, is that we do not model renaming. Renaming is left forfuture research (see section 2.5.4). For the observer pattern we therefore simply usethe names Hole and Plug instead of Subject and Observer respectively.

Without renaming, the most straightforward definition of a suite s′ being a special-isation of a suite s is that the set of traces of s′ is a subset of the set of traces of s.Denoting the set of traces of a suite s by µs (the meaning of s):

µs′ ⊆ µs

When we base a suite s′ on a suite s, our intention is not to define s′ completely fromscratch. We only want to define an extension e that describes how s is specialised.In case of the observer pattern, the extension describes two new attributes (origand copy), one new interface (IUpdate) and a new definition for method fillWith.In terms of our BNF-like notation, the extension Extension would be defined by(ESubject and EObserver only differ from Subject and Observer of section 2.2.4 withrespect to their role names, which reflects the fact that we do not model renaming):

Extension = suite Extension

<><ESubject ,EObserver>

ESubject = role Hole

<SIFill><SOrig><SSInv <>>

EObserver = role Plug

<OIUpdate><OCopy><OSInv <IUpdate>>

It now seems natural to define the meaning of ObserverPattern as the intersection

25

of the sets of traces µPlugPattern and µExtension. The interpretation in ISpec issubtly different however, which is related to the notion of signature. If we take forexample method empty of the plug pattern, its action clause states that with respectto the signature, only the attributes hasPlug and plug of the ‘this’ object possiblychange and no calls are performed. This means that if we do intersection at thesemantic level, method empty is interpreted in the signature of the plug pattern andnot in the signature of the observer pattern. We call this semantic inheritanceof method empty. In ISpec however, if no new definition is given for a method,its specification is reinterpreted in the new signature. We call this syntactic in-heritance. The specification of method empty should thus be reinterpreted in thesignature of the observer pattern. More formally, the meaning of ObserverPatternis equal to

µPlugPattern ∩ µExtension ′

where Extension ′ is defined by

Extension ′ = suite Extension

<><ESubject ′,EObserver ′>

ESubject ′ = role Hole

<ESIFill ′><SOrig><SSInv <>>

EObserver ′ = role Plug

<PIInsert ,OIUpdate><OCopy><OSInv <IUpdate>>

ESIFill ′ = interface IFill

<SFillWith ,HEmpty>

The difference between Extension ′ and Extension is that Extension ′ contains asyntactic copy of interface IInsert and method empty of the plug pattern, whereExtension does not.

Now that we know how inheritance of methods works, what happens exactly ifwe give a new definition for a method, like we did for fillWith in the observerpattern? In principle, what happens, is determined by the fact that we take theintersection of the sets of traces. A consequence is that if we had used “true” as post-condition in the new definition of fillWith, the post-condition of the plug pattern’sfillWith would still hold. In ISpec however the behaviour of a method for whicha new definition is given, is solely determined by this new definition. This is calledoverriding. ISpec does not allow arbitrary overriding, but combines overridingwith behavioural subtyping [38]. Behavioural subtyping means that when weoverride some methods, the behaviour of the resulting (child) suite should be a

26

specialisation of its parent suites. Behavioural subtyping is usually associated withthe following rules: pre-conditions and parameter types should not be strengthenedand attribute types, result types, post-conditions, action clauses and invariantsshould not be weakened. Our semantics for these concepts was chosen in such away that these rules indeed guarantee behavioural subtyping.

In ISpec there is another requirement on specialisation. If someone has written apartial implementation of the plug pattern, it should be possible to combine thispartial implementation with a partial implementation of the observer-pattern ex-tension into a new (possibly again partial) implementation of the observer pattern.In the context of simple set inclusion (also called partial refinement), this casealready has some complications as shown in section 8.5.7. Additional complicationsarise in the context of total refinement. Then we need to prove that a suitethat specialises another suite, is a conservative extension of that suite. Thisguarantees that an implementation of the extended part of a suite ‘is able to coop-erate’ with the already implemented part of the suite, no matter how that part wasimplemented. Details can be found in section 8.6.4.

In ISpec the observer pattern would, next to the roles Subject and Observer, alsostill contain the roles Plug and Hole. This is discussed in section 2.5.7.

2.5 Future research

In this section we discuss some topics that we left for future research.

2.5.1 Required interfaces

Next to provided interfaces, ISpec also specifies required interfaces. Actually “re-quires” should be read as “is allowed to use”. A rule in ISpec is that if a suite s′

specialises a suite s and s contains an interface i that is required by roles r0, . . . , rn,then each role r′ in s′ that wants to use i, should be connected to one of r0, . . . , rn

by means of an inheritance arrow. A way to represent the fact that i is a requiredinterface of roles r0, . . . , rn in our semantics, is to exclude all traces where a roleother than one of r0, . . . , rn performs a call on interface i. Adding the notion ofrequired interfaces increases the expressive power of the formalism. Its general pur-pose is to ensure that roles that are not explicitly part of an interaction pattern,cannot cause unwanted interference.

2.5.2 Parallellism

As mentioned in section 2.3.1, we only consider single-threaded systems. In [45],section 4, an attempt is made to model interleaved parallellism. The main idea isthat every call is placed on a (virtual) stack. Where in a single-threaded system,only the top-most call of the stack may return, in a multi-threaded system, every

27

call in the stack may return. The call depth of a return is a natural numberthat indicates how deep in the stack the call that returns, lies. Traces are thenrepresented as sequences of an equal number of calls and returns where the calldepth of each return is smaller than the number of calls preceding the return minusthe number of returns preceding it. If the call depth of every return equals zero, themodel is isomorphic to the single-threaded model of this thesis. Although this calldepth may appear to be a nice trick, the model does not really seem appropriate asa semantic model for ISpec with parallellism. Replacing the total orders (sequences)of our traces with partial orders, provides an interesting alternative. Where tracesin the single-threaded model look like (©T represents a trace, ©C a call and ©R areturn):

T

C T T R

C R C R

the use of partial orders instead of total orders would allow traces like:

T

C T

T R

C R

C R

In this model, multiple threads executing in parallel should access disjoint partsof the global state to avoid interference. For many systems this is probably not afeasible assumption and a more complicated model is needed.

28

2.5.3 Object existence

In this thesis we do not model object creation and deletion. In section 2.3.4 wephrased this as: “Each object always exists.”. To model object existence, a straight-forward generalisation of our semantic model would be to omit the totality require-ment on the function that models the global state. For several constructs, like thecall statement, it then has to be decided what happens if they are executed on anon-existent object.

2.5.4 Renaming

As mentioned in section 2.4.4, we do not formalise the concept of renaming. Al-though it appears a rather straightforward concept, several questions arise, like whatrestrictions to impose on a renaming relation and how exactly renaming should bedefined. In [22] renaming is investigated in more detail.

2.5.5 Black-box semantics

Attributes are in ISpec only considered a means to specify what really matters:traces of calls and returns. ISpec therefore distinguishes two kinds of semantics:white-box semantics, containing state information, and black-box semanticswhere no state information is present. The black-box semantics of a suite is ob-tained by projecting away the global-state information of the suite’s white-box se-mantics. In this thesis we only consider white-box semantics. Going from white-boxto black-box semantics probably has profound consequences on specialisation andcombination of suites.

2.5.6 Activation specifications

In ISpec the specification of a suite is complemented with an activation specifi-cation that corresponds to what is usually called “the main” in object-orientedlanguages. An activation specification can for example specify that a certain methodis called every millisecond. We do not model activation specifications in this thesis.This is the reason why we used dotted lines for Main.

2.5.7 Keeping parent roles

In ISpec, in case a (child) suite is based on another (parent) suite, the child suitedoes not only contain the specialised versions of the roles of the parent suite, butalso the non-specialised versions of these roles. If we keep non-specialised roles ina child suite, the notion of specialisation becomes part of a suite instead of only amatter between suites. It is then desirable that a method call does not contain a(statically fixed) role name, but that each object is explicitly associated with a set

29

of roles that determines the semantics of a method call on that object. In object-oriented programming this is referred to as dynamic binding, although there eachobject is associated with only one role (class) instead of a set of roles. We do notexplicitly model dynamic binding in this thesis. However, in section 9.9.3 we doshow that our model incorporates an implicit form of dynamic binding.

2.6 Conclusions

In this chapter we gave an informal description of the language of ISpec and its se-mantics. Chapter 11 defines a completely formal subset of the ISpec language andshows how the plug pattern and observer pattern can be formalised in this language.The formalisation of the ISpec language is far from complete as future-research sec-tion 2.5 shows, but already many interesting topics arise. In the upcoming chapters,the theory that we use for the formalisation is introduced in an incremental manner.Interesting topics are first (and sometimes only) investigated in the simplest modelsin which the topics can be treated.

30

Chapter 3

Relations

The primary mathematical formalism that is used in this thesis is the calculus of(binary) relations. In this chapter we describe the foundations of this calculus.Much of the theory in this chapter is well-known in the area of relational algebra.The purpose of this chapter is to fix the notation that we use and the exact meaningof this notation, in order to avoid any misinterpretations.

What, to the best of our knowledge, is new and might therefore deserve some ex-tra attention, is the generalisation from functions to relations of sectioning (section3.1.14) and the application relation (section 3.1.15), the spick and spack operators(section 3.3.8), the uniqueness and singleness properties (section 3.4.2) and the con-jointness property (section 3.4.8). All these play an important role in our discussionof products in chapter 5.

3.1 Basics

We start with the introduction of some basic theory.

3.1.1 Predicate calculus

We assume that the reader is familiar with predicate calculus. The proposi-tional operators that we use, are the conjunction ∧, the disjunction ∨, theimplication ⇒, the consequence ⇐, the equivalence ≡, the booleans falseand true and the negation ¬. For universal quantification and existentialquantification we use the notation

∀〈x || p.x || q.x〉∃〈x || p.x || q.x〉

31

The “p.x” tells which values the dummy x attains and the “q.x” tells what x satisfies.The following formulas are respectively equivalent to the above ones:

∀〈x |||| p.x ⇒ q.x〉∃〈x |||| p.x ∧ q.x〉

3.1.2 Omission of brackets

We often omit brackets to make formulas more readable. We do not postulate anypriority rules, but rely on common sense and often add some white space to showwhat is meant. We write for example a∧b ∨ c if we mean (a∧b)∨c and a ∧ b∨c if wemean a∧(b∨c). In some cases, brackets can be removed without the need for extrawhite space. Because (a⇒b)⇐c equals a⇒(b⇐c), we are allowed to write a⇒b⇐c.

3.1.3 Omission of quantifications

If we write a formula like

yx ≥ x+1 ⇐ x ≥ 1 ∧ y ≥ 2

we actually mean that it holds for all real numbers x and y:

∀〈x, y || x, y ∈ R || yx ≥ x+1 ⇐ x ≥ 1 ∧ y ≥ 2〉

We often assume that the reader is able to guess the free variables in a formula,the placement of universal quantifications over these free variables and the typerestrictions on these free variables.

3.1.4 Basic elements

Some basic elements we distinguish are the booleans false and true and the de-fault tags©0 ,©1 ,©2 , . . . . For giving examples, it is also useful to have identifiers.We represent these elements in typewriter font: x, piano, . . . . Also the real num-bers 0, π, . . . , a part of which are the integer numbers 0, −1, . . . , a part ofwhich are the natural numbers 0, 1, . . . , are useful elements for examples.

For these basic elements, we assume that equality is properly defined. We writey = z for the boolean that indicates whether or not y and z are equal.

3.1.5 Collections

A collection is what would usually be called a “set”. We write

32

x ǫ C

(x is-contained-by C) for the boolean that indicates whether or not collection Ccontains element x.

The letters C and D usually denote collections.

Equality between collections C and D is defined by

C = D ≡ ∀〈x |||| x ǫ C ≡ x ǫ D〉

We use the word “collection” instead of “set” because we want to reserve the word“set” for a special kind of relations (see section 3.1.19).

An important difference between our collections and the sets of basic set theory isthat we do have a universal collection that appears to contain all elements. A typesystem prevents however that the wrong kinds of elements can be put together inone collection. A collection that has as elements both©0 and a collection containingthis element, is for example prevented by this type system. See section 3.1.21 fordetails.

3.1.6 Connections

A connection is what would usually be called a “pair”. A connection is written as

(y, z)

where element y is called the output and element z the input of the connection.The reason for these names is explained in the next subsection.

Equality between connections (y0, z0) and (y1, z1) is defined by

(y0, z0) = (y1, z1) ≡ y0 = y1 ∧ z0 = z1

3.1.7 Relations

A relation is a collection of connections. Instead of

(y, z) ǫ R

we usually write

y (−R−) z

(R connects output y with input z).

33

The letters P , Q, R, S, T , U and V usually denote relations.

How equality between relations is defined, follows from the definition of equality forcollections and connections:

R = T ≡ ∀〈y, z |||| y (−R−) z ≡ y (−T −) z〉

From our definition of a relation, it is clear that we are not defining an abstractrelational algebra that admits several interpretations. If we say that we definesome relation by a certain formula, it means that the formula fixes for each y andz whether y (−R−) z holds or not.

Calling y the output and z the input of a connection (y, z), is the result of ourpreference to write R.z for the application of a relation R to an element z. Theapplication is described in section 3.1.10.

There are three ways to picture relations that help in understanding the theoryabout them:

0

1

2

3

0

1

2

3

0

2

1

3

3

0

2

1

0 1 2 3

In the first picture, we write all output elements on the left and all input elementson the right. A line between an input element and an output element represents aconnection. The graph thus created, is an undirected bipartite graph.

In the second picture, we only have one instance of each element and use arrowsfrom inputs to outputs to represent connections, obtaining a directed graph.

The third picture represents a relation by a dot matrix where the input elementsare placed on the bottom and the output elements on the left. A dot represents aconnection.

How useful a certain representation of a relation is for one’s understanding, dependson the context in which the relation is used.

3.1.8 Emptiness and fullness

A relation R is empty in an element z if R connects input z with no output:

34

¬∃〈y |||| y (−R−) z〉

and full in an element z if R connects input z with every output:

∀〈y |||| y (−R−) z〉

3.1.9 Functionality and totality

A relation R is functional in an element z if it connects input z with at most oneoutput:

∀〈x, y || x (−R−) z ∧ y (−R−) z || x = y〉

it is total in an element z if it connects input z with at least one output:

∃〈y |||| y (−R−) z〉

and single-valued in z if it connects input z with exactly one output, or equiva-lently, if it is functional and total in z.

We leave it to the reader to verify that functionality of R in z can be written as

∃〈y |||| ∀〈x |||| x (−R−) z ⇒ x = y〉〉

totality of R in z as

∃〈y |||| ∀〈x |||| x (−R−) z ⇐ x = y〉〉

and single-valuedness of R in z as

∃〈y |||| ∀〈x |||| x (−R−) z ≡ x = y〉〉

A relation R is functional if it connects each input with at most one output:

∀〈x, y, z || x (−R−) z ∧ y (−R−) z || x = y〉

it is total if it connects each input with at least one output:

∀〈z |||| ∃〈y |||| y (−R−) z〉〉

and single-valued if it connects each input with exactly one output:

∀〈z |||| ∃〈y |||| ∀〈x |||| x (−R−) z ≡ x = y〉〉〉

A functional relation is called a function. The letters f , g, h and k usually denotefunctions.

35

Notice that a function is empty in z exactly when it is not single-valued in z.

We purposely do not use “defined in” for “single-valued in” because “not defined insome input” means that it is left open which outputs are connected with that input.A reason could be that we do not know what the best choice is for such inputs.

3.1.10 Application

If a relation R is single-valued in some element z with output y, then the applica-tion of R to z, denoted by R.z, is equal to y.

3.1.11 Tuples

An n-tuple is a function that is single-valued in exactly the elements ©0 , . . . , ©n-1 .The n-tuple for which the respective outputs connected to these elements are x0,. . . , xn−1, is denoted by

〈x0, . . . , xn−1〉

Equality between n-tuples follows from their definition in terms of relations:

〈y0, . . . , yn−1〉 = 〈z0, . . . , zn−1〉≡

y0 = z0 ∧ . . . ∧ yn−1 = zn−1

A 2-tuple is called a pair.

3.1.12 Arguments

For n ≥ 0, an n-argument relation is a relation whose inputs are n-tuples. Theelements in the tuples are called arguments.

3.1.13 Fix notation

For a relation that is denoted by a symbol ⊙ . . . �• containing exactly n “ ”s(n ≥ 1), we allow to write z0⊙ . . . �• zn−1 instead of ⊙ . . . �• .〈z0, . . . , zn−1〉 in casen ≥ 2 and instead of ⊙ . . . �• .z0 in case n = 1. We call this fix notation. For asymbol of the form ⊙ it is called prefix notation, for a symbol of the form ⊙postfix notation and for a symbol of the form ⊙ infix notation. We often omitthe “ ”s of a symbol if it is clear which symbol is meant, talking for example about/ instead of / .

36

3.1.14 Sections

From each n-argument relation, a relation is obtained by fixing some (but not all)arguments. The result is called a section of the original relation.

When a relation is denoted by a symbol with “ ”s, we use the convention to replacethe “ ” of each argument that should be fixed, by the element it should be fixed to.For a relation ⌈ ⌉ , the sections z0⌈ ⌉ and z0⌈ ⌉z2 are for example defined by

y (−z0⌈ ⌉ −) 〈z1, z2〉 ≡ y (− ⌈ ⌉ −) 〈z0, z1, z2〉y (−z0⌈ ⌉z2−) z1 ≡ y (− ⌈ ⌉ −) 〈z0, z1, z2〉

Notice that, in accordance with fix notation, when only 1 argument is not fixed, wedo not use a 1-tuple but ‘its’ element as input.

For readability, we write x⊙ also as (x⊙) and ⊙x as (⊙x) if this notation isunambiguous (if we do not use the symbols ⊙ and ⊙).

3.1.15 Application relation

The application . is a 2-argument relation, defined by

y (− . −) 〈R, z〉 ≡ y (−R−) z

Notice that for an R that is single-valued in z, R.z (the meaning of which we gavein section 3.1.10) equals ( . ).〈R, z〉, as should be the case according to fix notation(see section 3.1.13).

The application has for each relation R a section (R.) and for each element z asection (.z). If R is single-valued in z, we have

(R.).z = R.z(.z).R = R.z

The equation

(R.) = R

even holds for arbitrary relations R.

3.1.16 Predicates

A relation is called a predicate if it is functional and only outputs booleans.

The letters p and q usually denote predicates.

37

3.1.17 Binary predicates

A binary predicate is a 2-argument predicate.

Each binary predicate ≃ has a corresponding negated binary predicate, de-noted by a strike-through symbol 6≃ and defined by

b (− 6≃ −) 〈y, z〉 ≡ ¬(b) (− ≃ −) 〈y, z〉

As mentioned in section 3.1.3, we do not always explicitly state the types of the freevariables in a formula. The b in this equation ranges for example over the booleans,which we assume to be clear from the fact that 6≃ is a binary predicate.

A binary predicate ≃ defines a relation ≃ by the equation

y (−≃−) z ≡ true (− ≃ −) 〈y, z〉

This allows us to use y (−≃−) z and y ≃ z interchangeably if ≃ is single-valued in〈y, z〉.

3.1.18 Equalilty

The is-equal-to = is a binary predicate that is single-valued in all pairs. Therelation = that corresponds to = is called the equality relation.

3.1.19 Sets

A relation R is a set if it only connects equal elements:

y (−R−) z ⇒ y = z

The letters A and B usually denote sets.

Notice that a set is a function.

3.1.20 Element-of and owner-of

The binary predicate is-element-of ∈ is exactly single-valued in all pairs 〈x, A〉where A is a set. On such pairs it is defined by

x ∈ A ≡ x (−A−) x

The binary predicate is-owner-of ∋ is exactly single-valued in all pairs 〈A, x〉where A is a set. On such pairs it is defined by

38

A ∋ x ≡ x (−A−) x

The corresponding relations ∈ and ∋ are called the element-of relation andowner-of relation respectively.

We often use “x0, . . . , xn ∈ A” as a shorthand for “x0 ∈ A ∧ . . . ∧ xn ∈ A”.

3.1.21 Types

Suppose we would define the set Russell by

x ∈ Russell ≡ x /∈ x

We then would have

Russell ∈ Russell ≡ Russell /∈ Russell

which means that true would equal false . We assume to have an external typesystem that rejects these kind of formulas by distinguishing several types of el-ements. It should support implicit typing (terms do not contain explicit typeinformation), polymorphism (types can contain variables) and dependent typ-ing (the type of the output of a relation can depend on the input or the type of theinput of a relation can depend on the output. Furthermore, the type of an elementin a tuple can depend on other elements in the tuple where cyclic dependencies aredisallowed). We also assume that each type in this type system contains at leastone element. Formalisation of this type system is left for future research. We hopecommon sense to prevent type errors in our case.

Next to external typing, we also do typing within the language to classify certaintypes of elements, using relations as internal types. If x (−R−) x holds for somerelation R, we say that R is a type of x. We mainly use sets as internal types.

We now introduce some elementary internal types. We assume A(i) and B to besets.

The set B consists of the booleans false and true, the set 2 consists of the defaulttags ©0 and ©1 , the set II consists of all identifiers, the set R consists of all realnumbers, the set ZZ consists of all integer numbers and the set N consists of allnatural numbers:

x ∈ B ≡ x = false ∨ x = truex ∈ 2 ≡ x = ©0 ∨ x = ©1x ∈ II ≡ x = x ∨ x = piano ∨ . . .x ∈ R ≡ x = 0 ∨ x = π ∨ . . .x ∈ ZZ ≡ x = 0 ∨ x = −1 ∨ . . .x ∈ N ≡ x = 0 ∨ x = 1 ∨ . . .

39

The set I, called the universal set, consists of all elements (that the external typesystem allows it to consist of):

x ∈ I

≡true

The set PA consists of all collections with elements of type A:

C ∈ PA

≡∀〈x || x ǫ C || x ∈ A〉

Although the formulas x ∈ I and x ∈ PI are both equivalent to true, the externaltype system assigns a more restricted type to variable x in the last case, forcing xto be a collection.

The set A⋆B consists of all connections with outputs of type A and inputs of typeB:

(y, z) ∈ A⋆B

≡y ∈ A ∧ z ∈ B

In case we write x ∈ I⋆I, the external type system forces x to be connection, meaningthat x = (y, z) for some y and z. The formula x ∈ I⋆I is however again equivalentto true.

The set of relations P(A⋆B) is also written as A )−−−( B. It consists of all relationswhose outputs are elements of A and whose inputs are elements of B:

R ∈ A )−−−( B

≡∀〈y, z || y (−R−) z || y ∈ A ∧ z ∈ B〉

The set A <−−−| B consists of all functions that are single-valued in exactly everyelement of B and whose outputs are elements of A:

R ∈ A <−−−| B≡

R ∈ A )−−−( B ∧ ∀〈z || z ∈ B || ∃〈y |||| ∀〈x |||| x (−R−) z ≡ x = y〉〉〉

The set ℘A consists of all sets whose elements are elements of A:

40

R ∈ ℘A

≡

∀〈y, z || y (−R−) z || y (−A−) z〉

For n ≥ 2, the set A0× . . .×An−1 consists of all n-tuples 〈x0, . . . , xn−1〉 wherexi ∈ Ai:

R ∈ A0× . . .×An−1

≡

∃〈x0, . . . , xn−1|| R = 〈x0, . . . , xn−1〉 || x0 ∈ A0 ∧ . . . ∧ xn−1 ∈ An−1〉

3.1.22 Enumeration

For n ≥ 0, the collection enumeration [x0, . . . , xn−1] is the collection that con-tains exactly the elements x0, . . . , xn−1:

x ǫ [x0, . . . , xn−1]

≡

x = x0 ∨ . . . ∨ x = xn−1

A special case is the relation enumeration [(y0, z0), . . . , (yn−1, zn−1)] that con-tains exactly the connections between output yi and input zi for 0 ≤ i < n:

y (−[(y0, z0), . . . , (yn−1, zn−1)]−) z

≡

(y = y0 ∧ z0 = z) ∨ . . . ∨ (y = yn−1 ∧ zn−1 = z)

For n ≥ 0, the set enumeration {x0, . . . , xn−1} is the set that consists exactly ofthe elements x0, . . . , xn−1:

{x0, . . . , xn−1} = [(x0, x0), . . . , (xn−1, xn−1)]

For n ≥ 0, the tuple 〈x0, . . . , xn−1〉 is the function that is exactly single-valued ineach ©i for 0 ≤ i < n, with respective output xi:

〈x0, . . . , xn−1〉 = [(x0,©0 ), . . . , (xn−1,©n-1 )]

3.1.23 Comprehension

For a total predicate p and a relation f that is single-valued in every x that satisfiesp.x, the collection comprehension [f.x | p.x | x] is the collection that containsexactly the elements f.x for all x satisfying p.x:

41

w ǫ [f.x | p.x | x]

≡

∃〈x || p.x || w = f.x〉

The collection comprehension is divided into three parts, separated by “|”s. Wecall the left part the range part, the middle part the domain part and the rightpart the dummy part. The dummy part contains the name of the dummy that isused in the comprehension, the domain part tells which values the dummy attainsand the range part tells for each of these values, which element is added to thecollection.

A special case of the collection comprehension is the relation comprehension.For a total predicate p and relations g and h that are single-valued in every xthat satisfies p.x, the relation comprehension [(g.x, h.x) | p.x | x] is the relationthat consists exactly of the connections between output g.x and input h.x for all xsatisfying p.x:

y (−[(g.x, h.x) | p.x | x]−) z

≡∃〈x || p.x || y = g.x ∧ h.x = z〉

For a total predicate p and a relation f that is single-valued in all x satisfyingp.x, the set comprehension {f.x | p.x | x} is the set that consists exactly of theelements f.x for all x satisfying p.x:

{f.x | p.x | x} = [(f.x, f.x) | p.x | x]

and the function comprehension 〈f.x | p.x | x〉 is the function that is single-valued in exactly each x satisfying p.x, with respective output f.x:

〈f.x | p.x | x〉 = [(f.x, x) | p.x | x]

For those cases where it is customary to put the dummy part on the left andthe range part on the right, we define the mirrored function comprehension〈x || p.x || f.x〉 by

〈x || p.x || f.x〉 = 〈f.x | p.x | x〉

This notation is mainly used in combination with ∀ and ∃.

An omitted domain part means the same as “true” in the domain part.

We allow the use of a tuple of dummies instead of one dummy. We usually omitthe brackets of a tuple in the dummy part. The predicate p then only needs to besingle-valued in all n-tuples where n is the number of dummies.

42

3.1.24 Non-strict evaluation

The formula R.z has a single-valued semantics if R is single-valued in z. For-mulas that do not have a single-valued semantics cannot be evaluated, so we donot have special elements like ⊥ to represent the semantics of such formulas. Aformula that has a subformula that is not single-valued, can usually also not beevaluated. There are a few exceptions however, like the comprehension notationwhere we allow a formula like

{x/x | x ∈ R ∧ x 6= 0 | x}

Although the formula x/x does not have a single-valued semantics for x = 0, theformula {x/x | x ∈ R ∧ x 6= 0 | x} can still be evaluated and is equal to {1}.

Operators that enable one to construct formulas with single-valued semantics fromformulas with not necessarily single-valued semantics, are called non-strict. Theconjunction ∧, disjunction ∨, implication ⇒ and consequence ⇐ are examples ofsuch operators. For a formula E whose semantics is possibly not single-valued andpossibly not even boolean-valued, we define

false ∧ E ≡ falseE ∧ false ≡ falsetrue ∨ E ≡ trueE ∨ true ≡ true

false ⇒ E ≡ trueE ⇒ true ≡ truetrue ⇐ E ≡ trueE ⇐ false ≡ true

The division / is not single-valued in 〈0, 0〉, so for x = 0, the formula x/x cannot beevaluated and also the formula x/x = 1 cannot be evaluated. However, the formulax = 0 ∨ x/x = 1 can be evaluated for x = 0 and is equal to true.

An example that shows the usefulness of the fact that false ∧ E can even be eval-uated if E is not boolean-valued, is the formula x ∈ B ∧ x. For x = piano forexample, the formula x ∈ B ∧ x is equal to false (assuming that the external typesystem would allow x to be equal to piano in the first place).

In chapter 6 we show how formulas that evaluate non-strictly can be formalised.

3.1.25 Feijen notation

For binary predicates ≃i we write the formula

x0 ≃0 x1 ∧ x1 ≃1 x2 ∧ . . . ∧ xn ≃n xn+1

also as

43

x0

≃0

x1

≃1

x2

. . .

xn

≃n

xn+1

We call this Feijen notation after Wim Feijen to whom this notation (in thecontext of proofs) is attributed [16]. In this thesis the notation is used to presentproofs as well as (for n = 0) definitions and theorems. For proofs, each xi ≃i xi+1

is called a step within the proof. We often put a comment {. . . } to hint why acertain proof step holds.

We use a bullet “•” to indicate extra assumptions. The formula

yx ≥ x+1

⇐ {• x ≥ 1}y ≥ 2

is for example equivalent to

(yx ≥ x+1 ⇐ y ≥ 2) ⇐ x ≥ 1

Interpreting this formula as a theorem that holds for all x, y ∈ R, a proof of it couldbe as follows:

yx

≥ {• x ≥ 0 ∧ y ≥ 2}2x

≥ {• x ≥ 1}x+1

Sometimes we omit the ‘new lines’ in this notation and write for example x ≤ y ≤ z.This is not always unambiguous (an example being a ≡ b ≡ c) and we only do thisif we are convinced that it is clear what we mean.

3.1.26 Axiom of choice

The axiom of choice says that for predicates p ∈ B <−−−| I and q ∈ B <−−−| I×I, thefact that there exists a z satisfying q.〈y, z〉 for each y satisfying p.y, is equivalentto the fact that there exists a choice function f that gives us such a z for each y

44

satisfying p.y:

∀〈y || p.y || ∃〈z |||| q.〈y, z〉〉〉≡

∃〈f || f ∈ I <−−−| {x | p.x | x} || ∀〈y || p.y || q.〈y, f.y〉〉〉

Take for example the formula

∀〈y || y ∈ N || ∃〈z |||| z ∈ N ∧ y < z〉〉

The axiom of choice tells us that this formula is equivalent to

∃〈f || f ∈ I <−−−| N || ∀〈y || y ∈ N || f.y ∈ N ∧ y < f.y〉〉

A choice function f that shows that this formula holds, is

〈x+1 | x ∈ N | x〉

The axiom of choice is used in section 5.4.6 for what we consider the most intricateproof of this thesis.

3.1.27 Point-wise against point-free

The theory in this section deals with things at a point-wise level. In sections 3.2and 3.3 we introduce operators that enable us to raise the abstraction level to point-freeness. Point-freeness means that we manipulate with collections/relations di-rectly without recourse to variables that represent elements that are contained bythem. Point-free formulas are more concise and therefore easier to read and ma-nipulate. Although point-free formulas may sometimes at first be more difficult tointerpret, they guide one to start thinking at a higher level of abstraction. Section3.8.4 shows how point-freeness can be taken to an extreme.

A disadvantage of raising the abstraction level notationally, is an explosive growthin the number of operators and theorems. A quick browse through the index showsthat the number of operators that are introduced in this thesis is huge. We triedto choose the symbols of operators in such a way that important structures thatare present in the calculus, become apparent. We sometimes even only introduceoperators for the mere purpose of revealing these structures. We hope that thishelps in remembering operators and their meaning.

3.2 Collection operators

In this section we introduce some standard operators on collections.

45

3.2.1 Inclusion

The is-subcollection-of and is-supercollection-of ⊆ , ⊇ ∈ B <−−−| PI×PI aredefined by

C ⊆ D ≡ ∀〈x |||| x ǫ C ⇒ x ǫ D〉C ⊇ D ≡ ∀〈x |||| x ǫ C ⇐ x ǫ D〉

In general, the term inclusion is used to refer to these two binary predicates andtheir corresponding relations. The relations ⊆ and ⊇ are called the subcollection-of relation and supercollection-of relation respectively.

In case C and D are relations, we talk about subrelations and superrelations.In case they are sets, we talk about subsets and supersets.

Two theorems that are referred to as indirect inequality are

C ⊆ D ≡ ∀〈X |||| X ⊆ C ⇒ X ⊆ D〉C ⊆ D ≡ ∀〈X |||| C ⊆ X ⇐ D ⊆ X〉

For sets A and B we also have

A ⊆ B ≡ ∀〈x |||| x ∈ A ⇒ x ∈ B〉A ⊇ B ≡ ∀〈x |||| x ∈ A ⇐ x ∈ B〉

and the following two indirect-inequality theorems:

A ⊆ B ≡ ∀〈X || X ∈ ℘I || X ⊆ A ⇒ X ⊆ B〉A ⊆ B ≡ ∀〈X || X ∈ ℘I || A ⊆ X ⇐ B ⊆ X〉

3.2.2 Equality

As already mentioned in section 3.1.5, the is-equal-to = ∈ B <−−−| I×I is betweencollections C and D defined by

C = D ≡ ∀〈x |||| x ǫ C ≡ x ǫ D〉

A point-free definition (as opposed to the above point-wise definition) is

C = D ≡ C ⊆ D ∧ D ⊆ C

Two point-free definitions that are called indirect equality are

C = D ≡ ∀〈X |||| X ⊆ C ≡ X ⊆ D〉C = D ≡ ∀〈X |||| C ⊆ X ≡ D ⊆ X〉

For sets A and B we also have

46

A = B ≡ ∀〈x |||| x ∈ A ≡ x ∈ B〉

and the following two indirect-equality theorems:

A = B ≡ ∀〈X || X ∈ ℘I || X ⊆ A ≡ X ⊆ B〉A = B ≡ ∀〈X || X ∈ ℘I || A ⊆ X ≡ B ⊆ X〉

3.2.3 Binary intersection and union

The binary intersection and binary union ∩ , ∪ ∈ PI <−−−| PI×PI are definedby

x ǫ C∩D ≡ x ǫ C ∧ x ǫ Dx ǫ C∪D ≡ x ǫ C ∨ x ǫ D

or point free:

X ⊆ C∩D ≡ X ⊆ C ∧ X ⊆ DC∪D ⊆ X ≡ C ⊆ X ∧ D ⊆ X

Conversely, if we assume that ∩ and = are already defined, we can define ⊆ by

C ⊆ D ≡ C∩D = C

or if we assume that ∪ and = are already defined, we can define ⊆ by

C ⊆ D ≡ C∪D = D

3.2.4 Then and when

The then and when =⊃ , ⊂= ∈ PI <−−−| PI×PI are defined by

x ǫ C=⊃X ≡ x ǫ C ⇒ x ǫ Xx ǫ X⊂=D ≡ x ǫ X ⇐ x ǫ D

or point free:

D ⊆ C=⊃X ≡ C∩D ⊆ XC ⊆ X⊂=D ≡ C∩D ⊆ X

3.2.5 Removed-from and without

The removed-from and without r, r ∈ PI <−−−| PI×PI are defined by

47

x ǫ C rX ≡ x /ǫ C ∧ x ǫ Xx ǫ XrD ≡ x ǫ X ∧ x /ǫ D

or point free:

C rX ⊆ D ≡ X ⊆ C∪DXrD ⊆ C ≡ X ⊆ C∪D

3.2.6 Same and other

The same and other ⊂==⊃ , 6⊂==⊃ ∈ PI <−−−| PI×PI are defined by

x ǫ C⊂==⊃D ≡ x ǫ C ≡ x ǫ Dx ǫ C 6⊂==⊃D ≡ x ǫ C 6≡ x ǫ D

or in terms of previously introduced operators:

C⊂==⊃D = C⊂=D ∩ C=⊃DC 6⊂==⊃D = CrD ∪ C rD

3.2.7 Empty and full collection

The empty collection and full collection ©�, Π ∈ PI are defined by

x ǫ ©� ≡ falsex ǫ Π ≡ true

or point free:

©� ⊆ XX ⊆ Π

In case ©� and Π are relations, we talk about the empty relation (or empty set)and full relation respectively.

3.2.8 Complement

The complement � ∈ PI <−−−| PI is defined by

x ǫ �C ≡ x /ǫ C

Two point-free definitions are

C ⊆ �D ≡ C∩D ⊆ ©��D ⊆ C ≡ Π ⊆ C∪D

48

The complement can also be directly defined by one of the following four equations:

�C = C=⊃©��C = ©�⊂=C�C = C rΠ�C = ΠrC

Conversely, if we assume that �is already defined, we can define =⊃, ⊂=, rand r by

C=⊃X = �C ∪ XX⊂=D = X ∪ �DC rX = �C ∩ XXrD = X ∩ �D

3.2.9 Arbitrary intersection and union

The arbitrary intersection and arbitrary union⋂

,⋃ ∈ PI <−−−| ℘(PI) are de-

fined by

x ǫ⋂

W ≡ ∀〈C || C ∈ W || x ǫ C〉

x ǫ⋃

W ≡ ∃〈C || C ∈ W || x ǫ C〉

or point free:

X ⊆ ⋂

W ≡ ∀〈C || C ∈ W || X ⊆ C〉

⋃

W ⊆ X ≡ ∀〈C || C ∈ W || C ⊆ X〉

3.2.10 Notational considerations

The similarity between the collection-operator symbols and boolean-operator sym-bols is not a coincidence of course. To show this similarity even better, some peopleuse the symbols

∧

and∨

instead of ∀ and ∃ respectively.

In the light of the notation for negated binary predicates (see section 3.1.17), a nicenotation for the full collection would be ©. This notation would also be consistentwith the Z-override relation ©Z that we introduce in section 7.6. We chose Πhowever because deviating too much from common notation makes formulas lessreadable for people from the field.

In most texts about relational algebra, the complement is usually denoted by thesymbol ¬. The reason why we use different symbols for negation (¬) and comple-ment ( �) is type checking. The negation is only single-valued for elements of B

whereas the complement is single-valued in all elements of PI. Even if we identifybooleans and collections (false = ©� and true = Π), we may still only write ¬Xinstead of �X if we know that X is an element of {©�, Π}. The same goes for other‘sharp-edged’ against ‘round-edged’ operators.

49

3.3 Relation operators

Next to the operators of the previous section that deal with arbitrary collections,we also have several operators specifically for relations.

3.3.1 Sequential composition

The sequential composition ◦ ∈ (I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I) is defined by

y (−S ◦P −) z ≡ ∃〈x |||| y (−S −) x ∧ x (−P −) z〉

If P is single-valued in z and S is single-valued in P.z, we have

(S ◦P ).z = S.(P.z)

3.3.2 Over and under

The over and under / , \ ∈ (I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I) are defined by

y (−R/P −) x ≡ ∀〈z |||| y (−R−) z ⇐ x (−P −) z〉x (−S\R−) z ≡ ∀〈y |||| y (−S −) x ⇒ y (−R−) z〉

or point free:

S ⊆ R/P ≡ S ◦P ⊆ RP ⊆ S\R ≡ S ◦P ⊆ R

Notice the difference between the symbols for the ‘over’ and ‘under’ (/ and \) andthe ones for the ‘removed-from’ and ‘without’ ( rand r).

3.3.3 Identity relation

The universal set I is also called the identity relation. The following definitionshows that it is actually just another notation for the equality relation:

y (−I−) z ≡ y = z

Four point-free definitions are

X ◦I = XI◦X = XX/I = XI\X = X

50

3.3.4 Domain and range

The domain and range >, < ∈ ℘I <−−−| (I )−−−( I) are defined by

z ∈ R> ≡ ∃〈y |||| y (−R−) z〉y ∈ R< ≡ ∃〈z |||| y (−R−) z〉

A point-free definition is that for all sets A and B

R> ⊆ B ≡ R ⊆ Π◦BR< ⊆ A ≡ R ⊆ A◦Π

If R> ⊆ B holds, we say that B is an upper domain of R and if R< ⊆ A holds, wesay that A is an upper range of R.

Another point-free definition is that for all sets A and B

B ⊆ R> ≡ B ⊆ Π◦RA ⊆ R< ≡ A ⊆ R◦Π

If B ⊆ R> holds, we say that B is a lower domain of R and if A ⊆ R< holds, wesay that A is a lower range of R.

Notice that the first point-free definition already implies that R> and R< are sets(take I for A and B). So the type constraint >, < ∈ (I )−−−( I) <−−−| (I )−−−( I) would bestrong enough to form together with these equations a complete definition.

3.3.5 Converse

The converse ˘ ∈ (I )−−−( I) <−−−| (I )−−−( I) is defined by

z (−R˘−) y ≡ y (−R−) z

The following two equations together also form a definition of :

R˘ ⊆ X ≡ R ⊆ X˘(S ◦P )˘ = P˘◦S˘

3.3.6 Iteration

The iteration * ∈ (I )−−−( I) <−−−| (I )−−−( I) is defined by

y (−R*−) z ≡ ∀〈X || R ⊆ X ∧ I ⊆ X ∧ X ◦X ⊆ X || y (−X −) z〉

or completely point free:

51

T ⊆ R* ≡ ∀〈X || R ⊆ X ∧ I ⊆ X ∧ X ◦X ⊆ X || T ⊆ X〉

Another point-free definition is given by the following two equations:

I ⊆ R* ∧ R*◦R* ⊆ R*I ⊆ X ∧ X ◦X ⊆ X ⇒ R* ⊆ X ≡ R ⊆ X

The following three theorems are called the leapfrog rules:

R*◦S ⊆ S ◦T * ⇐ R◦S ⊆ S ◦TR*◦S ⊇ S ◦T * ⇐ R◦S ⊇ S ◦TR*◦S = S ◦T * ⇐ R◦S = S ◦T

3.3.7 Power

For n ∈ N, the nth power n ∈ (I )−−−( I) <−−−| (I )−−−( I) is defined by

R0 = IR1 = RRi+j = Ri ◦ Rj

3.3.8 Spick and spack

The spick ◮ ∈ ℘I <−−−| (I )−−−( I)×I is defined by

y ∈ R◮x ≡ y (−R−) x

and the spack ◭ ∈ (I )−−−( I) <−−−| ℘I×I is defined by

y (−A◭x−) z ≡ y ∈ A ∧ z = x

The set R◮x consists of all elements that R connects to input x and A◭x is therelation that consists exactly of the connections that connect input x to an elementof A.

The reason for names “spick” and “spack” is that they can be seen as simple oper-ators that resemble the pick and pack that are introduced in chapter 5.

3.3.9 Constant function

The constant function K ∈ (I <−−−| I) <−−−| I is defined by

(K.y).z = y

52

For an element x, K.x is called the constant-x function.

3.3.10 Doubling function

The doubling function ∆ ∈ I×I <−−−| I is defined by

∆.x = 〈x, x〉

3.3.11 Everywhere and somewhere

The everywhere and somewhere everywhere, somewhere ∈ PI <−−−| PI are definedby (we borrowed the names for these operators from [15])

x ǫ everywhere .C ≡ ∀〈x |||| x ǫ C〉x ǫ somewhere .C ≡ ∃〈x |||| x ǫ C〉

For a relation R, they can also be defined by

everywhere .R = Π\R/Πsomewhere.R = Π◦R◦Π

A theorem that enables the construction of some ‘unconventional’ proofs is

C ⊆ D ≡ everywhere .(C =⊃ D) = Π

If we model the booleans by collections, defining false = ©� and true = Π, we cansimply write

C ⊆ D ≡ everywhere .(C =⊃ D)

An example of an ‘unconventional’ proof for

C ⊆ �D ∪ X ≡ D ⊆ �C ∪ X

is then

53

C ⊆ �D ∪ X

≡

everywhere .(C =⊃ �D ∪ X)

≡ {definition of =⊃ in terms of �and ∪}everywhere .( �C ∪ �D ∪ X)

≡ {commutativity of ∪, see section 3.4.10}everywhere .( �D ∪ �C ∪ X)

≡ {definition of =⊃ in terms of �and ∪}everywhere .(D =⊃ �C ∪ X)

≡D ⊆ �C ∪ X

3.4 Properties

In this section we introduce some properties that collections, and relations in par-ticular, can satisfy.


A collection C is empty if it contains no elements, non-empty if it does containan element, full if it contains all elements and non-full if it does not contain allelements:

C is empty ≡ ∀〈x |||| x /ǫ C〉C is non-empty ≡ ∃〈x |||| x ǫ C〉C is full ≡ ∀〈x |||| x ǫ C〉C is non-full ≡ ∃〈x |||| x /ǫ C〉

or point free:

C is empty ≡ C = ©�C is non-empty ≡ C 6= ©�C is full ≡ C = ΠC is non-full ≡ C 6= Π

Non-emptiness of a relation R can also be formulated as Π◦R◦Π = Π instead ofR 6= ©� because we assumed to have no empty external types. We actually preferΠ◦R◦Π = Π to R 6= ©� because positive formulations are often more useful in proofsthan negative ones.

54

3.4.2 Uniqueness and singleness

A relation has a unique input if each connection in the relation has the same inputand a unique output if each connection in the relation has the same output:

R has a unique input ≡ ∃〈x |||| ∀〈y, z || y (−R−) z || z = x〉〉R has a unique output ≡ ∃〈x |||| ∀〈y, z || y (−R−) z || y = x〉〉

or point free:

R has a unique input ≡ R˘◦Π◦R ⊆ IR has a unique output ≡ R◦Π◦R˘ ⊆ I

A relation has a unique connection if it has a unique input as well as a uniqueoutput. A non-empty relation has a single input if it has a unique input, it has asingle output if it has a unique output and it has a single connection if it hasa unique connection.

The notions of unique connection and single connection can be generalised to thatof a unique element and a single element for collections:

C has a unique element ≡ ∃〈x |||| ∀〈w |||| w ǫ C ⇒ w = x〉〉C has a single element ≡ ∃〈x |||| ∀〈w |||| w ǫ C ≡ w = x〉〉

3.4.3 Functionality, injectivity, totality and surjectivity

A relation R is functional if it connects each input with at most one output,injective if it connects each output with at most one input, total if it connectseach input with at least one output and surjective if it connects each output withat least one input:

R is functional ≡ ∀〈x, y, z || x (−R−) z ∧ y (−R−) z || x = y〉R is injective ≡ ∀〈x, y, z || y (−R−) x ∧ y (−R−) z || x = z〉R is total ≡ ∀〈z |||| ∃〈y |||| y (−R−) z〉〉R is surjective ≡ ∀〈y |||| ∃〈z |||| y (−R−) z〉〉

or point free:

R is functional ≡ R◦R˘ ⊆ IR is injective ≡ R˘◦R ⊆ IR is total ≡ I ⊆ R˘◦RR is surjective ≡ I ⊆ R◦R˘

3.4.4 Sets, conditions and squares

As mentioned in section 3.1.19, a set is a relation that only connects equal elements:

55

R is a set ≡ ∀〈y, z || y (−R−) z || y = z〉

This can be written point free as:

R is a set ≡ R ⊆ I

Sets model collections within the calculus of relations as subrelations of I. There arealso other ways to model collections as relations. A relation is an input conditionif it connects each input in its domain with each output, an output condition if itconnects each output in its range with each input and a square if it connects eachinput in its domain with each output in its range:

R is an input condition ≡ ∀〈x, y, z || x (−R−) z || y (−R−) z〉R is an output condition ≡ ∀〈x, y, z || y (−R−) x || y (−R−) z〉R is a square ≡ ∀〈w, x, y, z || y (−R−) x ∧ w (−R−) z || y (−R−) z〉

or point free:

R is an input condition ≡ R = Π◦RR is an output condition ≡ R = R◦ΠR is a square ≡ R = R◦Π◦R

3.4.5 Reflexivity, transitivity and symmetry

A relation R is reflexive if it connects each element with itself, irreflexive ifit connects no element with itself, transitive if it connects all elements that itconnects ‘indirectly’, symmetric if each connection has a ‘back’ connection andanti-symmetric if no connection between different elements has a ‘back’ connec-tion:

R is reflexive ≡ ∀〈x |||| x (−R−) x〉R is irreflexive ≡ ∀〈x |||| ¬(x (−R−) x)〉R is transitive ≡ ∀〈x, y, z || y (−R−) x ∧ x (−R−) z || y (−R−) z〉R is symmetric ≡ ∀〈y, z || z (−R−) y || y (−R−) z〉R is anti-symmetric ≡ ∀〈y, z || z (−R−) y ∧ y (−R−) z || y = z〉

or point free:

R is reflexive ≡ I ⊆ RR is irreflexive ≡ I∩R = ©�R is transitive ≡ R◦R ⊆ RR is symmetric ≡ R˘ = RR is anti-symmetric ≡ R˘∩R ⊆ I

A relation that is reflexive and transitive is called a preorder and an anti-symmetricpreorder is called a partial order.

56

3.4.6 Monotonicity

A total function F ∈ PI <−−−| PI is monotonic if its output is larger for larger inputsand anti-monotonic if its output is smaller for larger inputs:

F is monotonic ≡ ∀〈C, D |||| C ⊆ D ⇒ F.C ⊆ F.D〉

F is anti-monotonic ≡ ∀〈C, D |||| C ⊆ D ⇒ F.C ⊇ F.D〉

If the implications in these formulas can be strengthened into equivalences, we callF monomorph and anti-monomorph respectively:

F is monomorph ≡ ∀〈C, D |||| C ⊆ D ≡ F.C ⊆ F.D〉

F is anti-monomorph ≡ ∀〈C, D |||| C ⊆ D ≡ F.C ⊇ F.D〉

An n-argument function F ∈ PI <−−−| PI× . . .×PI is monotonic in a certain ar-gument if each section of F where all arguments except that certain one arefixed, is monotonic. The same goes for anti-monotonicity, monomorphity and anti-monomorphity. The function ‘over’ ( / ) is for example monotonic in its left argu-ment and anti-monotonic in its right argument. Sometimes we are sloppy and calla function (like for example ∩ ) monotonic, although we actually mean that it ismonotonic in its arguments.

For sets A and B that are equal to the universal set I, the set of monotonic totalfunctions PA <−−−|m PB is defined by

R ∈ PA <−−−|m PB

≡ {• A = I ∧ B = I}R ∈ PA <−−−| PB ∧ R is monotonic

The strange restriction on the sets A and B is there because we defined monotonicityonly for total functions. Notice that we can for example fill in I⋆I or PI for A andB.

3.4.7 Closedness

A set of collections W is subcollection closed if it owns all subcollections of eachcollection it owns and supercollection closed if it owns all supercollections ofeach collection it owns:

W is subcollection closed ≡ ∀〈C, D || C ⊆ D ∧ D ∈ W || C ∈ W 〉

W is supercollection closed ≡ ∀〈C, D || C ∈ W ∧ C ⊆ D || D ∈ W 〉

57

3.4.8 Disjointness and conjointness

Two collections C and D are disjoint if they do not share any elements and con-joint if together, they contain all elements:

C and D are disjoint ≡ ∀〈x |||| x /ǫ C ∨ x /ǫ D〉C and D are conjoint ≡ ∀〈x |||| x ǫ C ∨ x ǫ D〉

or point free:

C and D are disjoint ≡ C∩D = ©�C and D are conjoint ≡ C∪D = Π

Two sets A and B are called set-conjoint if together they own all elements:

A and B are set-conjoint ≡ A∪B = I

3.4.9 Domain equalness

Two relations R and T are domain equal if they have equal domains:

R and T are domain equal ≡ ∀〈z |||| ∃〈y |||| y (−R−) z〉 ≡ ∃〈y |||| y (−T −) z〉〉

or point free:

R and T are domain equal ≡ Π◦R = Π◦T

or using the domain operator:

R and T are domain equal ≡ R> = T >

We define the domain-equality relation DEQ ∈ (I )−−−( I) )−−−( (I )−−−( I) by

R (−DEQ −) T ≡ R and T are domain equal

3.4.10 Idempotency, commutativity and associativity

For a function ⊙ ∈ A <−−−| A×A, for some set A, idempotency, commutativityand associativity are defined as follows:

⊙ is idempotent ≡ ∀〈x || x ∈ A || x⊙x = x〉⊙ is commutative ≡ ∀〈x, y || x, y ∈ A || x⊙y = y⊙x〉⊙ is associative ≡ ∀〈x, y, z || x, y, z ∈ A || (x⊙y)⊙z = x⊙(y⊙z)〉

Associativity allows the removal of brackets as described in section 3.1.2 and ishardly ever mentioned explicitly in this thesis.

58

3.4.11 Zeros and units

For a function ⊙ ∈ A <−−−| A×A and an element x ∈ A, for some set A, we definethe notions left-zero, right-zero, left-unit and right-unit by

x is a left-zero of ⊙ ≡ ∀〈y || y ∈ A || x⊙y = x〉x is a right-zero of ⊙ ≡ ∀〈y || y ∈ A || y⊙x = x〉x is a left-unit of ⊙ ≡ ∀〈y || y ∈ A || x⊙y = y〉x is a right-unit of ⊙ ≡ ∀〈y || y ∈ A || y⊙x = y〉

A zero is an element that is a left-zero as well as a right-zero and a unit is anelement that is a left-unit as well as a right-unit.

3.4.12 Distribution

For functions f ∈ A <−−−| A and ⊙ ∈ A <−−−| A×A, for some set A, distribution off over ⊙ is defined by

f distributes over ⊙≡∀〈x, y || x, y ∈ A || f.(x⊙y) = f.x ⊙ f.y〉

We also define distribution for ‘arbitrary operators’ like the arbitrary union andintersection. For f ∈ A <−−−| A and ⊙ ∈ A <−−−| ℘A, for some set A:

f distributes over ⊙≡∀〈W |

| W ∈ ℘A || f.(⊙W ) = ⊙{f.x | x ∈ W | x}〉

Although formally not correct, we also say that a binary operator �• distributesover ⊙ if the sections (x�• ) and (�• x) both distribute over ⊙.

3.4.13 Commutation

For functions g, h ∈ A <−−−| A, commutation of g with h is defined by

g commutes with h

≡∀〈x || x ∈ A || g.(h.x) = h.(g.x)〉

or point free:

g◦h = h◦g

59

3.4.14 Abidence

For functions �• , ⊙ ∈ A <−−−| A×A, for some set A, abidence of �• with ⊙ isdefined by

�• abides with ⊙≡∀〈x0, x1, y0, y1

||

x0, x1, y0, y1 ∈ A || (x0�• x1) ⊙ (y0�• y1) = (x0⊙y0) �• (x1⊙y1)〉

The name “abide” stands for “above or beside” and is due to Richard Bird. Thename was inspired by the following way of writing the law, due to Tony Hoare:

x0 �• x1 x0 x1

⊙ = ⊙ �• ⊙y0 �• y1 y0 y1

3.4.15 Comparability, chains and continuity

Two collections are comparable if one is a subcollection of the other:

C and D are comparable ≡ C ⊆ D ∨ D ⊆ C

A set of collections W is a chain if all collections in W are comparable with eachother:

W is a chain ≡ ∀〈C, D || C, D ∈ W || C and D are comparable〉

A total function F ∈ PI <−−−| PI is continuous if it distributes over the arbitraryunion of all non-empty chains:

F is continuous

≡∀〈W |

| W is a chain ∧ W 6= ©� || F.(⋃

W ) =⋃{F.X | X ∈ W | X}〉

For sets A and B that are equal to I, the set of continuous total functions PA <−−−|c PBis defined by

R ∈ PA <−−−|c PB

≡ {• A = I ∧ B = I}R ∈ PA <−−−| PB ∧ R is continuous

We leave it to the reader to prove that a continuous total function is monotonic(hint: the set {C, D} with C ⊆ D is a chain).

Continuity comes into play in chapter 9 where calls in specifications can be made

60

visible in the semantics.

3.5 Galois connections

In this section we give a brief overview of the theory of Galois connections in thecontext of partial order ⊆. For more elaborate theory about Galois connections, werefer the reader to [1].

3.5.1 Definition

For F, G ∈ PI <−−−| PI, we call (F, G) a Galois connection if

F.X ⊆ Y ≡ X ⊆ G.Y

The function F is called the lower adjoint of the Galois connection and the functionG is called the upper adjoint.

An equivalent definition is

F is monotonicG is monotonicG.(F.X) ⊇ XF.(G.Y ) ⊆ Y

The lower two laws are referred to as cancellation.

3.5.2 More cancellation laws

A theorem that enables us to strengthen the cancellation laws into equalities is thatif (F, G) is a Galois connection then

G is surjective

≡F is injective

≡

∀〈X |||| X = G.(F.X)〉

F is surjective

≡G is injective

≡

∀〈Y |||| F.(G.Y ) = Y 〉

If we cannot use this theorem, we still have that for a Galois connection (F, G)

F.(G.(F.X)) = F.X G.(F.(G.Y )) = G.Y

All these theorems are also referred to as cancellation.

61

3.5.3 Uniqueness and existence of adjoints

The adjoints in a Galois connection are unique. So, if (F 0, G0) and (F 1, G1) areGalois connections then

F 0 = F 1 ≡ G0 = G1

The fundamental theorem of Galois connections gives us that a total functionG is an upper adjoint in a Galois connection exactly when G distributes over

⋂

and that a total function F is a lower adjoint in a Galois connection exactly whenF distributes over

⋃

. For sets A and B that are equal to I, we introduce the setPA <−−−|⋂ PB of total functions that distribute over

⋂

and the set PA <−−−|⋃ PB oftotal functions that distribute over

⋃

:

G ∈ PA <−−−|⋂ PB

≡ {• A = I ∧ B = I}G ∈ PA <−−−| PB ∧ G distributes over

⋂

F ∈ PA <−−−|⋃ PB

≡ {• A = I ∧ B = I}F ∈ PA <−−−| PB ∧ F distributes over

⋃

Because adjoints are unique, we can talk about the upper adjoint of a total func-tion that distributes over

⋃

and about the lower adjoint of a total function thatdistributes over

⋂

. The function sharp ♯ ∈ (PI <−−−|⋂ PI) <−−−| (PI <−−−|⋃ PI) gives theupper adjoint of a total function that distributes over

⋃

and the function flat♭ ∈ (PI <−−−|⋃ PI) <−−−| (PI <−−−|⋂ PI) gives the lower adjoint of a total function that

distributes over⋂

. They can be defined by

F ♯.Y =⋃{X | F.X ⊆ Y | X}

G♭.X =⋂{Y | X ⊆ G.Y | Y }

3.5.4 Exploiting Galois connections

If we know that an operator is part of a Galois connection, we get many theoremsfor free. For the sequential composition we have for example:

S ◦P ⊆ R ≡ S ⊆ R/PS ◦P ⊆ R ≡ P ⊆ S\R

From these definitions we see that section (◦P ) is the lower adjoint of a Galoisconnection with upper adjoint (/P ) and that section (S ◦) is the lower adjoint of aGalois connection with upper adjoint (S\). We thus get for free that ◦ is monotonicin both arguments, that / is monotonic in its left argument and that \ is monotonicin its right argument:

62

S0 ⊆ S1 ⇒ S0◦P ⊆ S1◦PR0 ⊆ R1 ⇒ R0/P ⊆ R1/PP 0 ⊆ P 1 ⇒ S ◦P 0 ⊆ S ◦P 1

R0 ⊆ R1 ⇒ S\R0 ⊆ S\R1

The cancellation laws that we get for free are

(S ◦P )/P ⊇ S(R/P )◦P ⊆ RS\(S ◦P ) ⊇ PS ◦(S\R) ⊆ R

((S ◦P )/P )◦P = S ◦P((R/P )◦P )/P = R/PS ◦(S\(S ◦P )) = S ◦PS\(S ◦(S\R)) = S\R

The distribution properties that we get for free are

⋃

W ◦P =⋃{S ◦P | S ∈ W | S}

⋂

W/P =⋂

{R/P | R ∈ W | R}S ◦

⋃

W =⋃{S ◦P | P ∈ W | P}

S\⋂

W =⋂

{S\R | R ∈ W | R}

Using the fact that Π =⋂

©�, ©� =⋃

©�, Q∩T =⋂{Q, T } and Q∪T =

⋃{Q, T }, weget

©�◦P = ©�Π/P = Π(Q∪T )◦P = Q◦P ∪ T ◦P(Q∩T )/P = Q/P ∩ T/P

S ◦©� = ©�S\Π = ΠS ◦(Q∪T ) = S ◦Q ∪ S ◦TS\(Q∩T ) = S\Q ∩ S\T

In chapter 5 the theory of Galois connections is exploited to prove several propertiesof products.

3.6 Fixed points

A fixed point X of a monotonic total function F is a collection that is ‘left un-changed’ by the function:

F.X = X

A monotonic total function F has a least fixed point and a greatest fixedpoint. The least–fixed-point operator and greatest–fixed-point operatorµ , ν ∈ PI <−−−| (PI <−−−|m PI) determine these fixed points. They are defined by

µF =⋂{X | F.X = X | X}

νF =⋃

{X | F.X = X | X}

63

The least–fixed-point operator and greatest–fixed-point operator can both also bedefined by the combination of two rules. One is called the computation rule. Itsays that µF and νF are fixed points of F :

F.µF = µFF.νF = νF

The other is called the induction rule. This one says that µF is the smallest andνF is the largest of all fixed points:

F.X = X ⇒ µF ⊆ XF.X = X ⇒ νF ⊇ X

It is a well-known fact that µ and ν can also be defined in terms of prefix pointsand postfix points respectively. A prefix point X of a monotonic total functionF is a collection that satisfies F.X ⊆ X and a postfix point X is a collection thatsatisfies F.X ⊇ X. We can also define µ and ν equivalently by

µF =⋂

{X | F.X ⊆ X | X}νF =

⋃{X | F.X ⊇ X | X}

or again by what we also call computation and induction:

F.µF ⊆ µFF.νF ⊇ νF

F.X ⊆ X ⇒ µF ⊆ XF.X ⊇ X ⇒ νF ⊇ X

The operators µ and ν satisfy several algebraic properties. One of them is that theyare monotonic, that is, for G, H ∈ PI <−−−|m PI we have

∀〈X |||| G.X ⊆ H.X〉 ⇒ µG ⊆ µH∀〈X |||| G.X ⊆ H.X〉 ⇒ νG ⊆ νH

We are actually not allowed to call this “monotonic” in our formalism, but weassume that the reader is able to tell the different uses of the word “monotonic”apart.

In case F is a continuous total function, the least fixed point of F is equal to theunion of all Fn.©� for n ∈ N:

µF =⋃{Fn.©� | n ∈ N | n} ⇐ F ∈ PI <−−−|c PI

For a function F that is a lower adjoint (F ∈ PI <−−−|⋃ PI), a function G thatis an upper adjoint (G ∈ PI <−−−|⋂ PI) and monotonic total functions H and K(H, K ∈ PI <−−−|m PI), the following fusion theorems hold:

64

F.µH ⊆ µK ⇐ ∀〈X |||| F.(H.X) ⊆ K.(F.X)〉F.µH ⊇ µK ⇐ ∀〈X |||| F.(H.X) ⊇ K.(F.X)〉F.µH = µK ⇐ ∀〈X |||| F.(H.X) = K.(F.X)〉

G.νH ⊇ νK ⇐ ∀〈X |||| G.(H.X) ⊇ K.(G.X)〉G.νH ⊆ νK ⇐ ∀〈X |||| G.(H.X) ⊆ K.(G.X)〉G.νH = νK ⇐ ∀〈X |||| G.(H.X) = K.(G.X)〉

Least fixed points are usually associated with finite elements and greatest fixedpoints with infinite elements. We illustrate this using the natural numbers as anexample.

If we assume the existence of an external type of possibly infinite natural numbers,where 0∞ denotes its ‘zero’, 1∞ denotes its ‘one’, ∞∞ denotes its ‘infinity’ and +∞denotes its ‘sum’, then for f∞, defined by

f∞.N = [n +∞ 1∞ | n ǫ N | n] ∪ [0∞]

νf∞ contains ∞∞ whereas µf∞ does not:

µf∞ = Πr[∞∞]νf∞ = Π

In case we would have used finite natural numbers as external type, both fixedpoints would be equal.

The theory of fixed points is used in chapter 8 to model inter-component commu-nication.

3.7 Relators

For a set A, we defined PA by

C ∈ PA

≡∀〈x || x ǫ C || x ∈ A〉

and for sets A and B, we defined A⋆B by

(y, z) ∈ A⋆B

≡y ∈ A ∧ z ∈ B

There is a natural way to generalise these definitions to relations. We define thepower relator P ∈ (PI )−−−( PI) <−−−| (I )−−−( I) by

65

C (−PR−) D

≡

∀〈y || y ǫ C || ∃〈z || z ǫ D || y (−R−) z〉〉 ∧∀〈z || z ǫ D || ∃〈y || y ǫ C || y (−R−) z〉〉

This definition is consistent with the one restricted to sets:

C (−PA−) D ≡ C = D ∧ ∀〈x || x ǫ C || x ∈ A〉

Furthermore, the following theorems can be proved for relations R and S:

R⊆S ≡ PR ⊆ PSP(R∩S) ⊆ PR ∩ PSP(R∪S) ⊇ PR ∪ PSP(R◦S) = PR ◦ PSPI = IP(R ) = (PR)˘

Most of these theorems are straightforward to prove at the point-wise level, exceptfor the fact that P(R◦S) ⊆ PR ◦ PS. This theorem can be proved using the axiomof choice. A more algebraic treatment can be found in [11].

For ⋆ we have a similar kind of generalisation. We define the connectional prod-uct ⋆ ∈ (I⋆I )−−−( I⋆I) <−−−| (I )−−−( I)×(I )−−−( I) by

(y0, y1) (−R0⋆R1−) (z0, z1) ≡ y0 (−R0−) z0 ∧ y1 (−R1−) z1

This definition is again consistent with the one restricted to sets:

(y0, y1) (−A0⋆A1−) (z0, z1) ≡ (y0, y1) = (z0, z1) ∧ y0 ∈ A0 ∧ y1 ∈ A1

Furthermore, the following theorems can be proved for relations Ri and Si:

R0⊆S0 ∧ R1⊆S1 ⇒ R0⋆R1 ⊆ S0⋆S1

R0∩S0 ⋆ R1∩S1 = R0⋆R1 ∩ S0⋆S1

R0∪S0 ⋆ R1∪S1 = R0⋆R1 ∪ R0⋆S1 ∪ S0⋆R1 ∪ S0⋆S1

R0 ◦ S0 ⋆ R1 ◦ S1 = R0⋆R1 ◦ S0⋆S1

I ⋆ I = IR0 > ⋆ R1 > = R0⋆R1 >

R0 < ⋆ R1 < = R0⋆R1 <

R0 ˘ ⋆ R1 ˘ = R0⋆R1 ˘

The proofs of these theorems are straightforward.

The generalisation of ⋆ to relations is used in section 6.8 for the theory about whatwe call “connectional expressions”.

The power relator and connectional product are examples of relators. For more

66

information about relators we refer the reader to [11].

3.8 Some theorems

In this section we discuss some fundamental theorems.

3.8.1 Shunting

The following theorem is called shunting. For total functions g and h we have

S ⊆ g˘◦R◦h ≡ g◦S ◦h˘ ⊆ R

or equivalently (using the fact that U ◦S ◦P ⊆ R ≡ S ⊆ U\R/P and indirect equal-ity):

g˘◦R◦h = g\R/h˘

We often use shunting with g or h instantiated to I. Specifically, for a total functionf we have

S ⊆ R◦f ≡ S ◦f˘ ⊆ RS ⊆ f˘◦R ≡ f ◦S ⊆ R

or equivalently:

R◦f = R/f˘f˘◦R = f\R

Each of these four properties (universally quantified over R and S) is in fact equiv-alent to f being a total function. The proof of this fact is left to the reader (hint:use the point-free formulation of functionality and totality).

A theorem that we also refer to as “shunting”, is that for total functions g and h

y (−g˘◦R◦h−) z ≡ g.y (−R−) h.zy (−g\R/h˘−) z ≡ g.y (−R−) h.z

This theorem is also used often with g, h or R instantiated to I.

The notion of shunting is fundamental in point-free relational calculus and it is usedat several places in this thesis.

67

3.8.2 Complementing things

Especially from the dot-matrix representation of relations, it is clear that for eachoperator that we defined, there exists an operator that behaves exactly the same,‘after taking the complement of everything’.

An example is the confrontation |◦ ∈ (I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I) (see [15]),defined by

y (−S |◦P −) z ≡ ∀〈x |||| y (−S −) x ∨ x (−P −) z〉

or in terms of ◦ and �:

S |◦P = �( �S ◦ �P )

The confrontation is associative, has �I as unit and distributes over ∩, which is atrivial consequence of the fact that ◦ is associative, has I as unit and distributesover ∪. In general, the algebraic laws of

〈⊆, ∩, ∪, =⊃, ⊂=, r, r, ⊂==⊃, 6⊂==⊃,©�, Π, �,⋂

,⋃

, ◦, I, , everywhere , somewhere〉

equal the algebraic laws of

〈⊇, ∪, ∩, r, r, =⊃, ⊂=, 6⊂==⊃, ⊂==⊃, Π,©�, �,⋃

,⋂

, |◦, �I, , somewhere , everywhere〉

3.8.3 Distribution of sequential composition over intersec-tion

A well-known property of the relational calculus is that in general, sequential com-position does not distribute over intersection. We do have that for a set A

(R∩S)◦A = R◦A ∩ S ◦AA◦(R∩S) = A◦R ∩ A◦S

More in general, for a function f we have

(R∩S)◦f = R◦f ∩ S ◦ff˘◦(R∩S) = f˘◦R ∩ f˘◦S

Both these properties (universally quantified over R and S) are even equivalent tothe fact that f is a function. In general for a relation T , we only have the followinginclusion though:

(R∩S)◦T ⊆ R◦T ∩ S ◦TT ◦(R∩S) ⊆ T ◦R ∩ T ◦S

68

This is called half-distribution of sequential composition over intersection.

There is a general theorem that gives an inclusion the other way around. Thistheorem is called the law of Desargues and is easy to prove at the point-wise level,although it involves many variables:

(R0◦U0 ∩ R1◦U1) ◦ (U0˘◦T 0 ∩ U1˘◦T 1) ⊇ R0◦T 0 ∩ R1◦T 1

⇐U0◦U1˘ ⊇ R0˘◦R1 ∩ T 0◦T 1˘

The following instantiations of this theorem are known as the laws of Dedekind:

(R ∩ S ◦T )◦T ⊇ R◦T ∩ S(R◦T˘ ∩ S)◦T ⊇ R ∩ S ◦TT ◦(R ∩ T˘◦S) ⊇ T ◦R ∩ ST ◦(T˘◦R ∩ S) ⊇ R ∩ T ◦S

Using half-distribution and the law of Desargues, the following theorem is easy toprove:

(R0∩R1) ◦ (T 0∩T 1) = (R0◦T 0) ∩ (R1◦T 1)

⇐

∃(U0, U1|||| U0◦U1˘ ⊇ R0˘◦R1 ∩ T 0◦T 1˘ ∧R0 = R0◦U0 ∧ T 0 = U0˘◦T 0 ∧R1 = R1◦U1 ∧ T 1 = U1˘◦T 1)

Yet another two distribution theorems we want to mention:

T ◦(R∩S) = T ◦R ∩ T ◦S = R∩S ⇐ I ⊆ T ∧ T ◦R ⊆ R ∧ T ◦S ⊆ S(R∩S)◦T = R◦T ∩ S ◦T = R∩S ⇐ I ⊆ T ∧ R◦T ⊆ R ∧ S ◦T ⊆ S

Both are easy to prove using a ping-pong proof. For the first one, the proof is

T ◦(R∩S)

⊆ {half-distribution of ◦ over ∩}T ◦R ∩ T ◦S

⊆ {• T ◦R ⊆ R ∧ T ◦S ⊆ S}R∩S

= {I is unit of ◦}I◦(R∩S)

⊆ {• I ⊆ T}T ◦(R∩S)

The proof of the second one is analogous.

The law of Desargues (which we obtained from [49]) and the last two distribution

69

theorems were used in previous versions of the proof in section 5.4.6. Althoughthese versions were at a more point-free level and did not resort to the axiom ofchoice, they were not as general and more ad hoc than the current proof. We stillincluded the above theorems however, because some readers might find them helpfulfor their understanding. The same goes for the next subsection.

3.8.4 Extreme point-freeness

Formulating equations in a point-free manner can be taken to an extreme, raisingthe level of abstraction even more. Most of the theorems in this section were usedin previous versions of the proofs in chapters 4 and 5. These formulas helped us toincrease the level of abstraction at which we could reason about the constructs thatare presented in those chapters. Although the theorems of this section are not usedanymore in the current version of this thesis, some readers might find them helpfulfor their understanding.

The following equations express the fact that I is a right-unit of ◦ and / and aleft-unit of ◦ and \:

(◦I) = I(/I) = I(I◦) = I(I\) = I

Three point-free ways to express associativity of sequential composition are:

(R◦) ◦ (◦T ) = (◦T ) ◦ (R◦)(R◦) ◦ (T ◦) = ((R◦T )◦)(◦R) ◦ (◦T ) = (◦(T ◦R))

Monotonicity and anti-monotonicity of a total function F can be formulated as

F is monotonic ≡ F ◦⊆ ⊆ ⊆◦FF is anti-monotonic ≡ F ◦⊆ ⊆ ⊇◦F

Subcollection closedness and supercollection closedness of a set of collections W canbe formulated as

W is subcollection closed ≡ ⊆◦W ⊆ W ◦⊆W is supercollection closed ≡ W ◦⊆ ⊆ ⊆◦W

The following theorem enables us to formulate monotonicity and closedness as akind of ‘absorption’ laws:

R◦⊆ ⊆ ⊆◦R ≡ ⊆◦R◦⊆ = ⊆◦R⊆◦R ⊆ R◦⊆ ≡ ⊆◦R◦⊆ = R◦⊆

70

We prove the first one. The proof of the second one is analogous.

(⇒)

⊆◦R◦⊆⊆ {• R◦⊆ ⊆ ⊆◦R}⊆◦⊆◦R

= {⊆◦⊆ = ⊆}⊆◦R

= {I is unit of ◦}⊆◦R◦I

⊆ {I ⊆ ⊆}⊆◦R◦⊆

(⇐)

R◦⊆= {I is unit of ◦}

R◦⊆◦I⊆ {I ⊆ ⊆}⊆◦R◦⊆

⊆ {• ⊆◦R◦⊆ ⊆ ⊆◦R}⊆◦R

To illustrate a nice ‘proof trick’, we prove that the sequential composition of twomonotonic total functions is monotonic, using the formulation of monotonicity asan ‘absorption’ law:

⊆◦F ◦G◦⊆= {• ⊆◦F = ⊆◦F ◦⊆}⊆◦F ◦⊆◦G◦⊆

= {• ⊆◦G◦⊆ = ⊆◦G}⊆◦F ◦⊆◦G

= {• ⊆◦F ◦⊆ = ⊆◦F}⊆◦F ◦G

The shunting rules for a total function f can be formulated as

(◦f) = (/f )(f˘◦) = (f\)

The fact that (F, G) is a Galois connection can be formulated as

71

F˘◦⊆ = ⊆◦G

where F˘◦⊆ (or ⊆◦G) is known as the pair algebra of the Galois connection (see[5]).

The alternative definition of a Galois connection (F, G) can also be formulated as

F ◦⊆ ⊆ ⊆◦FG◦⊆ ⊆ ⊆◦GG◦F ⊆ ⊇F ◦G ⊆ ⊆

and the extra cancellation laws as

I ⊆ G◦G˘

≡F˘◦F ⊆ I

≡G◦F = I

I ⊆ F ◦F˘

≡G˘◦G ⊆ I

≡F ◦G = I

and

F ◦G◦F = F G◦F ◦G = G

If we define the fixed-point-of relation FIXES ∈ PI )−−−( (PI <−−−|m PI) by

X (−FIXES −) F ≡ F.X = X

then the definitions of the least–fixed-point operator and greatest–fixed-point oper-ator can be formulated as

µ ⊆ FIXES ∧ FIXES ⊆ ⊇◦µν ⊆ FIXES ∧ FIXES ⊆ ⊆◦ν

3.9 Conclusions

The purpose of this chapter was to introduce the basic theory that is used in thisthesis. We stuck to common notation where possible, but deviated where we thoughtthis to be beneficial. An important ingredient of the theory is the external typesystem that we informally described in section 3.1.21. We see the formalisation ofthis type system as an important topic for future research.

72

Chapter 4

Types

Types are a means to restrict the elements that a variable can represent. In thischapter we introduce and investigate several types that can be used to restrict thevalues of variables that represent relations.

4.1 Cylindric typing

In functional type theories, the co/contra-variance rule is the primary rule forsubtyping on function types. Denoting subtyping by ≤ and the type of functionsfrom B to A by A← B, the rule is as follows:

A′ ≤ A ∧ B′ ≤ B ⇒ A′ ← B ≤ A← B′

The rule is usually formulated as “the output type may be strengthened and theinput type may be weakened”, telling how to construct a subtype of a functiontype. The fact that functions of the subtype may be defined on a larger domain,corresponds to subtyping in object-oriented languages, where a subclass can extenda superclass by new methods, the collection of method names forming the domainon which the class is defined. We call this phenomenon extensibility, which isformalised in section 4.2.8.

In relational theories, the co/contra-variance rule is not very common. One of themain reasons is that relational theorists like to treat relations bidirectionally,meaning that no specific side of a relation is chosen as input side. The asymmetrybetween input and output in the co/contra-variance rule does not match this idea.A result is that typing of relations is usually done in a ‘symmetric’ way. A relationS is typed by giving an upper range A and an upper domain B for S:

S< ⊆ A ∧ S> ⊆ B

73

We call this bidirectional typing. Some equivalent formulations are

S ⊆ A◦Π◦BS = A◦S ◦BS ⊆ A◦S ◦B

A way to write this down point wise is

∀〈y, z || y (−S −) z || y ∈ A ∧ z ∈ B〉

So we see that the type A )−−−( B that was introduced in section 3.1.21, is intendedfor bidirectional typing. Extensibility can be obtained by a weaker form of typing,stating only that S outputs an element of A if the input is an element of B:

∀〈y, z || y (−S −) z || y ∈ A ⇐ z ∈ B〉

We call this cylindric typing. In most functional type theories, a similar definitionis used for “f : A← B”. Notice that the symmetry between input and output isdestroyed.

Some point-free formulations that are equivalent to the above formula are

S ◦B ⊆ A◦ΠS ◦B = A◦S ◦BS ◦B ⊆ A◦S

For sets A and B, we introduce the set A −−−◦ B for cylindric typing:

S ∈ A −−−◦ B

≡∀〈y, z || y (−S −) z || y ∈ A ⇐ z ∈ B〉

The following cylindric-type rules are easy to verify. For sets A, B and C wehave

R ∈ A −−−◦ B ⇐ R ⊆ S ∧ S ∈ A−−−◦ BR∩S ∈ A −−−◦ B ⇐ R ∈ A −−−◦ B ∧ S ∈ A−−−◦ BR∪S ∈ A −−−◦ B ⇐ R ∈ A −−−◦ B ∧ S ∈ A−−−◦ BR rS ∈ A −−−◦ B ⇐ R ∈ A −−−◦ B ∧ S ∈ A−−−◦ BRrS ∈ A −−−◦ B ⇐ R ∈ A −−−◦ B ∧ S ∈ A−−−◦ BR ◦ S ∈ A −−−◦ B ⇐ R ∈ A −−−◦ C ∧ S ∈ C −−−◦ B

I ∈ A −−−◦ AR* ∈ A −−−◦ A ⇐ R ∈ A −−−◦ A

In contrast to bidirectional typing, we do not have that S˘ ∈ A −−−◦ B follows fromS ∈ B −−−◦ A in general. This reflects the unidirectionality of cylindric typing.

74

4.2 Type operators

A type operator is a function with type

((I )−−−( I) )−−−( (I )−−−( I)) <−−−| (I )−−−( I)×(I )−−−( I)

We call the left argument of a type operator the output type and the right argu-ment the input type.

4.2.1 Cylindric-type operator

The cylindric-type operator −−−−−◦ is defined by

S (−R −−−−−◦ P −) Q ≡ S ◦P ⊆ R◦Q

The correspondence between −−−−−◦ and−−−◦ is reflected by the following equation:

S (−A −−−−−◦ B −) S ≡ S ∈ A −−−◦ B

An important property of −−−−−◦ is that it is monotonic, or covariant, in its outputtype and anti-monotonic, or contravariant, in its input type:

R ⊆ T ∧ P ⊇ U ⇒ R −−−−−◦ P ⊆ T −−−−−◦ U

The proof of this fact is trivial. Contravariance in the input type has always beenthe standard in functional programming, but not in relational programming.

4.2.2 Functionality and totality

Recall the following two point-free formulations of functionality and totality:

S ◦S˘ ⊆ II ⊆ S˘◦S

These formulations can be generalised straightforwardly to variants where an inputtype and output type are included:

S ◦B ◦S˘ ⊆ AB ⊆ S˘◦A◦S

The first one means that S connects each input from B with at most one outputand that this output is an element of A. The second one means that S connectseach input from B with at least one output from A.

Just like we did with cylindric typing, we also generalise these two properties,

75

defining the type operators <−−−−− and −−−−−) by

S (−R <−−−−− P −) Q ≡ S ◦P ◦Q˘ ⊆ RS (−R −−−−−) P −) Q ≡ P ⊆ S˘◦R◦Q

A relation S is functional on B if it is functional in every element of B, orequivalently, S (−I <−−−−− B −) S. A relation S is total on B if it is total in every elementof B, or equivalently, S (−I −−−−−) B −) S. A relation S is single-valued on B if it issingle-valued in every element of B, or equivalently, if it is functional on B andtotal on B.

4.2.3 Restrictedness

Saying that a relation S is total on B, is the same as saying that B is a lowerdomain of S:

S (−I −−−−−) B −) S ≡ S> ⊇ B

We also have a type operator −−−−−( for upper domains, such that

S (−I −−−−−( B −) S ≡ S> ⊆ B

This type operator −−−−−( is defined as follows:

S (−R −−−−−( P −) Q ≡ S ⊆ R◦Q◦P˘

If S (−I −−−−−( B −) S holds, we say that S is restricted to B.

The type operator −−−−−( can actually be used for restricting the domain as well as therange:

S (−A −−−−−( B −) S ≡ S< ⊆ A ∧ S> ⊆ B

Another type operator that satisfies this property is )−−−−− , defined by

S (−R )−−−−− P −) Q ≡ Q˘ ⊆ P˘◦S˘◦R

For sets A and B we have

S (−A −−−−−( B −) S

≡S ∈ A )−−−( B

≡

S (−A )−−−−− B −) S

76

4.2.4 Combining type operators

By means of intersection, we can combine several type operators into one typeoperator. We write such a combined type operator as the combination of thesymbols of the type operators it combines. The type operator <−−−−−) is for exampledefined by

R <−−−−−) P = R <−−−−− P ∩ R −−−−−) P

Notice that with n type operators we can construct 2n combinations. The emptycombination is denoted by −−−−− , so R −−−−− P is equal to Π (the unit of ∩) for all Rand P .

4.2.5 Domain

We prefer to write the combined type operator −−−−−)( as −−−−−| . The formulaS (−I −−−−−| B −) S is equivalent to the fact that S has domain B:

S (−I −−−−−| B −) S ≡ S> = B

4.2.6 Bidirectional-type operator

The combined type operator )−−−−−( is called the bidirectional-type operator.We leave it to the reader to verify that A )−−−−−( B is a set for sets A and B and thatits definition matches the one of A )−−−( B given in section 3.1.21:

A )−−−−−( B = A )−−−( B

4.2.7 Set-preservingness

Applying the bidirectional-type operator to a pair of sets, results in a set. A typeoperator satisfying this property is called set-preserving. Not all type operatorsthat we introduced are set-preserving. For the cylindric-type operator we have forexample:

S (−I −−−−−◦ I−) Q ≡ S ⊆ Q

or point free:

I −−−−−◦ I = ⊆

The relation ⊆ is not a set. So, for sets A and B, A −−−−−◦ B is not a set in gen-eral. One could think that this is not really a problem because S (−A −−−−−◦ B −) S stillmeans that if S inputs an element of type B, it outputs an element of type A.

77

We would also ‘desire’ however that for sets A, B and C, S (−(A −−−−−◦ B) −−−−−◦ C −) Smeans that if S inputs an element of type C, it outputs a relation of type A −−−−−◦ Band S (−A −−−−−◦ (B −−−−−◦ C)−) S means that if S inputs a relation of type B −−−−−◦ C, itoutputs an element of type A. The first case turns out to be true. A more generalcase is proved in section 4.4.6. The latter case does not hold in general however.This is easy to see if we fill in I for A, B and C. The ‘desired’ interpretation ofS (−I −−−−−◦ (I −−−−−◦ I)−) S would be that if S inputs a relation of type I −−−−−◦ I, it outputsan element of type I. This is equivalent to true. However,

S (−I −−−−−◦ (I −−−−−◦ I)−) S

≡ {definition of −−−−−◦}S ◦(I −−−−−◦ I) ⊆ I◦S

≡ {I −−−−−◦ I = ⊆ and I is unit of ◦}S ◦⊆ ⊆ S

which is not equivalent to true for every S (take for example S = I).

To solve this ‘problem’ that type formulas do not always mean what we ‘desire’them to mean, we define the type operator −−− by

R −−− P = I

We call this type operator the set-forcer. If we combine this type operator with−−−−−◦ in the way described in section 4.2.4, we obtain the type operator −−−◦ . The

formula S ∈ A −−−◦ (B −−−◦ C) does have the ‘desired’ interpretation that S outputsan element of type A if it inputs a relation of type B −−−◦ C. The fact that we getthe ‘desired’ interpretation for type formulas that use set-forced type operators, isa trivial consequence of the fact that we designed each operator ⊙−−−−−�• such thatS (−A ⊙−−−−−�• B −) S had the ‘desired’ interpretation for sets A and B, combined withthe fact that A ⊙−−−�• B is the set satisfying

S ∈ A ⊙−−−�• B ≡ S (−A ⊙−−−−−�• B −) S

As mentioned in section 4.2.6, )−−−−−( does not necessarily have to be set-forced becauseA )−−−−−( B is already a set for sets A and B.

4.2.8 Extensibility

A set-preserving type operator ⊙−−−−−�• is extensible if it does not impose any re-strictions on a relation for input elements that are not element of the input type:

⊙−−−−−�• is extensible

≡∀〈A, B, S, X || S ∈ A ⊙−−−−−�• B || S ◦B ∪ X ◦(IrB) ∈ A ⊙−−−−−�• B〉

78

The type operators −−−◦, <−−−, −−−) and all their combinations (as defined in section4.2.4) are extensible. The type operator )−−−( is not extensible however.

4.2.9 Type diagrams

An insightful way to present type formulas, is by means of a type diagram. Thisis a graph where nodes represent sets and edges represent (set-preserving) typeoperators. We write the elements that are being typed above their correspondingtype operator. The typing

R ∈ A −−−◦ B ∧ S ∈ B )−−−( C ∧ T ∈ D )−−−( C ∧ U ∈ A−−−◦ D

is for example represented by the type diagram

C

B)S (

D

)

T (

A

U ©©

R

Type diagrams express a little more than suggested by the above example. Theexternal type associated with a node is fixed. The type diagram

A )R

( I )S

( B

expresses not only that

R ∈ A )−−−( I ∧ S ∈ I )−−−( B

but also that the inputs of R have the same external type as the outputs of S.Without the type diagram, this would be apparent from the fact that we somewhereuse a formula like R◦S.

4.2.10 Twelve type operators

If we take a close look at the five non-combined type operators we have defined sofar:

79

S (−R −−−−−◦ P −) Q ≡ S ◦P ⊆ R◦QS (−R <−−−−− P −) Q ≡ S ◦P ◦Q˘ ⊆ RS (−R −−−−−) P −) Q ≡ P ⊆ S˘◦R◦QS (−R −−−−−( P −) Q ≡ S ⊆ R◦Q◦P˘S (−R )−−−−− P −) Q ≡ Q˘ ⊆ P˘◦S˘◦R

we see that each of them can be obtained from the others by ‘shunting’ a little. Atable of twelve type operators can be obtained by ‘shunting’ a little more:

S (−R <−−−−− P −) Q ≡ S ◦P ◦Q˘ ⊆ RS (−R >−−−−− P −) Q ≡ R˘◦S ◦P ⊆ QS (−R −−−−−> P −) Q ≡ Q˘◦R˘◦S ⊆ P˘S (−R −−−−−< P −) Q ≡ P ◦Q˘◦R˘ ⊆ S˘

S (−R −−−−−◦ P −) Q ≡ S ◦P ⊆ R◦QS (−R −−−−−� P −) Q ≡ R˘◦S ⊆ Q◦P˘S (−R �−−−−− P −) Q ≡ Q˘◦R˘ ⊆ P˘◦S˘S (−R ◦−−−−− P −) Q ≡ P ◦Q˘ ⊆ S˘◦R

S (−R −−−−−) P −) Q ≡ P ⊆ S˘◦R◦QS (−R −−−−−( P −) Q ≡ S ⊆ R◦Q◦P˘S (−R (−−−−− P −) Q ≡ R˘ ⊆ Q◦P˘◦S˘S (−R )−−−−− P −) Q ≡ Q˘ ⊆ P˘◦S˘◦R

A property that these equations share, is that the external type of the inputs of Sis equal to the external type of the outputs of P , the external type of the inputs ofP is equal to the external type of the inputs of Q, the external type of the outputsof Q is equal to the external type of the inputs of R and the external type of theoutputs of R is equal to the external type of the outputs of S. The following typediagrams give an overview of the above definitions:

80

I

I )

P(

I

) Q˘(

I )

R()

S (

I

I )

P(

I

)

Q (

I )

R˘

()

S (

I

I )

P˘

(

I

) Q˘(

I )

R˘

()

S (

I

I )

P(

I

) Q˘(

I )

R˘

() S˘(

<−−−−− >−−−−− −−−−−> −−−−−<

I

I )

P(

I

)

Q (

I )

R()

S (

I

I )

P˘

(

I

)

Q (

I )

R˘

()

S (

I

I )

P˘

(

I

) Q˘(

I )

R˘

() S˘

(

I

I )

P(

I

) Q˘(

I )

R() S˘

(

−−−−−◦ −−−−−� �−−−−− ◦−−−−−

I

I )

P(

I

)

Q (

I )

R() S˘

(

I

I )

P˘

(

I

)

Q (

I )

R()

S (

I

I )

P˘

(

I

)

Q (

I )

R˘

() S˘

(

I

I )

P˘

(

I

) Q˘(

I )

R() S˘

(

−−−−−) −−−−−( (−−−−− )−−−−−

These type diagrams are not definitions of the type operators. For that we needsemi-commutative diagrams as described in for example [11].

There exist various interesting correspondences between these twelve type operators,some of which are reflected by their symbols. For each group of four type operators,we have for example that the substitution

S, R, P, Q := R , Q, S, P˘

gives the next type operator in the group. In particular, after two steps we get the‘mirrored’ version of a type operator, for example:

S (−R <−−−−− P −) Q ≡ Q˘(−P˘ −−−−−> R˘−) S˘

For sets A and B we have

S ∈ A <−−− B ≡ S˘ ∈ B −−−> A

The shunting theorems give us that the definitions of −−−−−◦, <−−−−−, −−−−−) and ◦−−−−− areequivalent if S and Q are total functions. The first three of these four type operatorsplay a main role in our theory. They allow us to express upper-range, functionalityand totality in an extensible manner, as mentioned in section 4.2.8.

81

4.3 Type-generalising some other concepts

In the previous section we generalised functionality and totality such that an inputtype and an output type were included. In this section we generalise some otherconcepts in a similar manner.


A relation S is empty on B if it is empty in every element of B, or equivalentlyS ◦B = ©�. A relation S is full on B if it is full in every element of B, or equivalentlyS ◦B = Π◦B.

4.3.2 Reflexivity

For a set A, a relation S is A-reflexive if A is a subrelation of S:

A ⊆ S

A relation that is A-reflexive and transitive is called an A-preorder and an anti-symmetric A-preorder is called an A–partial-order.

4.3.3 Shunting

The shunting theorems that we introduced in section 3.8.1 can be generalised fromtotal functions to relations that only need to be single-valued on a certain set. Forg ∈ I <−−−) S< and h ∈ I <−−−) S> we have

S ⊆ g˘◦R◦h ≡ g◦S ◦h˘ ⊆ R

or equivalently:

S ⊆ g˘◦R◦h ≡ S ⊆ g\R/h˘

For g ∈ I <−−− {y} and h ∈ I <−−− {z} we have

y (−g˘◦R◦h−) z ≡ y ∈ g> ∧ g.y (−R−) h.z ∧ z ∈ h>

y (−g\R/h˘−) z ≡ y ∈ g> ⇒ g.y (−R−) h.z ⇐ z ∈ h>

In particular, for g ∈ I <−−−) {y} and h ∈ I <−−−) {z} we have

y (−g˘◦R◦h−) z ≡ g.y (−R−) h.zy (−g\R/h˘−) z ≡ g.y (−R−) h.z

and for sets A and B we have

82

y (−A◦R◦B −) z ≡ y ∈ A ∧ y (−R−) z ∧ z ∈ By (−A\R/B −) z ≡ y ∈ A ⇒ y (−R−) z ⇐ z ∈ B

The proofs of these theorems are left to the reader.

4.4 Properties of the cylindric-type operator

In this section we investigate some algebraic properties of the cylindric-type oper-ator.

4.4.1 Inclusion

We already mentioned that −−−−−◦ is monotonic in its output type. If we take a non-empty relation as input type, we can strengthen monotonicity to monomorphity:

R ⊆ T

≡ {• P is non-empty}R −−−−−◦ P ⊆ T −−−−−◦ P

proof

R ⊆ T

⇒ {monotonicity of (−−−−−◦ P )}R −−−−−◦ P ⊆ T −−−−−◦ P

≡ {definition of ⊆ and −−−−−◦}∀〈S, Q ||

|| S ◦P ⊆ R◦Q ⇒ S ◦P ⊆ T ◦Q〉

⇒ {take S = {y}◦Π and Q = {z}◦Π}∀〈y, z ||

|| {y}◦Π◦P ⊆ R◦{z}◦Π ⇒ {y}◦Π◦P ⊆ T ◦{z}◦Π〉

≡ {shunting, {z}◦Π is a total function and ({z}◦Π)˘ = Π◦{z}}∀〈y, z ||

|| {y}◦Π◦P ◦Π◦{z} ⊆ R ⇒ {y}◦Π◦P ◦Π◦{z} ⊆ T 〉

≡ {• P is non-empty, then Π◦P ◦Π = Π}∀〈y, z ||

|| {y}◦Π◦{z} ⊆ R ⇒ {y}◦Π◦{z} ⊆ T 〉

≡ {{y}◦Π◦{z} ⊆ R ≡ y (−R−) z}∀〈y, z ||

|| y (−R−) z ⇒ y (−T −) z〉

≡ {definition of ⊆}R ⊆ T

4.4.2 Equality

Using the definition of equality in terms of inclusion, a trivial consequence of theinclusion theorem of the previous section is

83

R = T

≡ {• P is non-empty}R −−−−−◦ P = T −−−−−◦ P

4.4.3 Intersection

If we restrict the inputs to functions, (−−−−−◦ P ) distributes over the intersection:

Π◦(I <−−− I) ∩ (R∩T −−−−−◦ P )

=

Π◦(I <−−− I) ∩ (R −−−−−◦ P ∩ T −−−−−◦ P )

proof

S (−R∩T −−−−−◦ P −) Q

≡ {definition of −−−−−◦}S ◦P ⊆ (R∩T )◦Q

≡ {distribution of ◦ over ∩ for functions, • Q is a function}S ◦P ⊆ R◦Q ∩ T ◦Q

≡ {point-free definition of ∩}S ◦P ⊆ R◦Q ∧ S ◦P ⊆ T ◦Q

≡ {definition of −−−−−◦}S (−R −−−−−◦ P −) Q ∧ S (−T −−−−−◦ P −) Q

≡ {point-wise definition of ∩}S (−R −−−−−◦ P ∩ T −−−−−◦ P −) Q

4.4.4 Union

If we restrict the outputs to functions, then for all relations P with a unique con-nection, (−−−−−◦ P ) distributes over the union:

(I <−−− I)◦Π ∩ (R∪T −−−−−◦ P )

= {• P has a unique connection}(I <−−− I)◦Π ∩ (R −−−−−◦ P ∪ T −−−−−◦ P )

proof

84

S (−R∪T −−−−−◦ P −) Q

≡ {definition of −−−−−◦}S ◦P ⊆ (R∪T )◦Q

≡ {distribution of ◦ over ∪}S ◦P ⊆ R◦Q ∪ T ◦Q

≡ {S ◦P has a unique connection if • S is functional and • P has a unique connection}S ◦P ⊆ R◦Q ∨ S ◦P ⊆ T ◦Q

≡ {definition of −−−−−◦}S (−R −−−−−◦ P −) Q ∨ S (−T −−−−−◦ P −) Q

≡ {point-wise definition of ∪}S (−R −−−−−◦ P ∪ T −−−−−◦ P −) Q


For all sets P , (−−−−−◦ P ) distributes over the sequential composition:

R◦T −−−−−◦ P

= {• P is a set}(R −−−−−◦ P ) ◦ (T −−−−−◦ P )

proof

S (−R◦T −−−−−◦ P −) Q

≡ {definition of −−−−−◦}S ◦P ⊆ R◦T ◦Q

≡ {• P is a set, then (⇒): take X = T ◦Q, (⇐): S ◦P ⊆ U ≡ S ◦P ⊆ U ◦P }∃〈X |||| S ◦P ⊆ R◦X ∧ X ◦P ⊆ T ◦Q〉

≡ {definition of −−−−−◦}∃〈X |||| S (−R −−−−−◦ P −) X ∧ X (−T −−−−−◦ P −) Q〉

≡ {definition of ◦}S (−(R −−−−−◦ P ) ◦ (T −−−−−◦ P )−) Q


In section 4.2.7 we saw that for sets A and B, A −−−−−◦ B is not a set in general. Inthis section we search for properties that provide a little compensation. When weintroduced −−− in section 4.2.7, we remarked that although A −−−−−◦ B is not a set,for a set C, S (−(A −−−−−◦ B) −−−−−◦ C −) S still had the desired interpretation:

S (−(A −−−−−◦ B) −−−−−◦ C −) S ≡ S ∈ (A −−−◦ B) −−−◦ C

85

Stated otherwise:

(A −−−−−◦ B) −−−◦ C = (A −−−◦ B) −−−◦ C

The general case

(. . . ((A −−−−−◦ B0) −−−−−◦ B1) . . .) −−−◦ Bn

=

(. . . ((A −−−◦ B0)−−−◦ B1) . . .) −−−◦ Bn

can be proved if we find a set of relations W such that for all sets B

R ∈ ℘I ⇒ R ∈ WR ∈ W ⇒ (R −−−−−◦ B) ∈ WR ∈ W ⇒ R −−−◦ B = R∩I−−−◦ B

We know that W = ℘I does not satisfy the second property, so we need to findanother W . We use the third property to try to find such a W . The ‘⊇’ even holdswithout any restrictions on R, so we should use the ‘⊆’ to find a proper restrictionon R. The following calculation indicates a valid restriction:

S (−R −−−−−◦ B −) S

≡ {definition of −−−−−◦}S ◦B ⊆ R◦S

⇒ {S ⊆ Π}S ◦B ⊆ R◦Π

≡ {R◦Π = R<◦Π}S ◦B ⊆ R<◦Π

≡ {• R< = R∩I}S ◦B ⊆ (R∩I)◦Π

≡ {S ◦B ⊆ A◦Π ≡ S ◦B ⊆ A◦S for sets A and B}S ◦B ⊆ (R∩I)◦S

≡ {point-wise definition of −−−−−◦}S (−R∩I −−−−−◦ B −) S

For the ‘•’ in this calculation we have:

R< = R∩I

≡ {R< ⊇ R∩I}R< ⊆ R∩I

≡ {R< ⊆ I}R< ⊆ R

86

So, if we choose W to be the set Rno (range owning), defined by

R ∈ Rno ≡ R< ⊆ R

we can prove the third property. We now have to prove that W satisfies the firstand the second property. The proof of the first property is trivial. For the proof ofthe second property we use the following point-wise formulation of the definition ofRno, the proof of which is left to the reader:

R ∈ Rno ≡ ∀〈y, z || y (−R−) z || y (−R−) y〉

Using the point-free formulation of R ∈ Rno for its first occurrence in the secondproperty and this point-wise formulation for its second occurrence, we thus have toprove that

R< ⊆ R ⇒ ∀〈S, Q || S (−R −−−−−◦ B −) Q || S (−R −−−−−◦ B −) S〉

For a set B we calculate

S (−R −−−−−◦ B −) Q

≡ {point-wise definition of −−−−−◦}S ◦B ⊆ R◦Q

⇒ {Q ⊆ Π}S ◦B ⊆ R◦Π

≡ {R◦Π = R<◦Π}S ◦B ⊆ R<◦Π

≡ {S ◦B ⊆ A◦Π ≡ S ◦B ⊆ A◦S for sets A and B}S ◦B ⊆ R<◦S

⇒ {• R< ⊆ R}S ◦B ⊆ R◦S

≡ {point-wise definition of −−−−−◦}S (−R −−−−−◦ B −) S

So, the set Rno satisfies all three properties, thus proving that ‘as long as we usethe cylindric-type operator in the output type, everything goes well’.

Summarising the results, we have that for a set P , (−−−−−◦ P ) preserves Rno:

R ∈ Rno

⇒ {• P is a set}(R −−−−−◦ P ) ∈ Rno

and is what we call diagonal preserving:

87

(R∩I −−−−−◦ P ) ∩ I

= {• P is a set and • R ∈ Rno}(R −−−−−◦ P ) ∩ I

4.4.7 Converse

For all sets P , (−−−−−◦ P ) commutes with the converse if we restrict to connectionsbetween functions with equal domains:

(I <−−− I)◦DEQ ◦(I <−−− I) ∩ (R˘ −−−−−◦ P )

= {• P is a set}(I <−−− I)◦DEQ ◦(I <−−− I) ∩ (R −−−−−◦ P )˘

proof

S (−R˘ −−−−−◦ P −) Q

≡ {definition of −−−−−◦}S ◦P ⊆ R˘◦Q

≡ {shunting, • Q ∈ I <−−− I, • S> ⊆ Q> and • P is a set}S ◦P ◦Q˘ ⊆ R˘

≡ {shunting, • S ∈ I <−−− I, • Q> ⊆ S> and • P is a set}P ◦Q˘ ⊆ S˘◦R˘

≡ {• P is symmetric}P˘◦Q˘ ⊆ S˘◦R˘

≡ {Y ˘◦X˘ = (X ◦Y ) }(Q◦P )˘ ⊆ (R◦S)˘

≡ {X˘ ⊆ Y ˘ ≡ X ⊆ Y }Q◦P ⊆ R◦S

≡ {definition of −−−−−◦}Q (−R −−−−−◦ P −) S

≡ {point-wise definition of }S (−(R −−−−−◦ P )˘−) Q

4.5 Conclusions

In this chapter we introduced a rich collection of type operators that enable us toexpress some important properties of relations in a clear and concise manner. Wepaid special attention to the cylindric-type operator that generalises the traditionalco/contra-variant typing of functional programming. The main reason for our in-terest in this type operator is that it is extensible. Extensibility is an importantconcept in the context of object-oriented programming. For our purposes, it is

88

more important than the fact that the cylindric type operator has some ‘algebraicconflicts’ with the identity (I −−−−−◦ I 6= I) and the converse (R ∈ A−−−◦ B does notimply R˘ ∈ B −−−◦ A in general).

89

Chapter 5

Products

Products provide a means to combine information into packages that satisfy usefulalgebraic laws. In this chapter we introduce and investigate several different prod-ucts. Products are used in chapter 6 for the construction of a model for expressionsand in chapter 7 for the hierarchical structuring of procedures.

5.1 Cylindric product

In allegory theory [11], the product R0 × R1 of two relations R0 and R1 is definedby postulating the existence of two projection functions exl and exr that satisfythe following properties (the set I × I is assumed to be already defined):

exl ◦ exr˘ = Π

exl˘◦exl ∩ exr˘◦exr = I × I

and stating that

R0 × R1 = exl˘◦R0◦exl ∩ exr˘◦R1◦exr

The binary cartesian product × is a construct of this kind. The projectionfunctions exl and exr are ex©0 and ex©1 respectively, defined by

ex i = (.i) ◦ (I <−−−| 2)

The set I <−−−| 2, that is equal to I×I, constrains the input to pairs and the section(.i) yields their output for input i. For f ∈ I <−−−| 2 and i ∈ 2 we thus have

ex i.f = f.i

91

We now show a reformulation of the allegoric definition of the binary cartesianproduct that gives rise to one of the main constructs of this thesis. We start withthe lemma that is the core of this reformulation:

For g, h ∈ I <−−−) {i} we have

g (−(.i)˘◦R◦(.i)−) h ≡ g (−R −−−−−◦ {i}−) h

proof

Assume g, h ∈ I <−−−) {i}.

g (−(.i)˘◦R◦(.i)−) h

≡ {shunting}g.i (−R−) h.i

≡ {shunting}i (−g˘◦R◦h−) i

≡ {i (−R−) i ≡ {i} ⊆ R}{i} ⊆ g˘◦R◦h

≡ {shunting}g◦{i} ⊆ R◦h

≡ {definition of −−−−−◦}g (−R −−−−−◦ {i}−) h

Using this lemma, we can reformulate the allegoric definition of the cartesian prod-uct as follows:

R0 × R1

= {allegoric definition}ex©0 ˘◦R0◦ex©0 ∩ ex©1 ˘◦R1◦ex©1

= {definition of ex i}((I <−−−| 2) ◦ (.©0 )˘ ◦ R0 ◦ (.©0 ) ◦ (I <−−−| 2)) ∩((I <−−−| 2) ◦ (.©1 )˘ ◦ R1 ◦ (.©1 ) ◦ (I <−−−| 2))

= {use the lemma, I <−−−| 2 ⊆ I <−−−) {i} for i ∈ 2}((I <−−−| 2) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| 2)) ∩((I <−−−| 2) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| 2))

= {distribution of ◦ over ∩ for sets}(I <−−−| 2) ◦ (R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 }) ◦ (I <−−−| 2)

We now see that the binary cartesian product is a constrained version of a constructthat we shall call the binary cylindric product. The binary cylindric product⊗ ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| (I )−−−( I)×(I )−−−( I) is defined by

R0 ⊗ R1 = (R0 −−−−−◦ {©0 }) ∩ (R1 −−−−−◦ {©1 })

92

The binary cartesian product can be expressed in terms of the cylindric product asfollows:

R0 × R1 = (I <−−−| 2) ◦ R0⊗R1 ◦ (I <−−−| 2)

Another basic construct in allegory theory is the sum R0 + R1 of two relationsR0 and R1. This construct is defined by postulating the existence of two injectionfunctions inl and inr that satisfy the following properties (the set I + I is assumedto be already defined):

inl˘ ◦ inr = ©�

inl˘ ◦ inl = Iinr˘ ◦ inr = I

inl ◦inl˘ ∪ inr ◦inr˘ = I + I

and stating that

R0 + R1 = inl ◦R0◦inl˘ ∪ inr ◦R1◦inr˘

The binary cartesian sum + is a construct of this kind. An element x taggedwith an i, is modeled as [(x, i)]. Notice that I <−−−| {i} is the set of all elements thatare tagged with i. The injection functions inl and inr are in©0 and in©1 respectively,defined by

ini = (I <−−−| {i}) ◦ (.i)˘

or point-wise:

ini.x = [(x, i)]

We now show that the cartesian sum is also a constrained version of the cylindricproduct:

R0 + R1

=

((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ◦ R0⊗R1 ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))

At first sight the proof may look complicated because of the big terms involved, butit is rather straightforward:

93

((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ◦ R0⊗R1 ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))= {definition of ⊗}

((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ◦ (R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 }) ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))

= {distribution of ◦ over ∩ for sets}((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ◦ (R0 −−−−−◦ {©0 }) ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ∩((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ◦ (R1 −−−−−◦ {©1 }) ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))

= {distribution of ◦ over ∪}

(I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∪(I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©1 }) ∪(I <−−−| {©1 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∪(I <−−−| {©1 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©1 })

∩

(I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ∪(I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©0 }) ∪(I <−−−| {©0 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ∪(I <−−−| {©0 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©0 })

= {left to the reader}

(I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∪©� ∪

(I <−−−| {©1 }) ◦ Π ◦ (I <−−−| {©0 }) ∪(I <−−−| {©1 }) ◦ Π ◦ (I <−−−| {©1 })

∩

(I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ∪©� ∪

(I <−−−| {©0 }) ◦ Π ◦ (I <−−−| {©1 }) ∪(I <−−−| {©0 }) ◦ Π ◦ (I <−−−| {©0 })

= {©� is unit of ∪, distribution of ◦ over ∪}(

(I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∪(I <−−−| {©1 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))

)

∩(

(I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ∪(I <−−−| {©0 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))

)

= {distribution of ∩ over ∪}((I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∩ (I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ) ∪((I <−−−| {©0 }) ◦ (R0 −−−−−◦ {©0 }) ◦ (I <−−−| {©0 }) ∩ (I <−−−| {©0 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))) ∪((I <−−−| {©1 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ∩ (I <−−−| {©1 }) ◦ (R1 −−−−−◦ {©1 }) ◦ (I <−−−| {©1 }) ) ∪((I <−−−| {©1 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 })) ∩ (I <−−−| {©0 }) ◦ Π ◦ ((I <−−−| {©0 }) ∪ (I <−−−| {©1 })))

= {A◦R ∩ B ◦S = ©� for disjoint sets A and BR ∩ A◦Π◦B = A◦R◦B for sets A and B}

(I <−−−| {©0 })◦(R0 −−−−−◦ {©0 })◦(I <−−−| {©0 }) ∪ (I <−−−| {©1 })◦(R1 −−−−−◦ {©1 })◦(I <−−−| {©1 })

= {use the lemma from the beginning of this section, I <−−−| {i} ⊆ I <−−−) {i}}(I <−−−| {©0 })◦(.©0 )˘◦R0◦(.©0 )◦(I <−−−| {©0 }) ∪ (I <−−−| {©1 })◦(.©1 )˘◦R1◦(.©1 )◦(I <−−−| {©1 })

= {definition of in i}in©0 ◦R0◦in©0 ˘ ∪ in©1 ◦R1◦in©1 ˘

= {allegoric definition of +}R0 + R1

So we see that both the cartesian product and the cartesian sum are constrainedforms of the cylindric product. In the next section we introduce several otherconstrained forms.

5.2 Constrained cylindric products

The binary M-constrained cylindric product ⊗M ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−|(I )−−−( I)×(I )−−−( I) is defined by

R0 ⊗M R1 = R0⊗R1 ∩ M

The constraints M we investigate, are combinations of the constraints UNI , FUN ,NMP , DEQ , TOTB and RESB (for a set B), defined by

94

S (−UNI −) Q ≡ S and Q both have a unique inputS (−FUN −) Q ≡ S and Q are functionalS (−NMP −) Q ≡ S and Q are non-emptyS (−DEQ −) Q ≡ S and Q are domain equalS (−TOTB −) Q ≡ S and Q are total on BS (−RESB −) Q ≡ S and Q are restricted to B

Notice that all constraints except DEQ are squares (see section 3.4.4 for the defini-tion of squares).

The cartesian product and sum are obtained as follows:

R0 × R1 = R0 ⊗FUN ∩TOT 2∩RES 2R1

R0 + R1 = R0 ⊗UNI ∩FUN ∩NMP∩RES 2R1

This is a straightforward result of the fact that

(I <−−−| 2)◦Π◦(I <−−−| 2)

=

FUN ∩TOT 2∩RES 2

and

((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))◦Π◦((I <−−−| {©0 }) ∪ (I <−−−| {©1 }))=

UNI ∩FUN ∩NMP∩RES 2

Adding DEQ makes no difference in these two cases:

R0 × R1 = R0 ⊗FUN ∩DEQ∩TOT 2∩RES 2R1

R0 + R1 = R0 ⊗UNI ∩FUN ∩NMP∩DEQ∩RES 2R1

For × this holds because TOT 2∩RES 2 ⊆ DEQ .

For + it holds because

S (−UNI ∩NMP∩RES 2 −) Q ∧ S (−R0 ⊗ R1−) Q

⇒S and Q are domain equal

The proof of this is left to the reader.

Because TOT 2 ⊆ NMP , we also have

R0 × R1 = R0 ⊗FUN ∩NMP∩TOT 2∩RES 2R1

R0 × R1 = R0 ⊗FUN ∩NMP∩DEQ∩TOT 2∩RES 2R1

95

Because we need the constraint from + more often, we introduce a shorthand forit, where we generalise RES 2 to RESB for an arbitrary set B:

TAGB = UNI ∩ FUN ∩ NMP ∩ DEQ ∩ RESB

or equivalently:

TAGB =⋃{(I <−−−| {i}) ◦ Π ◦ (I <−−−| {i}) | i ∈ B | i}

So,

R0 + R1 = R0 ⊗TAG 2R1

Before we investigate the properties of the binary M -constrained cylindric product,we first introduce two related operators.

5.3 Constrained cylindric packs

In the previous chapter we proved several properties of (−−−−−◦ P ). For most of theseproperties we imposed a restriction on P , like “P is a set” in section 4.4.7. The onlyP s that satisfy all these restrictions are sets with a single element, called singletonsets. Next to the restrictions on P , we also encountered some restrictions on theinputs and outputs, like “(I <−−− I)◦DEQ ◦(I <−−− I)” in section 4.4.7. These two factssuggest the introduction of an operator that we call the M-constrained cylindricpack ©⊳ M ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| (I )−−−( I)×I, defined by

R©⊳ Mi = (R −−−−−◦ {i}) ∩ M

Using this operator, ⊗M can also be defined equivalently by

R0 ⊗M R1 = R0©⊳ M©0 ∩ R1©⊳ M©1

The cylindric pack puts a relation in a package, attaching a certain tag to it. Thepick ⊲ ∈ (I )−−−( I) <−−−| ((I )−−−( I) )−−−( (I )−−−( I))×I retrieves a relation with a certaintag from a package. It is defined by

y (−X⊲i−) z ≡ [(y, i)] (−X −) [(z, i)]

or point free:

X⊲i = in i˘ ◦ X ◦ in i

or equivalently by (see section 3.8.1 about shunting)

X⊲i = in i \ X / in i˘

96

The pick satisfies some useful algebraic properties that follow from the fact that (⊲i)is both a lower adjoint and an upper adjoint (see section 3.5 about Galois connec-tions). If we define the operators ⊲♯ , ⊲♭ ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| (I )−−−( I)×Iby

R⊲♯i = ini˘ \ R / in i

R⊲♭i = ini ◦ R ◦ ini˘

then (⊲♯i) is the upper and (⊲♭i) the lower adjoint of (⊲i):

X⊲i ⊆ R ≡ X ⊆ R⊲♯iR⊲♭i ⊆ X ≡ R ⊆ X⊲i

This is a trivial result of the point-free definitions of \ and / and the above twopoint-free definitions of ⊲.

The theory of Galois connections now gives us for free that (⊲i), (⊲♯i) and (⊲♭i) areall monotonic:

X ⊆ Y ⇒ X⊲i ⊆ Y ⊲iR ⊆ T ⇒ R⊲♯i ⊆ T⊲♯iR ⊆ T ⇒ R⊲♭i ⊆ T⊲♭i

and that (⊲♯i) distributes over⋂

, that (⊲♭i) distributes over⋃

and that (⊲i) dis-tributes over both, specifically:

Π ⊲ i = Π©� ⊲ i = ©�U∩V ⊲ i = U⊲i ∩ V ⊲iU∪V ⊲ i = U⊲i ∪ V ⊲i

Π ⊲♯ i = Π©� ⊲♭ i = ©�R∩T ⊲♯ i = R⊲♯i ∩ R⊲♯iR∪T ⊲♭ i = T⊲♭i ∪ T⊲♭i

Furthermore, the following cancellation laws hold (the equalities hold because (⊲i)is surjective):

R⊲♯i ⊲ i = R ∧ X ⊆ X⊲i ⊲♯ iR⊲♭i ⊲ i = R ∧ X ⊇ X⊲i ⊲♭ i

We now show how ⊲♯ and ⊲♭ can be defined in terms of −−−−−◦, to focus on their

relationship with ©⊳ M :

R⊲♯i = (I <−−−| {i}) \ (R −−−−−◦ {i}) / (I <−−−| {i})R⊲♭i = (I <−−−| {i}) ◦ (R −−−−−◦ {i}) ◦ (I <−−−| {i})

Using the ‘core lemma’ of section 5.1, the proof of this is rather straightforward andleft to the reader.

Making use of the fact that for sets A and B

97

A\R/B = R ⊂= A◦Π◦BA◦R◦B = R ∩ A◦Π◦B

we can write this equivalently as

R⊲♯i = (R −−−−−◦ {i}) ⊂= TAG{i}R⊲♭i = (R −−−−−◦ {i}) ∩ TAG{i}

A trivial consequence is

R©⊳ Mi ⊆ R⊲♯iR©⊳ Mi ⊇ R⊲♭i ⇐ TAG{i} ⊆ M

which gives us the following cancellation law:

R©⊳ Mi ⊲ i

= {• TAG{i} ⊆ M}R

proof

R©⊳ Mi ⊲ i

⊆ {monotonicity of (⊲i), R©⊳ Mi ⊆ R⊲♯i}R⊲♯i ⊲ i

= {cancellation}R

= {cancellation}

R⊲♭i ⊲ i

⊆ {monotonicity of (⊲i), R⊲♭i ⊆ R©⊳ Mi if • TAG{i} ⊆ M}R©⊳ Mi ⊲ i

We can use the following theorem in case the pack and pick use different tags:

R©⊳ Mj ⊲ i

= {• TAG{i} ⊆ M ∧ j 6= i}Π

proof

98

y (−R©⊳ Mj ⊲ i−) z

≡ {point-wise definition of ⊲}[(y, i)] (−R©⊳ Mj −) [(z, i)]

≡ {definition of R©⊳ Mj}[(y, i)] (−(R −−−−−◦ {j}) ∩ M −) [(z, i)]

≡ {point-wise definition of ∩}[(y, i)] (−R −−−−−◦ {j}−) [(z, i)] ∧ [(y, i)] (−M −) [(z, i)]

≡ {point-wise definition of −−−−−◦}[(y, i)]◦{j} ⊆ R◦[(z, i)] ∧ [(y, i)] (−M −) [(z, i)]

≡ {• j 6= i, then [(y, i)]◦{j} = ©�}[(y, i)] (−M −) [(z, i)]

≡ {• TAG{i} ⊆ M}true

≡ {point-wise definition of Π}y (−Π−) z

We also refer to this theorem as “cancellation”.

Because (−−−−−◦ P ) and (∩M) are monotonic, (©⊳ Mi) is also monotonic:

R ⊆ T ⇒ R©⊳ Mi ⊆ T©⊳ Mi

If we add the restriction that TAG{i} ⊆ M , we can strengthen it to monomorphity:

R ⊆ T

≡ {• TAG{i} ⊆ M}R©⊳ Mi ⊆ T©⊳ Mi

proof

R ⊆ T

⇒ {monotonicity of (©⊳ Mi)}R©⊳ Mi ⊆ T©⊳ Mi

⇒ {monotonicity of ⊲i}R©⊳ Mi ⊲ i ⊆ T©⊳ Mi ⊲ i

≡ {cancellation, • TAG{i} ⊆ M}R ⊆ T

A trivial consequence is

R = T

≡ {• TAG{i} ⊆ M}R©⊳ Mi = T©⊳ Mi

99

5.4 Properties of the binary constrained cylindricproducts

In the previous section we proved some properties of the pick and the M -constrainedcylindric pack. In this section we use these properties and the properties of thecylindric-type operator to prove properties of the binary M -constrained cylindricproduct.

5.4.1 Cancellation

The binary M -constrained cylindric product satisfies the following cancellation laws:

R0

= {• TAG{©0 } ⊆ M}R0⊗MR1 ⊲ ©0

R1

= {• TAG{©1 } ⊆ M}R0⊗MR1 ⊲ ©1

proof

We only prove one of them, the proof of the other is algebraically identical.

R0⊗MR1 ⊲ ©0= {definition of ⊗M in terms of ©⊳ M}

(R0©⊳ M©0 ∩ R1©⊳ M©1 ) ⊲ ©0= {distribution of (⊲i) over ∩}

R0©⊳ M©0 ⊲ ©0 ∩ R1©⊳ M©1 ⊲ ©0= {cancellation, • TAG{©0 } ⊆ M}

R0 ∩ Π

= {Π is unit of ∩}R0

If there exist functions f0 and f1 with appropriate domains, such that for all R0

and R1

f0.(R0⊗MR1) = R0

f1.(R0⊗MR1) = R1

then we call ⊗M information preserving.

The cartesian sum is for example information preserving: take f0 = (⊲©0 ) andf1 = (⊲©1 ). The cartesian product is however not information preserving. Forevery R we have

R×©� = ©�

100

and we cannot retrieve any information about R from ©�.

5.4.2 Inclusion

The binary M -constrained cylindric product is monotonic in both arguments. Thefollowing theorem shows that we may strengthen monotonicity to monomorphity ifTAG 2 ⊆ M holds:

R0 ⊆ T 0 ∧ R1 ⊆ T 1

≡ {• TAG 2 ⊆ M}R0 ⊗M R1 ⊆ T 0 ⊗M T 1

proof

R0 ⊆ T 0 ∧ R1 ⊆ T 1

⇒ {monotonicity of (©⊳ Mi)}R0©⊳ M©0 ⊆ T 0©⊳ M©0 ∧ R1©⊳ M©1 ⊆ T 1©⊳ M©1

⇒ {monotonicity of ∩}R0©⊳ M©0 ∩ R1©⊳ M©1 ⊆ T 0©⊳ M©0 ∩ T 1©⊳ M©1

≡ {definition of ⊗M in terms of ©⊳ M}R0 ⊗M R1 ⊆ T 0 ⊗M T 1

⇒ {monotonicity of (⊲i)}R0⊗MR1 ⊲ ©0 ⊆ T 0⊗MT 1 ⊲ ©0 ∧R0⊗MR1 ⊲ ©1 ⊆ T 0⊗MT 1 ⊲ ©1

≡ {cancellation, • TAG 2 ⊆ M}R0 ⊆ T 0 ∧ R1 ⊆ T 1

5.4.3 Equality

A trivial consequence of the theorem of the previous section is

R0 = T 0 ∧ R1 = T 1

≡ {• TAG 2 ⊆ M}R0 ⊗M R1 = T 0 ⊗M T 1

5.4.4 Intersection

The binary M -constrained cylindric product abides with the intersection if M re-stricts the inputs to functions:

101

R0∩T 0 ⊗M R1∩T 1

= {• M ⊆ Π◦(I <−−− I)}R0⊗MR1 ∩ T 0⊗MT 1

proof

R0∩T 0 ⊗M R1∩T 1

= {definition of ⊗M and ⊗}(R0∩T 0 −−−−−◦ {©0 }) ∩ (R1∩T 1 −−−−−◦ {©1 }) ∩ M

= {distribution of (−−−−−◦ {i}) over ∩, • M ⊆ Π◦(I <−−− I)}R0 −−−−−◦ {©0 } ∩ T 0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 } ∩ T 1 −−−−−◦ {©1 } ∩ M

= {idempotency, commutativity and associativity of ∩}R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 } ∩ M ∩ T 0 −−−−−◦ {©0 } ∩ T 1 −−−−−◦ {©1 } ∩ M

= {definition of ⊗ and ⊗M}R0⊗MR1 ∩ T 0⊗MT 1

5.4.5 Union

The binary M -constrained cylindric product distributes over the union if M restrictsthe output to functions:

R0∪T 0 ⊗M R1∪T 1

= {• M ⊆ (I <−−− I)◦Π}R0⊗MR1 ∪ R0⊗MT 1 ∪ T 0⊗MR1 ∪ T 0⊗MT 1

proof

R0∪T 0 ⊗M R1∪T 1

= {definition of ⊗M and ⊗}(R0∪T 0 −−−−−◦ {©0 } ∩ R1∪T 1 −−−−−◦ {©1 }) ∩ M

= {distribution of (−−−−−◦ {i}) over ∪, • M ⊆ (I <−−− I)◦Π}(R0 −−−−−◦ {©0 } ∪ T 0 −−−−−◦ {©0 }) ∩ (R1 −−−−−◦ {©1 } ∪ T 1 −−−−−◦ {©1 }) ∩ M

= {distribution of ∩ over ∪}((R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 }) ∪ (R0 −−−−−◦ {©0 } ∩ T 1 −−−−−◦ {©1 }) ∪(T 0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 }) ∪ (T 0 −−−−−◦ {©0 } ∩ T 1 −−−−−◦ {©1 })) ∩ M

= {distribution of ∩ over ∪}(R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 } ∩ M) ∪(R0 −−−−−◦ {©0 } ∩ T 1 −−−−−◦ {©1 } ∩ M) ∪(T 0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 } ∩ M) ∪(T 0 −−−−−◦ {©0 } ∩ T 1 −−−−−◦ {©1 } ∩ M)

= {definition of ⊗ and ⊗M}R0⊗MR1 ∪ R0⊗MT 1 ∪ T 0⊗MR1 ∪ T 0⊗MT 1

102


We now try to discover what restrictions on M are needed such that the binaryM -constrained cylindric product abides with the sequential composition:

R0◦T 0 ⊗M R1◦T 1

= {• some condition on M}R0⊗MR1 ◦ T 0⊗MT 1

A main insight was to use the axiom of choice (see section 3.1.26). We repeat ithere for ease of reference. For p ∈ B <−−−| I and q ∈ B <−−−| I×I we have

∀〈y || p.y || ∃〈z |||| q.〈y, z〉〉〉≡∃〈f || f ∈ I <−−−| {x | p.x | x} || ∀〈y || p.y || q.〈y, f.y〉〉〉

The axiom of choice is the core of the following theorem that we also refer to as“the axiom of choice”:

S ◦{i} ⊆ R◦U

≡∃〈f || f ∈ I <−−−| S◮i || f˘ ⊆ R ∧ S ◦{i} ⊆ f˘◦U〉

proof

103

S ◦{i} ⊆ R◦U

≡ {definition of ⊆}∀〈y, j || y (−S ◦{i}−) j || y (−R◦U −) j〉

≡ {y (−S ◦{i}−) j ⇒ j = i}∀〈y || y (−S −) i || y (−R◦U −) i〉

≡ {definition of ◦}∀〈y || y (−S −) i || ∃〈z |||| y (−R−) z ∧ z (−U −) i〉〉

≡ {axiom of choice, p.y ≡ y (−S −) i and q.〈y, z〉 ≡ y (−R−) z ∧ z (−U −) i, {x | x (−S −) i | x} = S◮i}∃〈f || f ∈ I <−−−| S◮i || ∀〈y || y (−S −) i || y (−R−) f.y ∧ f.y (−U −) i〉〉

≡

∃〈f || f ∈ I <−−−| S◮i ||∀〈y || y (−S −) i || y (−R−) f.y〉 ∧ ∀〈y || y (−S −) i || f.y (−U −) i〉〉

≡ {shunting}∃〈f || f ∈ I <−−−| S◮i ||∀〈y || y (−S −) i || y (−R◦f −) y〉 ∧ ∀〈y || y (−S −) i || y (−f˘◦U −) i〉〉

≡ {y (−S −) i ≡ y (−S◮i−) y}∃〈f || f ∈ I <−−−| S◮i ||∀〈y || y (−S◮i−) y || y (−R◦f −) y〉 ∧ ∀〈y || y (−S −) i || y (−f˘◦U −) i〉〉

≡ {y (−S◮i−) x ⇒ y = x, y (−S ◦{i}−) j ⇒ j = i}∃〈f || f ∈ I <−−−| S◮i ||∀〈y, x || y (−S◮i−) x || y (−R◦f −) x〉 ∧ ∀〈y, j || y (−S ◦{i}−) j || y (−f˘◦U −) j〉〉

≡ {definition of ⊆}∃〈f || f ∈ I <−−−| S◮i || S◮i ⊆ R◦f ∧ S ◦{i} ⊆ f˘◦U〉

≡ {shunting}∃〈f || f ∈ I <−−−| S◮i || f˘ ⊆ R ∧ S ◦{i} ⊆ f˘◦U〉

We now write out some definitions of operators in the composition-abide theoremto see how far we get:

S (−R0◦T 0 ⊗M R1◦T 1−) Q

≡ {definition of ⊗M , ∩, ⊗ and −−−−−◦}S (−M −) Q ∧ S ◦{©0 } ⊆ R0◦T 0◦Q ∧ S ◦{©1 } ⊆ R1◦T 1◦Q

≡ {• some condition on M , see below}∃〈K || S (−M −) K ∧ K (−M −) Q ||S ◦{©0 } ⊆ R0◦K ∧ S ◦{©1 } ⊆ R1◦K ∧K ◦{©0 } ⊆ T 0◦Q ∧ K ◦{©1 } ⊆ T 1◦Q〉

≡ {definition of −−−−−◦, ∩, ⊗ and ⊗M}∃〈K |||| S (−R0⊗MR1−) K ∧ K (−T 0⊗MT 1−) Q〉

≡ {definition of ◦}S (−R0⊗MR1 ◦ T 0⊗MT 1−) Q

We have to find conditions on M that enable us to do the second step in this

104

calculation. We start with the (⇐). We assume

S (−M −) K ∧ K (−M −) Q ∧S ◦{©0 } ⊆ R0◦K ∧ S ◦{©1 } ⊆ R1◦K ∧K ◦{©0 } ⊆ T 0◦Q ∧ K ◦{©1 } ⊆ T 1◦Q

and calculate:

S ◦{©0 } ⊆ R0◦T 0◦Q

⇐ {K ◦{©0 } ⊆ T 0◦Q}S ◦{©0 } ⊆ R0◦K ◦{©0 }

⇐ {S ◦{©0 } ⊆ R0◦K}S ◦{©0 } ⊆ S ◦{©0 }◦{©0 }

≡ {A◦A = A for sets A, reflexivity of ⊆}true

Same for S ◦{©1 } ⊆ R1◦T 1◦Q. For S (−M −) Q we calculate:

S (−M −) Q

⇐ {• M ◦M ⊆ M}S (−M ◦M −) Q

≡ {definition of ◦}∃〈X |||| S (−M −) X ∧ X (−M −) Q〉

≡ {take X = K}true

So for the (⇐) we found M ◦M ⊆ M as condition on M . Now for the (⇒):

S (−M −) Q ∧ S ◦{©0 } ⊆ R0◦T 0◦Q ∧ S ◦{©1 } ⊆ R1◦T 1◦Q

≡ {axiom of choice}S (−M −) Q ∧ ∃〈f0, f1

||||

f0 ∈ I <−−−| S◮©0 ∧ f0˘ ⊆ R0 ∧ S ◦{©0 } ⊆ f0˘◦T 0◦Q ∧f1 ∈ I <−−−| S◮©1 ∧ f1˘ ⊆ R1 ∧ S ◦{©1 } ⊆ f1˘◦T 1◦Q〉

⇒ {take K = f0◦S ◦{©0 } ∪ f1◦S ◦{©1 } ∪ k for some k ∈ I <−−−| (S>r2),• this step and the assumptions needed, are treated below}

∃〈K || S (−M −) K ∧ K (−M −) Q ||S ◦{©0 } ⊆ R0◦K ∧ S ◦{©1 } ⊆ R1◦K ∧K ◦{©0 } ⊆ T 0◦Q ∧ K ◦{©1 } ⊆ T 1◦Q〉

For the latter of these two steps, we first remark that the fact that for every Sthere exists a k ∈ I <−−−| (S>r2), is obviously true. We now prove this latter step.We assume

105

S (−M −) Q ∧f0 ∈ I <−−−| S◮©0 ∧ f0˘ ⊆ R0 ∧ S ◦{©0 } ⊆ f0˘◦T 0◦Q ∧f1 ∈ I <−−−| S◮©1 ∧ f1˘ ⊆ R1 ∧ S ◦{©1 } ⊆ f1˘◦T 1◦Q ∧k ∈ I <−−−| (S>r2) ∧K = f0◦S ◦{©0 } ∪ f1◦S ◦{©1 } ∪ k

and calculate

S ◦{©0 } ⊆ R0◦K

≡ {X ◦B ⊆ Y ≡ X ◦B ⊆ Y ◦B for sets B}S ◦{©0 } ⊆ R0◦K ◦{©0 }

≡ {K ◦{©0 } = f0◦S ◦{©0 }}S ◦{©0 } ⊆ R0◦f0◦S ◦{©0 }

≡ {X ◦B ⊆ Y ≡ X ◦B ⊆ Y ◦B for sets B}S ◦{©0 } ⊆ R0◦f0◦S

⇐ {f0˘ ⊆ R0}S ◦{©0 } ⊆ f0˘◦f0◦S

≡ {shunting, f0 ∈ I <−−−| S◮©0 }f0◦S ◦{©0 } ⊆ f0◦S

≡ {X ◦B ⊆ X for sets B}true

Same for S ◦{©1 } ⊆ R1◦K. Furthermore

K ◦{©0 } ⊆ T 0◦Q

≡ {K ◦{©0 } = f0◦S ◦{©0 }}f0◦S ◦{©0 } ⊆ T 0◦Q

≡ {shunting, f0 ∈ I <−−−| S◮©0 }S ◦{©0 } ⊆ f0˘◦T 0◦Q

≡ {assumption}true

Same for K ◦{©1 } ⊆ T 1◦Q.

The only thing that is left to prove is S (−M −) K ∧ K (−M −) Q. We need to find acondition on M that is independent of S, Q, f0, f1 and k. The condition that wechoose, is that for all S, Q, f0, f1, k and K (we use K actually just as a shorthand)

S (−M −) Q ⇒ S (−M −) K ∧ K (−M −) Q

⇐ {• K = f0◦S ◦{©0 } ∪ f1◦S ◦{©1 } ∪ k}f0 ∈ I <−−−| S◮©0 ∧ f1 ∈ I <−−−| S◮©1 ∧ k ∈ I <−−−| (S>r2)

This condition on M together with the condition we needed for the other direction:

106

M ◦M ⊆ M

guarantees abidence of ◦ with ⊗M . We now show that for any set of constraintsMwhere

M ⊆ {UNI ,FUN ,NMP ,DEQ} ∪{TOTB | B ∈ ℘I | B}{RESB | B ∈ ℘I | B}

∪

both conditions are satisfied by⋂M.

We start with the simple condition M ◦M ⊆ M . We leave the (easy) proof that itholds for all the above constraints individually to the reader. For an arbitrary setof constraintsM we calculate

S (−⋂M ◦⋂M−) Q

≡ {definition of ◦}∃〈K |||| S (−⋂M−) K ∧ K (−⋂M−) Q〉

≡ {point-wise definition of⋂

}∃〈K |||| ∀〈M |

| M ∈ M || S (−M −) K〉 ∧ ∀〈M |

| M ∈ M || K (−M −) Q〉〉

≡∃〈K |||| ∀〈M |

| M ∈ M || S (−M −) K ∧ K (−M −) Q〉〉

⇒

∀〈M || M ∈ M |

| ∃〈K |||| S (−M −) K ∧ K (−M −) Q〉〉≡ {definition of ◦}∀〈M |

| M ∈ M || S (−M ◦M −) Q〉

⇒ {• M ∈ M ⇒ M ◦M ⊆ M}∀〈M |

| M ∈ M || S (−M −) Q〉


}S (−⋂M−) Q

The other condition on M :

S (−M −) Q ⇒ S (−M −) K ∧ K (−M −) Q

⇐ {• K = f0◦S ◦{©0 } ∪ f1◦S ◦{©1 } ∪ k}f0 ∈ I <−−−| S◮©0 ∧ f1 ∈ I <−−−| S◮©1 ∧ k ∈ I <−−−| (S>r2)

we also first check for each constraint individually:

UNI : S has a unique input, so (K> = S>) K has a unique input.

FUN : S is functional, so (f0, f1 and k are functional) K is functional.

NMP : S is non-empty, so (K> = S>) K is non-empty.

107

DEQ : S> = Q> and K> = S>, so K> = Q>.

TOTB: S is total on B, so (K> = S>) K is total on B.

RESB: S is restricted to B, so (K> = S>) K is restricted to B.

For an arbitrary set of constraintsM we calculate:

S (−⋂M−) K ∧ K (−⋂M−) Q


}∀〈M |

| M ∈ M || S (−M −) K〉 ∧ ∀〈M |

| M ∈ M || K (−M −) Q〉

≡∀〈M |

| M ∈ M || S (−M −) K ∧ K (−M −) Q〉

⇐ {• every M ∈ M satisfies the condition}∀〈M |

| M ∈ M || S (−M −) Q〉


}S (−⋂M−) Q

Putting everything together, we have proved that for eachM with


∪

the following abidence theorem holds:

R0◦T 0 ⊗M R1◦T 1

= {• M =⋂M}

R0⊗MR1 ◦ T 0⊗MT 1


Similar to section 4.4.6, we do not have in general that A0 ⊗M A1 is a set for setsA0 and A1. We can prove however that ⊗M preserves Rno for the Ms we areconsidering and that ⊗M is diagonal preserving for arbitrary M .

The binary M -constrained cylindric product preserves Rno if M ∈ Rno:

R0, R1 ∈ Rno

⇒ {• M ∈ Rno}R0⊗MR1 ∈ Rno

proof

108

(R0⊗MR1)<

= {definition of ⊗M and ⊗}((R0 −−−−−◦ {©0 }) ∩ (R1 −−−−−◦ {©1 }) ∩ M)<

⊆ {(R∩S)< ⊆ R< ∩ S<}(R0 −−−−−◦ {©0 })< ∩ (R1 −−−−−◦ {©1 })< ∩ M <

⊆ {(−−−−−◦ {i}) preserves Rno, • R0, R1, M ∈ Rno}(R0 −−−−−◦ {©0 }) ∩ (R1 −−−−−◦ {©1 }) ∩ M

= {definition of ⊗ and ⊗M}R0⊗MR1

We leave it to the reader to verify that all combinations of the constraints we con-sider, are an element of Rno (hint: prove it for each of the constraints individuallyand then for an arbitrary intersection of constraints that are an element of Rno).

For arbitrary M we have that ⊗M is diagonal preserving:

(R0∩I ⊗M R1∩I) ∩ I

= {• R0, R1 ∈ Rno}R0⊗MR1 ∩ I

proof

(R0∩I ⊗M R1∩I) ∩ I

= {definition of ⊗M and ⊗}(R0∩I −−−−−◦ {©0 }) ∩ (R1∩I −−−−−◦ {©1 }) ∩ M ∩ I

= {idempotency, commutativity and associativity of ∩}(R0∩I −−−−−◦ {©0 }) ∩ I ∩ (R1∩I −−−−−◦ {©1 }) ∩ I ∩ M

= {(−−−−−◦ {i}) is diagonal preserving, • R0, R1 ∈ Rno}(R0 −−−−−◦ {©0 }) ∩ I ∩ (R1 −−−−−◦ {©1 }) ∩ I ∩ M

= {idempotency, commutativity and associativity of ∩}(R0 −−−−−◦ {©0 }) ∩ (R1 −−−−−◦ {©1 }) ∩ M ∩ I

= {definition of ⊗ and ⊗M}R0⊗MR1 ∩ I

5.4.8 Converse

The converse distributes over the binary M -constrained cylindric product if M is asymmetric subrelation of FUN ∩DEQ :

R0˘ ⊗M R1˘

= {• M ⊆ FUN ∩DEQ ∧ M is symmetric}(R0 ⊗M R1)˘

109

proof

R0˘ ⊗M R1˘

= {definition of ⊗M and ⊗}R0˘ −−−−−◦ {©0 } ∩ R1˘ −−−−−◦ {©1 } ∩ M

= {−−−−−◦ commutes with , • M ⊆ FUN ∩DEQ}(R0 −−−−−◦ {©0 })˘ ∩ (R1 −−−−−◦ {©1 })˘ ∩ M

= {• M is symmetric}(R0 −−−−−◦ {©0 })˘ ∩ (R1 −−−−−◦ {©1 })˘ ∩ M˘

= {distribution of ˘ over ∩}(R0 −−−−−◦ {©0 } ∩ R1 −−−−−◦ {©1 } ∩ M)˘

= {definition of ⊗ and ⊗M}(R0 ⊗M R1)˘

5.5 Arbitrary products

Next to the binary version of the M -constrained cylindric product, we also de-fine an arbitrary version. The arbitrary M-constrained cylindric product⊗M ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| ((I )−−−( I) )−−−( I) is defined by

⊗MW =⋂{R −−−−−◦ {i} | R (−W −) i | R, i} ∩ M

The way we model tuples by relations gives us

⊗M .〈R0, R1〉 = ⊗M .〈R0, R1〉

A property of the arbitrary M -constrained cylindric product that is important inthe context of object-oriented programming, is that it is anti-monotonic (‘becomessmaller when a relation is added’):

W ⊆ V ⇒ ⊗MW ⊇ ⊗MV

An arbitrary product ⊠ ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| ((I )−−−( I) )−−−( I) is informa-tion preserving if for each tag there exists a (total) function that from a packageconstructed with ⊠, can fully retrieve the relation with that tag:

∀〈i |||| ∃〈f || f ∈ (I )−−−( I) <−−−| ((I )−−−( I) )−−−( (I )−−−( I))|| ∀〈W |

| W ∈ (I )−−−( I) <−−−) {i} || f.(⊠W ) = W.i〉〉〉

We leave a structured investigation of the properties of the arbitrary M -constrainedcylindric product for future research. The intricate cases will be the ones where Wis infinite.

110

5.6 Conjoint sum

From our investigation of the constrained cylindric products, some new productswith useful properties emerge. The conjoint sum ∩+ is such a product. It is definedby

∩+ = ⊗UNI ∩FUN ∩NMP∩DEQ

The conjoint sum is similar to the cartesian sum, also called the disjoint sum.The main difference between the conjoint sum and the cartesian sum is that addinga relation to a conjoint sum results in a smaller relation whereas the arbitrarycartesian sum, defined as straightforward generalisation of the allegoric definitionof the binary cartesian sum:

+f =⋃{ini ◦ f.i ◦ ini˘ | i ∈ f > | i}

constructs packages that become larger if a relation is added.

The following two theorems show the close relationship between the conjoint sumand the cartesian sum:

R0+R1 = R0∩+ R1 ∩ RES 2

R0∩+ R1 = R0+R1 ∪ +〈Π | i /∈ 2 | i〉

proof

The first theorem we already proved in section 5.2, except for the expansion of somedefinitions. For the second theorem we calculate

R0∩+ R1

= {definition of ∩+ }R0⊗R1 ∩ UNI ∩FUN ∩NMP∩DEQ

= {UNI ∩FUN ∩NMP∩DEQ = TAGI = TAG 2∪TAGIr2, left to the reader}R0⊗R1 ∩ (TAG 2 ∪ TAG Ir2)

= {distribution of ∩ over ∪}(R0⊗R1 ∩ TAG 2) ∪ (R0⊗R1 ∩ TAGIr2)

= {TAGIr2 ⊆ R0⊗R1, left to the reader}(R0⊗R1 ∩ TAG 2) ∪ TAGIr2

= {see section 5.2, TAGIr2 = +〈Π | i /∈ 2 | i〉, left to the reader}R0+R1 ∪ +〈Π | i /∈ 2 | i〉

In chapter 7 we show how the conjoint sum can be used to model the ‘classes’ and‘packages’ of object-oriented languages.

If we have a look at the properties of the constrained cylindric products that weintroduced, the product ⊗FUN ∩DEQ appears worthy of note as it has all the useful

111

properties that we treated, with the least I/O constraints. From the theorems in 5.2it follows that if we restrict its I/O to pairs, we obtain the cartesian product and ifwe restrict its I/O to values that are tagged with ©0 or ©1 , we obtain the cartesiansum. The product ⊗FUN ∩DEQ thus seems to ‘combine the best of both worlds’,although it does not preserve the identity (I ⊗FUN ∩DEQ I does not equal I). In thenext chapter we show a possible application of ⊗FUN ∩DEQ in the construction ofnon-deterministic expressions.

5.7 Properties of the constrained cylindric packs

In section 5.3 we already proved some theorems about the M -constrained cylindricpack:

R = R©⊳ Mi ⊲ i ⇐ TAG{i} ⊆ MΠ = R©⊳ Mj ⊲ i ⇐ TAG{i} ⊆ M ∧ j 6= iR⊆T ≡ R©⊳ Mi ⊆ T©⊳ Mi ⇐ TAG{i} ⊆ MR=T ≡ R©⊳ Mi = T©⊳ Mi ⇐ TAG{i} ⊆ M

Some other theorems are almost a trivial consequence of the theorems about thecylindric-type operator (section 4.4) and are left to the reader:

R∩T ©⊳ M i = R©⊳ Mi ∩ T©⊳ Mi ⇐ M ⊆ Π◦(I <−−− I)R∪T ©⊳ M i = R©⊳ Mi ∪ T©⊳ Mi ⇐ M ⊆ (I <−−− I)◦ΠR∈Rno ⇒ R©⊳ Mi ∈ Rno ⇐ M ∈ RnoR∩I ©⊳ M i ∩ I = R©⊳ Mi ∩ I ⇐ M ∈ RnoR ˘ ©⊳ M i = R©⊳ Mi ˘ ⇐ M ⊆ FUN ∩DEQ ∧

M is symmetric

Distribution of ©⊳ M over composition is more tricky. The following theorem, theproof of which is left to the reader, enables us to reuse the corresponding theoremabout the binary M -constrained cylindric product:

R©⊳ M©0≡ {• M ⊆ DEQ}

R⊗MΠ

We use this theorem to prove that forM with


∪

we have

R◦T ©⊳ M ©0 = R©⊳ M©0 ◦ T©⊳ M©0 ⇐ M =⋂M ∧ M ⊆ DEQ

112

proof

R◦T ©⊳ M ©0= {above theorem, • M ⊆ DEQ}

R◦T ⊗M Π

= {Π = Π◦Π}R◦T ⊗M Π◦Π

= {abidence of ⊗M with ◦, • M =⋂M}

R⊗MΠ ◦ T⊗MΠ

= {above theorem, • M ⊆ DEQ}R©⊳ M©0 ◦ T©⊳ M©0

5.8 Loose product

If the cylindric product of two relations R0⊗R1 connects an input with some output,it also connects this input with all subrelations of that output. Furthermore, forevery input there exists a single largest output. We prove these facts by showingthat there exists a construct R0⊛R1 that has this largest output as output, rewritingthe definition of R0⊗R1 as follows:

S (−R0⊗R1−) Q

≡ {definition of ⊗ and −−−−−◦}S ◦{©0 } ⊆ R0◦Q ∧ S ◦{©1 } ⊆ R1◦Q

≡ {point-free definition of /}S ⊆ (R0◦Q)/{©0 } ∧ S ⊆ (R1◦Q)/{©1 }

≡ {point-free definition of ∩}S ⊆ (R0◦Q)/{©0 } ∩ (R1◦Q)/{©1 }

≡ {function comprehension}S ⊆ 〈(R0◦X)/{©0 } ∩ (R1◦X)/{©1 } || X〉.Q

≡ {shunting}S (−⊆ ◦ 〈(R0◦X)/{©0 } ∩ (R1◦X)/{©1 } || X〉−) Q

So, defining the binary loose product ⊛ ∈ ((I )−−−( I) <−−−| (I )−−−( I)) <−−−| (I )−−−( I)×(I )−−−( I) by

(R0⊛R1).Q = (R0◦Q)/{©0 } ∩ (R1◦Q)/{©1 }

the cylindric product can be defined in terms of this binary loose product as follows:

R0⊗R1 = ⊆ ◦ R0⊛R1

An important theorem about the binary loose product is that it abides with se-

113

quential composition:

R0⊛R1 ◦ T 0⊛T 1 = R0◦T 0 ⊛ R1◦T 1

proof

(R0⊛R1 ◦ T 0⊛T 1).Q

= {(f ◦g).x = f.(g.x) for total functions f and g}(R0⊛R1).((T 0⊛T 1).Q)

= {definition of ⊛}(R0⊛R1).((T 0◦Q)/{©0 } ∩ (T 1◦Q)/{©1 })

= {definition of ⊛}R0◦((T 0◦Q)/{©0 } ∩ (T 1◦Q)/{©1 }) / {©0 } ∩R1◦((T 0◦Q)/{©0 } ∩ (T 1◦Q)/{©1 }) / {©1 }

= {X/B = (X ◦B)/B for sets B, distribution of ◦ over ∩ for sets}R0◦(((T 0◦Q)/{©0 })◦{©0 } ∩ ((T 1◦Q)/{©1 })◦{©0 }) / {©0 } ∩R1◦(((T 0◦Q)/{©0 })◦{©1 } ∩ ((T 1◦Q)/{©1 })◦{©1 }) / {©1 }

= {X/B ◦ B = X ◦B and X/B ◦ D = Π◦D for disjoint sets B and D}R0◦(T 0◦Q◦{©0 } ∩ Π◦{©0 }) / {©0 } ∩ R1◦(Π◦{©1 } ∩ T 1◦Q◦{©1 }) / {©1 }

= {distribution of ◦ over ∩ for sets}R0◦(T 0◦Q ∩ Π)◦{©0 } / {©0 } ∩ R1◦(Π ∩ T 1◦Q)◦{©1 } / {©1 }

= {Π is unit of ∩}R0◦T 0◦Q◦{©0 } / {©0 } ∩ R1◦T 1◦Q◦{©1 } / {©1 }

= {X ◦B / B = X/B for sets B}R0◦T 0◦Q / {©0 } ∩ R1◦T 1◦Q / {©1 }

= {definition of ⊛}(R0◦T 0 ⊛ R1◦T 1).Q

This sequential-composition abidence theorem of ⊛ can on the other hand also beused to prove it for ⊗ (hint: prove that (R0⊗R1)◦⊆ equals R0⊗R1).

We also introduce a variation of the loose product that restricts the inputs andoutputs to elements of type I )−−−( 2. The binary restricted loose product∗ ∈ ((I )−−−( 2) <−−−| (I )−−−( 2)) <−−−| (I )−−−( I)×(I )−−−( I) is defined by

(R0∗R1).Q = (R0⊛R1).Q ◦ 2

or equivalently:

(R0∗R1).Q = R0◦Q◦{©0 } ∪ R1◦Q◦{©1 }

The following calculation proves the equivalence of both definitions:

114

(R0⊛R1).Q ◦ 2

= {definition of ⊛}((R0◦Q)/{©0 } ∩ (R1◦Q)/{©1 }) ◦ 2

= {X/A = X ◦A ∪ ¬(Π◦A)}((R0◦Q◦{©0 } ∪ ¬(Π◦{©0 })) ∩ (R1◦Q◦{©1 } ∪ ¬(Π◦{©1 }))) ◦ 2

= {distribution of ◦ over ∩ for sets and distribution of ◦ over ∪}(R0◦Q◦{©0 }◦2 ∪ ¬(Π◦{©0 })◦2) ∩ (R1◦Q◦{©1 }◦2 ∪ ¬(Π◦{©1 })◦2)

= {for sets B and D we have B ◦D = B if B ⊆ D and ¬(Π◦B)◦D = Π◦(DrB)}(R0◦Q◦{©0 } ∪ Π◦{©1 }) ∩ (R1◦Q◦{©1 } ∪ Π◦{©0 })

= {distribution of ∩ over ∪}(R0◦Q◦{©0 } ∩ R1◦Q◦{©1 }) ∪ (R0◦Q◦{©0 } ∩ Π◦{©0 }) ∪(Π◦{©1 } ∩ R1◦Q◦{©1 }) ∪ (Π◦{©1 } ∩ Π◦{©0 })

= {R◦B ∩ S ◦D = ©� for disjoint sets B and D, ©� is unit of ∪}(R0◦Q◦{©0 } ∩ Π◦{©0 }) ∪ (Π◦{©1 } ∩ R1◦Q◦{©1 })

= {distribution of ◦ over ∩ for sets, Π is unit of ∩}R0◦Q◦{©0 } ∪ R1◦Q◦{©1 }

To prove abidence of ∗ with ◦, we could use the first definition of ∗, together withthe abidence theorem of ⊛. The second definition of ∗ makes abidence of ∗ with ◦

however easy to prove directly:

(R0∗R1 ◦ T 0∗T 1).Q

= {(f ◦g).x = f.(g.x) for total functions f and g}(R0∗R1).((T 0∗T 1).Q)

= {second definition of ∗}(R0∗R1).(T 0◦Q◦{©0 } ∪ T 1◦Q◦{©1 })

= {second definition of ∗}R0◦(T 0◦Q◦{©0 } ∪ T 1◦Q◦{©1 })◦{©0 } ∪ R1◦(T 0◦Q◦{©0 } ∪ T 1◦Q◦{©1 })◦{©1 }

= {distribution of ◦ over ∪}R0◦T 0◦Q◦{©0 }◦{©0 } ∪ R0◦T 1◦Q◦{©1 }◦{©0 } ∪R1◦T 0◦Q◦{©0 }◦{©1 } ∪ R1◦T 1◦Q◦{©1 }◦{©1 }

= {B ◦B = B and B ◦D = ©� for disjoint sets B and D, ©� is unit of ∪}R0◦T 0◦Q◦{©0 } ∪ R1◦T 1◦Q◦{©1 }

= {second definition of ∗}(R0◦T 0 ∗ R1◦T 1).Q

In the next chapter we use the loose product in the construction of a general modelfor expressions that incorporates non-strict and even non-deterministic evaluation.

115

5.9 Conclusions

In this chapter we presented several constructs that enable us to combine relationsinto a package that satisfies several useful algebraic properties. One of the mainreasons for this investigation was the fact that both anti-monotonicity and infor-mation preservingness are important properties for our purposes. We introducedseveral products that, different from the cartesian sum and product, do combineboth properties, although we have to sacrifice the property that the product of twosets is again a set.

116

Chapter 6

Expressions

In this chapter we show how we model expressions in our formalism. The differentproducts of the previous chapter enable us to model different kinds of evaluationlike strict, non-strict and even non-deterministic evaluation. The chapter containsseveral theorems that show how concepts like typing and substitution fit into themodel.

6.1 Definition

A language is usually divided into a syntax, describing the structure of the languageand a semantics, describing the meaning of the language. The syntax is oftendescribed in some form of BNF-notation, for example

Exp ::= var Var | con Con | un Un Exp | bin Bin Exp Exp

Var ::= a | ... | z

Con ::= 0 | 1 | ...

Un ::= -

Bin ::= + | *

The meaning of a language is described by a semantics function ≪ ≫. The se-mantics function transforms a syntactic expression into what we call a semanticexpression. A semantic expression is a function that maps a context to the valueof the expression in that context. An often used context is a collection of variables,or more precise, a function that maps variable names to variable values. Thestraightforward definition of ≪ ≫ for the above example is

117

≪ var x ≫.h = h.x≪ con n ≫.h = ≪n≫.h≪ un o e ≫.h = (≪o≫.h).(≪e≫.h)≪bin o e0 e1≫.h = (≪o≫.h).〈≪e0≫.h,≪e1≫.h〉≪ − ≫.h = −≪ + ≫.h = +≪ ∗ ≫.h = ×≪ 0 ≫.h = 0≪ 1 ≫.h = 1

...

This way of describing the semantics of a language is known as denotationalsemantics. In the above example, the mapping of −, +, ∗, 0, 1, . . . to − , + ,× , 0, 1, . . . appears rather ‘clumsy’. This ‘clumsiness’ can be avoided by directly

using semantic expressions. In that case an expression is its semantics, being afunction that maps contexts to values. If we allow every element as variable nameand variable value and assume that each variable has a single value, then the typeof contexts is I <−−−| I and expressions are elements of type

I <−−−| (I <−−−| I)

A problem with this model for expressions is that every operator that we use toconstruct an expression, needs to be a total function (or a function that is total onthe set of all pairs in case of binary operators). Most operators of everyday life arenot total functions however. A possible solution could be to extend the collectionof elements by an artificial element (often denoted by ⊥) and use this as output forthe inputs in which an operator was originally not single-valued. There is however amore natural approach possible that does not require the addition of such artificialelements. If we model expressions as functions that are not necessarily total on thetype of contexts, i.e. as functions of type

I <−−−( (I <−−−| I)

then an expression can simply be empty in a certain context instead of having tooutput an artificial element. We even go a step further and model expressions asrelations with contexts as upper domain. This allows us to deal not only withpartiality, but also with non-determinism in expressions. We also abstractfrom the specific shape of contexts, allowing arbitrary elements as contexts. Somecommon shapes are treated in chapter 10. For the theory of the upcoming chapters,choosing a particular shape for the context is irrelevant and would only distract fromthe core issues. The type of contexts is thus I and the type of expressions is

I )−−−( I

In the next subsections we introduce several operators that enable us to constructexpressions.

118

6.1.1 Context

The context expression C| ∈ I )−−−( I represents the value of the context:

y (−C| −) z ≡ y = z

It is actually just another notation for the identity relation:

C| = I

The value of the context expression C| in some context, is that context:

C| .z = z

The reason why we use different symbols for the same thing is to somewhat re-obtain the separation of concerns that a semantics function provides: we separatethe fact that we want to express the value of the context from the specific way thisvalue is obtained. If we decide to model expressions differently, we do not need tochange the “I” of every expression into the new thing that obtains the value, butonly need to change the definition of C| .

6.1.2 Constants

The constant lift ¯ ∈ (I )−−−( I) <−−−| I transforms an element into a constant ex-pression:

y (−a−) z ≡ y = a

The constant lift is actually the constant function:

¯ = K

The value of constant expression a is a in every context:

a.z = a

6.1.3 Strict unary operators

The strict unary lift ˙ ∈ ((I )−−−( I) <−−−| (I )−−−( I)) <−−−| (I )−−−( I) transforms an arbi-trary relation into a strict unary expression operator:

y (−R.E −) z ≡ ∃〈x |||| y (−R−) x ∧ x (−E −) z〉

An equivalent definition in terms of the sequential composition is:

119

R.E = R◦E

We use the convention that fix notation is preserved by ˙, so ⊙E is equal to ⊙ .E.For z ∈ R with z ≥ 0, we have for example

(− ·√

C| ).z = −√z

The reason for the adjective “strict” is that if expression E is empty in a context z,

then R.E is also empty in z. The strict unary lift can for example not be used toconstruct an operator that checks whether or not an expression is ‘defined’. Thesekinds of operators are treated in section 6.1.5.

6.1.4 Loose binary operators

The loose binary lift ¨ ∈ ((I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I)) <−−−| (I )−−−( (I )−−−( 2)) trans-forms a relation with upper domain I )−−−( 2 into a loose binary expression op-erator:

y (−R.〈E0, E1〉−) z

≡∃〈T |||| y (−R−) T ∧ ∀〈x |||| x (−T −)©0 ≡ x (−E0−) z〉

∧ ∀〈x |||| x (−T −)©1 ≡ x (−E1−) z〉〉

The T of the existential quantification actually always exists and is uniquely de-termined by E0, E1 and z. An equivalent definition is (see section 3.3.8 for thedefinitions of ◮ and ◭)

y (−R.〈E0, E1〉−) z

≡y (−R−) ((E0◮z)◭©0 ∪ (E1◮z)◭©1 )

As its name suggests, the loose binary lift is closely related to the loose product.The following equation shows how ¨ can be defined in terms of this product:

R.〈E0, E1〉 = R ◦ E0∗E1 ◦ ∆

We leave the proof of equivalence of the above equations to the reader.

As an example of a loose binary operator, we model the conjunction of the four-valued logic E4 (see [42]). Its behaviour is described by the following table (⊥represents the case where an expression is empty in the context and false�truerepresents the case where an expression connects both booleans to the context):

120

∧4 ⊥ false true false�true⊥ ⊥ false ⊥ ⊥

false false false false falsetrue ⊥ false true false�true

false�true ⊥ false false�true false�true

A formal definition of ∧4 ∈ B )−−−( (B )−−−( 2) is given by the following equation:

y (− ∧4 −) T

≡

(T ∈ {false} <−−−) {©0 } ∧ ¬y) ∨(T ∈ {false} <−−−) {©1 } ∧ ¬y) ∨(T = [(true,©0 ), (true,©1 )] ∧ y) ∨(T = [(true,©0 ), (false ,©1 ), (true,©1 )]) ∨(T = [(false ,©0 ), (true,©0 ), (true,©1 )]) ∨(T = [(false ,©0 ), (true,©0 ), (false ,©1 ), (true,©1 )])

For the relation R defined by

R = [(true, true), (false , true)]

we have for example ( also preserves fix notation):

(R.C| ∧4¯false) ◮ false = {false}

(R.C| ∧4¯false) ◮ true = {false}

(R.C| ∧4 ¯true ) ◮ false = ©�(R.C| ∧4 ¯true ) ◮ true = {false, true}

6.1.5 Loose unary operators

To be able to incorporate operators like the ‘proper’ ∆4 (this operator is not inany way related to our ∆) and the ‘defined’ τ4 of the logic E4, we introduce theloose unary lift ˜ ∈ ((I )−−−( I) <−−−| (I )−−−( I)) <−−−| (I )−−−( (I )−−−( {©0 })) that transformsa relation with upper domain I )−−−( {©0 } into a loose unary expression operator:

y (−R.E −) z ≡ ∃〈T |||| y (−R−) T ∧ ∀〈x |||| x (−T −)©0 ≡ x (−E −) z〉〉

or equivalently:

y (−R.E −) z ≡ y (−R−) (E◮z)◭©0

The operators ∆4 and τ4, whose behaviour is described by the following table:

121

∆4 τ4

⊥ false falsefalse true truetrue true true

false�true false true

can for example be defined by ∆4 , τ4 ∈ B <−−−| (B )−−−( {©0 }) together with the fol-lowing equations:

∆4T ≡ T ∈ I <−−−) {©0 }τ4 T ≡ T 6= ©�

If we define the relation R again by

R = [(true, true), (false , true)]

we have ( also preserves fix notation)

(∆4(R.C| )).false = false

(∆4(R.C| )).true = false

(τ4 (R.C| )).false = false

(τ4 (R.C| )).true = true

Loose unary operators are hardly ever used in this thesis, so we do not pay muchattention to them anymore.

6.2 Non-strict evaluation

In 3.1.24 we described non-strict evaluation rather informally. Now that we haveintroduced expressions, we are able to formalise our notion of non-strict evaluation.Opposed to the negation (¬) and the equivalence (≡) which are strict:

¬ ∈ B <−−−| B≡ ∈ B <−−−| B×B

the operators ∧, ∨,⇒ and⇐ are non-strict, meaning that they are not only definedfor pairs of booleans. The conjunction, disjunction, implication and consequence∧ , ∨ , ⇒ , ⇐ ∈ B )−−−( (I )−−−( 2) satisfy the following equations:

y (− ∧ −) T

≡(T ∈ {false} <−−−) {©0 } ∧ ¬y) ∨(T ∈ {false} <−−−) {©1 } ∧ ¬y) ∨(T = 〈true, true〉 ∧ y)

122

y (− ∨ −) T

≡

(T ∈ {true} <−−−) {©0 } ∧ y) ∨(T ∈ {true} <−−−) {©1 } ∧ y) ∨(T = 〈false , false〉 ∧ ¬y)

y (− ⇒ −) T

≡(T ∈ {false} <−−−) {©0 } ∧ y) ∨(T ∈ {true} <−−−) {©1 } ∧ y) ∨(T = 〈true, false〉 ∧ ¬y)

y (− ⇐ −) T

≡(T ∈ {true} <−−−) {©0 } ∧ y) ∨(T ∈ {false} <−−−) {©1 } ∧ y) ∨(T = 〈false , true〉 ∧ ¬y)

These equations are not definitions due to the fact that the involved formulas containoperators that they should define. They illustrate the main idea however.

If we restrict our attention to expressions that are functional and boolean-valued(expressions of type B <−−− I), the behaviour of our implication is in accordance withthe following table:

⇒ ⊥ false true⊥ ⊥ ⊥ true

false true true truetrue ⊥ false true

This is different from the implication ⇒3 of the logic E3 (see [42]) that is defined alittle ‘looser’:

⇒3 ⊥ false true⊥ true true true

false true true truetrue ⊥ false true

So in case the expression at the left-hand side of⇒3 (the antecedent) is ‘undefined’,the outcome is also always true. We think that in practice it is a good habit tomake sure that antecedents (assumptions) are ‘defined’ in the contexts where theirvalue is relevant. So for y, z ∈ R we do not write a formula like

x = (y/z = 1 ⇒3 y 6= z)

but instead write

123

x = (z = 0 ∨ (z 6= 0 ∧ (y/z = 1 ⇒ y 6= z)))

This example might convince the reader that ‘undefined’ antecedents are not thatgood an idea as people could inadvertently think that the first formula is equivalentto x = false whereas it is equivalent to x = (z = 0). Non-determinism in expres-sions we avoid because of our lack of experience with it. We do not know if it couldbe a serious source of errors. We however now show some facts that could be ofinterest to people that are more experienced in this subject.

If we write out the point-free definitions of C| , , ˙ and ¨ for the expression

C| ∈ B ∧ ¬C|

we obtain

∧ ◦ ( ∈ ◦(I ∗ K.B)◦∆ ∗ ¬ ◦I) ◦ ∆

The use of ∗ enables non-strict evaluation. If we feed the above expression withcontext piano, it produces output false. However, if we replace the loose productby the cartesian product:

∧ ◦ ( ∈ ◦(I × K.B)◦∆ × ¬ ◦I) ◦ ∆

then no output is connected with input piano.

We can thus select between different kinds of expression evaluation by pluggingin another product. The product ⊗FUN ∩RES 2

for example also enables non-strictevaluation. The expression

∧ ◦ ( ∈ ◦(I ⊗FUN ∩RES 2K.B)◦∆ ⊗FUN ∩RES 2

¬ ◦I) ◦ ∆

also outputs false on input piano. The difference between ⊗FUN ∩RES 2and ∗ is

that ⊗FUN ∩RES 2provides a default treatment of non-determinism whereas the use

of ∗ requires this to be encoded in the operators (on the other hand providing morefreedom in how to deal with non-determinism). In case we use ⊗FUN ∩RES 2

, thenour non-strict conjunction:

∧ ⊥ false true⊥ ⊥ false ⊥

false false false falsetrue ⊥ false true

would behave according to the following table in case non-determinism is involved:

124

∧ ⊥ false true false�true⊥ ⊥ false ⊥ false

false false false false falsetrue ⊥ false true false�true

false�true false false false�true false�true

The false at the crosspoints of ⊥ and false�true makes it different from ∧4 of thelogic E4 that has ⊥ at these crosspoints. Intuitively, the above table for ∧ doesnot seem that strange however. If one of the components is false , the outcome isalways false . So, if one of the components is either false or true and the otherone is ‘undefined’, it does not seem that strange to say that the outcome false is‘angelically’ chosen.

We get the same behaviour if we replace ∆ by the cylindric-doubling function©∆ ∈ (I )−−−( 2) )−−−( I, defined by

T (−©∆ −) x

≡

T = 〈x, x〉 ∨ T = [(x,©0 )] ∨ T = [(x,©1 )] ∨ T = ©�

or equivalently:

©∆ = ⊆◦∆

After this replacement, replacing ⊗FUN ∩RES 2by the product ⊗FUN ∩DEQ (see the

end of section 5.6) still does not change the behaviour:

E0⊗FUN ∩DEQE1 ◦ ©∆ = E0⊗FUN ∩RES 2E1 ◦ ∆

We leave it to the reader to verify this fact. Our knowledge about non-determinismin expressions is too limited to judge if this default treatment of non-determinismhas all the nice properties it should have. We leave this for future research. Fornow, we simply stick to our strict unary and loose binary expression operators andavoid the use of non-determinism in expressions. Luckily not every theorem weconstruct is useless in case we would decide to use ⊗FUN ∩DEQ and ©∆ instead of ∗and ∆. Using the first two is the same as using the last two and replacing everybinary operator R ∈ I )−−−( (I )−−−( 2) by R◦(I <−−− I)◦⊆:

R ◦ E0⊗FUN ∩DEQE1 ◦ ©∆ = R◦(I <−−− I)◦⊆ ◦ E0∗E1 ◦ ∆

So, if we proved something about R for all R, we also proved it in case we would

use ⊗FUN ∩DEQ and ©∆ instead of ∗ and ∆.

125

6.3 Single-valuedness and typing

As stated before, we mainly use expressions in contexts where they are single-valued.The following single-valuedness type rules, whose proofs we leave to the reader,enable us to prove that an expression is single-valued and outputs elements of aspecific type for certain contexts. For sets A, B(i) and C we have

C| ∈ C <−−−) Ca ∈ A <−−−) C ⇐ a ∈ A

R.E ∈ A <−−−) C ⇐ R ∈ A <−−−) B ∧ E ∈ B <−−−) C

R.〈E0, E1〉 ∈ A <−−−) C ⇐ R ∈ A <−−−) B0×B1 ∧ E0 ∈ B0 <−−−) C∧ E1 ∈ B1 <−−−) C

As an example we prove

C| <·√C| +1 ∈ B <−−−) N

proof

C| <·√C| +1 ∈ B <−−−) N

⇐ {single-valuedness type rule for binary operators, < ∈ B <−−−) R×R}

C| ∈ R <−−−) N ∧ ·√C| +1 ∈ R <−−−) N

⇐ {single-valuedness type rule for context, R <−−−) R ⊆ R <−−−) N

single-valuedness type rule for unary operators,√ ∈ R <−−−) N}

C| +1 ∈ N <−−−) N

⇐ {single-valuedness type rule for binary operators, + ∈ N <−−−) N×N}C| ∈ N <−−−) N ∧ 1 ∈ N <−−−) N

≡ {single-valuedness type rule for contextsingle-valuedness type rule for constants, 1 ∈ N}

true

In case we use non-strict operators to construct an expression, it is possible thatan expression is still single-valued in certain contexts if one of the expressions it isconstructed from, is not. For these cases we can use the following rules:

E0 ∧E1 ∈ B <−−−) C ⇐ E0 ∈ {false} <−−−) CE0 ∧E1 ∈ B <−−−) C ⇐ E1 ∈ {false} <−−−) CE0 ∨E1 ∈ B <−−−) C ⇐ E0 ∈ {true} <−−−) CE0 ∨E1 ∈ B <−−−) C ⇐ E1 ∈ {true} <−−−) CE0⇒E1 ∈ B <−−−) C ⇐ E0 ∈ {false} <−−−) CE0⇒E1 ∈ B <−−−) C ⇐ E1 ∈ {true} <−−−) CE0⇐E1 ∈ B <−−−) C ⇐ E0 ∈ {true} <−−−) CE0⇐E1 ∈ B <−−−) C ⇐ E1 ∈ {false} <−−−) C

We usually also need some more advanced rules for these cases, like for example thedomain-split type rule:

126

E ∈ A <−−−) C0∪C1 ≡ E ∈ A <−−−) C0 ∧ E ∈ A <−−−) C1

and the disjoint-type rule:

E0∈E1 ∈ {false} <−−−) C ⇐ E0 ∈ A <−−−) C ∧ E1 ∈ ℘B <−−−) C ∧A∩B = ©�

The following example illustrates the use of these rules:

C| ∈B ∧ C| ∈ B <−−−) I

proof

C| ∈B ∧ C| ∈ B <−−−) I

≡ {domain-split type rule, I = B ∪ IrB}C| ∈B ∧ C| ∈ B <−−−) B ∧C| ∈B ∧ C| ∈ B <−−−) IrB

≡ {the truth of the first conjunct is left to the reader}C| ∈B ∧ C| ∈ B <−−−) IrB

⇐ {type rule for non-strict conjunction}C| ∈B ∈ {false} <−−−) IrB

⇐ {disjoint-type rule, B ∩ IrB = ©�}C| ∈ IrB <−−−) IrB ∧ B ∈ ℘B <−−−) IrB

≡ {type rule for context and type rule for constants, B ∈ ℘B}true

6.4 Theorem lifting

Suppose that an expression E is constructed with C| , , ˙ and . In case E and allits syntactic subexpressions (all expressions that are used for the constructionof E) are single-valued in a context z, the result of applying E to z is a formulathat is equal to E where, at the syntactic level, all accents ( , ˙ and ) are removedand each C| is replaced by z:

C| .z = za .z = a

(R.E) .z = R.(E.z) ⇐ E ∈ I <−−−) {z} ∧R ∈ I <−−−) {E.z}

(R.〈E0, E1〉).z = R.〈E0.z, E1.z〉 ⇐ E0, E1 ∈ I <−−−) {z} ∧R ∈ I <−−−) {〈E0.z, E1.z〉}

Because we proved for example that

C| <·√C| +1

127

and all its syntactic subexpressions are single-valued in contexts that are naturalnumbers, we may apply it to any context z ∈ N, with result

z <√

z+1

This enables us to straightforwardly transform theorems from our mathematicallanguage into theorems about expressions. Because in our mathematical languagewe have the rule that for z ∈ N

z <√

z+1 = z×z ≤ z

we also know that

(C| <·√C| +1)◦N = (C| ×C| ≤ C| )◦N

We call this theorem lifting. The “◦N” makes explicit that the equality holdsunder the assumption that the context is of type N.

6.5 Assignment and substitution

The usual definition of the assignment a := E is that it inputs a context h thatconsists of a collection of variables and outputs a context g where the value of thevariable with name a has acquired the value that expression E has in context h.All other variables are left unchanged. In case of shapeless contexts, we could saythat we only have one (nameless) variable: the context itself. The expression of anassignment is the assignment then. The assignment that transforms the value ofthe context into the value of the context plus 1, is for example the expression

C| + 1

Suppose now that we have an expression E that is constructed with C| , , ˙ and . Aconsequence of the following rules is that for an assignment S ∈ I )−−−( I, in contextsthat make S single-valued, E ◦S is equal to E where, at the syntactic level, every C|is replaced (substituted) by S:

C| ◦ S = Sa ◦ S = a ◦ S>

R.E ◦ S = R . E ◦S

R.〈E0, E1〉 ◦ S = R.〈E0◦S, E1◦S〉 ◦ S> ⇐ S is a function

We leave it to the reader to prove the first three rules. The fourth rule can beproved as follows:

128

R.〈E0, E1〉 ◦ S

= {definition of }R ◦ E0∗E1 ◦ ∆ ◦ S

= {• S is a function, see below}R ◦ E0∗E1 ◦ S∗S ◦ ∆ ◦ S>

= {abidence of ∗ with ◦}R ◦ (E0◦S ∗ E1◦S) ◦ ∆ ◦ S>

= {definition of }

R.〈E0◦S, E1◦S〉 ◦ S>

The second step is justified by the following calculation:

T (−S∗S ◦ ∆ ◦ S>−) z

≡ {shunting, S> is a set}T (−S∗S ◦ ∆−) z ∧ z ∈ S>

≡ {shunting (twice), ∆ and S∗S are total functions}T = (S∗S).(∆.z) ∧ z ∈ S>

≡ {definition of ∗}T = S ◦(∆.z)◦{©0 } ∪ S ◦(∆.z)◦{©1 } ∧ z ∈ S>

= {left to the reader, • S is a function}T = [(S.z,©0 ), (S.z,©1 )] ∧ z ∈ S>

= {tuple enumeration}T = 〈S.z, S.z〉 ∧ z ∈ S>

= {definition of ∆}T = ∆.(S.z) ∧ z ∈ S>

≡ {shunting, ∆ is a total function}T (−∆−) S.z ∧ z ∈ S>

≡ {shunting, • S is a function}T (−∆◦S −) z

As an example, we show how a relation f ∈ I <−−−) B distributes over the expression

−C| + 2

Notice that f ◦B is a function with domain B.

129

(−C| + 2) ◦ f ◦ B

= {substitution rule for binary operators}((−C| )◦f ◦B + 2◦f ◦B) ◦ B

= {substitution rule for unary operators and constants}(−(C| ◦f ◦B) + 2◦B) ◦ B

= {substitution rule for context}(−(f ◦B) + 2◦B) ◦ B

= {substitution rule for unary operators the other way around}((−f)◦B + 2◦B) ◦ B

= {substitution rule for binary operators the other way around,a set is a function and is equal to its own domain}

(−f + 2) ◦ B

Notice how the ‘reversed’ substitution rules enable us to get rid of the B-type re-strictions in the expression. From now on, we do not write out all these substitutionsteps anymore but only write

(−C| + 2) ◦ f ◦ B

= {substitution, f ∈ I <−−−) B}(−f + 2) ◦ B

6.6 Collection-comprehension operator

Collections are often described by predicates. The collection-comprehensionoperator [[ ]] ∈ PI <−−−| (I )−−−( I) transforms an expression into a collection. The col-lection [[E]] contains element x, exactly when expression E is single-valued in x,with output true:

x ǫ [[E]] ≡ E ∈ {true} <−−−) {x}

So, in case E ∈ B <−−−) {x}, we have

x ǫ [[E]] ≡ E.x

An immediate result is that for a collection C

[[C| ǫ C]] = C

The definition of the collection-comprehension operator is such that the conjunctionof expressions corresponds to intersection of the corresponding collections, the dis-junction corresponds to the union, the constant-false expression corresponds to theempty collection and the constant-true expression corresponds to the full collection:

130

[[E0∧E1]] = [[E0]]∩[[E1]][[E0∨E1]] = [[E0]]∪[[E1]][[ ¯false ]] = ©�[[ ¯true ]] = Π

We leave the rather straightforward proofs to the reader.

Because [[ ]] sort of identifies ‘undefinedness’ with false, [[¬E]] = �[[E]] does not holdin general (take for example E = ©�). However, in case E is a total predicate, wehave a similar rule for ¬:

[[¬E]] = �[[E]] ⇐ E ∈ B <−−−| I

A similar thing holds for ⇒, ⇐ and ≡:

[[E0⇒E1]] = [[E0]]=⊃ [[E1]] ⇐ E0 ∈ B <−−−| I[[E0⇐E1]] = [[E0]] ⊂=[[E1]] ⇐ E1 ∈ B <−−−| I[[E0 ≡E1]] = [[E0]]⊂==⊃[[E1]] ⇐ E0, E1 ∈ B <−−−| I

The proofs are again left to the reader.

For ⇒ and ⇐, the logic E3 eliminates the need for these ‘definedness’ restrictions.However, as we already mentioned, we prefer to only use antecedents that, in thecontexts where their value is relevant, are single-valued (and boolean-valued ofcourse).

We sometimes want to prove an inclusion or equality between collections that aredescribed by expressions. The following rules show how the proof can be kept atthe level of expressions (although our rather incomplete set of rules for expressionsusually still forces us to use theorem lifting):

[[E0⇒E1]] = [[ ¯true]] ≡ [[E0]]⊆[[E1]] ⇐ E0 ∈ B <−−−| I[[E0⇐E1]] = [[ ¯true]] ≡ [[E0]]⊇[[E1]] ⇐ E1 ∈ B <−−−| I[[E0 ≡E1]] = [[ ¯true]] ≡ [[E0]]=[[E1]] ⇐ E0, E1 ∈ B <−−−| I

We leave the proofs again to the reader (hint: use everywhere , defined in section3.3.11).

Although we formulated all these theorems for total predicates, they also hold fornot necessarily total predicates if proper domain restrictions are added. We refrainfrom spelling out the formulas as it probably does not provide more insight.

6.7 Set-comprehension operator

A set is also often described by means of a predicate. The set-comprehensionoperator {[ ]} ∈ ℘I <−−−| (I )−−−( I) transforms an expression into a set. The set {[E]}

131

owns exactly every element for which expression E is single-valued with outputtrue:

x ∈ {[E]} ≡ E ∈ {true} <−−−) {x}

So, in case E ∈ B <−−−) {x}, we have

x ∈ {[E]} ≡ E.x

An immediate result is that for a set A

{[C| ∈ A]} = A

The fact that

x ∈ {[E]} ≡ x ǫ [[E]]

enables us to transform theorems about [[ ]] into theorems about {[ ]}:

{[E0 ∧ E1]} = {[E0]} ∩ {[E1]}{[E0 ∨ E1]} = {[E0]} ∪ {[E1]}{[E0 ⇒ E1]} = ({[E0]}=⊃{[E1]})∩I ⇐ E0 ∈ B <−−−| I{[E0 ⇐ E1]} = ({[E0]} ⊂={[E1]})∩I ⇐ E1 ∈ B <−−−| I{[E0 ≡ E1]} = ({[E0]}⊂==⊃{[E1]})∩I ⇐ E0, E1 ∈ B <−−−| I{[ ¯false ]} = ©�{[ ¯true ]} = I{[ ¬ E ]} = ( �{[E]} )∩I ⇐ E ∈ B <−−−| I{[E0 ⇒ E1]} = {[ ¯true]} ≡ {[E0]}⊆{[E1]} ⇐ E0 ∈ B <−−−| I{[E0 ⇐ E1]} = {[ ¯true]} ≡ {[E0]}⊇{[E1]} ⇐ E1 ∈ B <−−−| I{[E0 ≡ E1]} = {[ ¯true]} ≡ {[E0]}={[E1]} ⇐ E0, E1 ∈ B <−−−| I

6.8 Connectional expressions

In this section we treat the special case of expressions with connections as contexts.

6.8.1 Definition

Where expressions have arbitrary elements as input, connectional expressionshave connections (y, z) as input. The type of connectional expressions is thusI )−−−( I⋆I. In the setting of connectional expressions, we call [[ ]] the relation-comprehension operator.

132

6.8.2 Constructing connectional expressions

The output conditioner and input conditioner ,´ ∈ (I )−−−( I⋆I) <−−−| (I )−−−( I) canbe used to transform an expression into a connectional expression that talks aboutthe output of the context or the input of the context respectively:

w (−E −) (y, z) ≡ w (−E −) y

w (−E −) (y, z) ≡ w (−E −) z

In particular:

C| .(y, z) = y

C| .(y, z) = z

We leave it to the reader to verify the following distribution theorems:

.(a) = a

.(R.E) = R.E

.(R.〈E0, E1〉) = R.〈E0, E1〉

.(a) = a

.(R.E) = R.E

.(R.〈E0, E1〉) = R.〈E0, E1〉

If an expression E is constructed with C| , , ˙ and , then applying ` to it, is thus

the same as syntactically replacing every C| by C| . The same holds for .

6.8.3 Assignment and substitution

In case the assignment is the connectional product of two relations S0 and S1 (S0⋆S1,

see section 3.7), we have the following rules for C| and C| :

C| ◦ S0⋆S1 = S0◦C| ◦ (I⋆S1)>

C| ◦ S0⋆S1 = S1◦C| ◦ (S0⋆I)>

The proofs of these theorems are left to the reader.

If S0 is constructed with the operators C| , , ˙ and ¨ then the substitution rules for

expressions (section 6.5) allow us to syntactically transform S0◦C| into S0 where

each C| is replaced by C| (notice that C| is a total function). The same holds for

S1◦C| .

A theorem that is closely related to the shunting theorems and that we also referto as shunting, is that for a connectional expression E and relations S0 and S1:

S0˘ ◦ [[E]] ◦ S1 = [[E ◦ S0⋆S1]]

The proof is left to the reader.

133

The proof of the following equation shows the above theorems in action.

R ◦ (C| +2)˘ ◦ [[C| ≤ C| ]] ◦ C| +1 ◦ R = R ◦[[C| +2 ≤ C| +1]]◦R

proof

R ◦ (C| +2)˘ ◦ [[C| ≤ C| ]] ◦ C| +1 ◦ R

= {shunting}

R ◦[[C| ≤ C| ◦ (C| +2 ⋆ C| +1)]]◦R

= {shunting}

[[C| ≤ C| ◦ (C| +2 ⋆ C| +1) ◦ R⋆R]]

= {substitution rule for binary operators, (C| +2 ⋆ C| +1) ∈ I <−−−) R⋆R}

[[C| ◦(C| +2 ⋆ C| +1) ≤ C| ◦(C| +2 ⋆ C| +1) ◦ R⋆R]]

= {substitution rule for ` and , the trick of the example in section 6.5can again be used to get the Rs in and out}

[[(C| +2 ◦ C| ) ≤ (C| +1 ◦ C| ) ◦ R⋆R]]

= {substitution, C| and C| are total functions}

[[(C| +2) ≤ (C| +1) ◦ R⋆R]]

= {shunting}

R ◦[[C| +2 ≤ C| +1]]◦R

From now on this is shortened to

R ◦ (C| +2)˘ ◦ [[C| ≤ C| ]] ◦ C| +1 ◦ R

= {substitution, C| +2, C| +1 ∈ I <−−−) R}

R ◦[[C| +2 ≤ C| +1]]◦R

6.8.4 Some relationships

The following theorems show the close relationship between the set-comprehensionoperator and the relation-comprehension operator:

{[E]}◦Π = [[E]]

Π◦{[E]} = [[E]]

Together with the fact that

I = [[C| = C| ]]

and [[E0∧E1]] = [[E0]]∩[[E1]] (see section 6.6), it is also easy to prove

{[E]} = [[C| = C| ∧ E]]

{[E]} = [[C| = C| ∧ E]]

134

The connectional expression on the right-hand side of ∧ may also contain a mix of

“C| ”s and “C| ”s.

To write an expression in terms of the relation-comprehension operator, we can usethe theorem that for a set B

E ◦B = [[C| = E]]◦B ⇐ E ∈ I <−−−) B

6.9 Notational conventions

For readability, we omit from now on the accents , ˙ and ¨ from formulas writtenwithin [[ ]] or {[ ]}, assuming that the reader is able to put these accents at the right

places. We furthermore prefer the notation [[C| = E]] to E, although we have to be

careful that E is properly typed. So, the last equation of section 6.8.3 is from nowon written as

R ◦ [[C| = C|+2]]˘ ◦ [[C| ≤ C| ]] ◦ [[C| = C|+1]] ◦ R

= {substitution, C| +2, C| +1 ∈ I <−−−) R}

R ◦[[C|+2 ≤ C|+1]]◦R

6.10 Conclusions

The purpose of this chapter was to introduce a model for expressions that incorpo-rates non-strictness in an elegant way. The idea of ‘semantic expressions’ is not new,although we do not know to whom this idea should be attributed. Our treatment ofnon-strictness appears to be new however, being the result of our detailed analysisof product-like constructs.

This chapter contains several theorems that show how fundamental concepts liketyping and substitution fit into the presented model for expressions. Although mosttheorems are formulated in terms of a single variable (the context), the theory aboutconnectional expressions illustrates how to treat contexts that consist of multiplevariables, like the type of contexts that we introduce in chapter 10.

135

Chapter 7

Specifications

In this chapter we show how several concepts that are often found in practical speci-fication languages can be formalised if we use relations as model for specifications.

7.1 Refinement

Refinement plays an essential role in the development of software. If we choose acertain refinement relation for our development process, we fix what we considerto be ‘acceptable specialisations’ (refinements) of some specification. In the con-text of a refinement where S′ refines S, we call S′ the fine specification and S thecoarse specification.

If we talk about refinement, we mean refinement with refinement relation ⊆, alsocalled partial refinement. A specification S′ is a thus refinement of a specificationS if S′ is a subrelation of S:

S′ ⊆ S

Refinements of a relation are created by reducing the collection of outputs that arepossible on an input, even if the collection becomes empty. The specification thattells that the inputs and outputs are integer numbers and that the output is at mostthe input:

ZZ ◦[[C| ≤ C| ]]◦ZZ

is for example refined by the specification that tells that the input is an integernumber and that the output is one less than the input:

[[C| = C|−1]]◦ZZ

137

It is however also refined by the specification that tells that the output is integerand that the input is the square of the output:

ZZ ◦[[C| 2 = C| ]]

The original specification connects every integer input to some output, but thisrefinement does not. It is for example empty in 2. This emptiness issue is addressedin section 7.8.

7.2 Post and pre

A specification is often described by means of a post that tells what the specifi-cation guarantees and a pre that tells under which circumstances the specificationguarantees this. In our relational model, a post is a relation R, describing whichoutputs the specification connects with which inputs, and a pre is a set P , describ-ing the inputs for which the specification guarantees something. The specificationS that is described by them, is defined by

S = R/P

or equivalently:

S = R ⊂= Π◦P

or point wise:

y (−S −) z ≡ (y (−R−) z ⇐ z ∈ P )

An example is the specification sqrt that outputs the square root of its input if thisinput is a real number that is at least zero:

sqrt = sqrtpost / sqrtpre

sqrtpost = [[C| =√

C| ]]sqrtpre = {[C| ∈ R ∧ C| ≥ 0]}

Inputs that do not adhere to the pre, in the example the inputs that are less thanzero or not even a real number, are connected to every output. This means thata refinement is completely free in its behaviour for such inputs. Specifically, aspecification that is described by a post R and a pre P is refined by a specificationthat is described by a post R′ and a pre P ′ if P refines P ′ and R′ refines R forinputs from P :

R′/P ′ ⊆ R/P

⇐ {• P and P ′ are sets}P ⊆ P ′ ∧ R′ ◦P ⊆ R

138

A more general case is proved in section 7.3.5.

7.3 Partial correctness

By generalising pres to be relations instead of sets, it is possible to construct a proofsystem for refinement that is very similar to Hoare logic for partial correctness[24].

The partial-correctness operator −−) (−− ∈ B <−−−| (I )−−−( I)×(I )−−−( I)×(I )−−−( I) is de-fined by any of the following three equations:

R −−)S(−−P ≡ S ⊆ R/PR −−)S(−−P ≡ S ◦P ⊆ RR −−)S(−−P ≡ P ⊆ S\R

If R −−)S(−−P holds, we call specification S partially correct with respect to post Rand pre P . The pre P is ‘what has already been established’, the post R is ‘whathas to be established’ and the specification S is ‘how it is established’. Notice thatwe place the post on the left and the pre on the right. An example is

ZZ ◦[[C| > C| ]]◦ZZ −−)[[C| = C|+1]](−− ZZ ◦[[C| ≥ C| ]]◦ZZ

telling that if it has already been established that the output is an integer numberthat is at least as large as the integer input, then adding 1 transforms this outputinto an integer number that is larger than the input.

In the following subsections we introduce several partial-correctness rules thatshow how R −−)S(−−P can be proved in certain cases. An example shows these rules inaction. Except for the rule for /, no rule strengthens the original proof obligation.This gives some sense of completeness, a property that is often strived for in proofsystems. The rules whose proof is omitted, are trivial results of the three definitionsof −−) (−− .

7.3.1 Conjunctivity of post

The partial-correctness proof of a specification with respect to a post that is theintersection of two relations, can be split up into two partial-correctness proofs:

R0∩R1 −−)S(−−P≡

R0 −−)S(−−P ∧ R1 −−)S(−−P

139

7.3.2 Disjunctivity of pre

The partial-correctness proof of a specification with respect to a pre that is theunion of two relations, can also be split up into two partial-correctness proofs:

R −−)S(−−P 0∪P 1

≡R −−)S(−−P 0 ∧ R −−)S(−−P 1

7.3.3 Binary union

Partial correctness of the union of two specifications can be split up into partialcorrectness of the individual specifications:

R −−)S0∪S1(−−P≡

R −−)S0(−−P ∧ R −−)S1(−−P


For the sequential composition we have three partial-correctness rules. The first onesays that we have to invent a relation X that acts as post for the ‘firstly executed’specification S1 and as pre for the ‘secondly executed’ specification S0:

R −−)S0◦S1(−−P≡∃〈X |||| R −−)S0(−−X ∧ X −−)S1(−−P 〉

proof

R −−)S0◦S1(−−P≡ {definition of −−) (−− }

S0◦S1◦P ⊆ R

≡ {(⇒): take X = S1◦P , (⇐): monotonicity of ◦ and transitivity of ⊆}∃〈X |||| S0◦X ⊆ R ∧ S1◦P ⊆ X〉

≡ {definition of −−) (−− }∃〈X |||| R −−)S0(−−X ∧ X −−)S1(−−P 〉

The second rule tells how the pre should be transformed in order to eliminate the‘firstly executed’ specification S1:

140

R −−)S0◦S1(−−P≡

R −−)S0(−−S1◦P

The third rule tells how the post should be transformed in order to eliminate the‘secondly executed’ specification S0:

R −−)S0◦S1(−−P≡

S0\R −−)S1(−−P

7.3.5 Over

Partial correctness of a specification that is described by means of a post/pre com-bination, can be proved with the following rule:

R −−)R′/P ′(−−P≡ {• P ′ is a set and • P < ⊆ P ′}

R −−)R′(−−P

proof

R −−)R′/P ′(−−P≡ {definition of −−) (−− }

(R′/P ′)◦P ⊆ R

≡ {R′/P ′ = R′ ⊂= Π◦P ′ if • P ′ is a set}(R′ ⊂= Π◦P ′)◦P ⊆ R

≡ {X ⊂= Y = X ∪ �Y }(R′ ∪ �(Π◦P ′))◦P ⊆ R

≡ {distribution of ◦ over ∪}R′ ◦P ∪ �(Π◦P ′)◦P ⊆ R

≡ { �(Π◦P ′)◦P = ©� if • P < ⊆ P ′>}R′ ◦P ∪ ©� ⊆ R

≡ {©� is unit of ∪}R′ ◦P ⊆ R

≡ {definition of −−) (−− }R −−)R′(−−P

Informally, this rule can be read as: “The pre of the call should imply the pre of thecalled specification and the post of the called specification should imply the post ofthe call under the assumption of the pre of the call.”.

141


The identity relation is correct with respect to post R and pre P if R is refined byP :

R −−)I(−−P≡

R ⊇ P

7.3.7 Iteration

Partial correctness of the iteration of a specification can be proved by inventing aproper loop invariant X :

R −−)S*(−−P≡∃〈X |||| R ⊇ X ∧ X −−)S(−−X ∧ X ⊇ P 〉

proof

We split the proof into (⇒) and (⇐):

(⇒):

R −−)S*(−−P≡ {definition of −−) (−− }

S*◦P ⊆ R

⇒ {take X = S*◦P and use the facts S ◦S* ⊆ S* and I ⊆ S*}∃〈X |||| X ⊆ R ∧ S ◦X ⊆ X ∧ P ⊆ X〉

≡ {definition of −−) (−− }∃〈X |||| X ⊆ R ∧ X −−)S(−−X ∧ P ⊆ X〉

(⇐):

142

R −−)S*(−−P≡ {definition of −−) (−− }

S* ⊆ R/P

⇐ {• P ⊆ X ∧ X ⊆ R}S* ⊆ X/X

≡ {property of *, X/X is a preorder (left to the reader)}S ⊆ X/X

≡ {definition of −−) (−− }X −−)S(−−X

7.3.8 If-then-else

The if-then-else if then else ∈ (I )−−−( I) <−−−| ℘I×(I )−−−( I)×(I )−−−( I) is defined by

if B then S0 else S1

=

S0◦B ∪ S1◦(IrB)

or equivalently:

if B then S0 else S1

=

S0/B ∩ S1/(IrB)

The equivalence of both definitions is a result of the fact that the guards B andIrB are disjoint (B ∩ IrB = ©�) and set-conjoint (B ∪ IrB = I).

A partial-correctness rule for if B then S0 else S1 can be derived from the rules ofthe constituent components:

R −−)if B then S0 else S1(−−P≡ {definition of if then else }

R −−)S0◦B ∪ S1◦(IrB)(−−P≡ {partial-correctness rule for ∪}

R −−)S0◦B(−−P ∧ R −−)S1◦(IrB)(−−P≡ {second partial-correctness rule for ◦}

R −−)S0(−−B ◦P ∧ R −−)S1(−−(IrB)◦P

7.3.9 While

Another common construct in programming languages is the while. The program

143

while {[C| 6= 0 ∧ C| 6= 1]} do [[C| = C|−2]]

outputs for example 0 if the input is a non-negative even integer and 1 if the inputis a non-negative odd integer. If x is a negative integer, the program enters aninfinite loop.

How should we define the ‘while’ in our relational model? The following equationshows the general intuition behind its meaning:

while B do S

=

if B then (while B do S)◦S else I

So, while B do S is a fixed point of the function

〈if B then X ◦S else I || X〉

Which fixed point should we now take? In case we want to be able to describeinfinite behaviour with the ‘while’, the least fixed point does not seem a propercandidate because it identifies while I do S with ©� for each S:

µ〈if I then X ◦S else I || X〉= {definition of if then else }

µ〈X ◦S ◦I ∪ I◦(IrI) || X〉= {I is unit of ◦, IrI = ©�, ©� is unit of ∪}

µ〈X ◦S || X〉= {©� is the smallest X such that X ◦S ⊆ X}

©�

If all infinite loops are identified with ©�, then a generalisation of relations thatcaptures information about events that occur while a program executes, would notbe able to capture events that occur in an infinite loop.

Maybe the greatest fixed point or even another one? We refrain from makinga choice by using the ‘while’ only in case we know for sure that the function〈if B then X ◦S else I || X〉 has exactly one fixed point. In [17] it is shown thatthis is equivalent to the relation S ◦B being well-founded. A compact definitionof well-foundedness of a relation R is ν〈X ◦R || X〉 = ©� (or using section notation:ν(◦R) = ©�).

Using the theorems of [17], the least fixed point of 〈if B then X ◦S else I || X〉 canbe shown to be equal to IrB ◦ (S ◦B)*. In other words, we have

144

while B do S

= {• S ◦B is well-founded}IrB ◦ (S ◦B)*

This rule is however a little too weak for our purposes. If we take a look at theexample that we presented at the beginning of this section:

while {[C| 6= 0 ∧ C| 6= 1]} do [[C| = C|−2]]

we want to be able to use the fact that this program does not enter an infinite loopif its input is a non-negative integer. We therefore generalise the above theorem,adding an input restriction:

(while B do S) ◦ A

= {• S ◦B ◦A is well-founded and • S ◦B ∈ A −−−◦ A}IrB ◦ (S ◦B)* ◦ A

So if we restrict the inputs to elements of some set A, we only need to prove thatS ◦B ◦A is well-founded and that S ◦B is such that we stay within A. To prove thistheorem, we prove the slightly more general (a monotonic total function f has asingle fixed point exactly when its least fixed point equals its greatest fixed point)

ν〈T ∪ X ◦R || X〉◦A= {• R◦A is well-founded and • R ∈ A−−−◦ A}

µ〈T ∪ X ◦R || X〉◦A

proof

The proof is a slight variation on a proof in [17]. The addition of the input constraintrequired some small modifications.

ν〈T ∪ X ◦R || X〉◦A = µ〈T ∪ X ◦R || X〉◦A≡ {νf ⊇ µf for every f ∈ PI <−−−|m PI, monotonicity of ◦}

ν〈T ∪ X ◦R || X〉◦A ⊆ µ〈T ∪ X ◦R || X〉◦A≡ {U ◦A ⊆ V ◦A ≡ U ◦A ⊆ V }

ν〈T ∪ X ◦R || X〉◦A ⊆ µ〈T ∪ X ◦R || X〉≡ {definition of µ}

ν〈T ∪ X ◦R || X〉◦A ⊆ ⋂{Y | T ∪ Y ◦R ⊆ Y | Y }≡ {point-free definition of

⋂

}∀〈Y || T ∪ Y ◦R ⊆ Y || ν〈T ∪ X ◦R || X〉◦A ⊆ Y 〉

⇐ {see below}ν〈X ◦R◦A || X〉 = ©� ∧ R ∈ A−−−◦ A

The last step in this proof is justified by the following calculation:

145

ν〈T ∪ X ◦R || X〉◦A ⊆ Y

≡ {U ◦A ⊆ V ≡ U ⊆ V ∪ Π◦(IrA)}ν〈T ∪ X ◦R || X〉 ⊆ Y ∪ Π◦(IrA)

≡ {• ν〈X ◦R◦A || X〉 = ©�, ©� is unit of ∪}ν〈T ∪ X ◦R || X〉 ⊆ Y ∪ Π◦(IrA) ∪ ν〈X ◦R◦A || X〉

⇐ {fusion with the following instantiations:G = 〈Y ∪ Π◦(IrA) ∪ X || X〉, distributes over

⋂

H = 〈X ◦R◦A || X〉K = 〈T ∪ X ◦R || X〉}

∀〈X |||| T ∪ (Y ∪ Π◦(IrA) ∪ X)◦R ⊆ Y ∪ Π◦(IrA) ∪ X ◦R◦A〉≡ {distribution of ◦ over ∪}∀〈X |||| T ∪ Y ◦R ∪ Π◦(IrA)◦R ∪ X ◦R ⊆ Y ∪ Π◦(IrA) ∪ X ◦R◦A〉

≡ {U ⊆ V ∪ Π◦(IrA) ≡ U ◦A ⊆ V }∀〈X |||| (T ∪ Y ◦R ∪ Π◦(IrA)◦R ∪ X ◦R)◦A ⊆ Y ∪ X ◦R◦A〉

≡ {distribution of ◦ over ∪}∀〈X |||| T ◦A ∪ Y ◦R◦A ∪ Π◦(IrA)◦R◦A ∪ X ◦R◦A ⊆ Y ∪ X ◦R◦A〉

≡ {(⇒): take X = ©�, (⇐): monotonicity of ∪}T ◦A ∪ Y ◦R◦A ∪ Π◦(IrA)◦R◦A ⊆ Y

≡ {• R ∈ A −−−◦ A, then (IrA)◦R◦A = ©�}T ◦A ∪ Y ◦R◦A ∪ Π◦©� ⊆ Y

≡ {©� is zero of ◦, ©� is unit of ∪}T ◦A ∪ Y ◦R◦A ⊆ Y

≡ {distribution of ◦ over ∪}(T ∪ Y ◦R)◦A ⊆ Y

⇐ {U ◦A ⊆ U , transitivity of ⊆}T ∪ Y ◦R ⊆ Y

If we use the theorem about the ‘while’ with the input restriction and write outthe partial-correctness rules of the constituent components, we arrive at the ‘well-known’ rule for the ‘while’:

R −−)while B do S(−−P≡ {• S ◦B ◦(P <) is well-founded and • S ◦B ∈ P <−−−◦ P <}

R −−)IrB ◦ (S ◦B)*(−−P≡ {third partial-correctness rule for ◦}

(IrB)\R −−)(S ◦B)*(−−P≡ {partial-correctness rule for *}∃〈X |||| (IrB)\R ⊇ X ∧ X −−)S ◦B(−−X ∧ X ⊇ P 〉

≡ {second partial-correctness rule for ◦}∃〈X |||| (IrB)\R ⊇ X ∧ X −−)S(−−B ◦X ∧ X ⊇ P 〉

≡ {definition of \}∃〈X |||| R ⊇ (IrB)◦X ∧ X −−)S(−−B ◦X ∧ X ⊇ P 〉

146

7.3.10 Assignment

In case a specification is functional and total on the range of the pre, we canuse the following rule that we suggestively call the partial-correctness rule for theassignment:

R −−)S(−−P≡ {• S ∈ I <−−−) P <}

S˘◦R ⊇ P

proof

R −−)S(−−P≡ {definition of −−) (−− }

S ◦P ⊆ R

≡ {shunting, • S ∈ I <−−−) P <}P ⊆ S˘◦R

7.3.11 Example

In this section we present an example to demonstrate the partial-correctness rules.The specification more outputs a real number smaller than 1 and larger than theabsolute value of the input if its input is a real number between −1 and 1, unequalto 0:

more = morepost / morepre

morepost = [[C| ∈ R ∧ |C| | < C| ∧ C| < 1]]morepre = {[C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

We now prove that more is refined by more ′, defined by

more ′ = sqrt ◦ abs

sqrt = sqrtpost / sqrtpre

sqrtpost = [[C| =√

C| ]]sqrtpre = {[C| ∈ R ∧ C| ≥ 0]}

abs = I◦{[C| ≥ 0]} ∪ [[C| = −C| ]]◦{[C| ≤ 0]}

We thus have to prove more ′ ⊆ morepost/morepre, or writing it with the partial-correctness operator:

morepost −−)more ′(−−morepre

Using the first partial-correctness rule for the composition, we have to invent a

147

relation moreint such that

morepost

−−)sqrt(−−

moreint

−−)abs(−−

morepre

We start with morepost −−)sqrt(−−more int. Writing out the definition of sqrt , the partial-correctness rule for the ‘over’ leaves us with

moreint< ⊆ sqrtpre ∧ morepost −−)sqrtpost(−−moreint

which can be rewritten into the following point-wise form:

∀〈x0, x1, x2|| x1 (−moreint −) x2|| x1 ∈ sqrtpre ∧ (x0 (−sqrtpost −) x1 ⇒ x0 (−morepost −) x2)〉

The following calculation shows a possible choice for moreint :

x1 ∈ sqrtpre ∧ (x0 (−sqrtpost −) x1 ⇒ x0 (−morepost −) x2)

≡ {definition of sqrtpre}x1 ∈ {[C| ∈ R ∧ C| ≥ 0]} ∧ (x0 (−sqrtpost −) x1 ⇒ x0 (−morepost −) x2)

≡ {sections 6.7 and 6.4}x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 (−sqrtpost −) x1 ⇒ x0 (−morepost −) x2)

≡ {definition of sqrtpost}

x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 (−[[C| =√

C| ]]−) x1 ⇒ x0 (−morepost −) x2)

≡ {sections 6.6, 6.4 and 6.8.2}x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 =

√x1 ⇒ x0 (−morepost −) x2)

≡ {definition of morepost}

x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 =√

x1 ⇒ x0 (−[[C| ∈ R ∧ |C| | < C| ∧ C| < 1]]−) x2)

≡ {sections 6.6, 6.4 and 6.8.2, • x2 ∈ R}x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 =

√x1 ⇒ (x0 ∈ R ∧ |x2| < x0 ∧ x0 < 1))

≡ {(x1 ∈ R ∧ x1 ≥ 0 ∧ x0 =√

x1) ⇒ x0 ∈ R}x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 =

√x1 ⇒ (|x2| < x0 ∧ x0 < 1))

≡ {Leibniz}x1 ∈ R ∧ x1 ≥ 0 ∧ (x0 =

√x1 ⇒ (|x2| <

√x1 ∧

√x1 < 1))

≡ {• x1 = |x2| together with previous ‘•’, then x1 ∈ R ∧ x1 ≥ 0}x0 =

√x1 ⇒ (x1 <

√x1 ∧

√x1 < 1)

≡ {• x1 6= 0 ∧ x1 < 1 together with previous ‘•’s}true

148

Notice that if we want to do this calculation at the level of expressions rather thanat the (not completely formalised) level of formulas in the mathematical languagethat we use, we need expressions that can talk about three points instead of onlytwo (C| and C| ). To be able to do complicated calculations like the one above, theexpression formalism should also be developed much more than it is now. We leavethat for future research.

Putting it all together, we found the following restrictions on x1 and x2:

x2 ∈ R ∧ x1 = |x2| ∧ x1 6= 0 ∧ x1 < 1

which means the following choice for more int:

moreint = [[C| ∈ R ∧ C| = |C| | ∧ C| 6= 0 ∧ C| < 1]]

We now arrive at the other part of the composition: more int −−)abs(−−morepre. Writingout the definition of abs :

moreint −−)I◦{[C| ≥ 0]} ∪ [[C| = −C| ]]◦{[C| ≤ 0]}(−−morepre

the partial-correctness rule for the union leaves us with the following two proofobligations:

moreint −−) I ◦{[C| ≥ 0]}(−−morepre

moreint −−)[[C| = −C| ]]◦{[C| ≤ 0]}(−−morepre

Writing out the definition of morepre:

moreint −−) I ◦{[C| ≥ 0]}(−− {[C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}moreint −−)[[C| = −C| ]]◦{[C| ≤ 0]}(−− {[C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

we apply the second partial-correctness rule for the composition and use the factthat {[E0]}◦{[E1]}, {[E0]}∩{[E1]} and {[E0∧E1]} are equal:

moreint −−) I (−−{[C| ≥ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}moreint −−)[[C| = −C| ]](−−{[C| ≤ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

We start with the first of these two proof obligations. The partial-correctness rulefor I leaves us with:

moreint ⊇ {[C| ≥ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

This can be proved as follows:

149

moreint

= {definition of more int}

[[C| ∈ R ∧ C| = |C| | ∧ C| 6= 0 ∧ C| < 1]]

⊇ {section 6.6 and theorem lifting (section 6.4)}

[[C| = C| ∧ C| ≥ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]]

= {section 6.8.4}{[C| ≥ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

For the second one,

moreint −−)[[C| = −C| ]](−−{[C| ≤ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

we use the partial-correctness rule for the assignment (notice that −C| ∈ I <−−−) R)and calculate:

[[C| = −C| ]]˘ ◦ more int

= {definition of more int}

[[C| = −C| ]]˘ ◦ [[C| ∈ R ∧ C| = |C| | ∧ C| 6= 0 ∧ C| < 1]]

⊇ {R ⊇ A◦R for a set A}

R ◦ [[C| = −C| ]]˘ ◦ [[C| ∈ R ∧ C| = |C| | ∧ C| 6= 0 ∧ C| < 1]]

= {substitution, −C| ∈ I <−−−) R (section 6.8.3)}

R ◦[[C| ∈ R ∧ −C| = |C| | ∧ −C| 6= 0 ∧ −C| < 1]]

⊇ {section 6.6 and theorem lifting (section 6.4)}

R ◦[[C| = C| ∧ C| ≤ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]]

= {A◦[[E]] = [[C| ∈ A ∧ E]]}

[[C| = C| ∧ C| ≤ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]]

= {section 6.8.4}{[C| ≤ 0 ∧ C| ∈ R ∧ −1 < C| ∧ C| 6= 0 ∧ C| < 1]}

This completes our proof of the fact that more ′ is a refinement of more.

7.4 Type, declarative and operational

It is often convenient to split up a post into a post-type, a post-condition andan action clause, and a pre into a pre-type and a pre-condition. Pre-types andpost-types are sets that are thought of to be ‘simple’ like ZZ or B. A pre-conditionis a set that is described by means of some kind of unary predicate-logic formulaand a post-condition is a relation that is described by means of some kind of bi-nary predicate-logic formula. The action clause deserves some more explanation. Inmost theories about sequential programming, the pre-condition and post-conditionspecify the ‘desired behaviour’ of a program in a declarative way. Then, separate

150

from the pre-condition and post-condition, there is code that implements the be-haviour that is specified by them in an operational way. The operational code ishowever often more readable than the declarative specification. This does not reallystimulate the use of pre-conditions and post-conditions. The fact that declarativespecifications are often much harder to read than the corresponding operational codeis not that strange because many specifications of everyday life have an operationalnature. A pragmatic specification language, like ISpec, therefore combines bothdeclarative and operational descriptions, resulting in compact and understandablespecifications. Hence the action clause.

An example of a specification mod2 for the ‘modulo 2’ of a ‘two’s complement byte’is

mod2 = post / pre

post = postType ◦Π ∩ postCondition ∩ actionClausepre = preType ∩ preCondition

postType = ZZ

preType = ZZ

postCondition = [[0 ≤ C| ∧ C| < 2]]preCondition = {[−128 ≤ C| ∧ C| < 128]}

actionClause = ([[C| = C|−2]] ∪ [[C| = C|+2]])*

The pre-type and pre-condition together say that the input should be a two’s com-plement byte. If this is the case, then the post-type and post-condition togethertell us that the output is either 0 or 1 and the action clause tells us that 2 isadded/subtracted several times to/from the input. This specification thus clearlydescribes the modulo 2 of a two’s complement byte.

We now prove that mod2′, defined by

mod2′ = while {[C| < 0 ∨ 2 ≤ C| ]} do

if {[C| ≥ 0]}then [[C| = C|−2]]

else [[C| = C|+2]]

is a refinement of mod2.

An advantage of separating a post into type, declarative and operational aspects,is that partial-correctness proofs can also be separated into these aspects. This isa trivial consequence of the conjunctivity of the post (see section 7.3.1):

151

post −−)mod2′(−−pre≡ {definition of post}

(postType ◦Π ∩ postCondition ∩ actionClause) −−)mod2′(−− pre

≡ {conjunctivity of post}postType ◦Π −−)mod2′(−− pre ∧postCondition −−)mod2′(−− pre ∧actionClause −−)mod2′(−− pre

Before we continue, we first introduce some shorthands:

mod2′ = while WG do IFIF = if IG then S2 else A2WG = {[C| < 0 ∨ 2 ≤ C| ]}IG = {[C| ≥ 0]}S2 = [[C| = C|−2]]

A2 = [[C| = C|+2]]

We now show that we are allowed to use the least–fixed-point interpretation ofthe ‘while’. Section 7.3.9 tells us that this follows from the fact that IF ◦WG ◦ZZ iswell-founded and IF ◦WG ∈ ZZ −−−◦ ZZ. We have not introduced practical theory forproving well-foundedness, but assume that the reader believes us when we say thatIF ◦WG ◦ZZ is well-founded. The fact that IF ◦WG ∈ ZZ −−−◦ ZZ, can be proved by asimple type proof (the cylindric-type rules can be found in section 4.1):

IF ◦WG ∈ ZZ −−−◦ ZZ

⇐ {cylindric-type rule for ◦}IF ∈ ZZ −−−◦ ZZ ∧ WG ∈ ZZ −−−◦ ZZ

≡ {definition of IF , WG ∈ ZZ −−−◦ ZZ follows from the cylindric-type rules for I and ⊆}if IG then S2 else A2 ∈ ZZ −−−◦ ZZ

≡ {definition of if then else }S2◦IG ∪ A2◦(IrIG) ∈ ZZ −−−◦ ZZ

⇐ {cylindric-type rule for ∪}S2◦IG ∈ ZZ −−−◦ ZZ ∧ A2◦(IrIG) ∈ ZZ −−−◦ ZZ

⇐ {cylindric-type rule for ◦}S2 ∈ ZZ −−−◦ ZZ ∧ IG ∈ ZZ −−−◦ ZZ ∧ A2 ∈ ZZ −−−◦ ZZ ∧ IrIG ∈ ZZ −−−◦ ZZ

≡ {IG, IrIG ∈ ZZ −−−◦ ZZ follows from the cylindric-type rules for I and ⊆}S2 ∈ ZZ −−−◦ ZZ ∧ A2 ∈ ZZ −−−◦ ZZ

⇐ {A <−−−) B ⊆ A−−−◦ B}S2 ∈ ZZ <−−−) ZZ ∧ A2 ∈ ZZ <−−−) ZZ

≡ {chapter 6}true

We thus know that we can use the least–fixed-point interpretation of the ‘while’ if

152

the inputs are of type ZZ. We now prove

postType ◦Π −−)mod2′(−−preType∩preCondition

We can simply stay on the type level and do not need the pre-condition. Using thefact that

A◦Π −−)S(−−B ≡ S ∈ A−−−◦ B

we again have a simple type proof:

mod2′ ∈ ZZ −−−◦ ZZ

≡ {definition of mod2′}while WG do IF ∈ ZZ −−−◦ ZZ

≡ {least–fixed-point interpretation of the ‘while’, see above text}IrWG ◦ (IF ◦WG)* ∈ ZZ −−−◦ ZZ

⇐ {cylindric-type rule for ◦, I and ⊆}(IF ◦WG)* ∈ ZZ −−−◦ ZZ

⇐ {cylindric-type rule for *}IF ◦WG ∈ ZZ −−−◦ ZZ

≡ {see above proof}true

Now for the post-condition. Again we only need the fact that the input is of typeZZ:

153

postCondition −−)mod2′(−− ZZ≡ {definition of mod2′}

postCondition −−)while WG do IF (−− ZZ≡ {least fixed point interpretation of the ‘while’}

postCondition −−)IrWG ◦ (IF ◦WG)*(−− ZZ≡ {definition of −−) (−− }

IrWG ◦ (IF ◦WG)* ◦ ZZ ⊆ postCondition

≡ {(IF ◦WG)* ∈ ZZ −−−◦ ZZ, see previous proof}IrWG ◦ ZZ ◦ (IF ◦WG)* ◦ ZZ ⊆ postCondition

⇐ {R◦S ⊆ T ⇐ R◦Π ⊆ T}IrWG ◦ ZZ ◦ Π ⊆ postCondition

≡ {definition of WG and postCondition}

Ir{[C| < 0 ∨ 2 ≤ C| ]} ◦ ZZ ◦ Π ⊆ [[0 ≤ C| ∧ C| < 2]]

≡ {(Ir{[E]})◦B = {[C| ∈ B ∧ ¬E]} if E ∈ I <−−−) B}

{[C| ∈ ZZ ∧ ¬(C| < 0 ∨ 2 ≤ C| )]} ◦ Π ⊆ [[0 ≤ C| ∧ C| < 2]]

≡ {{[E]}◦Π = [[E]]}

[[C| ∈ ZZ ∧ ¬(C| < 0 ∨ 2 ≤ C| )]] ⊆ [[0 ≤ C| ∧ C| < 2]]

≡ {theorem lifting}true

Notice that the only thing we used from the ‘while’ is its guard.

The last thing we need to prove is the action clause:

actionClause −−)mod2′(−−preType

≡ {similar to previous calculation}IrWG ◦ (IF ◦WG)* ◦ preType ⊆ actionClause

⇐ {IrWG , WG and preType are sets}IF* ⊆ actionClause

≡ {definition of IF}(if IG then S2 else A2)* ⊆ actionClause

≡ {definition of if then else}(S2◦IG ∪ A2◦(IrIG))* ⊆ actionClause

⇐ {IG and IrIG are sets}(S2 ∪ A2)* ⊆ actionClause

≡ {definition of S2, A2 and actionClause}

([[C| = C|−2]] ∪ [[C| = C|+2]])* ⊆ ([[C| = C|−2]] ∪ [[C| = C|+2]])*

≡ {reflexivity of ⊆}true

154

Notice that we could do this proof completely at the operational level. This cleanseparation of type, declarative and operational reasoning is not always possible, butshould in our opinion be strived for as much as possible in order to keep refinementcomprehensible.

7.5 Structural hierarchy

An important concept in specification/programming languages is structural hi-erarchy in specifications/programs. In traditional sequential programming, a pro-gram consists of a collection of procedures. The structural hierarchy in classicalobject-oriented programming has one layer extra. There a program consists ofclasses which again consist of methods. Moreover, most modern object-orientedlanguages allow to put classes into packages and even allow to put packages intopackages, enabling the construction of arbitrary structural hierarchies. Some object-oriented languages allow to put classes into classes. The class inside another classis then called an inner class of that class.

The pack operators that we introduced in chapter 5 enable the hierarchical structur-ing of specifications. We use the pack operator that corresponds to the conjoint sumbecause that one has the properties that we find desirable. This includes the factthat is resembles the disjoint sum, making it ‘more familiar’ than other candidates.We therefore define the pack ⊳ by

⊳ = ©⊳ UNI ∩FUN ∩NMP∩DEQ

We illustrate the use of ⊳ by means of a simple specification MATH that contains aclass with name Crease and body Crease1 with a method named inc whose bodyinc1 increases its input by 1 and a method named dec whose body dec1 decreases itsinput by 1. Specification MATH also contains a class Three with a method direct

that outputs 3 on any input, calculated by subtracting 1 from 4, using method dec

of class Crease. Class Three also has a method indirect that outputs 3 on anyinput, but calculates this by subtracting 1 from the output of procedure four, usingmethod dec of class Crease. The procedure four again calculates its output byadding 1 to the output of method direct of class Three, using method inc of classCrease:

MATH = Crease1⊳Crease ∩ Three⊳Three ∩ four⊳fourCrease1 = inc1⊳inc ∩ dec1⊳decThree = direct3⊳direct ∩ indirect3⊳indirect

inc1 = [[C| = C|+1]]

dec1 = [[C| = C|−1]]

direct3 = (MATH ⊲Crease)⊲dec ◦ [[C| = 4]]indirect3 = (MATH ⊲Crease)⊲dec ◦ MATH ⊲fourfour = (MATH ⊲Crease)⊲inc ◦ (MATH ⊲Three)⊲direct

The following equation illustrates the behaviour of MATH :

155

((MATH ⊲Three)⊲indirect).z = 3

proof

((MATH ⊲Three)⊲indirect).z

= {MATH ⊲Three = Three, see below}(Three⊲indirect).z

= {Three⊲indirect = indirect3, similar}indirect3.z

= {definition of indirect3}((MATH ⊲Crease)⊲dec ◦ MATH ⊲four).z


(dec1 ◦ inc1 ◦ dec1 ◦ [[C| = 4]]).z

= {left to the reader}3

MATH ⊲ Three

= {definition of MATH }(Crease1⊳Crease ∩ Three⊳Three ∩ four⊳four) ⊲ Three

= {distribution of (⊲i) over ∩}(Crease1⊳Crease ⊲ Three) ∩(Three ⊳Three ⊲ Three) ∩(four ⊳four ⊲ Three)

= {cancellation}Π ∩ Three ∩ Π

= {Π is unit of ∩}Three

In the following example we show a way to prove refinement between two structural-hierarchical specifications. The specification Crease, consisting of two proceduresinc and dec where inc outputs an integer that is larger than its integer input anddec outputs an integer that is smaller than its integer input:

Crease = inc⊳inc ∩ dec⊳dec

inc = ZZ ◦[[C| > C| ]]◦ZZdec = ZZ ◦[[C| < C| ]]◦ZZ

is refined by the specification Crease ′ that consists of three procedures inc, dec andchg where inc adds 1 to its integer input, dec subtracts 1 from its integer inputand chg outputs an integer that is different from its integer input:

156

Crease ′ = inc′⊳inc ∩ dec′⊳dec ∩ chg ′⊳chg

inc′ = [[C| = C|+1]]◦ZZ

dec′ = [[C| = C|−1]]◦ZZ

chg ′ = ZZ ◦[[C| 6= C| ]]◦ZZ

proof

Crease ′ ⊆ Crease

≡ {definition of Crease ′ and Crease}inc′⊳inc ∩ dec′⊳dec ∩ chg ′⊳chg ⊆ inc⊳inc ∩ dec⊳dec

⇐ {R∩S ⊆ S}inc′⊳inc ∩ dec′⊳dec ⊆ inc⊳inc ∩ dec⊳dec

⇐ {monotonicity of ∩}inc′⊳inc ⊆ inc⊳inc ∧ dec′⊳dec ⊆ dec⊳dec

≡ {monomorphity of (⊳i)}inc′ ⊆ inc ∧ dec′ ⊆ dec

≡ {see below}true

inc′ ⊆ inc

≡ {definition of inc′ and inc}

[[C| = C|+1]]◦ZZ ⊆ ZZ ◦[[C| > C| ]]◦ZZ≡ {x1 ∈ ZZ ∧ x0 = x1+1 ⇒ x0, x1 ∈ ZZ ∧ x0 > x1}

true

Similar for dec′ ⊆ dec.

This example shows the anti-monotonicity of the conjoint sum in action. Because,in contrast to the disjoint sum, adding something to a conjoint sum is done by meansof intersection instead of union, we can simply use inclusion for refinement and donot need to complicate things with functions that project away new procedures.

In the second and third step of the proof it seems as if we are strengthening ourproof obligation. The following calculation however shows that this is not the case:

157

inc′⊳inc ∩ dec′⊳dec ∩ chg ′⊳chg ⊆ inc⊳inc ∩ dec⊳dec

⇒ {monotonicity of (⊲i)}(inc′⊳inc ∩ dec ′⊳dec ∩ chg ′⊳chg)⊲inc ⊆ (inc⊳inc ∩ dec⊳dec)⊲inc ∧(inc′⊳inc ∩ dec ′⊳dec ∩ chg ′⊳chg)⊲dec ⊆ (inc⊳inc ∩ dec⊳dec)⊲dec

≡ {distribution of (⊲i) over ∩ and cancellation}inc′ ∩ Π ∩ Π ⊆ inc ∩ Π ∧Π ∩ dec′ ∩ Π ⊆ Π ∩ dec

≡ {Π is unit of ∩}inc′ ⊆ inc ∧ dec′ ⊆ dec

7.6 Components

With the increasing complexity of tasks that have to be performed by softwareand the increasing development effort that has to be spent in order to build suchsoftware, the wish came that software could be constructed from componentsthat can be developed independently from each other. As a result, a new paradigmemerged, called component-oriented programming.

A prime ingredient of component-oriented programming is component composi-tion. Suppose that several teams are refining distinct parts of a specification. Eachteam is responsible for a correct refinement of its part, without knowing how theother teams refine their parts. The component composition of all these refinementsshould now result in a specification that refines the original specification.

The model for specifications of this chapter (relations) provides a simple definitionof components and their composition. Before giving the formal definitions, we firstillustrate the main idea by means of an example.

We want two separate teams to refine the specification Crease:

Crease = inc⊳inc ∩ dec⊳dec

inc = ZZ ◦[[C| > C| ]]◦ZZdec = ZZ ◦[[C| < C| ]]◦ZZ

Team INC develops the following specification that refines procedure inc:

Increase = inc′⊳inc ∩ dec⊳dec

inc′ = [[C| = C|+1]]◦ZZ

Team DEC develops the following solution:

Decrease = inc⊳inc ∩ dec′⊳dec

dec′ = [[C| = C|−1]]◦ZZ

The intersection of Increase and Decrease, Crease ′, now consists of a procedure inc

158

with body inc′ and a procedure dec with body dec ′. This matches the commonintuition about what component composition means:

Crease ′ = inc′⊳inc ∩ dec′⊳dec

proof

Crease ′

= {definition of Crease ′}Increase ∩ Decrease

= {definition of Increase and Decrease}inc′⊳inc ∩ dec⊳dec ∩ inc⊳inc ∩ dec′⊳dec

= {associativity and commutativity of ∩}inc′⊳inc ∩ inc⊳inc ∩ dec⊳dec ∩ dec′⊳dec

= {distribution of (⊳i) over ∩}(inc′∩inc)⊳inc ∩ (dec∩dec ′)⊳dec

= {inc′ ⊆ inc and dec ′ ⊆ dec}inc′⊳inc ∩ dec′⊳dec

Furthermore, Crease ′ clearly is a refinement of Crease.

Separation of a specification into distinct parts is done by means of its input values.In the above example, two distinct parts of the specification are described by thetwo disjoint sets of input values INC and DEC , defined by

INC = I )−−−( {inc}DEC = I )−−−( {dec}

The following equation shows the partitioning of the specification into distinct parts:

Crease ′ = Increase ◦INC ∪ Decrease ◦DEC ∪ Crease ◦(I r INC∪DEC )

We now formalise the ideas in this example. We call a specification S′ a Z-overrideof a specification S if S′ is equal to S for inputs outside the set Z. We define theis-Z-override-of ©Z ∈ B <−−−| (I )−−−( I)×(I )−−−( I) by

S′ ©Z S ≡ S′ ◦(IrZ) = S ◦(IrZ)

If for disjoint sets Z0 and Z1, S0 is a Z0-override of S and S1 is a Z1-override of S,then the component composition of S0 and S1 (S0∩S1) is the specification S0 forinputs from Z0, the specification S1 for inputs from Z1 and the specification S forall other inputs:

159

S0∩S1 = S0◦Z0 ∪ S1◦Z1 ∪ S ◦(I r Z0∪Z1)

⇐ {• Z0 and Z1 are disjoint sets}S0 ©Z0

S ∧ S1 ©Z1S

A trivial consequence is that S0∩S1 is a Z0∪Z1-override of S (disjointness of Z0

and Z1 is not needed):

S0∩S1 ©Z0∪Z1S

⇐

S0 ©Z0S ∧ S1 ©Z1

S

In the above example we have

Increase ©INC CreaseDecrease ©DEC Crease

and therefore

Increase∩Decrease ©INC∪DEC Crease

We call a specification S′ a Z-refinement of a specification S if S′ is a refinementand a Z-override of S. The is-Z-refinement-of ⊆Z ∈ B <−−−| (I )−−−( I)×(I )−−−( I) isdefined by

S′ ⊆Z S ≡ S′ ⊆ S ∧ S′ ©Z S

For sets Z0 and Z1, the component composition of S0 and S1 is a Z0∪Z1-refinementof S if S0 is a Z0-refinement of S and S1 is a Z1-refinement of S:

S0∩S1 ⊆Z0∪Z1S

⇐S0 ⊆Z0

S ∧ S1 ⊆Z1S

So, because the following refinements hold for our example:

Increase ⊆INC CreaseDecrease ⊆DEC Crease

we have

Increase∩Decrease ⊆INC∪DEC Crease

A non-empty set of specifications S is called a decomposition of a specification Sif for each pair of different specifications S0, S1 from S, there exist disjoint sets Z0,Z1 such that S0 is a Z0-refinement of S and S1 is a Z1-refinement of S. Formally,for a non-empty set of specifications S we define:

160

S is a decomposition of S

≡

∀〈S0, S1|| S0, S1 ∈ S ∧ S0 6= S1|| ∃〈Z0, Z1

|| Z0 and Z1 are disjoint sets|| S0 ⊆Z0

S ∧ S1 ⊆Z1S〉〉

For any decomposition S of a specification S, the component composition of allspecifications in S is a refinement of S. Formally, for a non-empty set of specifica-tions S:

⋂S ⊆ S ⇐ S is a decomposition of S

This is a trivial result of the fact that S is non-empty and that all specifications inS are refinements of S. Actually, we only need that at least one specification in Sis a refinement of S. However, when we require total refinement, the fact that S isa decomposition of S becomes more relevant (see section 7.8).

This all looks rather trivial and indeed it is. We neglected however an importantaspect of components. Often there exist dependencies between components. Inthe model of components and component composition of this chapter, dependenciesbetween components are impossible, although specification MATH of section 7.5seems to suggest otherwise. Decomposition of MATH into separate componentsrequires binding of variable MATH to be explicitly modeled however. This is thesubject of the next chapter. Dependencies are then possible and we have to facethe problems that they cause.

7.7 Aspects and invariants

A relatively new paradigm that is expected to have a big impact on the developmentof large software systems is aspect-oriented programming. Aspect-oriented pro-gramming languages enable one to isolate a common property of several proceduresinto an aspect. This prevents the property from being duplicated and scatteredover the entire system.

7.7.1 Aspect operator

In order to enable isolation of common properties of procedures, we define theaspect operator <| ∈ ((I )−−−( I) )−−−( (I )−−−( I)) <−−−| (I )−−−( I)×(℘I) by

R <| B = R −−−−−◦ B ∩ UNI ∩FUN ∩NMP∩DEQ

The aspect operator is thus the cylindric-type operator that is constrained by theconjoint-sum constraint. It is actually a straightforward generalisation of the packand a specialisation of the arbitrary conjoint sum. The following alternative defi-nitions of the aspect operator show the close relationship between these operators

161

(the “∩ UNI ∩FUN ∩NMP∩DEQ” is necessary for the case in which B is empty):

R <| B =⋂{R⊳i | i ∈ B | i} ∩ UNI ∩FUN ∩NMP∩DEQ

R <| B = ∩+ [(R, i) | i ∈ B | i]

If we take B = {i} in the first of these two definitions, we see in what way theaspect operator is a generalisation of the pack:

R <| {i} = R ⊳ i

The theorems about the pack can be generalised to the following theorems aboutthe aspect operator:

R = R<|B ⊲ i ⇐ i ∈ BΠ = R<|B ⊲ j ⇐ j /∈ BR⊆T ≡ R<|B ⊆ T<|B ⇐ B is non-emptyR=T ≡ R<|B = T<|B ⇐ B is non-emptyR∩T <|B = R<|B ∩ T<|BR∪T <|B = R<|B ∪ T<|B ⇐ B has a unique elementR ◦ T <|B = R<|B ◦ T<|BR ˘ <|B = R<|B ˘

The first two theorems are straightforward results of the pack’s cancellation theo-rems and the fact that (⊲i) distributes over the arbitrary intersection. The inclusionand equality theorems can be proved in the same way as the corresponding theo-rems about the binary constrained cylindric products. The intersection, union andconverse theorems are straightforward results of the corresponding theorems aboutthe cylindric-type operator. To prove the composition theorem, the fact can be usedthat S (−UNI ∩FUN ∩NMP∩DEQ −) Q implies that S and Q are of the form [(y, i)]and [(z, i)] respectively.

The aspect operator enables us to add a property to relations that are packed witha certain tag. As an example we take specification Math , defined by

Math = inc⊳inc ∩ dec⊳dec ∩ chg⊳chg ∩ skp⊳skp

inc = ZZ ◦[[C| > C| ]]◦ZZdec = ZZ ◦[[C| < C| ]]◦ZZchg = ZZ ◦[[C| 6= C| ]]◦ZZskp = ZZ ◦[[C| = C| ]]◦ZZ

There is one property that all four procedures share and that is that the inputsand outputs are integer numbers. The procedures inc, dec and chg also shareanother property: their output is unequal to their input. We now show an equivalentdefinition of Math where we factored out these two properties into separate aspects:

162

Math = int <| {inc, dec, chg, skp}∩ neq<| {inc, dec, chg}∩ inc′⊳inc ∩ dec′⊳dec ∩ chg ′⊳chg ∩ skp′⊳skp

int = ZZ ◦Π◦ZZ

neq = [[C| 6= C| ]]

inc′ = [[C| ≥ C| ]]dec′ = [[C| ≤ C| ]]chg ′ = [[true]]

skp′ = [[C| = C| ]]

The following example shows how the aspect operator can be used to factor outcommon behaviour of methods of different classes:

MATH = (int<| {inc, dec, chg})<| {Crease} ∩ (int<| {skp})<| {Skip}∩ (neq<| {inc, dec, chg})<| {Crease}∩ Crease⊳Crease ∩ Skip⊳Skip

Crease = inc ′⊳inc ∩ dec′⊳dec ∩ chg ′⊳chgSkip = skp′⊳skp

Because most programming languages do not have an intersection, aspects are usu-ally added by means of sequential composition. An aspect T is then usually im-plemented by two pieces of code T 0 and T 1 that are placed respectively before andafter the original code. According to our definition of an aspect, these two piecesshould satisfy

T 0◦S ◦T 1 ⊆ S∩T

for all method bodies S to which the aspect is added. The aspect int from ourexample could for example be implemented by the pieces ZZ and ZZ.

Using sequential composition to add aspects also enables one to alter the behaviourof procedures in a non-refining manner. We leave the answer to the question whetheror not this is desirable to researchers from the field of aspect-oriented programming.

7.7.2 Invariants

In object-oriented specifications a class usually has an invariant attached to it. Themeaning of this is that all methods of the class adhere to the invariant. Invariantsare usually separated into two kinds: state invariants and history invariants.A state invariant is a property (modeled by a set) that the context (state) satisfiesbefore and after each method call. A history invariant is a relation that tells whatkind of state change is guaranteed by each method. An invariant I is thus definedby a state invariant SI and a history invariant HI as follows:

163

I = SI ◦HI ◦SI

We seem to deviate here from the traditional view where ‘a state invariant onlyneeds to hold afterwards if it held initially’. We think however that this traditionalview is based on a misunderstanding between what a specification defines and howone proves that an implementation satisfies this. Section 7.7.4 should clarify this.

Invariants are actually no different from aspects. Enforcing an invariant on allmethods of a class can be done by using the universal set I as right argument of <| :

Crease = inv<| I ∩ inc⊳inc ∩ dec⊳dec ∩ chg⊳chginv = stateInv ◦historyInv ◦stateInvstateInv = {[C| ∈ ZZ]}historyInv = [[C| 6= C| ]]inc = [[C| ≥ C| ]]dec = [[C| ≤ C| ]]chg = [[true]]

7.7.3 Refinement

Apart from the readability of specifications, factoring out aspects/invariants alsohas advantages for refinement. It is rather easy to refine the specification Creaseof section 7.7.2 to the specification Crease1 where the inputs and outputs are two’scomplement bytes and where the increases and decreases are not by an arbitraryinteger number, but always by 1:

Crease1 = inv1<| I ∩ inc⊳inc ∩ dec⊳dec ∩ chg⊳chginv1 = stateInv1◦historyInv1◦stateInv1stateInv1 = {[C| ∈ ZZ ∧ −128 ≤ C| ∧ C| < 128]}historyInv1 = [[|C|−C| | = 1]]

We only need to copy (inherit) the procedure bodies from Crease and strengthenthe invariant.

7.7.4 Proving invariants

Programming languages are usually not able to ‘magically’ ensure that proceduresadhere to an invariant, although some invariants can be handled with aspect-oriented programming techniques. In general however, we have to prove that eachprocedure adheres to all invariants.

There is a simple ‘trick’ to ensure that a certain procedure cannot violate anyinvariant and that is to simply not allow that procedure to be called. This ‘trick’is part of almost every programming language. Procedures that are allowed tobe called, we refer to as supported procedures. In object-oriented languages for

164

example, a class is always associated with a collection of methods that are supportedby the class. This collection is usually known at compile time but sometimes onlyat runtime. Calling an unsupported method results in an error (either at compiletime or at runtime).

For procedures that are supported, it is usually undesirable to have to check thestate invariant at the beginning of each procedure. It can be costly to have tocheck it and if it does not hold, the only option we have is to abort in one way oranother. There is a way to avoid this. We then only need to prove that the stateinvariant holds after the body of the procedure has been executed, if it held when theprocedure was called. The trick is that we provide the user of our procedures with aninitialiser (comparable to the notion of constructor or factory in object-orientedlanguages) that establishes the state invariant somehow. If the specification thatuses our procedures, from now on referred to as the main, first calls the initialiserand then only changes the state by calling supported procedures, we know thatthe state invariant ‘holds at every point in the main’. This ‘trick’ is called thedatatype-induction principle. A similar ‘trick’, without the initialiser, is oftenused to ensure that a procedure maintains the state invariant. Let it only changethe state by calling procedures of which it is known that they maintain the stateinvariant.

An example of a specification that uses the datatype-induction principle to ‘refine’specification Crease1 of section 7.7.3 is

Crease1′ = inc1′⊳inc ∩ dec1′⊳dec ∩ chg1′⊳chg ∩ init1′⊳init

inc1′ = [[C| = C|+1]] ◦ {[C| 6= 127]}dec1′ = [[C| = C|−1]] ◦ {[C| 6= −128]}chg1′ = inc1′

init1′ = [[C| = 0]]

Although Crease1′ is not a refinement of Crease1, it becomes one if we restrict tothe supported procedures and assume that the state invariant holds for their inputs:

Crease1′ ◦ (stateInv1 )−−−( {inc, dec, chg}) ⊆ Crease1

Notice the guards at the beginning (right) of inc1′ and dec1′ which are necessaryto avoid violation of the state invariant.

An example of a main that uses Crease1′ is (remember to read right-left and bottom-up)

if {[C| > 0]}then Crease1′⊲dec ◦ Crease1′⊲decelse Crease1′⊲inc ◦ Crease1′⊲inc

◦ Crease1′⊲chg◦ Crease1′⊲init

165

Because Crease1′⊲init establishes the state invariant, because all supported proce-dures maintain it and because of certain algebraic properties of the operators thatare used to construct the main, we know that the state invariant ‘holds at everypoint in the main program’, meaning that the above formula is equal to

stateInv1◦ if {[C| > 0]}

then stateInv1 ◦ Crease1′⊲dec ◦ stateInv1 ◦ Crease1′⊲dec ◦ stateInv1else stateInv1 ◦ Crease1′⊲inc ◦ stateInv1 ◦ Crease1′⊲inc ◦ stateInv1

◦ stateInv1◦ Crease1′⊲chg◦ stateInv1◦ Crease1′⊲init

This distribution of the state invariant over the main is a trivial consequence of thefollowing properties:

S0∪S1 ◦ A = A◦(A◦S0◦A ∪ A◦S1◦A)◦A ⇐ S0, S1 ∈ A−−−◦ AS0◦S1 ◦ A = A◦S0◦A◦S1◦A ⇐ S0, S1 ∈ A−−−◦ AS* ◦ A = A◦(A◦S ◦A)*◦A ⇐ S ∈ A−−−◦ AB ◦ A = A◦B ◦A = A◦B

In object-oriented languages, an additional trick is used to make it easier to main-tain state invariants. The state is then partitioned into the same classes as theprocedures and procedures are only allowed to directly change the state partitionof their class. The state partition of another class may only be changed by call-ing (directly or indirectly) a procedure of that class. This helps in keeping trackof the state partitions that can be changed by a call to a certain procedure andconsequently helps to see which invariants could be affected by a certain call.

7.7.5 Type, declarative and operational invariants

Just like a pre can be split up into a pre-type and a pre-condition, a state invariantcan be split up into a state-invariant type and a state-invariant condition.A history invariant is usually split up into a post invariant, describing the statechange in a declarative manner and an action invariant, describing the statechange in an operational manner.

7.8 Totality

In many cases, (partial) refinement is not considered strong enough to model theconcept of ‘acceptable specialisations’. The empty specification ©� is for example a(partial) refinement of every specification and cannot really be considered an ‘ac-ceptable specialisation’ of every specification. This is where totality requirementscome in.

166

7.8.1 Total refinement

If someone constructs a refinement S′ of a specification S, it is in many casesdesirable that S′ is not refining something by means of emptiness if specification Sdid not prescribe emptiness. In other words, the domain of S′ should be at least aslarge as the domain of S:

S′> ⊇ S>

We say that S′ domain-includes S.

The combination of refinement and domain-inclusion is called total refinement.The is-total-refinement-of ⊑ ∈ B <−−−| (I )−−−( I)×(I )−−−( I) is defined by

S′ ⊑ S ≡ S′ ⊆ S ∧ S′> ⊇ S>

or equivalently (> is monotonic):

S′ ⊑ S ≡ S′ ⊆ S ∧ S′> = S>

A total refinement of the specification

ZZ ◦[[C| ≤ C| ]]◦ZZ

is for example

[[C| = C|−1]]◦ZZ

The specification

ZZ ◦[[C| 2 = C| ]]

is however not a total refinement because it is for example empty in 2 whereas

ZZ ◦[[C| ≤ C| ]]◦ZZ is not empty in 2.

7.8.2 Proving totality

The type operator−−−) can be used to prove totality. The meaning of S ∈ A −−−) B isthat S connects each input that is an element of B with at least one output that is

an element of A. Some totality rules that we can use, are that for sets A(′), B(′),

C and D:

167

S ∈ A−−−) B′ ⇐ S ∈ A′ −−−) B ∧ A′ ⊆ A ∧ B′ ⊆ BS′ ∈ A−−−) B ⇐ S ∈ A −−−) B ∧ S′ ⊇ SS0∪S1 ∈ A−−−) B∪D ⇐ S0 ∈ A −−−) B ∧ S1 ∈ A −−−) DS0◦S1 ∈ A−−−) B ⇐ S0 ∈ A −−−) C ∧ S1 ∈ C −−−) BB ∈ B −−−) B

We have for example:

[[C| = −√

−C| ]]◦{[C| ≤ 0]} ∪ [[C| =√

C| ]]◦{[C| ≥ 0]} ∈ I−−−) R

⇐ {totality rule for ∪, R = R− ∪ R+

R− = {x | x ∈ R ∧ x ≤ 0 | x}R+ = {x | x ∈ R ∧ x ≥ 0 | x}}

[[C| = −√

−C| ]]◦{[C| ≤ 0]} ∈ I−−−) R− ∧[[C| =

√

C| ]]◦{[C| ≥ 0]} ∈ I−−−) R+

⇐ {totality rule for ◦}

[[C| = −√

−C| ]] ∈ I −−−) R− ∧{[C| ≤ 0]} ∈ R−−−−) R− ∧[[C| =

√

C| ]] ∈ I −−−) R+ ∧{[C| ≥ 0]} ∈ R+−−−) R+

⇐ {totality rule for ⊇, R− ⊆ {[C| ≤ 0]}, R+ ⊆ {[C| ≥ 0]}}

[[C| = −√

−C| ]] ∈ I −−−) R− ∧R− ∈ R−−−−) R− ∧[[C| =

√

C| ]] ∈ I −−−) R+ ∧R+ ∈ R+−−−) R+

⇐ {A <−−−) B ⊆ A −−−) B, totality rule for sets}

[[C| = −√

−C| ]] ∈ I <−−−) R− ∧[[C| =

√

C| ]] ∈ I <−−−) R+

≡ {chapter 6}true

7.8.3 Total correctness

The notion of partial correctness that was presented in section 7.3 can be extendedto a notion of total correctness by adding the requirement that the range ofthe pre is a subset of the domain of the body. We define the total-correctnessoperator −−| |−− ∈ B <−−−| (I )−−−( I)×(I )−−−( I)×(I )−−−( I) by

R −−|S|−−P ≡ R −−)S(−−P ∧ P < ⊆ S>

If R −−|S|−−P holds, we call specification S totally correct with respect to post R andpre P . The following total-correctness rules hold:

168

R0∩R1 −−| S |−− P ≡ R0 −−|S|−−P ∧ R1 −−|S|−−PR −−| S |−−P 0∪P 1 ≡ R −−|S|−−P 0 ∧ R −−|S|−−P 1

R −−|S0∪S1|−− P ⇐ R −−|S0|−−P ∧ R −−|S1|−−PR −−| S0◦S1 |−− P ⇐ ∃〈X |||| R −−|S0|−−X ∧ X −−|S1|−−P 〉R −−|R′/P ′ |−− P ≡ R −−|R′|−−P ⇐ P < ⊆ P ′ ⊆ IR −−| I |−− P ≡ R ⊇ P

We leave the proofs to the reader. Notice that where the partial-correctness rules forthe union and sequential composition are equivalences, the total-correctness rulesare only implications. Furthermore, we only give one total-correctness rule for thesequential composition whereas for partial correctness, we had three rules. Thetotal-correctness rule for the if-then-else, whose proof we also leave to the reader,provides some compensation:

R −−|if B then S0 else S1|−−P≡

R −−|S0|−−B ◦P ∧ R −−|S1|−−(IrB)◦P

The iteration does not seem an appropriate construct in the context of total cor-rectness. For this case, the ‘while’ provides compensation:

R −−|while B do S|−−P≡ {• S ◦B ◦(P <) is well-founded and • S ◦B ∈ P <−−−◦ P <}∃〈X |||| R ⊇ (IrB)◦X ∧ X −−|S|−−B ◦X ∧ X ⊇ P 〉

The remainder of this subsection is dedicated to proving this theorem.

R −−|while B do S|−−P≡ {definition of −−| |−− }

R −−)while B do S(−−P ∧ P < ⊆ (while B do S)>

≡ {A ⊆ T > ≡ A = (T ◦A)> for all sets A and relations T}R −−)while B do S(−−P ∧ P < = ((while B do S) ◦ P <)>

≡ {• S ◦B ◦(P <) is well-founded and • S ◦B ∈ P <−−−◦ P < (see section 7.3.9)}R −−)IrB ◦ (S ◦B)*(−−P ∧ P < = (IrB ◦ (S ◦B)* ◦ P <)>

≡ {• S ◦B ◦(P <) is well-founded and • S ◦B ∈ P <−−−◦ P < (see below)}∃〈X |||| R ⊇ (IrB)◦X ∧ X −−)S(−−B ◦X ∧ (B ◦X)< ⊆ S> ∧ X ⊇ P 〉

≡ {definition of −−| |−− }∃〈X |||| R ⊇ (IrB)◦X ∧ X −−|S|−−B ◦X ∧ X ⊇ P 〉

We split the penultimate step of this proof into (⇒) and (⇐), starting with (⇒):

169

R −−)IrB ◦ (S ◦B)*(−−P ∧ P < = (IrB ◦ (S ◦B)* ◦ P <)>

≡ {definition of −−) (−− , A ⊆ T > ≡ A = (T ◦A)> for all sets A and relations T}IrB ◦ (S ◦B)* ◦ P ⊆ R ∧ P < ⊆ (IrB ◦ (S ◦B)*)>

⇒ {• S ◦B ∈ P <−−−◦ P <, take X = (S ◦B)* ◦ P (see below)}∃〈X |||| (IrB)◦X ⊆ R ∧ S ◦B ◦X ⊆ X ∧ (B ◦X)< ⊆ S> ∧ P ⊆ X〉

≡ {definition of −−) (−− }∃〈X |||| R ⊇ (IrB)◦X ∧ X −−)S(−−B ◦X ∧ (B ◦X)< ⊆ S> ∧ X ⊇ P 〉

For the X that we took in the middle step, we focus on the proof of (B ◦X)< ⊆ S>.For the other properties that this X should satisfy, we refer to section 7.3.7.

(B ◦ (S ◦B)* ◦ P )< ⊆ S>

≡ {(R ◦ T )< = (R ◦ T <)< for all relations R and T}(B ◦ (S ◦B)* ◦ P <)< ⊆ S>

≡ {• S ◦B ∈ P <−−−◦ P <, then (S ◦B)* ◦ P < = P < ◦ (S ◦B)* ◦ P <}(B ◦ P < ◦ (S ◦B)* ◦ P <)< ⊆ S>

⇐ {R ⊆ Π for all relations R}(B ◦ P < ◦ Π)< ⊆ S>

≡ {(A◦Π)< = A for all sets A}B ◦ P < ⊆ S>

⇐ {(IrB ◦ (S ◦B)* ◦ B)> ⊆ S> (left to the reader)}B ◦ P < ⊆ (IrB ◦ (S ◦B)* ◦ B)>

≡ {easy to prove using the fact that A ⊆ T > ≡ A = (T ◦A)> for all sets A and relations T )}B ◦ P < ⊆ (IrB ◦ (S ◦B)*)>

⇐ {B is a set}P < ⊆ (IrB ◦ (S ◦B)*)>

This completes the proof of (⇒). We now proceed with the (⇐). Partial correctnesswas already treated in section 7.3.9. The interesting part is the one that deals withtotality. The key lemma that we use, is that if a relation is well-founded then thereis a finite path from every element in its domain to an element outside its domain.This lemma can be formalised as follows:

R is well-founded

⇒((I r R>) ◦ R*)> = I

To prove this lemma, we use a theorem from [17] that states that well-foundednessof a relation R is equivalent to

∀〈S, T |||| T = S ∪ T ◦R ≡ T = S ◦ R*〉

The above lemma can now be proved as follows:

170

I = ((I r R>) ◦ R*)>

≡ {I = T > ≡ Π = Π◦T for all relations T}Π = Π ◦ (I r R>) ◦ R*

≡ {• R is well-founded (use the above definition of well-foundedness)}Π = Π◦(I r R>) ∪ Π◦R

≡ {left to the reader}true

We now rewrite the formula “P < = (IrB ◦ (S ◦B)* ◦ P <)>” such that we can applythe lemma:

P < = (IrB ◦ (S ◦B)* ◦ P <)>

≡ {• S ◦B ∈ P <−−−◦ P <, then (S ◦B)* ◦ P < = P < ◦ (S ◦ B ◦ P <)* ◦ P <}P < = (IrB ◦ P < ◦ (S ◦ B ◦ P <)* ◦ P <)>

≡ {IrB ◦ A = Ir(B ◦A) ◦ A for all sets A and B}P < = (Ir(B ◦ P <) ◦ P < ◦ (S ◦ B ◦ P <)* ◦ P <)>

≡ {• S ◦B ∈ P <−−−◦ P <, then P < ◦ (S ◦ B ◦ P <)* ◦ P < = (S ◦ B ◦ P <)* ◦ P <}P < = (Ir(B ◦ P <) ◦ (S ◦ B ◦ P <)* ◦ P <)>

≡ {A ⊆ T > ≡ A = (T ◦A)> for all sets A and relations T}P < ⊆ (Ir(B ◦ P <) ◦ (S ◦ B ◦ P <)*)>

≡ {• (B ◦X)< ⊆ S> and • P ⊆ X, then B ◦ P < = (S ◦ B ◦ P <)> (left to the reader)}P < ⊆ (Ir((S ◦ B ◦ P <)>) ◦ (S ◦ B ◦ P <)*)>

≡ {• S ◦B ◦(P <) is well-founded, then (lemma) (Ir((S ◦ B ◦ P <)>) ◦ (S ◦ B ◦ P <)*)> = I}P < ⊆ I

≡ {P < is a set}true

This concludes our proof of the total-correctness rule for the ‘while’.

7.8.4 Components

We now investigate components in the context of total refinement. We call a speci-fication S′ a total Z-refinement of a specification S if it is a total refinement anda Z-override of S. The is-total-Z-refinement-of ⊑Z ∈ B <−−−| (I )−−−( I)×(I )−−−( I)is defined by

S′ ⊑Z S ≡ S′ ⊑ S ∧ S′ ©Z S

If S0 is a total Z0-refinement of S and S1 is a total Z1-refinement of S for disjointsets Z0 and Z1, then the component composition of S0 and S1 is a total Z0∪Z1-refinement of S:

171

S0∩S1 ⊑Z0∪Z1S

⇐ {• Z0 and Z1 are disjoint sets}S0 ⊑Z0

S ∧ S1 ⊑Z1S

We leave the rather straightforward proof to the reader.

A non-empty set of specifications S is called a total decomposition of a specifi-cation S if for each pair of different specifications S0, S1 from S there exist disjointsets Z0, Z1 such that S0 is a total Z0-refinement of S and S1 is a total Z1-refinementof S. Formally, for a non-empty set of specifications S, we define:

S is a total decomposition of S

≡∀〈S0, S1

|| S0, S1 ∈ S ∧ S0 6= S1|| ∃〈Z0, Z1

|| Z0 and Z1 are disjoint sets|| S0 ⊑Z0

S ∧ S1 ⊑Z1S〉〉

For any finite total decomposition S of a specification S, the component compositionof all specifications in S is a total refinement of S. Formally, for a non-empty finiteset of specifications S:

⋂

S ⊑ S ⇐ S is a total decomposition of S

For the case that S consists of two specifications, this is a trivial consequence of theprevious theorem. For other S, the two-element case can be used for the inductionstep in an inductive proof.

Things become more complicated in the next chapter where dependencies betweencomponents are possible.

7.8.5 Invariants

Looking at invariants, a problem arises in the context of total refinement. In general,we are not allowed to strengthen the state invariant anymore. The specificationCrease whose state invariant enforces the state to be an integer number:

Crease = inv<| I ∩ inc⊳inc ∩ dec⊳dec ∩ chg⊳chginv = stateInv ◦Π◦stateInvstateInv = {[C| ∈ ZZ]}inc = [[C| > C| ]]dec = [[C| < C| ]]chg = [[C| 6= C| ]]

does not have as total refinement the specification Crease ′ whose state invariantenforces the state to also be even:

172

Crease ′ = inv ′<| I ∩ inc⊳inc ∩ dec⊳dec ∩ chg⊳chginv ′ = stateInv ′ ◦Π◦stateInv ′

stateInv ′ = {[C| ∈ ZZ ∧ C| /2 ∈ ZZ]}

The datatype-induction principle again helps out. If we use this principle, we onlyneed to prove total refinement for those inputs that adhere to the state invariant ofthe fine specification:

Crease ′ ⊑ Crease ◦ (stateInv ′)−−−( I)

This clearly holds because inc, dec and chg are total on stateInv ′.

The specification that restricts the state to two’s complement bytes:

Crease ′′ = inv ′′<| I ∩ inc⊳inc ∩ dec⊳dec ∩ chg⊳chginv ′′ = stateInv ′′ ◦Π◦stateInv ′′

stateInv ′′ = {[C| ∈ ZZ ∧ −128 ≤ C| ∧ C| < 128]}

is not a total refinement, even if we use the datatype-induction principle:

Crease ′′ ⊑/ Crease ◦ (stateInv ′′)−−−( I)

Things go wrong for inputs [(127, inc)] and [(−128, dec)].

7.9 Conclusions

In this chapter we showed how several specification concepts can be modeled withinthe calculus that is used in this thesis. An important ingredient is the fact thatwe see pre-conditions, post-conditions, operational descriptions and invariants allas defining properties rather than one being a derived property of another. Wehave illustrated the gain in expressive power this can provide, especially in termsof simpler specifications and proofs.

173

Chapter 8

Statements

Recursion is an essential aspect of every realistic programming language. In thischapter we show how recursion is formalised by means of fixed-point theory.

8.1 Recursion

In most programming languages, procedures are able to call each other. Whatthis essentially means, is that the program that contains the procedures is able touse its own behaviour. This can be modeled by defining programs as monotonicfunctions that have program behaviours as input and output. Taking a fixed pointof a program now means that its own behaviour is used to determine its behaviour.This is called recursion.

In general we model program behaviours by collections and programs by monotonictotal functions whose inputs and outputs have the same external type. The type ofbehaviours is thus PI and the type of programs is PI <−−−|m PI for I equal to I.

A program can have several fixed points. Similar to the ‘while’ (see section 7.3.9),we could now focus on programs with a single fixed point, but rather avoid thistopic as it requires much extra theory. We simply always take the least fixed point,that we call the canonical behaviour of a program.

It is useful to have something that is more general than programs to allow for a richcollection of programming constructs. For this purpose, we introduce the notion ofstatements which are actually just total functions. A program is thus a monotonicstatement whose inputs and outputs have the same external type.

175

8.2 Statement operators

In this section we introduce some useful statement operators.

8.2.1 Inclusion

The statement-inclusion ⊆ ∈ B <−−−| (PI <−−−| I)×(PI <−−−| I) is defined by

s0 ⊆ s1 ≡ ∀〈b |||| s0.b ⊆ s1.b〉

8.2.2 Binary intersection and union

The binary statement-intersection and binary statement-union ∩ , ∪ ∈(PI <−−−| I) <−−−| (PI <−−−| I)×(PI <−−−| I) are defined by

(s0∩s1).b = s0.b ∩ s1.b(s0∪s1).b = s0.b ∪ s1.b

8.2.3 Empty and universal statement

The empty statement and universal statement ©�, Π ∈ PI <−−−| I are defined by

©�.b = ©�Π.b = Π


The sequential statement-composition ◦ ∈ ((I )−−−( I) <−−−| I) <−−−| ((I )−−−( I) <−−−| I)×((I )−−−( I) <−−−| I) is defined by

(s0 ◦s1).b = s0.b ◦ s1.b

8.2.5 Identity statement

The identity statement I ∈ ((I )−−−( I) <−−−| I) is defined by

I.b = I

176

8.2.6 Pick and pack

The statement-pick ⊲ ∈ ((I )−−−( I) <−−−| I) <−−−| (((I )−−−( I) )−−−( (I )−−−( I)) <−−−| I)×I andthe statement-pack ⊳ ∈ (((I )−−−( I) )−−−( (I )−−−( I)) <−−−| I) <−−−| ((I )−−−( I) <−−−| I)×I aredefined by

(s⊲i).b = s.b ⊲ i(s⊳i).b = s.b ⊳ i

8.2.7 Call

The call call ∈ I <−−−| I is defined by

call.b = b

The call enables recursion. In combination with the statement-pick, it enables us tocall a procedure with a specific name. This is illustrated by an upcoming example.

8.2.8 Constrain

The constrain const ∈ (I <−−−| I) <−−−| I is defined by

(const.c).b = c

The constrain enables us to describe behaviour by means of some fixed element (arelation for example).

8.2.9 Preservation of monotonicity

The operators that we introduced in section 8.2.2 till 8.2.8 are monotonicity pre-serving: they either construct a monotonic statement or transform monotonicstatements into a monotonic statement. If we only use these operators to constructa statement, we know for sure that it is monotonic.

8.2.10 Other operators

We could of course define many more statement operators like ˆ�, /, * and ˆ. Someof these would not be monotonicity preserving, but that is not a major problembecause using them in the right way still enables us to construct monotonic state-ments. We simply left them out because we do not need them for the upcomingtheory, except for a few that are introduced in chapter 11.

177

8.2.11 Correspondence with expressions

Statements are actually just expressions (see chapter 6) that are total and func-tional. The input of a statement is also called its context and determines themeaning of a call. In particular we have:

∩ = ∩∪ = ∪©� = ©�Π = Π◦ = ◦

I = I

(⊲i) = ˙(⊲i)

(⊳i) = ˙(⊳i)call = C|

const = ¯

8.2.12 Theorem lifting

Similar to theorems about expressions, many of the theorems that hold for ⊆, ∩,

∪, ©�, Π, ◦, I, ⊳ and ⊲ can be directly transformed into theorems about ⊆, ∩, ∪,

©�, Π, ◦, I, ⊳ and ⊲. In the context of statements we also call this theorem lifting.

Distribution of (⊲i) over ∩ can for example be proved as follows:

(s0∩s1)⊲i . b

= {definition of ⊲}(s0∩s1).b ⊲ i

= {definition of ∩}(s0.b ∩ s1.b) ⊲ i

= {distribution of (⊲i) over ∩}(s0.b ⊲ i) ∩ (s1.b ⊲ i)

= {definition of ⊲}(s0⊲i).b ∩ (s1⊲i).b

= {definition of ∩}(s0⊲i ∩ s1⊲i).b

It is possible to treat constants, unary operators and binary operators in a uniformway, using functions with a 0-tuple as input instead of constants and functions witha 1-tuple as input instead of unary operators. Another way to treat them in auniform way is to use constant-valued functions as constants and the objects of aproduct category (see [11]) as pairs. This would enable the definition of a genericlift operator ˆ and a generic formulation of the above theorem. Such generic theoryis outside the scope of this thesis though.

178

Algebraic frameworks like allegory theory [11] provide many free theorems by prov-ing some simple properties of ⊆, ∩, ∪, ©�, Π, ◦ and I. An algebraic framework

that includes ⊳, ⊲, const and call is left for future research. We stick to ‘proofs ondemand’: if we need a certain theorem, we include an ‘ad-hoc’ proof.

8.2.13 Example

We now show how we can model the recursion that occurs in the example of section7.5. The program MATH is defined by

MATH = Crease1⊳Crease ∩ Three ⊳Three ∩ four ⊳fourCrease1 = inc1⊳inc ∩ dec1⊳decThree = direct3⊳direct ∩ indirect3⊳indirect

inc1 = const.[[C| = C|+1]]

dec1 = const.[[C| = C|−1]]

direct3 = (call⊲Crease)⊲dec ◦ const.[[C| = 4]]indirect3 = (call⊲Crease)⊲dec ◦ call⊲fourfour = (call⊲Crease)⊲inc ◦ (call⊲Three)⊲direct

The following equations demonstrate its canonical behaviour:

(µMATH ⊲ Crease) ⊲ inc = [[C| = C|+1]]

(µMATH ⊲ Crease) ⊲ dec = [[C| = C|−1]]

(µMATH ⊲ Three) ⊲ direct = [[C| = 3]]

(µMATH ⊲ Three) ⊲ indirect = [[C| = 3]]

µMATH ⊲ four = [[C| = 4]]

In the following section we present a theorem that helps to prove these kinds ofequations.

8.3 Call expansion

A well-known rule in programming is that “a call to a procedure may be replaced bythe procedure’s body”. We introduce a similar rule that we name call expansion.For a function F that maps statements to statements (F ∈ (PI <−−−| I) <−−−| (PI <−−−| I)),that is statement-monotonic:

s′ ⊆ s ⇒ F .s′ ⊆ F .s

monotonicity preserving:

s is monotonic ⇒ F .s is monotonic

and context preserving:

179

∀〈s, s′, b || s, s′ ∈ I <−−−| I ∧ s.b = s′.b || (F .s).b = (F .s′).b〉

the following equation holds:

µ(F .call) = µ(F .(F .call))

proof

We define the following shorthands:

s = F .calls′ = F .(F .call) (= F .s)s′′ = F .(F .call ∩ call) (= F .(s∩call))

and prove µs′′ ⊆ µs′ ⊆ µs ⊆ µs′′:

µs′′ ⊆ µs′

⇐ {monotonicity of µ}

s′′ ⊆ s′

≡ {definition of s′′ and s′}

F .(s∩call) ⊆ F .s

⇐ {• statement-monotonicity of F}

s∩call ⊆ s

≡ {s0∩s1 ⊆ s0}true

µs′ ⊆ µs

⇐ {induction}s′.µs = µs

≡ {computation}s′.µs = s.µs

≡ {definition of s′ and s}(F .s).µs = (F .call).µs

⇐ {• F is context preserving}s.µs = call.µs

≡ {definition of call}s.µs = µs

≡ {computation}true

180

µs ⊆ µs′′

⇐ {induction}s.µs′′ = µs′′

≡ {computation}s.µs′′ = s′′.µs′′

≡ {definition of s and s′′}(F .call).µs′′ = (F .(s∩call)).µs′′

⇐ {• F is context preserving}call.µs′′ = (s∩call).µs′′

≡ {definition of ∩}call.µs′′ = s.µs′′ ∩ call.µs′′

≡ {definition of call}µs′′ = s.µs′′ ∩ µs′′

≡ {computation}µs′′ = s.µs′′ ∩ s′′.µs′′

≡ {definition of ∩}µs′′ = (s∩s′′).µs′′

≡ {• statement-monotonicity of F , we then have s′′ ⊆ s, or equivalently, s∩s′′ = s′′}µs′′ = s′′.µs′′

≡ {computation}true

Although it appears that we did not use the monotonicity preservingness of F , weused it implicitly by assuming several fixed points to exist.

All Fs that can be finitely constructed with the statement operators that we intro-duced in section 8.2, are statement-monotonic, monotonicity preserving and contextpreserving. This can be proved by induction on the structure of such Fs.

Call expansion seems closely related to the square rule of fixed-point calculus (seefor example [4]). The square rule states that for f ∈ PI <−−−|m PI (see section 3.3.7for the definition of n)

µf = µ(f2)

We were unable to exploit this rule in the proof of the call-expansion theorem.

As an example of call expansion in action, we prove that program p0, defined by

p0 = m0⊳m ∩ n0⊳n

m0 = const.[[C| = 4]]

n0 = const.[[C| ≥ C| ]] ◦ call⊲m

181

has the same canonical behaviour as program p1, defined by

p1 = m0⊳m ∩ n1⊳n

n1 = const.[[C| ≥ 4]]

proof

µp0

= {definition of p0}µ(m0⊳m ∩ n0⊳n)

= {definition of n0}

µ(m0⊳m ∩ (const.[[C| ≥ C| ]] ◦ call⊲m)⊳n)

= {call expansion with F = 〈m0⊳m ∩ (const.[[C| ≥ C| ]] ◦ X⊲m)⊳n || X〉, F .call = p0}

µ(m0⊳m ∩ (const.[[C| ≥ C| ]] ◦ p0⊲m)⊳n)

= {see below}µ(m0⊳m ∩ n1⊳n)

= {definition of p1}µp1

const.[[C| ≥ C| ]] ◦ p0⊲m

= {cancellation}

const.[[C| ≥ C| ]] ◦ m0

= {definition of m0}

const.[[C| ≥ C| ]] ◦ const.[[C| = 4]]


const.[[C| ≥ 4]]

= {definition of n1}n1

8.4 Refinement

In this section we discuss refinement between statements.

8.4.1 Statement-refinement

An obvious candidate for refinement between statements is statement-inclusion. Wecall a statement s′ a statement-refinement of a statement s if

s′ ⊆ s

182

Statement-refinement is a (PI <−−−| I)–partial-order.

8.4.2 Behavioural refinement

More fine-grained than statement-refinement, is refinement between behaviours ofprograms. We call a program s′ a behavioural refinement of a program s if thecanonical behaviour of s′ refines the canonical behaviour of s. The is-behavioural-

refinement-ofµ

⊆ ∈ B <−−−| (PI <−−−|m PI)×(PI <−−−|m PI) is defined by

s′µ

⊆ s ≡ µs′ ⊆ µs

The relationµ

⊆ is a (PI <−−−|m PI)-preorder. In contrast to ⊆, it is not anti-symmetric.

The fact that the least–fixed-point operator is monotonic, implies that behaviouralrefinement is weaker than statement-refinement. Formally, for all programs s′ ands we have

s′µ

⊆ s ⇐ s′ ⊆ s

8.4.3 Simple refinement rules

Some simple refinement rules that enable us to prove refinement for some simplecases are:

s0′ ∩s1

′ ⊆ s0∩s1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

s0′ ∪s1

′ ⊆ s0∪s1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

©� ⊆ ©� ≡ true

Π ⊆ Π ≡ true

s0′ ◦s1

′ ⊆ s0 ◦s1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

I ⊆ I ≡ true

s′⊲i ⊆ s⊲i ⇐ s′ ⊆ s

s′⊳i ⊆ s⊳i ≡ s′ ⊆ s

call ⊆ call ≡ true

const.C′ ⊆ const.C ≡ C′ ⊆ C

8.4.4 Example

Although the simple refinement rules are rather weak, we can handle already someinteresting examples if we combine them with call expansion and some other basicalgebraic rules. We show how we can prove that program p, defined by

183

p = m⊳m ∩ n⊳n

m = const.[[C| ≥ 3]]

n = const.[[C| ≥ C| ]] ◦ call⊲m

is behaviourally refined by program p′, defined by

p′ = m′⊳m ∩ n′⊳n ∩ o′⊳o

m′ = const.[[C| = 4]]

n′ = const.[[C| = 5]]

o′ = const.[[C| ≥ C| ]] ◦ call⊲n

The first step that we take, is to use the simple refinement rules to prove that p isbehaviourally refined by p0, defined by

p0 = m′⊳m ∩ n⊳n

The proof is as follows:

p0

µ

⊆ p

⇐ {behavioural refinement is weaker than statement-refinement}

p0 ⊆ p

≡ {definition of p0 and p}

m′⊳m ∩ n⊳n ⊆ m⊳m ∩ n⊳n

⇐ {simple refinement rule for ∩}

m′⊳m ⊆ m⊳m ∧ n⊳n ⊆ n⊳n

≡ {(PI <−−−| I)-reflexivity of ⊆}

m′⊳m ⊆ m⊳m

≡ {simple refinement rule for ⊳}

m′ ⊆ m

≡ {definition of m′ and m}

const.[[C| = 4]] ⊆ const.[[C| ≥ 3]]

≡ {simple refinement rule for const}

[[C| = 4]] ⊆ [[C| ≥ 3]]

≡ {4 ≥ 3}true

In section 8.3 we already showed that the canonical behaviour of p0 is equal to thecanonical behaviour of p1 defined by

p1 = m′⊳m ∩ n1⊳n

n1 = const.[[C| ≥ 4]]

184

The last step is to again use the simple refinement rules to show that p′ is a be-havioural refinement of p1:

p′µ

⊆ p1

⇐ {similar to the previous proof}

m′⊳m ∩ n′⊳n ∩ o′⊳o ⊆ m′⊳m ∩ n1⊳n

⇐ {s0∩s1 ⊆ s0, transitivity of ⊆}

m′⊳m ∩ n′⊳n ⊆ m′⊳m ∩ n1⊳n

≡ {similar to the previous proof}true

The fact thatµ

⊆ is a (PI <−−−|m PI)-preorder now gives us that p′µ

⊆ p.

8.4.5 A ‘strange’ refinement

Choosing relations as model for behaviour has a ‘strange’ consequence. If we againtake program p, defined by

p = m⊳m ∩ n⊳n

m = const.[[C| ≥ 3]]


its appears to be also behaviourally refined by p′′, defined by

p′′ = m′′⊳m ∩ n′′⊳n

m′′ = const.[[C| = 4]]

n′′ = const.[[C| = 3]]

We leave it to the reader to check this fact (hint: start with call expansion). Intu-itively this refinement looks a bit strange because we ‘naturally’ interpret statementn as: “The output is at least as large as the output of m.”, where it should be inter-preted as: “The output is at least as large as some output of the given specificationof m.”. These kinds of ‘unnatural’ refinements are due to the fact that relationsabstract from information that we ‘naturally’ see as part of the semantics, like thecall to m. The semantics of a call in this chapter is referred to as an invisiblecall. In the next chapter we introduce a richer semantics where calls can be madevisible. We can then write down something that really means: “The output is atleast as large as the output of m.”.

185

8.5 Components

In this section we show how components and their composition can be modeledwithin the framework of statements. We take behavioural refinement as the pre-ferred kind of refinement and investigate different ways to compose components.

8.5.1 Example

We want two separate teams to construct programs whose component compositionbehaviourally refines program q, defined by

q = c⊳c ∩ d⊳d

c = const.[[C| ≥ 3]]

d = const.[[C| ≥ 4]]

Team C develops the following program that is clearly a behavioural refinement ofq:

qc = c′⊳c ∩ d⊳d

c′ = const.[[C| = 3]]

Team D decides to reuse whatever team C develops and simply add 1:

qd = c⊳c ∩ d′⊳d

d′ = const.[[C| = C|+1]] ◦ call⊲c

We now investigate three different kinds of component composition. One importantrequirement that we have, is that the component composition of two behaviouralrefinements of a program is a behavioural refinement of that program.

8.5.2 Statement-intersection

Had we taken statement-refinement as the preferred kind of refinement, statement-intersection would be the natural choice for component composition. In the contextof behavioural refinement however, statement-intersection seems too ‘coarse’. Forthe statement-intersection of qc and qd we have for example

qc ∩ qd = c′⊳c ∩ d′⊳d ∩ d⊳d

The “∩ d⊳d” can however not be eliminated. The ‘knowledge’ that the call to c ind′ results in a value that is at least 3, is not ‘transferred’ if we use ∩ as compositionoperator. This means that the information that d outputs a value that is at least4, as specified by d, cannot be identified as redundant.

Although statement-refinement does not seem the perfect candidate, it does comply

186

with the requirement that the component composition of two behavioural refine-ments of a program is a behavioural refinement of that program:

s0

µ

⊆ s ∧ s1

µ

⊆ s ⇒ s0∩s1

µ

⊆ s

8.5.3 Behavioural intersection

A composition operator that does incorporate the ‘knowledge transfer’ that thestatement-intersection operator ∩ lacks, is the binary behavioural intersection

µ

∩ ∈ (PI <−−−| PI) <−−−| (PI <−−−|m PI)×(PI <−−−|m PI), defined by

(s0

µ

∩ s1).b = µs0 ∩ µs1

The following theorem holds:

sµ

⊆ s0

µ

∩s1 ≡ sµ

⊆ s0 ∧ sµ

⊆ s1

This theorem is not a definition due to the fact thatµ

⊆ is not a partial order, but

only a preorder.

The behavioural intersection satisfies our main requirement:

s0

µ

⊆ s ∧ s1

µ

⊆ s ⇒ s0

µ

∩s1

µ

⊆ s

Although the behavioural intersection seems the right candidate in the context ofbehavioural refinement, it does not represent the kind of component compositionthat is considered ‘common practice’. For the behavioural intersection of the qcand qd of section 8.5.1, we have for example

µ(qcµ

∩ qd) = [[C| = 3]]⊳c ∩ [[C| ≥ 4]]⊳d

This shows that components interact at the level of specifications rather than at

the level of implementations ifµ

∩ is used as component-composition operator. In

the following subsection we introduce a component-composition operator whereinteraction takes place at the level of implementations.

8.5.4 Statement-component composition

The kind of component composition that is considered ‘common practice’, is theone where components interact at the level of implementations. In that case thebehaviour of the component composition of qc and qd of section 8.5.1 is equal to

[[C| = 3]]⊳c ∩ [[C| = 4]]⊳d

187

This is equal to the behaviour of q′ defined by

q′ = c′⊳c ∩ d′⊳d

We call this form of component composition statement-component composi-tion.

The program q′ is a behavioural refinement of q. In general however, it is not a trivialfact that the statement-component composition of two behavioural refinements ofa program is a behavioural refinement of that program. This is shown in section8.5.7.

We now show how the notion of statement-component composition can be for-malised. For disjoint sets Z0 and Z1, the (Z0, Z1)-component composition

Z0©C Z1

∈ (I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I) is defined by

S0 Z0©C Z1

S1

= {• Z0 and Z1 are disjoint sets}(S0 ∪ Π◦Z1) ∩ (S1 ∪ Π◦Z0)

and the statement-(Z0, Z1)-component composition Z0©C Z1

∈ ((I )−−−( I) <−−−| I)<−−−| ((I )−−−( I) <−−−| I)×((I )−−−( I) <−−−| I) is defined by

(s0 Z0©C Z1

s1).b

= {• Z0 and Z1 are disjoint sets}s0.b Z0

©C Z1s1.b

or equivalently:

s0 Z0©C Z1

s1

= {• Z0 and Z1 are disjoint sets}

(s0 ∪ (Π ◦ const.Z1)) ∩ (s1 ∪ (Π ◦ const.Z0))

For the example of section 8.5.1 we have

qc C©C D qd = c′⊳c ∩ d′⊳d

where C = I )−−−( {c} and D = I )−−−( {d}.

8.5.5 Override

We call a statement s′ a statement-Z-override of a statement s if for all be-haviours b, s′.b is equal to s.b for inputs outside the set Z. We define the is-

statement-Z-override-of ©Z ∈ B <−−−| ((I )−−−( I) <−−−| I)×((I )−−−( I) <−−−| I) by

188

s′ ©Z s ≡ ∀〈b |||| s′.b ©Z s.b〉

or equivalently:

s′ ©Z s ≡ s′ ◦ const.(IrZ) = s ◦ const.(IrZ)

If for disjoint sets Z0 and Z1, a statement s0 is a statement-Z0-override of somestatement s and a statement s1 is a statement-Z1-override of that same s, then thestatement-(Z0, Z1)-component composition of s0 and s1 equals s0 for inputs fromZ0, s1 for inputs from Z1 and s for all other inputs:

s0 Z0©C Z1

s1 = (s0 ◦ const.Z0) ∪ (s1 ◦ const.Z1) ∪ (s ◦ const.(I r Z0∪Z1))

⇐ {• Z0 and Z1 are disjoint sets}

s0 ©Z0s ∧ s1 ©Z1

s

A trivial consequence is that it is a statement-Z0∪Z1-override of s:

(s0 Z0©C Z1

s1) ©Z0∪Z1s


s0 ©Z0s ∧ s1 ©Z1

s

For the example we have

qc ©C q ∧ qd ©D q

and thus

(qc C©C D qd) ©C∪D q

The component-composition operators ©C and ©C treat components in a symmetricway. Two operators that are closely related to the component-composition opera-tors, but that are more suitable for the asymmetric treatment that is to follow, arethe override operators.

For a set Z, the Z-override operator ©O Z ∈ (I )−−−( I) <−−−| (I )−−−( I)×(I )−−−( I) isdefined by

S ©O Z S′ = S ◦(IrZ) ∪ S′ ◦Z

and the statement-Z-override operator ©O Z ∈ ((I )−−−( I) <−−−| I) <−−−| ((I )−−−( I) <−−−|I)×((I )−−−( I) <−−−| I) is defined by

(s ©O Z s′).b = s.b ©O Z s′.b

or equivalently:

189

s ©O Z s′ = (s ◦ const.(IrZ)) ∪ (s′ ◦ const.Z)

These two operators satisfy several algebraic properties like idempotency and asso-ciativity (for a fixed Z). We address these properties on a need-to-know basis. The

following theorem shows the close relationship between ©C and ©O :

s0 Z0©C Z1

s1

= {• Z0 and Z1 are disjoint sets, • s0 ©Z0s ∧ s1 ©Z1

s for some s}

s0 ©O Z1s1

8.5.6 Statement-refinement

We call a statement s′ a statement-Z-refinement of a statement s if s′ is astatement-refinement and a statement-Z-override of s. We define the is-statement-

Z-refinement-of ⊆Z ∈ B <−−−| ((I )−−−( I) <−−−| I)×((I )−−−( I) <−−−| I) by

s′ ⊆Z s ≡ ∀〈b |||| s′.b ⊆Z s.b〉

or equivalently:

s′ ⊆Z s ≡ s′ ⊆ s ∧ s′ ©Z s

We leave it to the reader to verify that for disjoint sets Z0 and Z1, the statement-(Z0, Z1)-component composition of statements s0 and s1 is a statement-Z0∪Z1-refinement of a statement s if s0 is a statement-Z0-refinement of s and s1 is astatement-Z1-refinement of s:

(s0 Z0©C Z1

s1) ⊆Z0∪Z1s


s0 ⊆Z0s ∧ s1 ⊆Z1

s

8.5.7 Behavioural refinement

We call a program s′ a behavioural Z-refinement of a program s if s′ is abehavioural refinement and a statement-Z-override of s. The is-behavioural-

Z-refinement-ofµ

⊆Z ∈ B <−−−| ((I )−−−( I) <−−−|m (I )−−−( I))×((I )−−−( I) <−−−|m (I )−−−( I)) is

defined by

s′µ

⊆Z s ≡ s′µ

⊆ s ∧ s′ ©Z s

We now try to discover under which circumstances, for disjoint sets Z0 and Z1, thestatement-(Z0, Z1)-component composition of programs s0 and s1 is a behaviouralZ0∪Z1-refinement of a program s if s0 is a behavioural Z0-refinement of s and s1

190

is a behavioural Z1-refinement of s:

(s0 Z0©C Z1

s1)µ

⊆Z0∪Z1s

⇐ {• Z0 and Z1 are disjoint sets and ???}

s0

µ

⊆Z0s ∧ s1

µ

⊆Z1s

For the example of section 8.5.1 we have

qcµ

⊆C q ∧ qdµ

⊆D q

and also

(qc C©C D qd)µ

⊆C∪D q

The following example shows however that the “???” is not equivalent to true.Suppose program r is defined by

r = c⊳c ∩ d⊳d ∩ e⊳e

c = const.[[C| ≥ 3]]

d = const.[[C| ≥ 4]]e = call⊲c

The sets of input values CD = I )−−−( {c, d} and E = I )−−−( {e} describe two disjointparts of this program. A behavioural CD-refinement of r is the program rcd , definedby

rcd = c1⊳c ∩ d1⊳d ∩ e⊳e

c1 = const.[[C| = 4]]d1 = call⊲e

and a behavioural E-refinement of r is the program re, defined by

re = c⊳c ∩ d⊳d ∩ e1⊳e

e1 = const.[[C| = 3]]

The statement-(CD , E)-component composition of rcd and re is equal to r1, definedby

r1 = c1⊳c ∩ d1⊳d ∩ e1⊳e

which is not a behavioural CD∪E-refinement of r. The use of call expansion givesus that r1’s canonical behaviour is equal to the canonical behaviour of r1

′ definedby

191

r1′ = c1⊳c ∩ d1

′⊳d ∩ e1⊳e

d1′ = const.[[C| = 3]]

This is obviously not a behavioural refinement of r.

The root cause of the problem is the mutual dependency between the two compo-nents that are composed. In general, such a mutual dependency does not allow us tobehaviourally refine components in isolation if ©C is used as composition operator.It is however allowed to behaviourally refine one component if we statement-refinethe other:

(s0 Z0©C Z1

s1)µ

⊆Z0∪Z1s


s0

µ

⊆Z0s ∧ s1 ⊆Z1

s

proof

The override part of the proof can be found in section 8.5.5. For the behavioural-refinement part, assuming Z0 and Z1 to be disjoint sets, s0 to be a statement-Z0-override of s and s1 to be a statement-Z1-override of s, we calculate:

(s0 Z0©C Z1

s1)µ

⊆ s

≡ {relationship between ©C and ©O (see section 8.5.5)}

(s0 ©O Z1s1)

µ

⊆ s

⇐ {transitivity ofµ

⊆, • s0

µ

⊆ s}

(s0 ©O Z1s1)

µ

⊆ s0

≡ {because Z0 and Z1 are disjoint sets and s0 ©Z0s, we have s0 = s0 ©O Z1

s}

(s0 ©O Z1s1)

µ

⊆ (s0 ©O Z1s)

≡ {definition ofµ

⊆}

µ(s0 ©O Z1s1) ⊆ µ(s0 ©O Z1

s)

⇐ {monotonicity of µ}

s0 ©O Z1s1 ⊆ s0 ©O Z1

s

⇐ {statement-monotonicity of (x ©O Z)}

s1 ⊆ s

The last three steps are actually the core of the proof. The other steps reformulatethe problem in terms of the override operator. We repeat this core as a theorem:

(s0 ©O Z1s1)

µ

⊆ (s0 ©O Z1s)

⇐

s1 ⊆ s

192

In the following subsection we show a restriction that allows us to behaviourallyrefine both components.

8.5.8 Independence

We call a set Z an independent part of a statement s if the behaviour of s forinputs from Z is not influenced by the way its context behaves on inputs outside Z:

∀〈b, b′ || b◦Z = b′ ◦Z || s.b ◦ Z = s.b′ ◦ Z〉

If we take the example of the previous section:

r = c⊳c ∩ d⊳d ∩ e⊳e

c = const.[[C| ≥ 3]]

d = const.[[C| ≥ 4]]e = call⊲m

and consider in this case all combinations of the parts C = I )−−−( {c}, D = I )−−−( {d}and E = I )−−−( {e}, then C, D, C∪D, C∪E and C∪D∪E are independent partsof r and E and D∪E are not. If we only use the statement operators of section8.2 to construct statements then, informally stated, independence of a part can beensured by having no calls from that part to another part.

The main theorem that we pursue, is that for disjoint sets Z0 and Z1, the statement-(Z0, Z1)-component composition of programs s0 and s1 is a behavioural Z0∪Z1-refinement of a program s if s0 is a behavioural Z0-refinement of s, s1 is a behaviouralZ1-refinement of s and Z1 is an independent part of s and s1:

(s0 Z0©C Z1

s1)µ

⊆Z0∪Z1s

⇐ {• Z0 and Z1 are disjoint sets and • Z1 is an independent part of s and s1}

s0

µ

⊆Z0s ∧ s1

µ

⊆Z1s

Similar to the theorem of the previous subsection, this theorem is a trivial conse-quence of the following theorem that is a reformulation of the theorem in terms ofthe statement-override operator:

(s0 ©O Z1s1)

µ

⊆ (s0 ©O Z1s)

⇐ {Z1 is an independent part of s and s1}

s1

µ

⊆ s

To prove this theorem, we prove some lemmas that enable us to replace an inde-pendent part of a program by the ‘const’ of its canonical behaviour. We can thenuse that statement-refining this ‘const’ is the same as behaviourally refining theindependent part.

193

The first lemma says that if Z is an independent part of a program s, then thecanonical behaviour of s restricted to inputs from Z, is equal to the canonicalbehaviour of s ◦ const.Z:

µs ◦ Z = µ(s ◦ const.Z) ⇐ Z is an independent part of s

proof

µs ◦ Z = µ(s ◦ const.Z)

⇐ {fusion with F = (◦Z), H = s and K = s ◦ const.Z}∀〈b |||| s.b ◦ Z = (s ◦ const.Z).(b◦Z)〉

≡ {definition of ◦ and const}∀〈b |||| s.b ◦ Z = s.(b◦Z) ◦ Z〉

⇐ {• Z is an independent part of s}∀〈b |||| b◦Z = b◦Z ◦Z〉

≡ {Z is a set, so Z ◦Z = Z}true

The second lemma states that if Z is an independent part of a program s, thenthe canonical behaviour of s is equal to the canonical behaviour of the result ofstatement-Z-overriding s with the const of the canonical behaviour of s:

µs = µ(s ©O Z const.µs) ⇐ Z is an independent part of s

proof

We split the proof into ⊇ and ⊆. For the ⊇ we use induction, showing that µs is a

fixed point of (s ©O Z const.µs):

(s ©O Z const.µs).µs

= {definition of ©O }s.µs ©O Z (const.µs).µs

= {computation, definition of const}µs ©O Z µs

= {idempotency of ©O Z}µs

For the ⊆ we calculate

194

µs ⊆ µ(s ©O Z const.µs)

⇐ {µg ⊆ µh if each fixed point of h is a fixed point of g}

∀〈b || (s ©O Z const.µs).b = b || s.b = b〉≡ {definition of ©O }∀〈b || s.b ©O Z (const.µs).b = b || s.b = b〉

≡ {definition of const}∀〈b || s.b ©O Z µs = b || s.b = b〉

≡ {Leibniz}∀〈b || s.b ©O Z µs = b || s.b = s.b ©O Z µs〉

≡ {S = S©O ZS′ ≡ S ◦Z = S′ ◦Z}∀〈b || s.b ©O Z µs = b || s.b ◦ Z = µs ◦ Z〉

≡ {• Z is an independent part of s, then s.b ◦ Z = s.µs ◦ Z follows from b◦Z = µs◦Zwhich again follows from b = s.b ©O Z µs}

∀〈b || s.b ©O Z µs = b || s.µs ◦ Z = µs ◦ Z〉≡ {computation}

true

Using these two lemmas, we prove a third one that we call the isolation lemma:

µ(s ©O Z s′) = µ(s ©O Z const.µs′) ⇐ Z is an independent part of s′

proof

We assume that Z is an independent part of s′. A trivial consequence is that it

then also is an independent part of s ©O Z s′. We now calculate:

195

µ(s ©O Z s′)

= {second lemma, Z is an independent part of s ©O Z s′}

µ(s ©O Z s′ ©O Z const.µ(s ©O Z s′))

= {x0 ©O Z x1 ©O Z x2 = x0 ©O Z x2}

µ(s ©O Z const.µ(s ©O Z s′))

= {x ©O Z x′ = x ©O Z (x′ ◦ const.Z)}

µ(s ©O Z (const.µ(s ©O Z s′) ◦ const.Z))

= {const.S0 ◦ const.S1 = const.(S0◦S1)}

µ(s ©O Z const.(µ(s ©O Z s′) ◦ Z))

= {first lemma, Z is an independent part of s ©O Z s′}

µ(s ©O Z const.(µ((s ©O Z s′) ◦ const.Z)))

= {(x ©O Z x′) ◦ const.Z = x′ ◦ const.Z}

µ(s ©O Z const.(µ(s′ ◦ const.Z)))

= {first lemma, Z is an independent part of s′}

µ(s ©O Z const.(µs′ ◦ Z))

= {const.(S0◦S1) = const.S0 ◦ const.S1}

µ(s ©O Z (const.µs′ ◦ const.Z))

= {x ©O Z (x′ ◦ const.Z) = x ©O Z x′}

µ(s ©O Z const.µs′)

With this isolation lemma, we are now able to prove the theorem that we were after:

(s0 ©O Z1s1)

µ

⊆ (s0 ©O Z1s)

⇐ {• Z1 is an independent part of s1 and s}

s1

µ

⊆ s

proof

(s0 ©O Z1s1)

µ

⊆ (s0 ©O Z1s)


⊆}

µ(s0 ©O Z1s1) ⊆ µ(s0 ©O Z1

s)

≡ {isolation lemma, • Z1 is an independent part of s1 and s}

µ(s0 ©O Z1const.µs1) ⊆ µ(s0 ©O Z1

const.µs)

⇐ {section 8.5.7}

const.µs1 ⊆ const.µs

≡ {simple refinement rule for const}µs1 ⊆ µs


⊆}

s1

µ

⊆ s

196

As already mentioned, the following theorem is a trivial consequence:

(s0 Z0©C Z1

s1)µ

⊆Z0∪Z1s

⇐ {• Z0 and Z1 are disjoint sets and • Z1 is an independent part of s and s1}

s0

µ

⊆Z0s ∧ s1

µ

⊆Z1s

If we have a look at the example of section 8.5.1 and the parts M = I )−−−( {m} andN = I )−−−( {n}, then we see that M is an independent part of p and pm . Thismeans that the fact that pm is a behavioural M -refinement of p and that pn isa behavioural N -refinement of p, gives us that the statement-(M, N)-componentcomposition of pm and pn is a behavioural M∪N -refinement of p.

If we compose two components with ©C , it is not necessary that one of them isan independent part to be able to apply the main theorem of this section. As anexample, we again take program MATH , defined by

MATH = Crease1⊳Crease ∩ Three ⊳Three ∩ four ⊳fourCrease1 = inc1⊳inc ∩ dec1⊳decThree = direct3⊳direct ∩ indirect3⊳indirect

inc1 = const.[[C| = C|+1]]

dec1 = const.[[C| = C|−1]]

direct3 = (call⊲Crease)⊲dec ◦ const.[[C| = 4]]indirect3 = (call⊲Crease)⊲dec ◦ call⊲fourfour = (call⊲Crease)⊲inc ◦ (call⊲Three)⊲direct

Now, consider the three parts

Z1 = I )−−−( {Crease}Z3 = I )−−−( {Three}Z4 = I )−−−( {four}

Part Z1 clearly is an independent part of MATH . However, the parts Z3 and Z4

depend on each other, so we cannot apply the main theorem to them. The crux isto consider the parts

Z30 = (I )−−−( {direct}) )−−−( {Three}Z31 = (I )−−−( {indirect}) )−−−( {Three}Z4 = I )−−−( {four}

We see that Z1∪Z30 and Z1∪Z30∪Z4 are independent parts of MATH . Be-haviourally refining Z3 as a whole is not allowed, but behaviourally refining the indi-vidual parts Z1, Z30, Z31 and Z4 is allowed, as long as Z1, Z1∪Z30 and Z1∪Z30∪Z4

remain independent parts:

197

MATH 1

µ

⊆Z1MATH ∧

MATH 30

µ

⊆Z30MATH ∧

MATH 4

µ

⊆Z4MATH ∧

MATH 31

µ

⊆Z31MATH

⇒ {• Z1 is an independent part of MATH 1}

(MATH 1 Z1©C Z30

MATH 30)µ

⊆Z1∪Z30MATH ∧

MATH 4

µ

⊆Z4MATH ∧

MATH 31

µ

⊆Z31MATH

⇒ {• Z1∪Z30 is an independent part of MATH 1 Z1©C Z30

MATH 30}

((MATH 1 Z1©C Z30

MATH 30) Z1∪Z30©C Z4

MATH 4)µ

⊆Z1∪Z30∪Z4MATH ∧

MATH 31

µ

⊆Z31MATH

⇒ {• Z1∪Z30∪Z4 is an independent part of (MATH 1 Z1©C Z30


MATH 4}

(((MATH 1 Z1©C Z30


MATH 4) Z1∪Z30∪Z4©C Z31

MATH 31)µ

⊆Z1∪Z30∪Z4∪Z31MATH

This recipe can be used to handle many practical situations. Suppose that we havea program s and a set of disjoint parts Z ∈ ℘(℘I). A Z-preorder D ∈ Z )−−−(Z iscalled a dependency relation of 〈s,Z〉 if for each part Z ∈ Z, the union of allparts that D connects with input Z, is an independent part of s:

∀〈Z || Z ∈ Z ||⋃

(D◮Z) is an independent part of s〉

The dependency relation that we used for our example looks as follows (we omittedthe arrows from a part to itself):

Z1

Z30�

-

Z31

�

Z4

6

�

�

An independent part in this graph is a collection of nodes without outgoing arrows.

If Z is finite and the dependency relation is a Z–partial-order (meaning that itsgraph contains no cycles), then all parts in Z may be behaviourally refined inisolation. Using the main theorem of this section, this can be proved by inductionin the way suggested by the above calculation.

The main message is that in the context of statement-component composition (theway components are composed in practice) mutual dependencies should be avoidedas much as possible. A simple solution could be to treat mutually dependent parts

198

as one part and behaviourally refine this part as a whole. We may still refine partsof this whole in isolation by choosing one part of this whole that we really want tobehaviourally refine, and statement-refine the other parts of this whole (using thetheorem of section 8.5.7). Although these solutions might be sufficiently powerfulfor many practical situations, they also might not be for some cases. The mainproblem seems to be the fact that a call to a procedure may be replaced by thespecification of that procedure. This means that the information that it is a callto that procedure is lost. We already mentioned in section 8.4.5 that in the nextchapter, we introduce a model where calls can be made visible. The visibility of callsbetween mutually dependent parts might bring us closer to behavioural refinementof mutually dependent programs in isolation. We leave that for future researchhowever.

8.6 Totality

In this section we investigate the addition of totality requirements on refinementbetween statements.

8.6.1 Total statement-refinement

A statement s′ is a total statement-refinement of a statement s if for eachcontext b, s′.b is a total refinement of s.b. Formally, the is-total-statement-

refinement-of ⊑ ∈ B <−−−| ((I )−−−( I) <−−−| I)×((I )−−−( I) <−−−| I) is defined by

s′ ⊑ s ≡ ∀〈b |||| s′.b ⊑ s.b〉

8.6.2 Total behavioural refinement

A program s′ is a total behavioural refinement of a program s if the canonicalbehaviour of s′ is a total refinement of that of s. The is-total-behavioural-

refinement-ofµ

⊑ ∈ B <−−−| ((I )−−−( I) <−−−|m (I )−−−( I))×((I )−−−( I) <−−−|m (I )−−−( I)) is de-

fined by

s′µ

⊑ s ≡ µs′ ⊑ µs

8.6.3 Example

In section 8.5.7 we saw that the addition of recursion already introduces someproblems in the field of components. These problems were caused by mutual de-pendencies. Switching from partial refinement to total refinement introduces somenew challenges that are unrelated to mutual dependencies.

199

We again take the q, qc and qd of section 8.5.1:

q = c⊳c ∩ d⊳d

c = const.[[C| ≥ 3]]

d = const.[[C| ≥ 4]]


c′ = const.[[C| = 3]]


d′ = const.[[C| = C|+1]] ◦ call⊲c

The statement-(C, D)-component composition of qc and qd , where C = I )−−−( {c}and D = I )−−−( {d}:

qc C©C D qd = c′⊳c ∩ d′⊳d

‘clearly’ is a total behavioural refinement of q. One might be inclined to think that,similar to section 7.8.4, this is a trivial consequence of the fact that qc and qd aretotal behavioural refinements of q. However, another total behavioural refinementof q is qd2, defined by

qd2 = c⊳c ∩ d2⊳dd2 = const.{[C| ≥ 4]} ◦ call⊲c

Its statement-(C, D)-component composition with qc:

qc C©C D qd2 = c′⊳c ∩ d2⊳d

is not a total behavioural refinement of q. The problem is that after statement-component composition, the effect of a call to c changes in a way ‘the designersof qd2 did not foresee’. The call expansion rule shows the exact problem. It tellsus that the canonical behaviour of qd2 is equal to the canonical behaviour of qd2

′,defined by

qd2′ = c⊳c ∩ d2

′⊳d

d2′ = const.{[C| ≥ 4]} ◦ const.[[C| ≥ 3]]

or simplifying the definition of d2′:

qd2′ = c⊳c ∩ d2

′⊳d

d2′ = const.[[C| ≥ 4]]

In other words, µqd2 equals µq. The canonical behaviour of (qc M©C N qd2) is

however equal to the canonical behaviour of qcd2, defined by

200

qcd2 = c′⊳c ∩ d2′′⊳d

d2′′ = const.{[C| ≥ 4]} ◦ const.[[C| = 3]]

or simplifying the definition of d2′′:

qcd2 = c′⊳c ∩ d2′′⊳d

d2′′ = ©�

which clearly is not a total behavioural refinement of q.

8.6.4 Conservative users

In this section we investigate the totality issue of the previous subsection. Wedo not consider mutual dependencies, assuming that we have a team A writing astatement s that makes use of some total refinement b′ that a team B is developingof some specification b. The issue is that team A does not exactly know what teamB’s b′ looks like. Team A only has an abstract description b and knows that theconcrete b′ is a total refinement of that description. Of course team A wants itsstatement s to ‘work’ for each possible total refinement that team B can come upwith. With ‘work’ we mean that for every total refinement b′ of b, s.b′ should be atotal refinement of s.b:

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉

If this property holds, we call s a conservative user of b.

If we would only demand partial refinement, we would obtain the property

∀〈b′ || b′ ⊆ b || s.b′ ⊆ s.b〉

which we get for free if s is monotonic. From section 8.2.9 we know that mono-tonicity of s is not hard to achieve. However, monotonicity alone is not enough inthe context of total refinement. In the following calculation we isolate the extraproperty that we need besides monotonicity:

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡ {definition of ⊑}∀〈b′ || b′ ⊑ b || s.b′ ⊆ s.b ∧ (s.b′)> ⊇ (s.b)>〉

≡∀〈b′ || b′ ⊑ b || s.b′ ⊆ s.b〉 ∧ ∀〈b′ || b′ ⊑ b || (s.b′)> ⊇ (s.b)>〉

≡ {• monotonicity of s}∀〈b′ || b′ ⊑ b || (s.b′)> ⊇ (s.b)>〉

This extra property is not so trivial to accomplish. Take for example the specifica-tion b9 that outputs an arbitrary integer number that is less than 9:

201

b9 = [[C| ∈ ZZ ∧ C| ≤ 9]]

Statement s6, defined by

s6 = const.[[C| ∈ ZZ ∧ C| ≤ 6 ∧ C| ≥ C| ]] ◦ call

is not a conservative user of b9, although s6.b9 is total. For the total refinement b8

of b9, defined by

b8 = [[C| = 8]]

s6.b8 is equal to ©�, which clearly is not total.

Another way to show that s6 is not a conservative user of b9, is to derive a b′ thatcan act as counter example. Assuming that b′ ⊑ b9, we calculate:

s6.b′ ⊑ s6.b9

≡ {monotonicity of s6}(s6.b

′)> ⊇ (s6.b9)>

≡ {(s6.b9)> = I}(s6.b

′)> ⊇ I

≡∀〈z |||| ∃〈y |||| y (−s6.b

′ −) z〉〉≡ {definition of s6}

∀〈z |||| ∃〈y |||| y (−[[C| ∈ ZZ ∧ C| ≤ 6 ∧ C| ≥ C| ]]◦b′ −) z〉〉≡ {definition of ◦}

∀〈z |||| ∃〈y, x |||| y (−[[C| ∈ ZZ ∧ C| ≤ 6 ∧ C| ≥ C| ]]−) x ∧ x (−b′ −) z〉〉

≡ {x (−b′ −) z ⇒ x (−b9−) z and x (−b9−) z ⇒ x ∈ ZZ}∀〈z |||| ∃〈y, x ||

|| y ∈ ZZ ∧ y ≤ 6 ∧ y ≥ x ∧ x ∈ ZZ ∧ x (−b′ −) z〉〉

≡ {(⇒): x ≤ y ∧ y ≤ 6 ⇒ x ≤ 6, (⇐): take y = x}∀〈z |||| ∃〈x |||| x ∈ ZZ ∧ x ≤ 6 ∧ x (−b′ −) z〉〉

So, by assuming s6.b′ to be a total refinement of s6.b9, we derived that each total

refinement b′ of b9 should satisfy

∀〈z |||| ∃〈x |||| x ∈ ZZ ∧ x ≤ 6 ∧ x (−b′ −) z〉〉

This property clearly does not hold for every total refinement of b9 (b8 providesagain a counter example).

In general, for a specification b and a statement s, we have that s is not a conser-vative user of b exactly when there exists a total predicate p that holds for eachspecification b′ for which s.b′ is a total refinement of s.b, but that does not hold foreach total refinement of b:

202

¬∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡

∃〈p || p ∈ B <−−−| (I )−−−( I) || ∀〈b′ || s.b′ ⊑ s.b || p.b′〉 ∧ ¬∀〈b′ || b′ ⊑ b || p.b′〉〉

Taking the negation of both sides of the equivalence, we see that this is equivalentto the fact that s is a conservative user exactly when each total predicate p thatholds for each specification b′ for which s.b′ is a total refinement of s.b, also holdsfor each total refinement of b:

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡∀〈p || p ∈ B <−−−| (I )−−−( I) || ∀〈b′ || s.b′ ⊑ s.b || p.b′〉 ⇒ ∀〈b′ || b′ ⊑ b || p.b′〉〉

The (⇒) is trivial. For (⇐), take the total predicate p defined by

p.b′ ≡ s.b′ ⊑ s.b

A third way to look at conservativity, is that the set of all total refinements of b forwhich s ‘works’, should be equal to the set of all total refinements of b. In otherwords:

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡{b′ | b′ ⊑ b ∧ s.b′ ⊑ s.b | b′} = {b′ | b′ ⊑ b | b′}

This is a trivial result of the fact that

(x ⇒ y) ≡ (x∧y ≡ x)

We thus found three equivalent formulations of conservativity:

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡∀〈p || p ∈ B <−−−| (I )−−−( I) || ∀〈b′ || s.b′ ⊑ s.b || p.b′〉 ⇒ ∀〈b′ || b′ ⊑ b || p.b′〉〉

≡

{b′ | b′ ⊑ b ∧ s.b′ ⊑ s.b | b′} = {b′ | b′ ⊑ b | b′}

Notice that the equivalence of these three notions is actually independent of therefinement relation that we choose (⊑ in the above case).

The reason why we focus on these three formulations in particular, is that theseare all fundamental notions in ISpec. To clarify this somewhat, we introduce afew ad-hoc notions. We read (s, b) as “specification b extended with s”, calling bthe “base” and s the “extension”. Taking the identity function I for s means “noextension”. We define (s, b) |= p (p is “valid” for (s, b)) by

203

(s, b) |= p ≡ ∀〈b′ || s.b′ ⊑ s.b || p.b′〉

and B(s, b) (the “behaviour of the base” of (s, b)) by

B(s, b) = {b′ | b′ ⊑ b ∧ s.b′ ⊑ s.b | b′}

We can now reformulate the above three equivalent formulations of conservativityas

∀〈b′ || b′ ⊑ b || s.b′ ⊑ s.b〉≡∀〈p || p ∈ B <−−−| (I )−−−( I) || (s, b) |= p ⇒ (I, b) |= p〉

≡B(s, b) = B(I, b)

In ISpec, the first formulation would be referred to as “b is substitutable in s”,the second one would be referred to as “s is a conservative extension of b” andthe third one would be referred to as “s does not influence the behaviour of b”. Wethus showed that these three notions are equivalent in the framework that is usedhere.

Now that we know that conservativity can be disproved by finding an appropriatecounter-example predicate, the question naturally rises how to prove conservativity.We again take our specification b9, defined by

b9 = [[C| ∈ ZZ ∧ C| ≤ 9]]

The statement s12, defined by

s12 = const.[[C| ∈ ZZ ∧ C| ≤ 12 ∧ C| ≥ C| ]] ◦ call

is a conservative user of b9. To prove conservativity, we usually need to combinetotality properties with partial-refinement properties. This is where the type oper-ator−−−)◦ comes in. The meaning of S ∈ A−−−)◦ B is that S connects each input thatis an element of B to at least one element of A and only to elements of A. Some

conservativity rules that we can use, are that for sets A(′), B(′), C and G:

S ∈ A −−−)◦ B′ ⇐ S ∈ A′ −−−)◦ B ∧ A′ ⊆ A ∧ B′ ⊆ BS′ ∈ A −−−)◦ B ⇐ S ∈ A −−−)◦ B ∧ S′ ⊑ Sif G then S0

else S1 ∈ A −−−)◦ B ⇐ S0 ∈ A−−−)◦ B∩G ∧ S1 ∈ A−−−)◦ BrGS0◦S1 ∈ A −−−)◦ B ⇐ S0 ∈ A−−−)◦ C ∧ S1 ∈ C −−−)◦ BB ∈ B′ −−−)◦ B′ ⇐ B′ ⊆ B

Comparing these conservativity rules to the totality rules:

204

S ∈ A−−−) B′ ⇐ S ∈ A′ −−−) B ∧ A′ ⊆ A ∧ B′ ⊆ BS′ ∈ A−−−) B ⇐ S ∈ A −−−) B ∧ S′ ⊇ SS0∪S1 ∈ A−−−) B∪D ⇐ S0 ∈ A −−−) B ∧ S1 ∈ A −−−) DS0◦S1 ∈ A−−−) B ⇐ S0 ∈ A −−−) C ∧ S1 ∈ C −−−) BB ∈ B −−−) B

and the cylindric-type rules:

S ∈ A−−−◦ B′ ⇐ S ∈ A′ −−−◦ B ∧ A′ ⊆ A ∧ B′ ⊆ BS′ ∈ A−−−◦ B ⇐ S ∈ A −−−◦ B ∧ S′ ⊆ SS0∪S1 ∈ A−−−◦ B ⇐ S0 ∈ A −−−◦ B ∧ S1 ∈ A −−−◦ BS0◦S1 ∈ A−−−◦ B ⇐ S0 ∈ A −−−◦ C ∧ S1 ∈ C −−−◦ BI ∈ B −−−◦ B

we see that at the places where the totality rules and cylindric-type rules differ, theconservativity rules show a way to integrate them: the inclusion rules have beenintegrated into a rule about total refinement, the union rules have been integratedinto an if-then-else rule and the guard rules have been integrated into a generalisedrule, where the generalisation compensates for the fact that the inclusion rules havebeen replaced by the total-refinement rule.

The following calculation shows how the conservativity rules can be used to provethat s12 is a conservative user of b9:

s12.b′ ∈ I−−−)◦ I

≡ {definition of s12}

(const.[[C| ∈ ZZ ∧ C| ≤ 12 ∧ C| ≥ C| ]] ◦ call).b′ ∈ I−−−)◦ I

≡ {definition of ◦, const and call}

[[C| ∈ ZZ ∧ C| ≤ 12 ∧ C| ≥ C| ]]◦b′ ∈ I −−−)◦ I

⇐ {conservativity rule for ◦}

[[C| ∈ ZZ ∧ C| ≤ 12 ∧ C| ≥ C| ]] ∈ I −−−)◦ {[C| ∈ ZZ ∧ C| ≤ 12]} ∧b′ ∈ {[C| ∈ ZZ ∧ C| ≤ 12]} −−−)◦ I

⇐ {first conjunct is left to the reader, conservativity rule for total refinement, • b′ ⊑ b9}b9 ∈ {[C| ∈ ZZ ∧ C| ≤ 12]} −−−)◦ I


The conservativity rules show the fundamental issues but do not make up a powerfulproof system. For that the total-correctness rules that were presented in section7.8.3 seem the obvious candidate, but we have to leave this for future research.

How does all this relate to components and their composition? Suppose that wehave a program with an independent part. Then the above conservativity storycan be applied where the canonical behaviour of the independent part is the usedspecification and the rest of the program is the user. To be precise:

205

(s0 Z0©C Z1

s1)µ

⊑Z0∪Z1s

⇐ {• Z0 and Z1 are disjoint sets and • Z1 is an independent part of s1 and s

• 〈µ(s0 ©O Z1const.b) || b〉 is a conservative user of µs}

s0

µ

⊑Z0s ∧ s1

µ

⊑Z1s

Similar to the sections 8.5.7 and 8.5.8, the core step of the proof is the followingtheorem:

(s0 ©O Z1s1)

µ

⊑ (s0 ©O Z1s)

⇐ {• Z1 is an independent part of s1 and s

• 〈µ(s0 ©O Z1const.b) || b〉 is a conservative user of µs}

s1

µ

⊑ s

proof

(s0 ©O Z1s1)

µ

⊑ (s0 ©O Z1s)


⊑}

µ(s0 ©O Z1s1) ⊑ µ(s0 ©O Z1

s)

≡ {isolation lemma, • Z1 is an independent part of s1 and s}

µ(s0 ©O Z1const.µs1) ⊑ µ(s0 ©O Z1

const.µs)

⇐ {• 〈µ(s0 ©O Z1const.b) || b〉 is a conservative user of µs}

µs1 ⊑ µs


⊑}

s1

µ

⊑ s

The above theorems do not give a detailed path on how to prove total behaviouralrefinement in a modular fashion within our framework. That is left for futureresearch, as is the investigation whether or not the theory of the next chapter couldprovide a more powerful theory that allows mutually dependent parts to be refinedin isolation.

8.7 Conclusions

In this chapter we showed how recursion is modeled. We paid special attention topartial and total behavioural refinement and investigated component composition inthese settings. We pointed out that the use of relations as model for behaviour has asa consequence that communication between components is invisible. This seems tobe the main cause for the problem that we encountered with statement-componentcomposition in section 8.5.7. To illustrate the problem in a more practical setting,we now reformulate it in terms of the observer pattern of section 2.2.4.

Suppose that the observer pattern is behaviourally refined by two teams in isolationwhere one team refines Subject and the other team refines Observer. Further-

206

more, the fact that fillWith really calls update, instead of only realising the givenspecification, cannot be expressed. A behavioural refinement of Subject wouldthen be that fillWith updates the Observer’s copy by a different means thancalling update. Suppose that in the behavioural refinement of Observer, methodinsertInto sets some boolean b to true before the call to fillWith and update

sets b again to false. After the call to fillWith, insertInto now changes thevalue of copy into 481 if b is true. Both teams have constructed correct behaviouralrefinements of the observer pattern. However, in the statement-component compo-sition of these refinements, the observer pattern’s invariant is violated in general.The reason is that b is not set to false when insertInto calls fillWith, becausefillWith does not call update.

One could simply deal with the above problem by requiring that if one combinesthe implementations of several specifications by statement-component composition(called implementation inheritance), one has to prove that the combinationis a behavioural refinement of (implements) all these specifications. This meansthat for each implementation we reuse, we have to construct a new correctnessproof. The theory of section 8.5.8 shows that if we prove that there exist no mutualdependencies, these correctness proofs are not necessary. In other words, the theoryenables modular reuse of implementations. In the next chapter we introduce a modelwhere communication between components can be made visible. Whether or notvisible communication can provide the fundaments for a more powerful theory thateven works when there exist mutual dependencies, is left for future research.

207

Chapter 9

Protocols

In the previous chapter we observed that it is not possible to specify ‘visible calls’ ifrelations are used as model for behaviour. In this chapter we present a generalisationof relations, called connection protocols, that can capture the extra informationthat is needed for this. Where a relation is a collection of connections, a connectionprotocol is a collection of so-called connection traces.

9.1 Definitions

In this section we introduce some external types that form the basis of connectionprotocols.

9.1.1 Sequences

We assume that there exists an external type of (finite) sequences. We do notdefine this external type formally, but limit ourselves to saying that we use thesame notation for sequences as for tuples, except that we decorate them with a

V. A

sequence of length n (n ∈ N) that consists of the respective elements x0, . . . , xn−1

is denoted by

〈x0, . . . , xn−1〉V

For a set A, the set of sequences with elements of type A is denoted by VA:

〈x0, . . . , xn−1〉V ∈ VA ≡ x0, . . . , xn−1 ∈ A

The formula v ∈ VI means that v is a sequence and thus that v = 〈x0, . . . , xn−1〉Vfor some x0, . . . , xn−1 for some n ∈ N. The formula itself is equivalent to true.

209

The sequence 〈〉V

is called the empty sequence.

The concatenation ++ ∈ VI <−−−| VI×VI pastes two sequences together:

〈y0, . . . , yn−1〉V ++ 〈z0, . . . , zn−1〉V = 〈y0, . . . , yn−1, z0, . . . , zn−1〉V

The number-of # ∈ (N <−−−| VI) <−−−| I counts the number of occurrences of a certainelement in a sequence:

#a.〈〉V = 0#a.〈x〉V = 0 ⇐ a 6= x#a.〈x〉V = 1 ⇐ a = x#a.(v0++v1) = #a.v0 + #a.v1

The occurs-in in ∈ B <−−−| I×VI checks whether or not a certain element occurs ina sequence:

a in 〈〉V

≡ falsea in 〈x〉

V≡ a = x

a in v0++v1 ≡ a in v0 ∨ a in v1

The all-contained-by <− ∈ B <−−−| VI×PI checks if all elements in a sequence arecontained by a given collection:

v <− C ≡ ∀〈x || x in v || x ǫ C〉

9.1.2 Traces

We also assume that there exists an external type of (finite) traces. A trace isdenoted by (x, v)

Twhere the root element x is an arbitrary element and the

visual v is a sequence of traces.

A node trace of a trace is either the trace itself or a node trace of a trace in thevisual:

t is a node trace of (x, v)T

≡t = (x, v)

T∨ ∃〈t′ || t′ in v || t is a node trace of t′〉

A node element of a trace is the root element of some node trace of the trace:

x is a node element of t

≡∃〈v |||| (x, v)

Tis a node trace of t〉

For a set A, the set of all traces with node elements of type A, is denoted by TA:

210

t ∈ TA ≡ ∀〈x || x is a node element of t || x ∈ A〉

An example of a trace of type TN, consisting of 7 nodes, is

(0, 〈(1, 〈(2, 〈〉V)T〉V)T, (2, 〈(0, 〈〉

V)T, (3, 〈〉

V)T〉V)T, (3, 〈〉

V)T〉V)T

The two occurrences of (3, 〈〉V)T

are different nodes with the same node trace.

The following representation of the above trace is called a tree picture:

0

1 2 3

2 0 3

9.1.3 Connection traces

Traces with connections as node elements are called connection traces. Connec-tion traces thus have type T(I⋆I). Instead of ((y, z), v)

T, we usually write (y:v:z)

T.

We call y the output and z the input of this connection trace.

Two examples of connection traces are

(0:〈(1:〈〉V:1)

T, (0:〈〉

V:2)

T〉V:1)

T

and

(0:〈(1:〈(1:〈〉V:0)

T〉V:2)

T〉V:1)

T

In terms of tree pictures:

(0,1)

(1,1) (0,2)

for the first connection trace and

(0,1)

(1,2)

(1,0)

211

for the second one.

Another way to visualise connection traces is by means of a connection-tracepicture. For the first connection trace, this picture is

I O

O 0

1

2

O

I

I

and for the second connection trace it is

O O

O 0

1

2

I

I

I

In these pictures a connection trace is divided into an observation sequence,〈0, 1, 1, 0, 2, 1〉

Vfor both traces, and a connection pattern, 〈O, O, I, O, I, I〉

Vand

〈O, O, O, I, I, I〉V

respectively. A connection pattern is not an arbitrary sequence ofOs and Is. It is non-empty with an equal number of Os and Is and for each O, thenumber of Is on its right minus the number of Os on its right is at least 1. Formally,a sequence l ∈ V{O, I} is a connection pattern if

#I.l = #O.l ≥ 1

and

∀〈l0, l1 || l = l0++〈O〉V++l1|| #I.l1 − #O.l1 ≥ 1〉

An equivalent definition is

l = 〈O, I〉V

∨l = 〈O〉

V++l′++〈I〉

Vfor some connection pattern l′ ∨

l = l0++l1 for connection patterns l0 and l1

Each connection trace corresponds to the combination of an observation sequenceand a connection pattern of equal length. If we walk from right to left through theconnection-trace picture and connect each O we encounter with the nearest I on itsright that is not already connected to some O, then each connection corresponds toa node of the connection trace. For the first example connection trace:

212

I O

O 0

1

2

O

I

I

and for the second one:

O O

O 0

1

2

I

I

I

9.1.4 Protocols

A protocol is a collection of traces. The set of all protocols is thus P(TI).

9.1.5 Connection protocols

A connection protocol is a protocol where the node elements of the traces areconnections. The set of all connection protocols is thus P(T(I⋆I)).

The set of all connection protocols whose traces have a root element (a connection)whose output is of type A and input is of type B, is denoted by A )∧∨

∧

∨

∧

∨( B:

P ∈ A )∧∨

∧

∨

∧

∨( B

≡∀〈y, v, z || (y:v:z)

Tǫ P || y ∈ A ∧ z ∈ B〉

A connection protocol can be visualised by drawing all its connection traces intoone connection-protocol picture. For the connection protocol

[(0:〈(1:〈〉V:1)

T, (0:〈〉

V:2)

T〉V:1)

T, (1:〈(0:〈〉

V:2)

T〉V:0)

T]

this picture looks for example like

213

I O

O 0

1

2

O

I

I

I

I

O

O

9.2 Protocol operators

In this section we define some operators that, next to the collection operators, canbe used to manipulate protocols.


The sequential protocol composition ◦p ∈ (I )∧∨

∧

∨

∧

∨( I) <−−−| (I )∧∨

∧

∨

∧

∨( I)×(I )∧∨

∧

∨

∧

∨( I) isdefined by

(y:v:z)T

ǫ P 0◦pP 1

≡∃〈v0, x, v1

|| v = v0++v1

|| (y:v0:x)

Tǫ P 0 ∧ (x:v1:z)

Tǫ P 1〉

Connection-protocol pictures provide a good means to understand how this operatorworks.

9.2.2 Identity protocol

The identity protocol Ip ∈ I )∧∨

∧

∨

∧

∨( I is defined by

(y:v:z)T

ǫ Ip ≡ y = z ∧ v = 〈〉V

9.2.3 Domain and range

The protocol-domain and protocol-range >p, <p ∈ (I )∧∨

∧

∨

∧

∨( I) <−−−| (I )∧∨

∧

∨

∧

∨( I) are de-fined by

(y:v:z)T

ǫ P >p

≡y = z ∧ v = 〈〉

V∧ ∃〈y′, v′ ||

|| (y′:v′:z)

Tǫ P 〉

(y:v:z)T

ǫ P <p

≡y = z ∧ v = 〈〉

V∧ ∃〈v′, z′ |||| (y:v′:z′)

Tǫ P 〉

214

9.2.4 Pick and pack

The protocol-pick ⊲p ∈ (I )∧∨

∧

∨

∧

∨( I) <−−−| ((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I))×I and the protocol-pack ⊳p ∈ ((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−| (I )∧∨

∧

∨

∧

∨( I)×I are defined by

(y:v:z)T

ǫ P⊲pi ≡ ([(y, i)]:v:[(z, i)])T

ǫ P

(Y :v:Z)T

ǫ P⊳pi

≡∃〈y, z, j || Y = [(y, j)] ∧ Z = [(z, j)] || j = i ⇒ (y:v:z)

Tǫ P 〉

The correspondence with the pick and pack on relations should be clear from thefollowing definitions for those:

y (−R⊲i−) z ≡ [(y, i)] (−R−) [(z, i)]

Y (−R⊳i−) Z

≡

∃〈y, z, j || Y = [(y, j)] ∧ Z = [(z, j)] || j = i ⇒ y (−R−) z〉

We leave it to the reader to verify that this definition of ⊳ is equivalent to theoriginal one.

9.2.5 Universal dark protocol

The universal dark protocol dark ∈ P(TI) is defined by

(x, v)T

ǫ dark ≡ v = 〈〉V

A subcollection of dark is called a dark protocol. A dark protocol is a protocolthat ‘performs no visible actions’.

9.2.6 Show

The show show ∈ P(TI) <−−−| P(TI) is defined by

(x, v)T

ǫ show.P ≡ ∃〈v′ || v = 〈(x, v′)T〉V

|| (x, v′)

Tǫ P 〉

The show transforms a protocol P into one that contains the traces (x, 〈(x, v′)T〉V)T

for all (x, v′)T

that P contains. It makes the root element of each trace in P visible.

215

9.2.7 Spec

The spec spec ∈ P(TI) <−−−| PI is defined by

(x, v)T

ǫ spec.C ≡ x ǫ C

The spec enables the specification of possible root elements by means of a collection.

9.2.8 Example

In this section we present a small example to show the above operators in action.

We define the connection protocols M and N by

M = dark ∩ spec.[[C| ≥ 3]]

N = dark ∩ spec.[[C| ≥ C| ]]

The following equivalences show the meaning of some connection protocols. Weleave it to the reader to verify these equivalences:

(y:v:z)T

ǫ M ≡ v = 〈〉V∧ y (−≥−) 3

(y:v:z)T

ǫ N ≡ v = 〈〉V∧ y (−≥−) z

(y:v:z)T

ǫ (N ◦p M) ≡ v = 〈〉V∧ y (−≥−) 3

(y:v:z)T

ǫ (N ◦p show.M) ≡ ∃〈x || v = 〈(x:〈〉V:z)

T〉V

|| y (−≥−) x ∧ x (−≥−) 3〉

The last equivalence demonstrates how show can be used to make the intermediatex between M and N visible in the semantics.

9.3 Visual independence

A protocol P is called visual independent if

∀〈x, v, v′ |||| (x, v)

Tǫ P ≡ (x, v′)

Tǫ P 〉

or equivalently:

∀〈x, v, v′ || (x, v)T

ǫ P || (x, v′)T

ǫ P 〉

In other words, (x, v)T

ǫ P holds for every v if (and only if) it holds for some v.Visual-independent protocols model collections as protocols in a similar way asconditions model collections as relations (see section 3.4.4).

For every collection C, spec.C is visual independent. As a matter of fact, a protocolP is visual independent exactly when there exists a collection C such that P equalsspec.C:

216

P is visual independent

≡

∃〈C |||| P = spec.C〉

If P ⊆ R for a visual-independent protocol R, then we can ‘extract this visual-independent protocol from a show.P ’. The visual-independent extraction the-orem formalises what we mean by this:

show.P ⊆ R

≡ {• R is visual independent}P ⊆ R

proof

show.P ⊆ R

≡ {definition of ⊆}∀〈x, v || (x, v)

Tǫ show.P || (x, v)

Tǫ R〉

≡ {definition of show}∀〈x, v || ∃〈v′ || v = 〈(x, v′)

T〉V

|| (x, v′)

Tǫ P 〉 || (x, v)

Tǫ R〉

≡ {predicate calculus}∀〈x, v, v′ || v = 〈(x, v′)

T〉V∧ (x, v′)

Tǫ P || (x, v)

Tǫ R〉

≡ {1-point rule}∀〈x, v′ || (x, v′)

Tǫ P || (x, 〈(x, v′)

T〉V)T

ǫ R〉≡ {• R is visual independent}∀〈x, v′ || (x, v′)

Tǫ P || (x, v′)

Tǫ R〉

≡ {definition of ⊆}P ⊆ R

Visual-independent extraction enables extraction of relational behaviour from aprotocol. If we again take the M and N of section 9.2.8:

M = dark ∩ spec.[[C| ≥ 3]]

N = dark ∩ spec.[[C| ≥ C| ]]

then we can use visual-independent extraction to prove that the output of theconnection protocol (N ◦p show.M) is at least 3, or in the theorem’s words, to

extract the visual-independent connection protocol spec.[[C| ≥ 3]]:

N ◦p show.M ⊆ spec.[[C| ≥ 3]]

proof

217

N ◦p show.M ⊆ spec.[[C| ≥ 3]]

⇐ {show.M ⊆ spec.[[C| ≥ 3]], see below}

N ◦p spec.[[C| ≥ 3]] ⊆ spec.[[C| ≥ 3]]


show.M ⊆ spec.[[C| ≥ 3]]

≡ {visual-independent extraction}

M ⊆ spec.[[C| ≥ 3]]

≡ {definition of M}

dark ∩ spec.[[C| ≥ 3]] ⊆ spec.[[C| ≥ 3]]

≡ {P 0∩P 1 ⊆ P 1}true

9.4 Refinement

For (partial) refinement between protocols, we use inclusion (⊆). If we again takethe M and N of section 9.2.8:

M = dark ∩ spec.[[C| ≥ 3]]

N = dark ∩ spec.[[C| ≥ C| ]]

then the following refinement holds:

M ◦M ⊆ N ◦M

This means that first computing a number x greater than 3 and then a number thatis larger than x, is refined by first computing a number greater than 3 and then anarbitrary number greater than 3. This is a trivial consequence of the fact that theintermediate x is not visible.

If we put the M into a show, such a refinement is not possible anymore because theintermediate x is now visible:

M ◦ show.M * N ◦ show.M

The left protocol contains the trace (4:〈(3:〈〉V:0)

T〉V:0)

T, whereas the right protocol

does not.

For simple cases the following simple protocol-refinement rules can be used toprove refinement between protocols:

218

P 0′∩P 1

′ ⊆ P 0∩P 1 ⇐ P 0′ ⊆ P 0 ∧ P 1

′ ⊆ P 1

P 0′∪P 1

′ ⊆ P 0∪P 1 ⇐ P 0′ ⊆ P 0 ∧ P 1

′ ⊆ P 1

©� ⊆ ©� ≡ trueΠ ⊆ Π ≡ trueP 0

′ ◦pP 1′ ⊆ P 0◦pP 1 ⇐ P 0

′ ⊆ P 0 ∧ P 1′ ⊆ P 1

Ip ⊆ Ip ≡ trueP ′>p ⊆ P >p ⇐ P ′ ⊆ PP ′<p ⊆ P <p ⇐ P ′ ⊆ PP ′⊲pi ⊆ P⊲pi ⇐ P ′ ⊆ PP ′⊳pi ⊆ P⊳pi ≡ P ′ ⊆ Pdark ⊆ dark ≡ trueshow.P ′ ⊆ show.P ≡ P ′ ⊆ Pspec.C′ ⊆ spec.C ≡ C′ ⊆ C

We leave it to the reader to verify these rules. Notice that they cannot deal withthe above example.

We leave the study of total refinement in the context of protocols for future research.We give however a definition that we think is appropriate. The total protocolrefinement ⊑p ∈ B <−−−| (I )∧∨

∧

∨

∧

∨( I)×(I )∧∨

∧

∨

∧

∨( I) is defined by

P ′ ⊑p P ≡ P ′ ⊆ P ∧ P ′>p ⊇ P >p

9.5 Protocol statements

Because protocols are a special kind of collections, the theory of chapter 8 that isabout collections in general, also holds for protocols. In this particular setting, wetalk about protocol programs and protocol statements.

Next to the operators of chapter 8 that can be used for collections in general (⊆,

∩, ∪, ©�, Π, call and const), we introduce some operators specifically for protocolstatements.


The sequential protocol-statement composition ◦p ∈ ((I )∧∨

∧

∨

∧

∨( I) <−−−| I) <−−−| ((I)∧∨

∧

∨

∧

∨( I) <−−−| I)×((I )∧∨

∧

∨

∧

∨( I) <−−−| I) is defined by

(s0 ◦ps1).b = s0.b ◦p s1.b

9.5.2 Identity protocol statement

The identity protocol statement Ip ∈ ((I )∧∨

∧

∨

∧

∨( I) <−−−| I) is defined by

219

Ip.b = Ip

9.5.3 Pick and pack

The protocol-statement–pick ⊲p ∈ ((I )∧∨

∧

∨

∧

∨( I) <−−−| I) <−−−| (((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I))<−−−| I)×I and protocol-statement–pack ⊳p ∈ (((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−| I) <−−−|((I )∧∨

∧

∨

∧

∨( I) <−−−| I)×I are defined by

(s⊲pi).b = s.b ⊲p i(s⊳pi).b = s.b ⊳p i

9.5.4 Universal statement-dark statement

The universal statement-dark statement dark ∈ P(TI) <−−−| I is defined by

dark.b = dark

If s ⊆ dark holds, we call s statement-dark.

9.5.5 Show

The statement-show show ∈ (P(TI) <−−−| I) <−−−| (P(TI) <−−−| I) is defined by

(show.s).b = show.(s.b)

9.5.6 Spec

The statement-spec spec ∈ (P(TI) <−−−| I) <−−−| PI is defined by

(spec.C).b = spec.C

9.6 Visual-independent statements

A protocol statement s is called statement–visual-independent if s.b is visualindependent for all b.

The following statement–visual-independent—extraction theorem is a trivialconsequence of the visual-independent extraction theorem of section 9.3:

220

show.s ⊆ r

≡ {• r is statement–visual-independent}

s ⊆ r

9.7 Visibility of calls

In this section we investigate how call information can be made visible in a protocolprogram. In the first subsection we show a call that is completely invisible inthe semantics. The second subsection shows a call that is itself not visible, butwhose input/output is visible. The third subsection shows a call that appears to becompletely visible, but that could be ‘fake’.

9.7.1 Invisible calls

The protocol program p0, defined by

p0 = m⊳pm ∩ n0⊳pn

m = dark ∩ spec.[[C| ≥ 3]]

n0 = (dark ∩ spec.[[C| ≥ C| ]]) ◦p call⊲pm

has the same canonical behaviour as p0′, defined by

p0′ = m⊳pm ∩ n0

′⊳pn

n0′ = dark ∩ spec.[[C| ≥ 3]]

In other words, because the call to m in procedure n is not made visible, the bodyof n of the canonical behaviour only says that the output is at least 3 and that thevisual is empty:

(y:v:z)T

ǫ µp0 ⊲p n

≡v = 〈〉

V∧ y (−≥−) 3

9.7.2 Visible input/output

The protocol program p1, defined by


m = dark ∩ spec.[[C| ≥ 3]]

n1 = (dark ∩ spec.[[C| ≥ C| ]]) ◦p show.(call⊲pm)

has the same canonical behaviour as p1′, defined by

221

p1′ = m⊳pm ∩ n1

′⊳pn

n1′ = (dark ∩ spec.[[C| ≥ C| ]]) ◦p show.m

The fact that we can replace the “show.(call⊲pm)” by “show.m” means that theinformation that it is a call to m, is invisible. However, the input/output of m isvisible. The body of n of the canonical behaviour says that the visual is 〈(x:〈〉

V:z)

T〉V,

where z is the input of n and x is some element that is at least 3. The output is atleast x:

(y:v:z)T

ǫ µp1 ⊲p n

≡

∃〈x || v = 〈(x:〈〉V:z)

T〉V

|| y (−≥−) x ∧ x (−≥−) 3〉

9.7.3 ‘Fake’ visible calls

If we use “(show.call)⊲pm” instead of “show.(call⊲pm)”:


m = dark ∩ spec.[[C| ≥ 3]]

n2 = (dark ∩ spec.[[C| ≥ C| ]]) ◦p (show.call)⊲pm

then the show makes it impossible for (⊲pm) to completely cancel the (⊳pm). However,it can still be shown that p2 has the same canonical behaviour as p2

′, defined by

p2′ = m⊳pm ∩ n2

′⊳pn

m = dark ∩ spec.[[C| ≥ 3]]

n2′ = (dark ∩ spec.[[C| ≥ C| ]]) ◦p (show.(m⊳pm))⊲pm

The body of n of the canonical behaviour expresses that the visual is equal to〈([(x, m)]:〈〉

V:[(z, m)])

T〉V

where z is the input of n and x is some element that is atleast 3. The output is at least x:

(y:v:z)T

ǫ µp2 ⊲p n

≡∃〈x || v = 〈([(x, m)]:〈〉

V:[(z, m)])

T〉V

|| y (−≥−) x ∧ x (−≥−) 3〉

Although m now appears in the visual, we see that the n of p2′ contains no call. This

means that we still have not achieved to formalise what we mean by: “The outputis at least as large as the output of m.”. In the next section we address this issue.

222

9.8 Genuine statements

Putting a call into a show still does not make the call itself really visible. Intuitivelyspeaking, this is a result of the fact that the notions ‘protocol’ and ‘statement’are ‘orthogonal’ in protocol statements. We want the two notions to ‘interact’appropriately, by which we mean that ‘the only thing that is shown are real calls’.In this section we formalise this, enabling us to write a procedure whose body reallymeans that its output is at least as large as the output of some other procedure.

9.8.1 Introspectivity

A protocol P is introspective if for every trace t it contains, it also contains alltraces in the visual of t:

∀〈x, v || (x, v)T

ǫ P || v <− P 〉

For a set A, the set PTiA of introspective protocols where node elements have typeA, is defined by

P ∈ PTiA ≡ P ∈ P(TA) ∧ P is introspective

We leave it to the reader to verify that the operators ∩, ∪, ©�, Π, Ip and dark areintrospectivity preserving:

P 0∩P 1 ∈ PTiI ⇐ P 0, P 1 ∈ PTiIP 0∪P 1 ∈ PTiI ⇐ P 0, P 1 ∈ PTiI©� ∈ PTiIΠ ∈ PTiIIp ∈ PTiIdark ∈ PTiI

The operators ◦p, (⊲pi), (⊳pi), show and spec.C are not introspectivity preserving.We leave it to the reader to find counter examples.

The definition of introspectivity is recursive in the sense that if P is introspective,then for each trace t0 that P contains, P also contains each trace t1 that occursin the visual of t0 and thus, because P is introspective, P also contains each tracet2 that occurs in the visual of t1, etcetera. Because traces are finite, this impliesthat introspectivity is equivalent to the property that a protocol contains each ofits node traces:

∀〈x, v || (x, v)T

ǫ P || v <− P 〉≡∀〈t0 || t0 ǫ P || ∀〈t || t is a node trace of t0

|| t ǫ P 〉〉

The (⇐) is trivial. The (⇒) can be proved by induction on the depth of t0 where

223

the depth of a trace is 0 when its visual is the empty sequence and otherwise itis 1 plus the maximum of the depths of the traces in its visual.

In case we would allow traces to be infinite, the above equivalence would not holdin general, but would represent some kind of ‘inductiveness’ property of traces.

9.8.2 Genuineness

A protocol statement s is genuine if for each protocol b, the visual of each trace ins.b consists only of traces contained by b:

∀〈b, x, v || (x, v)T

ǫ s.b || v <− b〉

For sets A and B that are equal to I, the set of genuine statements P(TA) <−−−|g PBis defined by

s ∈ P(TA) <−−−|g PB

≡ {• A = I ∧ B = I}s ∈ P(TA) <−−−| PB ∧ s is genuine

Informally stated, a protocol statement is genuine if ‘the only things that are shownare real calls’. This is formalised by the fact that for each context, the traces thatare ‘shown’ by the protocol statement, must be traces from the context.

The operators ∩, ∪, ©�, ◦p, Ip, (⊲pi) and dark are genuineness preserving:

s0∩s1 ∈ P(TI) <−−−|g PI ⇐ s0, s1 ∈ P(TI) <−−−|g PIs0∪s1 ∈ P(TI) <−−−|g PI ⇐ s0, s1 ∈ P(TI) <−−−|g PI©� ∈ P(TI) <−−−|g PIs0 ◦ps1 ∈ P(TI) <−−−|g PI ⇐ s0, s1 ∈ P(TI) <−−−|g PI

Ip ∈ P(TI) <−−−|g PIs⊲pi ∈ P(TI) <−−−|g PI ⇐ s ∈ P(TI) <−−−|g PIdark ∈ P(TI) <−−−|g PI

We leave it to the reader to verify these facts.

The operator show is not genuineness preserving. If it were, this would contradictthe fact that ‘the only things that may be shown are real calls’. Also the operatorcall is not genuineness preserving. This fact is discussed in section 9.9.4. Thecombination of these two operators, show.call, is genuineness preserving however:

show.call ∈ P(TI) <−−−|g PI

The operators Π, (⊳pi) and spec.C are also not genuineness preserving. For theseoperators, we introduce special versions that do preserve genuineness.

224

The universal genuine statement Πg ∈ P(TI) <−−−| PI is defined by

(x, v)T

ǫ Πg.b ≡ v <− b

The genuine-statement–pack ⊳g ∈ (((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−| PI) <−−−| ((I )∧∨

∧

∨

∧

∨( I)<−−−|g PI)×I is defined by

(Y :v:Z)T

ǫ (s⊳gi).b

≡

∃〈y, z, j || Y = [(y, j)] ∧ Z = [(z, j)]|| j = i ⇒ (y:v:z)

Tǫ s.b ∧

j 6= i ⇒ v <− b〉

The genuine-statement–spec specg ∈ (P(TI) <−−−| PI) <−−−| PI is defined by

(x, v)T

ǫ (specg.C).b ≡ x ǫ C ∧ v <− b

These last two operators can be equivalently defined in terms of their non-genuinecounterparts as follows:

s⊳gi = Πg ∩ s⊳pi

specg.C = Πg ∩ spec.C

The proofs are again left to the reader. Notice that the s in the first equation rangesover genuine statements.

The universal genuine statement is the largest genuine statement and all smallerstatements are also genuine:

s ∈ P(TI) <−−−|g PI ≡ s ⊆ Πg

A direct consequence is that the operators Πg, (⊳gi) and specg.C are genuinenesspreserving:

Πg ∈ P(TI) <−−−|g PIs⊳gi ∈ P(TI) <−−−|g PI ⇐ s ∈ P(TI) <−−−|g PIspecg.C ∈ P(TI) <−−−|g PI

The operator specg ‘magically’ ensures that a constructed statement is genuine.Ordinary programming languages do not have such a ‘magical’ operator and sucha statement must then be implemented by means of a call or some statement-darkstatement.

225

9.8.3 Continuity

Monotonicity is not always a strong enough requirement for statements to have allproperties that we desire. Strengthening monotonicity to continuity often helps.The operators ∩, ∪, ©�, Π, ◦p, Ip, (⊲pi), (⊳pi), dark, show, spec.C, call, const.C, Πg,

(⊳gi) and specg.C are all continuity preserving:

s0∩s1 ∈ PI <−−−|c PI ⇐ s0, s1 ∈ PI <−−−|c PIs0∪s1 ∈ PI <−−−|c PI ⇐ s0, s1 ∈ PI <−−−|c PI©� ∈ PI <−−−|c PI

Π ∈ PI <−−−|c PIs0 ◦ps1 ∈ PI <−−−|c PI ⇐ s0, s1 ∈ PI <−−−|c PI

Ip ∈ PI <−−−|c PIs⊲pi ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIs⊳pi ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIdark ∈ PI <−−−|c PIshow.s ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIspec.C ∈ PI <−−−|c PIcall ∈ PI <−−−|c PIconst.C ∈ PI <−−−|c PI

Πg ∈ PI <−−−|c PIs⊳gi ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIspecg.C ∈ PI <−−−|c PI

proof

We first prove it for const.C, for an arbitrary collection C:

const.C is continuous

≡ {definition of continuity}∀〈W |

| W is a chain ∧ W 6= ©�|| (const.C).(

⋃

W ) =⋃{(const.C).X | X ∈ W | X}〉

≡ {definition of const}∀〈W |

| W is a chain ∧ W 6= ©� || C =⋃{C | X ∈ W | X}〉

≡ {W 6= ©� ⇒ ⋃{C | X ∈ W | X} = C}true

We now also have tackled the cases ©�, Π, Ip, dark and spec.C because

©� = const.©�Π = const.Π

Ip = const.Ipdark = const.dark

spec.C = const.(spec.C)

226

For ∩, we assume that W is a non-empty chain and calculate:

x ǫ (s0∩s1).(⋃

W )

≡ {definition of ∩}x ǫ s0.(

⋃

W ) ∩ s1.(⋃

W )

≡ {definition of ∩}x ǫ s0.(

⋃

W ) ∧ x ǫ s1.(⋃

W )

≡ {• s0, s1 are continuous}x ǫ

⋃{s0.b0 | b0 ∈ W | b0} ∧ x ǫ⋃{s1.b1 | b1 ∈ W | b1}

≡ {definition of⋃

}∃〈b0

|| b0 ∈ W |

| x ǫ s0.b0〉 ∧ ∃〈b1|| b1 ∈ W |

| x ǫ s1.b1〉≡ {(⇐): take b0 = b1 = b

(⇒): take b = b0∪b1, this is an element of W because W is a chain,• s0, s1 are monotonic}

∃〈b || b ∈ W || x ǫ s0.b ∧ x ǫ s1.b〉

≡ {definition of ∩}∃〈b || b ∈ W |

| x ǫ (s0.b ∩ s1.b)〉≡ {definition of

⋃

}x ǫ

⋃{s0.b ∩ s1.b | b ∈ W | b}≡ {definition of ∩}

x ǫ⋃{(s0∩s1).b | b ∈ W | b}

The proofs for the other non-g protocol-statement operators are left to the reader(remark: the proof for (⊳pi) needs the non-emptiness of W as much as the proof for

const.C). For Πg we prove for a non-empty chain W :

(x, v)T

ǫ Πg.(⋃

W )

≡ {definition of Πg}v <−

⋃

W

≡ {definition of <−}∀〈t || t in v || t ǫ

⋃

W 〉≡ {point-wise definition of

⋃

}∀〈t || t in v || ∃〈P || P ∈ W |

| t ǫ P 〉〉≡ {(⇐): trivial, (⇒): see below}∃〈P || P ∈ W |

| ∀〈t || t in v || t ǫ P 〉〉≡ {definition of <−}∃〈P || P ∈ W |

| v <− P 〉≡ {definition of Πg}

∃〈P || P ∈ W || (x, v)

Tǫ Πg.P 〉

≡ {point-wise definition of⋃

}

(x, v)T

ǫ⋃

{Πg.P | P ∈ W | P}

227

Now for the (⇒) of the fourth step:

∀〈t || t in v || ∃〈P || P ∈ W || t ǫ P 〉〉

≡ {axiom of choice}∃〈f || f ∈ I <−−−| {t | t in v | t} || ∀〈t || t in v || f.t ∈ W ∧ t ǫ f.t〉〉

⇒ {Take P =⋃{f.t | t in v | t}. The set {f.t | t in v | t} is finite because sequences are

finite by definition. We thus have P ∈ W because the union of the elements of afinite subset of a chain is an element of that chain.}

∃〈P || P ∈ W || ∀〈t || t in v || t ǫ P 〉〉

The continuity preservingness of (⊳gi) and specg.C follows directly from their defi-nition in terms of their non-genuine counterparts.

The canonical behaviour of a continuous genuine statement is introspective:

µs is introspective ⇐ s is a continuous genuine statement

proof

Assume that s is a continuous genuine statement.

µs is introspective

≡ {definition of introspectivity}∀〈x, v || (x, v)

Tǫ µs || v <− µs〉

≡ {definition of <−}∀〈x, v || (x, v)

Tǫ µs || ∀〈t || t in v || t ǫ µs〉〉

≡ {s is continuous, so µs =⋃{sn.©� |n∈N | n} (see section 3.6)}

∀〈x, v || (x, v)T

ǫ⋃{sn.©� |n∈N | n} || ∀〈t || t in v || t ǫ

⋃{sm.©� |m∈N | m}〉〉≡ {definition of

⋃

}∀〈x, v || ∃〈n ||n∈N || (x, v)

Tǫ sn.©�〉 || ∀〈t || t in v || ∃〈m ||m∈N || t ǫ sm.©�〉〉〉

≡ {predicate calculus}∀〈n ||n∈N || ∀〈x, v || (x, v)

Tǫ sn.©� || ∀〈t || t in v || ∃〈m ||m∈N || t ǫ sm.©�〉〉〉〉

⇐ {take m = n}∀〈n ||n∈N || ∀〈x, v || (x, v)

Tǫ sn.©� || ∀〈t || t in v || t ǫ sn.©�〉〉〉

≡ {definition of <−}∀〈n ||n∈N || ∀〈x, v || (x, v)

Tǫ sn.©� || v <− sn.©�〉〉

≡ {definition of introspectivity}∀〈n ||n∈N || sn.©� is introspective〉

We prove this last formula by mathematical induction. The basis n = 0 holdsbecause ©� is introspective. For the step we calculate:

228

sn+1.©�

= {Rn+1 = Rn ◦ R}sn.(s.©�)

= {©� is unit of ∪}sn.(©� ∪ s.©�)

= {left to the reader (hint: prove by induction that sn is continuous)}sn.©� ∪ sn.(s.©�)

= {Rn ◦ R = R ◦ Rn}sn.©� ∪ s.(sn.©�)

The induction hypothesis gives us that sn.©� is introspective. We now complete theproof by showing that for each introspective protocol b, b ∪ s.b is also introspective:

∀〈b || b ∈ PTiI|| b ∪ s.b ∈ PTiI〉

≡ {definition of introspectivity}∀〈b || b ∈ PTiI

|| ∀〈x, v || (x, v)

Tǫ (b ∪ s.b) || v <− (b ∪ s.b)〉〉

⇐ {monotonicity of <− in its right argument}∀〈b || b ∈ PTiI

|| ∀〈x, v || (x, v)

Tǫ (b ∪ s.b) || v <− b〉〉

≡ {point-wise definition of ∪}∀〈b || b ∈ PTiI

|| ∀〈x, v || (x, v)

Tǫ b ∨ (x, v)

Tǫ s.b) || v <− b〉〉

≡ {domain split}∀〈b || b ∈ PTiI

|| ∀〈x, v || (x, v)

Tǫ b || v <− b〉 ∧ ∀〈x, v || (x, v)

Tǫ s.b || v <− b〉〉

≡ {definition of introspectivity}∀〈b || b ∈ PTiI

|| ∀〈x, v || (x, v)

Tǫ s.b || v <− b〉〉

⇐ {predicate calculus}∀〈b, x, v || (x, v)

Tǫ s.b || v <− b〉

≡ {s is genuine}true

9.9 Refinement of protocol statements

In this section we discuss refinement of protocol statements.

9.9.1 Simple refinement rules

Some simple protocol-statement–refinement rules are:

229

s0′ ∩s1

′ ⊆ s0∩s1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

s0′ ∪s1

′ ⊆ s0∪s1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

©� ⊆ ©� ≡ true

Π ⊆ Π ≡ true

s0′ ◦ps1

′ ⊆ s0 ◦ps1 ⇐ s0′ ⊆ s0 ∧ s1

′ ⊆ s1

Ip ⊆ Ip ≡ true

s′⊲pi ⊆ s⊲pi ⇐ s′ ⊆ s

s′⊳pi ⊆ s⊳pi ≡ s′ ⊆ s

dark ⊆ dark ≡ true

show.s′ ⊆ show.s ≡ s′ ⊆ s

spec.C′ ⊆ spec.C ≡ C′ ⊆ C

call ⊆ call ≡ true

Πg ⊆ Πg ≡ true

s′⊳gi ⊆ s⊳gi ≡ s′ ⊆ s

specg.C′ ⊆ specg.C ≡ C′ ⊆ C

The proofs of these rules are straightforward.

9.9.2 A ‘strange’ refinement revisited

In section 8.4.5 we observed that the use of relations as model for behaviour has asa result that program p, defined by

p = m⊳m ∩ n⊳n

m = const.[[C| ≥ 3]]


is behaviourally refined by p′′, defined by

p′′ = m′′⊳m ∩ n′′⊳n

m′′ = const.[[C| = 4]]

n′′ = const.[[C| = 3]]

We now show that if we restrict to continuous genuine programs and make the callto m visible, such a ‘strange’ refinement is not possible anymore. Suppose programp3 is defined by

p3 = m3⊳gm ∩ n3⊳gn

m3 = dark ∩ specg.[[C| ≥ 3]]

n3 = (dark ∩ specg.[[C| ≥ C| ]]) ◦p (show.call)⊲pm

and p4, defined by

p4 = m4⊳gm ∩ n4⊳gn

m4 = dark ∩ specg.[[C| = 4]]

230

for some statement n4, is a continuous genuine program that behaviourally refinesp3. We now prove that the output of procedure n of p4 is at least 4:

(µp4)⊲pn ⊆ spec.[[C| ≥ 4]]

proof

We first investigate what can be derived from the fact that p4 is a behaviouralrefinement of p3:

(y:v:z)T

ǫ (µp4)⊲pn

⇒ {p4

µ

⊆ p3}(y:v:z)

Tǫ (µp3)⊲pn

≡ {left to the reader (see also section 9.7.3)}v <− µp3 ∧ ∃〈x || v = 〈([(x, m)]:〈〉

V:[(z, m)])

T〉V

|| y (−≥−) x ∧ x (−≥−) 3〉

⇒ {we remove the things that we do not need}∃〈x || v = 〈([(x, m)]:〈〉

V:[(z, m)])

T〉V

|| y (−≥−) x〉

We now calculate:

(y:v:z)T

ǫ (µp4)⊲pn

≡ {definition of ⊲p}([(y, n)]:v:[(z, n)])

Tǫ µp4

⇒ {the property we just derived, gives us the shape of v}∃〈x |||| y (−≥−) x ∧ ([(y, n)]:〈([(x, m)]:〈〉

V:[(z, m)])

T〉V:[(z, n)])

Tǫ µp4〉

⇒ {µp4 is introspective because p4 is continuous and genuine (section 9.8.3)}∃〈x |||| y (−≥−) x ∧ ([(x, m)]:〈〉

V:[(z, m)])

Tǫ µp4〉

≡ {left to the reader}∃〈x |||| y (−≥−) x ∧ x = 4〉

≡ {1-point rule}y (−≥−) 4

9.9.3 Components

In section 8.5.3 we saw that behavioural intersection of program qc, defined by


c′ = const.[[C| = 3]]

d = const.[[C| ≥ 4]]

with program qd , defined by

231


c = const.[[C| ≥ 3]]

d′ = const.[[C| = C|+1]] ◦ call⊲c

has as behaviour:

[[C| = 3]]⊳c ∩ [[C| ≥ 4]]⊳d

rather than what we would ‘expect’:

[[C| = 3]]⊳c ∩ [[C| = 4]]⊳d

The reason is that “call⊲c” does not mean that a call to procedure c is performed,but that the given specification of c is somehow realised. In other words, the callto c is invisible. We now show that if we make the call to c visible, we get thebehaviour we ‘expect’.

The program qc3 is defined by

qc3 = c3′⊳gc ∩ d3⊳gd

c3′ = dark ∩ specg.[[C| = 3]]

d3 = specg.[[C| ≥ 4]]

and the program qd3 is defined by

qd3 = c3⊳gc ∩ d3′⊳gd

c3 = dark ∩ specg.[[C| ≥ 3]]

d3′ = (dark ∩ specg.[[C| = C|+1]]) ◦p (show.call)⊲pc

We now prove for the behaviour of the behavioural intersection of qc3 and qd3 thatthe output of procedure d is equal to 4:

µ(qc3

µ

∩qd3) ⊲p d ⊆ spec.[[C| = 4]]

proof

232

(y:v:z)T

ǫ µ(qc3

µ

∩qd3) ⊲p d

≡ {definition of ⊲p}

([(y, d)]:v:[(z, d)])T

ǫ µ(qc3

µ

∩qd3)

≡ {s0

µ

∩s1 = const.(µs0 ∩ µs1)}([(y, d)]:v:[(z, d)])

Tǫ µ(const.(µqc3 ∩ µqd3))

≡ {µ(const.c) = c}([(y, d)]:v:[(z, d)])

Tǫ µqc3 ∩ µqd3

≡ {definition of ∩}([(y, d)]:v:[(z, d)])

Tǫ µqc3 ∧

([(y, d)]:v:[(z, d)])T

ǫ µqd3

≡ {Trivial though long calculations, left to the reader}y ≥ 4 ∧ v <− µqc3 ∧∃〈x |||| y = x+1 ∧ x ≥ 3 ∧ v = 〈([(x, c)]:〈〉

V:[(z, c)])

T〉V〉

≡ {calculus}∃〈x |||| y ≥ 4 ∧ y = x+1 ∧ x ≥ 3 ∧ v <− µqc3

∧ v = 〈([(x, c)]:〈〉V:[(z, c)])

T〉V〉

≡ {([(x, c)]:〈〉V:[(z, c)])

Tǫ µqc3 ≡ x = 3}

y = 4 ∧ v = 〈([(3, c)]:〈〉V:[(z, c)])

T〉V

The last step shows how the visual enables us to use the fact that procedure c

outputs 3. This shows how our model incorporates an implicit form of dynamicbinding (see also section 2.5.7).

9.9.4 Invisible calls

In section 9.8.2 we remarked that call is not genuineness preserving. A way to makecall genuineness preserving, is to change the definition of genuineness by addingb ∈ PTiI to the domain of the quantification, changing it into:

∀〈b, x, v || b ∈ PTiI ∧ (x, v)T

ǫ s.b || v <− b〉

To guarantee that some basic algebraic properties of the formalism are preserved,the definition of Πg then needs to be changed into

(x, v)T

ǫ Πg.b ≡ (b ∈ PTiI ⇒ v <− b)

This new Πg is not continuous however.

Invisible calls thus seem not to fit well into our framework. There is another solutionto incorporate invisible calls however which involves the introduction of an opera-tor that explicitly hides visible information. The hide hide ∈ P(TI) <−−−| P(TI) isdefined by

233

(x, v)T

ǫ hide.P ≡ v = 〈〉V∧ ∃〈v′ |||| (x, v′)

Tǫ P 〉

and the statement-hide hide ∈ (P(TI) <−−−| I) <−−−| (P(TI) <−−−| I) by

(hide.s).b = hide.(s.b)

The statement-hide creates a genuine statement from any statement:

hide.s ∈ P(TI) <−−−|g PI ⇐ s ∈ P(TI) <−−−| PI

This fact holds because (x, v)T

ǫ (hide.s).b implies that the visual v is empty. Theproof of statement-hide being continuity preserving:

hide.s ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−| PI

is also straightforward.

A result of all this is that invisible calls can be done with a hide.call. Notice thoughthat the visible calls of a procedure that is called with a hide.call, become invisiblewithin that call. We leave further investigation of invisible calls for future research.

9.10 Conclusions

In this chapter we showed how visible calls can be modeled. Visible calls enable oneto specify that a certain procedure should be called. This gain in expressivity isessential for some design patterns. Suppose in the plug-pattern example of section2.2, the call of insertInto to fillWith would be invisible. If someone wouldhave implemented insertInto according to the plug-pattern specification and weimplement fillWith according to the observer-pattern specification, there is noway of knowing for sure that calling insertInto of an observer, results in callingour fillWith. Making the call visible does provide this assurance.

234

Chapter 10

Variables

In this chapter we show how we model variables. Special attention is paid to theparticular kind of variable-concepts of object-oriented specification languages likeISpec.

10.1 Maps

We assume the existence of an external type of maps. Maps are isomorphicto total functions. The set of all maps is denoted by I ≺−−− I. The selection

◮ ∈ I <−−−| (I ≺−−− I)×I is the equivalent of the application. If f ◮z = y holds, we saythat f maps z to y. Equality between maps g and h is defined by

g = h ≡ ∀〈x |||| g◮x = h◮x〉

The operator ≺−−−−− ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| (I )−−−( I)×(I )−−−( I) is defined by

g (−R ≺−−−−− P −) h ≡ ∀〈y, z |||| g◮y (−R−) h◮z ⇐ y (−P −) z〉

For sets A and B, A ≺−−−−− B is not a set in general. For reasons mentioned in sec-tion 4.2.7, a set-forced version ≺−−− ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| (I )−−−( I)×(I )−−−( I) isintroduced:

R ≺−−− P = (R ≺−−−−− P ) ∩ I

The set A ≺−−− B consists of all maps that map elements of type B to elements oftype A.

The reason why we introduce maps and not simply use total functions, is that thefact I ≺−−− I = I often allows for cleaner formulas.

235

10.2 Variables

We model variables by a map from variable names to variable values. The factthat we use maps, means that each variable name is mapped to exactly one value. Ifwe want to model existence (creation and deletion) of variables, we can model thenon-existence of a variable by a special null value or switch to (partial) functions,similar to what we did in chapter 6. We leave the incorporation of variable existencein our framework for future research however.

10.2.1 Variable expressions

The selection enables the retrieval of the value of a variable with a specific name.The expression that represents the value of the variable (with name) a is (C| ◮ a). Inthis particular case where a context is a map from variable names to variable values,we normally use the term “state” instead of “context”. In case of connectionalexpressions (see section 6.8), we talk about “new state” instead of “output of thecontext” and about “old state” instead of “input of the context”. The connectionalexpression that represents the new value of variable a (the value of variable a in

the new state) is (C| ◮ a) and the connectional expression that represents the old

value of variable a (the value of variable a in the old state) is (C| ◮ a).

The relation that tells that variable a is increased at least by the old value of variableb, can for example be written as

[[C| ◮a ≥ C| ◮a + C| ◮b]]

10.2.2 Modify

The relation [[C| ◮a ≥ C| ◮a + C| ◮b]] tells something about the new value of variable a,but nothing about the new values of other variables. This means that these variablesmay change arbitrarily. For expressing the fact that all variables outside a certainset remain equal, we define the modify modify ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| ℘I by:

g (−modify.A−) h ≡ ∀〈x || x /∈ A || g◮x = h◮x〉

The relation

[[C| ◮a ≥ C| ◮a + C| ◮b]] ∩ modify.{a}

expresses that variable a is increased at least by the value of variable b and onlyvariable a possibly changes.

Notice that if the value of a variable does not change (like the value of b in theabove example), we talk about “the” value of that variable instead of “the old” or“the new” value. If it does not matter whether or not we use a ` or a ´ in a relation

236

comprehension, we prefer . This corresponds to the fact that in ISpec, “x” is usedfor “the new” or “the” value of variable x and “x′” for “the old” value of variablex.

The proofs of the following theorems are left to the reader:

modify.A0 ∩ modify.A1 = modify.(A0∩A1)modify.A0 ◦ modify.A1 = modify.(A0∪A1)

10.2.3 Declared variables

By a “modify.A” it is often not meant that each variable whose name is not anelement of A, remains equal. Usually there exists some set of variable names Dthat represents the declared variables: the variables that the specification ‘talksabout’. A “modify.A” is then expected to only talk about these declared variables.Variables that are not declared, can be added in a refinement and may change arbi-trarily. In other words, a “modify.A” then actually is a modifyD.A, where for a set(of declared-variable names) D, modifyD ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| ℘I is definedby

modifyD.A = modify.(IrD ∪ A)

The relation

[[C| ◮a ≥ C| ◮a + C| ◮b]] ∩ modifyD.{a}

where D = {a, b, c}, is for example refined by

[[C| ◮a > C| ◮a + C| ◮b ∧ C| ◮d = C| ◮a]] ∩ modifyD′.{a, d}

where D′ = {a, b, c, d, e}.

10.2.4 Pointers

A pointer is a variable whose value is the name of a variable. The relation

[[C| ◮(C| ◮p) ≥ C| ◮(C| ◮p) + C| ◮(C| ◮q)]]

expresses for example that the variable whose name is the old value of variable p

(that pointer p points to in the old state), is increased at least by the old value ofthe variable that q points to in the old state.

Like before, we often want all other variables to remain equal. For this purpose weintroduce a generalisation of modify. To indicate the possibly modified variables,we use total functions that are evaluated in the old state. The pointer-modify

237

pmodify ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| ℘(I <−−−| (I ≺−−− I)) is defined by

g (−pmodify.K −) h ≡ g (−modify.{k.h | k ∈ K | k}−) h

Instead of defining the pmodify in terms of the modify, the modify could also bedefined in terms of the pmodify:

modify.A = pmodify.{a | a ∈ A | a}

The relation

[[C| ◮(C| ◮p) ≥ C| ◮(C| ◮p) + C| ◮(C| ◮q)]] ∩ pmodify.{C| ◮ p}

expresses for states where p and q point to variables (whose value is) of type R, thatthe variable a that p points to, is increased at least by the old value of the variablethat q points to and a is the only possibly modified variable. Notice that if p andq point to the same variable, also the value of the variable that q points to possiblychanges.

In case we ‘execute’ the relation

[[C| ◮(C| ◮p) = C| ◮(C| ◮q)]] ∩ pmodify.{C| ◮ p}

in a state where variable p points to itself then, in the new state, p points to thevariable that was pointed at by the variable that q was pointing to in the old state.In case p would point to q in the old state, then q would point to that variable inthe new state. In our interpretation of the relation of the previous example, theassumption that p and q point to variables of type R and the (not explicitly stated)fact that R and II are disjoint, ensure that p cannot possibly point to p or q.

The fact that pointers give rise to such intricate behaviour is reflected by the factthat pmodify.K0 ◦ pmodify.K1 is not equal to pmodify.(K0∪K1) in general. Wehave for example

pmodify.{C| ◮ q} ◦ pmodify.{C| ◮ p} 6= pmodify.{(C| ◮ q), (C| ◮ p)}

If we ‘execute’ the right formula, only the variables where p and q point to in theold state, can change. If we ‘execute’ the left formula however, then every variablecan change if p points to q in the old state.

The above inequality can be turned into an equality if we restrict to old states wherep does not point to q:

g (−pmodify.{C| ◮ q} ◦ pmodify.{C| ◮ p}−) h

≡ {• h◮p 6= q}g (−pmodify.{(C| ◮ q), (C| ◮ p)}−) h

238

This theorem is a trivial consequence of the following theorem, whose proof we leaveto the reader:

g (−pmodify.{k} ◦ pmodify.{l}−) h

≡ {• ∀〈f || f (−pmodify.{l}−) h || k.f = k.h〉}g (−pmodify.{k, l}−) h

The condition in this theorem expresses that the value of k is not affected by themodification of a variable whose name is the value of l in the old state.

We also define a pointer-modify that incorporates declared variables. For a set (ofdeclared-variable names) D, pmodifyD ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| ℘(I <−−−| (I ≺−−− I))is defined by

pmodifyD.K = pmodify.({x | x /∈ D | x} ∪ K)

In other words, all variables whose name is an element of D and not the value ofany k ∈ K in the old state, remain equal.

10.2.5 Assignment

The common way to change the values of variables, is by means of assignments. Theassignment =: ∈ ((I ≺−−− I) )−−−( (I ≺−−− I)) <−−−| (I )−−−( (I ≺−−− I))×(I <−−−| (I ≺−−− I)) is de-fined by

g (−R=:k −) h ≡ g◮(k.h) (−R−) h ∧ g (−pmodify.{k}−) h

The relation R=:k expresses that the variable whose name is the value of k in theold state, is (non-deterministically) assigned a value of relation R in the old state.All other variables remain equal.

We use the symbol “=:” instead of “:=” as a reminder of the fact that the new stateis placed on the left and the old state on the right.

The assignment

(C| ◮ a) + (C| ◮ b) =: a

expresses for example that variable a is increased by the value of variable b and a

is the only possibly modified variable.

An example of a non-deterministic assignment is

[[C| ≥ C| ◮a + C| ◮b]] =: a

expressing that variable a is at least increased by the value of variable b and a is

239

the only possibly modified variable.

An example of a pointer-assignment is

(C| ◮ (C| ◮ p)) + (C| ◮ (C| ◮ q)) =: (C| ◮ p)

which, in case p and q point to variables of type R, expresses that the variable athat p points to, is increased by the old value of the variable that q points to anda is the only possibly modified variable.

For specifications we advise the combination of a relation comprehension and amodify (or pmodify if necessary) to express changes to variables. This is in linewith section 7.4 where we show the advantages of splitting a specification into anoperational and a declarative part. The operational part (the modify) tells whichvariables possibly change and the declarative part (the relation comprehension) tellshow they change.

10.3 Objects

In this section we discuss the particular kind of states that are found in object-oriented programming.

10.3.1 Global states

In object-oriented programming, a program has access to a global state that ispartitioned into fields where a field is identified by an object name and an at-tribute name. Formally, a global state is a map from field names to field valueswhere the field name with object name o and attribute name a is denoted by (o, a)

F.

We talk about “attribute a of object o” to indicate the field with name (o, a)F.

We assume the existence of an external type of field names. The set of all (o, a)F

with o ∈ O and a ∈ A is denoted by F(O, A):

(o, a)F∈ F(O, A) ≡ o ∈ O ∧ a ∈ A

We denote the set of all object names by O and the set of all attribute names byA. We define both equal to I to allow for cleaner formulas:

O = IA = I

The set G of all global states is now defined by

G = I ≺−−− F(O, A)

The formula

240

g◮(o, a)F

represents the value of attribute a of object o (field (o, a)F) in global state g.

10.3.2 Field selection

The field selection −> ∈ (I <−−−| G) <−−−| (O <−−−| G)×A is defined by

(e−>a).g = g◮(e.g, a)F

The expression

o −> a

represents the value of attribute a of object o. Assuming that attribute a of objecto is pointing to some object (has an object name as value), the expression

(o −> a) −> b

represents the value of attribute b of that object.

It is uncommon in object-oriented languages to indicate an object directly by itsname (o in the example). This issue is dealt with in section 10.4 where we introducethe notion of a ‘this’-object name.

For the evaluation of the new and old value of a field, we introduce the functions−> , −> ∈ (I <−−−| G⋆G) <−−−| (O <−−−| G⋆G)×A, defined by

(e−>a).(g, h) = (K.(e.(g, h)) −> a).g(e−>a).(g, h) = (K.(e.(g, h)) −> a).h

Notice the ‘trick’ of using a constant-valued function K.(e.(g, h)) as a single-state

expression that actually depends on two states. This enables us to define −> and

−> in terms of −>. We use this ‘trick’ at several places.

The relation

[[o−>a ≥ o−>a + o−>b]]

expresses that attribute a of object o is increased at least by the old value ofattribute b of object o.

241

10.3.3 Field-modify

The field-modify fmodify ∈ (G )−−−( G) <−−−| ℘((O <−−−| G)×A) can be used to expressmodification of fields:

g (−fmodify.X −) h ≡ g (−modify.{(k.h, a)F| 〈k, a〉 ∈ X | k, a}−) h

The relation

[[o−>a ≥ o−>a + o−>b]] ∩ fmodify.{〈o, a〉}

expresses for example that attribute a of object o is increased at least by the valueof attribute b of object o and attribute a of object o is the only possibly modifiedfield.

Similar to what we observed for pmodify, fmodify.X0 ◦ fmodify.X1 is not equal tofmodify.(X0∪X1) in general. We do have

g (−fmodify.{〈k, a〉} ◦ fmodify.{〈l, b〉}−) h

≡ {• ∀〈f || f (−fmodify.{〈l, b〉}−) h || k.f = k.h〉}g (−fmodify.{〈k, a〉, 〈l, b〉}−) h

The fact that attribute names in the field-selection notation are constants, makesit possible to syntactically (by which we mean “regardless of the states g and h”)ensure that a modification cannot possibly affect the value of a certain expression.The following theorem holds for example:

fmodify.{〈(o −> a), b〉} ◦ fmodify.{〈k, c〉}= {• a 6= c}

fmodify.{〈(o −> a), b〉, 〈k, c〉}

The fact that a and c are different attribute names, means that modifying a fieldwith attribute name c cannot possibly affect the value of expression (o −> a).

Field modification can also be combined with the notion of declared variables. How-ever, instead of field names we use attribute names to indicate the declared variablesand we talk about “declared attributes”. For a set D of (declared) attributenames, fmodifyD ∈ (G )−−−( G) <−−−| ℘((O <−−−| G)×A) is defined by

fmodifyD.X

=

fmodify.({〈o, a〉 | a /∈ D | o, a} ∪ X)

The relation

[[o−>a ≥ o−>a + o−>b]] ∩ fmodify{a, b, c}.{〈o, a〉}

242

expresses for example that attribute a of object o is increased at least by the valueof attribute b of object o. From the attributes a, b and c of any object, attribute a

of object o is the only possibly modified field. For every object, all attributes otherthan a, b or c may change arbitrarily.

10.4 Carriers

Fields are not the only variables that occur in object-oriented programming. Wealso encounter things like parameters, a result and a special variable that isusually called “this” or “self”.

In this section we introduce the notion of a carrier. A carrier is a variable thatrepresents some piece of information that a specification can talk about, like forexample the global state or the parameters that are passed to a method. Carriersare described by a carrier record which is a map from carrier names to carriervalues. The set of all carrier records is denoted by C. In the following subsectionswe introduce some common carriers.

10.4.1 Global state

The carrier named globalState holds a global state:

C ⊆ G ≺−−− {globalState}

If we talk about the global state of a carrier record, we mean the value of thisparticular carrier. The function globalState ∈ G <−−−| C returns the global state of acarrier record:

globalState.c = c◮globalState

10.4.2 This

In object-oriented languages, the keyword “this” (or sometimes “self”) is used toidentify the ‘currently active object’. The carrier that holds the ‘this’-object name,is named this:

C ⊆ O ≺−−− {this}

The function this ∈ O <−−−| C returns the ‘this’-object name of a carrier record:

this.c = c◮this

243

10.4.3 Field selection

In order to express field selection in case states are carrier records, we introduce thecarrierised field selection −>

C∈ (I <−−−| C) <−−−| (O <−−−| C)×A, defined by

(e −>C

a).c = (K.(e.c) −> a).(globalState.c)

An expression that represents the value of attribute b of the object that attributea of the ‘this’ object is pointing to, is

(this −>Ca) −>

Cb

For the evaluation of the new and old value of an attribute, we introduce thefunctions −>

C, −>

C∈ (I <−−−| C⋆C) <−−−| (O <−−−| C⋆C)×A, defined by

(e −>C

a).(c0, c1) = (K.(e.(c0, c1)) −> a).(globalState.c0, globalState.c1)(e −>

Ca).(c0, c1) = (K.(e.(c0, c1)) −> a).(globalState.c0, globalState.c1)

The relation

[[ `this−>Ca ≥ `this−>

Ca + `this−>

Cb]] ∩ modify.{globalState}

expresses for example that attribute a of the ‘this’ object is increased at least bythe old value of attribute b of the ‘this’ object. Furthermore, the only carrier thatis possibly modified is globalState.

10.4.4 Field-modify

Also the field-modify has to be adapted in case states are carrier records. Thecarrierised field-modify fmodify

C∈ (C )−−−( C) <−−−| ℘((O <−−−| C)×A) is defined by

c0 (−fmodifyC.X −) c1

≡

globalState.c0 (−fmodify.{〈K.(k.c1), a〉 | 〈k, a〉 ∈ X | k, a}−) globalState.c1

The only fields of the global state that are possibly modified, are the ones for which〈k, a〉 ∈ X, where a is the attribute name of the field and the value of k in the oldstate is the object name of the field.

The relation

[[ `this−>Ca ≥ `this−>

Ca + `this−>

Cb]] ∩ fmodify

C.{〈this, a〉}

∩ modify.{globalState}

expresses for example that attribute a of the ‘this’ object is increased at least bythe value of attribute b of the ‘this’ object and only attribute a of the ‘this’ object

244

is possibly modified.

The function fmodifyCD ∈ (C )−−−( C) <−−−| ℘((O <−−−| C)×A), where D is a set of at-

tribute names, combines fmodifyC

with the notion of declared attributes:

fmodifyCD.X

=

fmodifyC.({〈o, a〉 | a /∈ D | o, a} ∪ X)

10.4.5 Parameters

Parameters are held by the carrier named parameters. This carrier holds a pa-rameter record which is a map from parameter names to parameter values.The set of all parameter names is denoted by P and the set of all parameter recordsis I ≺−−− P:

C ⊆ (I ≺−−− P) ≺−−− {parameters}

The function parameters ∈ (I ≺−−− P) <−−−| C returns the parameter record of a carrierrecord:

parameters.c = c◮parameters

The function par ∈ (I <−−−| C) <−−−| P returns the value of a certain parameter of acarrier record:

ppar = parameters ◮ p

10.4.6 Result

The carrier for the result is named result:

C ⊆ I ≺−−− {result}

The function result ∈ I <−−−| C returns the result of a carrier record:

result.c = c◮result

10.4.7 Example

The relation

[[ `result ≥ ( `this −>Ca) + `bpar ]] ∩ modify.{result}

245

expresses that the new value of the result is at least the value of attribute a of the‘this’ object plus the value of parameter b. The only possibly modified carrier isresult.

10.5 Conclusions

In this chapter we showed how we model several variable-concepts that play a rolein object-oriented specification languages like ISpec. We did not pay too muchattention to the construction of proof rules, except for a few that illustrate somecommon ‘pointer issues’.

246

Chapter 11

Suites

In this chapter we show how the thus far developed theory corresponds to ISpec bydefining a formal language for a subset of ISpec.

11.1 Some more operators

We first introduce a few more operators for the semantic models that we introducedin chapters 8 and 9.

11.1.1 Over and under

The statement-over and statement-under / , \ ∈ ((I )−−−( I) <−−−| I) <−−−| ((I )−−−( I)

<−−−| I)×((I )−−−( I) <−−−| I) are defined by

(s/s1).b = s.b / s1.b

(s0\s).b = s0.b \ s.b

The protocol-over and protocol-under /p , \p ∈ (I )∧∨

∧

∨

∧

∨( I) <−−−| (I )∧∨

∧

∨

∧

∨( I)×(I )∧∨

∧

∨

∧

∨( I)are defined by

(y:v0:x)T

ǫ P/pP 1

≡

∀〈v, v1, z|| v = v0++v1

|| (y:v:z)

Tǫ P ⇐ (x:v1:z)

Tǫ P 1〉

(x:v1:z)T

ǫ P 0\pP≡∀〈y, v0, v

|| v = v0++v1

|| (y:v0:x)

Tǫ P 0 ⇒ (y:v:z)

Tǫ P 〉

247

The protocol-statement–over and protocol-statement–under /p , \p ∈ ((I)∧∨

∧

∨

∧

∨( I) <−−−| I) <−−−| ((I )∧∨

∧

∨

∧

∨( I) <−−−| I)×((I )∧∨

∧

∨

∧

∨( I) <−−−| I) are defined by

(s/ps1).b = s.b /p s1.b

(s0\ps).b = s0.b \p s.b

The genuine-statement–over and genuine-statement–under /g , \g ∈ ((I)∧∨

∧

∨

∧

∨( I) <−−−| PI) <−−−| ((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI)×((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI) are defined by

(y:v0:x)T

ǫ (s/gs1).b

≡∀〈v, v1, z

|| v = v0++v1

|| (x:v1:z)

Tǫ s1.b ⇒ (y:v:z)

Tǫ s.b ∧

(x:v1:z)T

/ǫ s1.b ⇒ v0 <− b〉

(x:v1:z)T

ǫ (s0\gs).b≡

∀〈y, v0, v|| v = v0++v1

|| (y:v0:x)

Tǫ s0.b ⇒ (y:v:z)

Tǫ s.b ∧

(y:v0:x)T

/ǫ s0.b ⇒ v1 <− b〉

The following point-free definitions are equivalent to the above point-wise ones:

s0 ⊆ s/s1 ≡ s0 ◦s1 ⊆ s

s1 ⊆ s0\s ≡ s0 ◦s1 ⊆ s

P 0 ⊆ P/pP 1 ≡ P 0◦pP 1 ⊆ PP 1 ⊆ P 0\pP ≡ P 0◦pP 1 ⊆ P

s0 ⊆ s/ps1 ≡ s0 ◦ps1 ⊆ s

s1 ⊆ s0\ps ≡ s0 ◦ps1 ⊆ s

s0 ⊆ s/gs1 ≡ s0 ◦ps1 ⊆ s

s1 ⊆ s0\gs ≡ s0 ◦ps1 ⊆ s

where the point-free definitions of /g and \g require the additional assumption that

/g , \g ∈ ((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI) <−−−| ((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI)×((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI). So the s, s0

and s1 in those definitions range over (I )∧∨

∧

∨

∧

∨( I) <−−−|g PI.

To prove that these point-free definitions are equivalent with their point-wise coun-terparts, the only thing that needs to be shown, is that the point-free equations are aconsequence of the point-wise definitions. We leave these proofs to the reader. Theother direction then automatically holds because the point-free equations are Galoisconnections, although we should then use a definition of Galois connections in thecontext of an arbitrary poset 〈A,�〉 instead of only the particular poset 〈PI,⊆〉that we used in section 3.5. Because adjoints in a Galois connection are unique with

248

respect to their behaviour within the poset, the point-wise defined operators mustbe those defined by the point-free equations.

The operators /, \, /p, \p, /g and \g are not continuity preserving in general. Thefollowing theorems show when they do preserve continuity:

s/s1 ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s1 ⊆ const.I

s0\s ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s0 ⊆ const.I

s/ps1 ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s1 ⊆ dark ∩ spec.I

s0\ps ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s0 ⊆ dark ∩ spec.I

s/gs1 ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s1 ⊆ dark ∩ spec.I

s0\gs ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI ∧ s0 ⊆ dark ∩ spec.I

These theorems are a trivial consequence of the following theorems, whose proofswe leave to the reader (B is a set):

s/(const.B) = s ◦(const.B) ∪ Π◦(const.(IrB))

(const.B)\s = (const.B)◦s ∪ (const.(IrB))◦Π

s/p(dark ∩ spec.B) = s ◦p(dark ∩ spec.B) ∪ Π◦p(dark ∩ spec.(IrB))

(dark ∩ spec.B)\ps = (dark ∩ spec.B)◦ps ∪ (dark ∩ spec.(IrB))◦pΠ

s/gs1 = (s/ps1) ∩ Πg

s0\gs = (s0\ps) ∩ Πg

In the language that we introduce in this chapter, the operator /g is used to combinepres and posts (see section 11.2.4).

11.1.2 Arbitrary intersection

The arbitrary statement-intersection ˆ⋂ ∈ (PI <−−−| I) <−−−| ℘(PI <−−−| I) is definedby

( ˆ⋂w).b =⋂{s.b | s ∈ w | s}

The arbitrary genuine-statement–intersection ˆ⋂g ∈ (PI <−−−| PI) <−−−| ℘(PI <−−−|g

PI) is defined by

ˆ⋂g©� = Πg

ˆ⋂gw = ˆ⋂w ⇐ w 6= ©�

We leave it to the reader to verify that ˆ⋂w is continuous for a finite set w of con-

249

tinuous statements. The fact that ˆ⋂gw is continuous for a finite set w of continuous

genuine statements, is a trivial consequence of the following theorem, whose proofis also left to the reader:

ˆ⋂gw = ˆ⋂w ∩ Πg

11.1.3 Aspect operator

The statement–aspect-operator <| ∈ (((I )−−−( I) )−−−( (I )−−−( I)) <−−−| I) <−−−| ((I )−−−(

I) <−−−| I)×(℘I) is defined by

(s<|B).b = s.b <| B

The protocol–aspect-operator <| p ∈ ((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−| (I )∧∨

∧

∨

∧

∨( I)×(℘I) isdefined by

(Y :v:Z)T

ǫ P<| pB

≡∃〈y, z, j || Y = [(y, j)] ∧ Z = [(z, j)] || j ∈ B ⇒ (y:v:z)

Tǫ P 〉

The protocol-statement–aspect-operator <| p ∈ (((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−| I)<−−−| ((I )∧∨

∧

∨

∧

∨( I) <−−−| I)×(℘I) is defined by

(s<| pB).b = s.b <| p B

and the genuine-statement–aspect-operator <| g ∈ (((I )−−−( I) )∧∨

∧

∨

∧

∨( (I )−−−( I)) <−−−|PI) <−−−| ((I )∧∨

∧

∨

∧

∨( I) <−−−|g PI)×(℘I) is defined by

(Y :v:Z)T

ǫ (s<| gB).b

≡

∃〈y, z, j || Y = [(y, j)] ∧ Z = [(z, j)] || j ∈ B ⇒ (y:v:z)T

ǫ s.b∧ j /∈ B ⇒ v <− b〉

or in terms of <| p:

s<| gB = s<| pB ∩ Πg

The operators (<|B), (<| pB) and (<| gB) are continuity preserving:

s<| B ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIs<| pB ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PIs<| gB ∈ PI <−−−|c PI ⇐ s ∈ PI <−−−|c PI

We leave it to the reader to verify these facts (notice that it is not possible tosimply use the definition of the aspect operator in terms of the pack, because the

250

arbitrary intersection of an infinite set of continuous statements is not necessarilycontinuous).

11.2 Formal ISpec language

We now introduced enough machinery for the definition of our formal ISpec lan-guage. We do not define an explicit syntax together with a denotational semanticsfunction, but simply introduce a number of (semantic) operators. The operatorsthat are introduced in this section are called ISpec operators. Although in prin-ciple every mathematical operator may be used to construct input for an ISpecoperator (as long as the types match), the following picture shows the intendedinformation flow:

suite

role

interface

method

post pre

parametersType preCondition resultType postCondition actionClause

postInvariant attributeType stateInvariant actionInvariant

roleInvariant

role

The operators interface and roleInvariant are for example intended to be used forthe construction of input for operator role. Section 11.3 contains an example thatshows the intended use of the operators.

Comparing the above structure to the syntax that was presented in chapter 2,several differences can be observed. These differences are a result of the fact thatthe above structure follows the intended semantic structure of ISpec whereas thesyntax that was presented in chapter 2 follows traditional syntactic structures.

The top-most operator, suite, constructs a suite statement. We do not call thisa “suite”, because we prefer to use the term “suite” for a broader concept a partof which is a suite statement. Other parts could be a name for the suite and a

251

graphical icon representing the suite. In informal explanations, we often talk interms of these broader concepts to keep text readable.

A suite is a hierarchically structured collection of procedures. The hierarchy isconstituted by role names, interface names and method names, representedby the sets R, I and M respectively. Although in principle we leave these setsunspecified, we often use the set II of identifiers for them. The procedures that asuite consists of, operate on states that are carrier records (see section 10.4). Inthis chapter we fix the type C of carrier records by the equation

C = G ≺−−− {globalState}∩ O ≺−−− {this }∩ (I ≺−−− P) ≺−−− {parameters }∩ I ≺−−− {result }

The set of the four carrier names that are used for our formal ISpec language, isdenoted by IC (ISpec carriers):

IC = {globalState, this, parameters, result}

This set of declared-carrier names is used at places where we need to modify carriers.

Because procedures should be able to call other procedures, a suite statement is de-fined as a statement, with suite behaviours as input and output. Suite behavioursare connection protocols of type B, defined by

B = (((C )−−−( M) )−−−( I) )−−−( R) )∧∨

∧

∨

∧

∨( (((C )−−−( M) )−−−( I) )−−−( R)

This type reflects the fact that a product-like construct is used to constitute thehierarchy of procedures (see sections 11.2.1, 11.2.2 and 11.2.3).

The suite statements that we are actually interested in, are the ones that are genuineand continuous. We made genuineness part of the types of the relevant operators.This means that we, the designers of the operators, ensure that if an operator isapplied to an element of its domain, the result is a genuine statement. For theseparticular operators this is obvious from the fact that they are defined in terms ofgenuineness-preserving operators. We do not mention this fact explicitly anymore.We could have done the same thing for continuity, but then we needed to introduceagain more notation. We refrained from doing so, also because it was not necessaryfor obtaining elegant formulas as opposed to the genuineness case.

We now define the output types of the main ISpec operators:

252

Suite = ((((C )−−−( M) )−−−( I) )−−−( R) )∧∨

∧

∨

∧

∨( (((C )−−−( M) )−−−( I) )−−−( R)) <−−−|g BRole = (((C )−−−( M) )−−−( I) )∧∨

∧

∨

∧

∨( ((C )−−−( M) )−−−( I)) <−−−|g BInterface = ((C )−−−( M) )∧∨

∧

∨

∧

∨( (C )−−−( M)) <−−−|g BMethod = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BPost = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BActionClause = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BPostCondition = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BResultType = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BPre = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BPreCondition = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BParametersType = (C )∧∨

∧

∨

∧

∨( C) <−−−|g B

RoleInvariant = (((C )−−−( M) )−−−( I) )∧∨

∧

∨

∧

∨( ((C )−−−( M) )−−−( I)) <−−−|g BActionInvariant = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BPostInvariant = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BStateInvariant = (C )∧∨

∧

∨

∧

∨( C) <−−−|g BAttributeType = (C )∧∨

∧

∨

∧

∨( C) <−−−|g B

The following table shows how the elements of the above types are called:

Suite suite statementRole role statementInterface interface statementMethod method statementPost post statementActionClause action-clause statementPostCondition post-condition statementResultType result-type statementPre pre statementPreCondition pre-condition statementParametersType parameters-type statement

RoleInvariant role-invariant statementActionInvariant action-invariant statementPostInvariant post-invariant statementStateInvariant state-invariant statementAttributeType attribute-type statement

In the following subsections we formally define the ISpec operators.

11.2.1 Suites

The ISpec operator suite ∈ Suite <−−−| ℘(Role×R), defined by

253

suite.roles

=

ˆ⋂g{role ⊳g r | 〈role , r〉 ∈ roles | role, r}

constructs a suite statement from a set of 〈role statement,role name〉-pairs, usinga conjoint-sum kind of construct.

11.2.2 Roles

The ISpec operator role ∈ Role <−−−| ℘(Interface×I)×RoleInvariant, defined by

role.〈interfaces , roleInv 〉=

ˆ⋂g{interface ⊳g i | 〈interface, i〉 ∈ interfaces | interface, i} ∩ roleInv

constructs a role statement from a set of 〈interface statement,interface name〉-pairs. A role-invariant statement roleInv imposes additional constraints.

11.2.3 Interfaces

The ISpec operator interface ∈ Interface <−−−| ℘(Method×M), defined by

interface.methods

=

ˆ⋂g{method ⊳g m | 〈method , m〉 ∈ methods | method , m}

constructs an interface statement from a set of 〈method statement,method name〉-pairs.

11.2.4 Methods

The ISpec operator method ∈ Method <−−−| Post×Pre, defined by

method.〈post , pre〉=

post /g pre

constructs a method statement from a post statement and a pre statement. Theoperators that we introduce to construct pre statements are such that each con-structed pre statement pre satisfies pre ⊆ dark ∩ spec.I. This allows us to interpret

post /g pre as “post holds if pre holds” and ensures preservation of continuity as

254

shown in section 11.1.1.

11.2.5 Posts

The ISpec operator post ∈ Post <−−−| ActionClause×PostCondition×ResultType, de-fined by

post.〈actionClause , postCondition , resultType〉=

actionClause ∩ postCondition ∩ resultType

constructs a post statement from an action-clause statement, a post-conditionstatement and a result-type statement.

11.2.6 Action clauses

The ISpec operator actionClause ∈ ActionClause <−−−| ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B), defined by

actionClause.s

=

s

constructs an action-clause statement from a statement s of the proper type.Some operators for the construction of these ss are introduced in sections 11.2.18,11.2.19 and 11.2.20.

11.2.7 Post-conditions

The ISpec operator postCondition ∈ PostCondition <−−−| (C )−−−( C), defined by

postCondition.S

=

specg.S

constructs a post-condition statement from a binary relation S, ensuring S tohold between the new and old state.

11.2.8 Result types

The ISpec operator resultType ∈ ResultType <−−−| ℘I, defined by

255

resultType.V

=

specg.[[ `result ∈ V ]]

constructs a result-type statement from a set V , ensuring that the new value ofcarrier result is an element of V .

11.2.9 Pres

The ISpec operator pre ∈ Pre <−−−| PreCondition×ParametersType, defined by

pre.〈preCondition , parametersType〉=

preCondition ∩ parametersType

combines a pre-condition statement and a parameters-type statement into a prestatement.

11.2.10 Pre-conditions

The ISpec operator preCondition ∈ PreCondition <−−−| ℘C, defined by

preCondition.C

=

dark ∩ specg.C

constructs a pre-condition statement from a set of states C.

11.2.11 Parameters types

The ISpec operator parametersType ∈ ParametersType <−−−| ℘(℘I × P), defined by

parametersType.W

=

dark ∩ specg.(f.W )

where f ∈ ℘C <−−−| ℘(℘I × P) is defined by

c ∈ f.W

≡∀〈V, p || 〈V, p〉 ∈ W |

| (ppar).c ∈ V 〉

256

constructs a parameters-type statement from a set of 〈parameter type,parametername〉-pairs W .

11.2.12 Role invariants

The ISpec operator roleInvariant ∈ RoleInvariant <−−−| ℘(ActionInvariant×℘I)×℘(Post

Invariant×℘I)×℘(StateInvariant×℘I)×℘(AttributeType×℘I), defined by

roleInvariant.〈actionInvs , postInvs , stateInvs, attributeTypes〉=

ˆ⋂g{(ai <| g M) <| g Iris | 〈ai , is〉 ∈ actionInvs | ai , is} ∩

ˆ⋂g{(pi <| g M) <| g Iris | 〈pi , is〉 ∈ postInvs | pi , is} ∩

ˆ⋂g{(si <| g M) <| g Iris | 〈si , is〉 ∈ stateInvs | si , is} ∩

ˆ⋂g{(at <| g M) <| g Iris | 〈at , is〉 ∈ attributeTypes | at , is}

combines four kinds of invariant statements into one role-invariant statement.The four kinds of invariants that a role-invariant is constructed from, are actioninvariants, post invariants, state invariants and attribute types. Their constructionis treated in sections 11.2.13, 11.2.14, 11.2.15 and 11.2.16.

The set of interface names attached to an invariant, denotes excluded interfaces.(The methods of) these interfaces do not necessarily adhere to that particular invari-ant. The crux of the observer pattern is the re-establishment of the state invariantsthat postulate that the copy of an observer is equal to the orig of its subject.The interfaces that are used for re-establishing a state invariant, often have to beexcluded from the state invariant itself (see sections 2.4.2 and 11.4).

11.2.13 Action invariants

The ISpec operator actionInvariant ∈ ActionInvariant <−−−| ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B), definedby

actionInvariant.s

=

s

constructs an action-invariant statement from a statement of the proper type.An action invariant is like an action clause, except for the fact that it is intendedto be distributed over multiple methods.

11.2.14 Post invariants

The ISpec operator postInvariant ∈ PostInvariant <−−−| (C )−−−( C), defined by

257

postInvariant.S

=

specg.S

constructs a post-invariant statement from a binary relation between states.Post invariants are a less expressive kind of action invariants (similar to post-conditions versus action clauses), describing only a relation between the new andold state.

11.2.15 State invariants

The ISpec operator stateInvariant ∈ StateInvariant <−−−| ℘C, defined by

stateInvariant.C

=

specg.(C ◦Π◦C)

constructs a state-invariant statement from a set C of states. It can be used toensure that the old and new state are an element of C. See section 7.7.2 for detailsabout the specific way we model state invariants.

11.2.16 Attribute types

The ISpec operator attributeType ∈ AttributeType <−−−| (℘I)×A, defined by

attributeType.〈V, a〉=

stateInvariant.{[this −>C

a ∈ V ]}

constructs an attribute-type statement from an 〈attribute type,attribute name〉-pair. An attribute type is a less expressive kind of state invariant that only expressesthat a certain attribute of the ‘this’ object has some specific type.

11.2.17 Primitive types

The ISpec operators void, bool, int, object ∈ ℘I, defined by

void = Ibool = B

int = ZZ

object = O

represent some primitive types intended to be used as parameter types, result

258

types and attribute types. Notice that we use one type (object) for objects insteadof a type for each role name. This is explained in section 11.2.20.


The ISpec–sequential-composition ; ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) <−−−| ((C )∧∨

∧

∨

∧

∨( C) <−−−|gB)×((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) is defined by

s0 ; s1

=

s1 ◦p s0

We reversed the order of statements because most people prefer reading from leftto right.

11.2.19 Modify

In ISpec, a ‘modify’ indicates which attributes of which objects possibly change.Apart from this, in ISpec a ‘modify’ also means that no calls are performed onmethods of the suite’s declared interfaces, also not indirectly via a method ofan undeclared interface. We call a modify of this kind a dark modify. Thedeclared interfaces of a suite are the interfaces that the suite ‘talks about’. Opposedto methods of declared interfaces, methods of undeclared interfaces can be calledduring a dark modify.

The fact that no (direct or indirect) calls may be performed on declared interfaces,described by a set of interface names I, can be expressed by means of the operatordarkI ∈ C )∧∨

∧

∨

∧

∨( C, defined by

(y:v:z)T∈ darkI

≡v ∈ V(T( (((C )−−−( M) )−−−( IrI) )−−−( R) ⋆ (((C )−−−( M) )−−−( IrI) )−−−( R) ))

Notice that we use sets of interface names to describe declared interfaces and notsets of 〈role name,interface name〉-pairs. This simplification is justified by the factthat, as mentioned in section 2.4.1, we assume all interfaces in a suite to havedifferent names.

The statement-version of darkI is darkI ∈ (C )∧∨

∧

∨

∧

∨( C) <−−−| B, defined by

darkI.b = darkI

The genuine version darkgI ∈ (C )∧∨

∧

∨

∧

∨( C) <−−−|g B is defined by

259

darkgI = darkI ∩ Πg

The dark modify dmodifyA, I ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) <−−−| ℘((O <−−−| C)×A) is now de-fined by

dmodifyA, I.X

=

smodifyA.X ∩ darkgI

where the spec-modify smodifyA ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) <−−−| ℘((O <−−−| C)×A) is de-fined by

smodifyA.X

=

specg.(fmodifyCA.X ∩ modifyIC .{globalState, result})

The statement dmodify{a, b, c}, {IA, IB}.{〈this, a〉} for example means that no calls areperformed on the interfaces IA and IB, that the carriers parameters and this

remain equal and that from the attributes a, b, c of any object, only attribute a

of the ‘this’ object possibly changes. The reason for allowing carrier result toarbitrarily change, is to avoid undesirable result dependencies.

11.2.20 Call

The most complicated ISpec operator is the one for method calls. The operator−>

call:: :: ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) <−−−| (O <−−−| C)×R×I×M×((I <−−−| C) <−−−( P) is de-fined by

e −>call

r::i::m ps

=

( dark ∩ specg.(modifyIC .{this, parameters})

◦p ((show.call ⊲p r) ⊲p i) ⊲p m

◦p dark ∩ specg.(modifyIC .{this, parameters, result} ∩ setThis .e∩ setParameters .ps)

) ∩ specg.(modifyIC .{globalState, result})

where (the⌢⌣ are just brackets)

setThis .e = [[ `this = e]]

setParameters .ps =⋂{[[⌢

⌣ppar = ⌢

⌣ps .p]] | p ∈ ps> | p}

We explain this definition by describing in an operational manner what happens

260

during a method call.

First, by means of “setThis .e”, carrier this is assigned the value that expressione has in the old state and by means of “setParameters .ps”, carrier parameters ismodified such that each parameter whose name p is in the domain of ps , is assignedthe value that its corresponding expression ps .p has in the old state. To prevent com-plications, we require e and all ps .p to be total functions. Notice that the functionsetParameters is defined in such a way that it is possible to add parameters in a re-finement of a call. Carrier result is part of “modifyIC .{this, parameters, result}”to avoid unwanted result dependencies.

The following step in a method call is a (visible) call to method m of interface iof role r. In section 11.2.17 we mentioned that we only have one type to representobjects: object. In ISpec, the type of an object is represented by means of a rolename. In our formal ISpec language, all role names are replaced by object. A typechecker should be able to determine the role name that corresponds to the objectexpression e of a call. This can then be used to determine the role name r of acall if this role name is not mentioned explicitly, or to check the role name if it ismentioned explicitly.

In the final step of a method call, the carriers this and parameters are changedback to their original values by “dark ∩ specg.(modifyIC .{this, parameters})” and“∩ specg.(modifyIC .{globalState, result})”. After execution of the call, carrierresult contains the result of the call.

In ISpec it is allowed to refine a call by adding modifications of undeclared at-tributes and calls on undeclared interfaces before and after the call. This canbe modeled by putting a dmodifyA, I.{} before and one after each call. For a setof attribute names A and a set of interface names I, we define the ISpec-call−>

callA, I :: :: ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B) <−−−| (O <−−−| C)×R×I×M×((I <−−−| C) <−−−( P) by

e −>callA, I r::i::m ps

=

dmodifyA, I.{}◦p e −>

callr::i::m ps

◦p dmodifyA, I.{}

Notice that the result of the call is now lost. It would be possible to store the resultin the carrier result by adding “∩ specg.[[ `result = ´result]]” to the top-most dmodify.This can however lead to undesirable result dependencies. We therefore choose to in-troduce a call that is combined with an assignment of the result to some attribute ofthe ‘this’ object, defining the operator := −>

callA, I :: :: ∈ ((C )∧∨

∧

∨

∧

∨( C) <−−−|g B)<−−−| A×(O <−−−| C)×R×I×M×((I <−−−| C) <−−−( P) by

261

a := e −>callA, I r::i::m ps

=

dmodifyA, I.{〈this, a〉} ∩ specg.[[ `this −>C

a = ´result]]◦p e −>

callr::i::m ps

◦p dmodifyA, I.{}

11.3 Plug pattern

We are now able to formalise the plug pattern and observer pattern that wereintroduced in chapter 2. We start with the plug pattern:




Hole


Plug Main

PlugPattern

11.3.1 Signature

The attributes and interfaces that are declared by the plug pattern’s class diagram,are represented by the sets PPA and PPI respectively. Together they constitutethe signature of the suite:

PPA = {hasPlug, plug, inHole, hole}PPI = {IFill, IInsert}

These sets are used for the “A” and “I” of modify statements and call statements.

11.3.2 Hierarchy

The role-interface-method hierarchy that is defined by the class diagram, is con-structed with the ISpec operators suite, role and interface. Role Main is not part ofour formalisation as explained in section 2.5.6.

262

PlugPatternA, I = suite. {〈HoleA, I , Hole 〉, 〈PlugA, I , Plug 〉}

HoleA, I = role.〈 {〈HIFillA, I , IFill 〉},HRInvA, I〉PlugA, I = role.〈 {〈PIInsertA, I , IInsert 〉},PRInvA, I〉

HIFillA, I = interface.{〈HFillWithA, I , fillWith 〉, 〈HEmptyA, I , empty 〉}

PIInsertA, I = interface.{〈PInsertIntoA, I, insertInto〉, 〈PRemoveA, I , remove 〉}

The sets A and I represent the declared attributes and declared interfaces respec-tively (the signature). They are passed as arguments, starting from PlugPattern , .The formula PlugPatternPPA,PPI thus represents the plug pattern. The reason whywe pass arguments A and I, and not simply use PPA and PPI at places where theyare needed, is that in the construction of refinements of a suite, we often use thesame statements, except for the fact that they are interpreted in an extended sig-nature. This is similar to inheritance of method implementations in object-orientedprogramming. See sections 2.4.4 and 11.4.2 for further explanation.

11.3.3 Invariants

Next to the role-interface-method hierarchy, the class diagram also defines attributetypes for the roles Hole and Plug. In our formal ISpec language, these are part ofthe role invariants:

HRInvA, I = roleInvariant.〈 {}, {}, {〈HSInv1 , {}〉, 〈HSInv2 , {}〉}, {〈HHasPlugT , {}〉, 〈HPlugT , {}〉}〉

PRInvA, I = roleInvariant.〈 {}, {}, {〈PSInv1 , {}〉, 〈PSInv2 , {}〉}, {〈PInHoleT , {}〉, 〈PHoleT , {}〉}〉

The four attribute-type statements HHasPlugT , HPlugT , PInHoleT and PHoleTare defined by

HHasPlugT = attributeType.〈bool , hasPlug〉HPlugT = attributeType.〈object, plug 〉PInHoleT = attributeType.〈bool , inHole 〉PHoleT = attributeType.〈object, hole 〉

Notice the replacement of a role name by object, as explained in section 11.2.20.

The state-invariant statements HSInv1, HSInv2, PSInv1 and PSInv2, in section

263

2.2.2 represented by

HSInv1 = stateInvariant hasPlug ⇒ plug.inHole

HSInv2 = stateInvariant hasPlug ⇒ plug.hole = this

PSInv1 = stateInvariant inHole ⇒ hole.hasPlug

PSInv2 = stateInvariant inHole ⇒ hole.plug = this

are in our formal ISpec language defined by

HSInv1 = stateInvariant.{[this −>

ChasPlug ⇒ (this −>

Cplug) −>

CinHole ]}

HSInv2 = stateInvariant.{[this −>

ChasPlug ⇒ (this −>

Cplug) −>

Chole = this]}

PSInv1 = stateInvariant.{[this −>

CinHole ⇒ (this −>

Chole) −>

ChasPlug ]}

PSInv2 = stateInvariant.{[this −>

CinHole ⇒ (this −>

Chole) −>

Cplug = this]}

11.3.4 Methods

What is left, is the definition of the individual methods. For each method of theplug pattern we give its description from section 2.2.3, followed by its formalisation:

264


<HFiParameter>HFiResult<HFiEffect>

HFiParameter = parameter p

objectType Plug

HFiResult = result valueType void

HFiEffect = effect HFiPreConditionHFiActionClauseHFiPostCondition

HFiPreCondition = preCondition ¬hasPlug∧ p.inHole∧ p.hole = this

HFiActionClause = actionClause modify{hasPlug, plug}

HFiPostCondition = postCondition hasPlug

∧ plug = p

HFillWithA, I = method. 〈 HFiPostA, I

, HFiPre〉

HFiPostA, I = post. 〈 HFiActionClauseA, I

, HFiPostCondition, HFiResultType〉

HFiPre = pre. 〈 HFiPreCondition, HFiParametersType〉

HFiParametersType = parametersType.{〈object, p〉}

HFiResultType = resultType. void

HFiPreCondition = preCondition. {[ ¬(this −>ChasPlug)

∧ ppar −>CinHole

∧ ppar −>Chole = this]}

HFiActionClauseA, I = actionClause. dmodifyA, I.{〈this, hasPlug〉, 〈this, plug〉}

HFiPostCondition = postCondition. [[ `this −>ChasPlug

∧ `this −>Cplug = `ppar ]]

265








HEmptyA, I = method. 〈 HEmPostA, I

, HEmPre〉

HEmPostA, I = post. 〈 HEmActionClauseA, I

, HEmPostCondition, HEmResultType〉

HEmPre = pre. 〈 HEmPreCondition, HEmParametersType〉

HEmParametersType = parametersType.{}

HEmResultType = resultType. void

HEmPreCondition = preCondition. {[this −>ChasPlug]}

HEmActionClauseA, I = actionClause. dmodifyA, I.{〈this, hasPlug〉, 〈this, plug〉}

HEmPostCondition = postCondition. [[¬( `this −>ChasPlug)]]

266


<PInParameter>PInResult<PInEffect>

PInParameter = parameter h

objectType Hole

PInResult = result valueType void

PInEffect = effect PInPreConditionPInActionClausePInPostCondition

PInPreCondition = preCondition ¬inHole∧ ¬(h.hasPlug)

PInActionClause = actionClause modify{inHole, hole}; hole.fillWith(this)

PInPostCondition = postCondition inHole

∧ hole = h

PInsertIntoA, I = method. 〈 PInPostA, I

, PInPre〉

PInPostA, I = post. 〈 PInActionClauseA, I

, PInPostCondition, PInResultType〉

PInPre = pre. 〈 PInPreCondition, PInParametersType〉

PInParametersType = parametersType.{〈object, h〉}

PInResultType = resultType. void

PInPreCondition = preCondition. {[ ¬(this −>CinHole)

∧ ¬(hpar −>ChasPlug)]}

PInActionClauseA, I = actionClause. dmodifyA, I.{〈this, inHole〉, 〈this, hole〉}

; (this −>Chole) −>

callA, I

Hole::IFill::fillWith[(this, p)]

PInPostCondition = postCondition. [[ `this −>CinHole

∧ `this −>Chole = `hpar ]]

267


<>PRmResult<PRmEffect>

PRmResult = result valueType void

PRmEffect = effect PRmPreConditionPRmActionClausePRmPostCondition

PRmPreCondition = preCondition inHole

PRmActionClause = actionClause hole.empty(); modify{inHole, hole}

PRmPostCondition = postCondition ¬inHole

PRemoveA, I = method. 〈 PRmPostA, I

, PRmPre〉

PRmPostA, I = post. 〈 PRmActionClauseA, I

, PRmPostCondition, PRmResultType〉

PRmPre = pre. 〈 PRmPreCondition, PRmParametersType〉

PRmParametersType = parametersType.{}

PRmResultType = resultType. void

PRmPreCondition = preCondition. {[this −>CinHole]}

PRmActionClauseA, I = actionClause. (this −>Chole) −>

callA, I

Hole::IFill::empty[]; dmodifyA, I.{〈this, inHole〉

, 〈this, hole〉}

PRmPostCondition = postCondition. [[¬( `this −>CinHole)]]

11.3.5 A trace of insertInto

In this section we explain the relationship between the description of a suite in termsof ISpec operators (syntax) and its behaviour (semantics). We do this by means of

268

a trace for method insertInto of the plug-pattern suite. Actually we should talkabout a family of traces, because the trace contains mathematical variables. Westart with a graphical representation of the trace that we consider:

h.hasPlug = false p.inHole = false

insertInto(h)

p

p.inHole p.hole

h.hasPlug = false p.inHole = true p.hole = h

h

fillWith(p)

h.hasPlug h.plug

h.hasPlug = true h.plug = p p.inHole = true p.hole = h

h.hasPlug = true h.plug = p p.inHole = true p.hole = h

The trace represents the interaction between objects h (for hole) and p (for plug).It is possible that h equals p, in which case we are looking at an object talking toitself.

The trace starts with a call of method insertInto on object p by ‘someone from theoutside’ (the main program). The parameter value that is passed, is h. The rectan-gle that follows, shows the values of the global state’s significant fields. AttributehasPlug of object h and attribute inHole of object p both have value false .

The rounded rectangle that follows, represents the fields that are possibly modified:the attributes inHole and hole of object p. After this, method fillWith of object his called with parameter value p. The rectangle that follows, again shows the valuesof the significant fields. The attributes hasPlug and plug of object h are thenpossibly modified, after which method fillWith returns and finally insertInto

returns.

We now show how to formally write down that the behaviour of the plug-patternsuite contains this particular (family of) trace(s):

269

( [([([(c0, insertInto)], IInsert)], Plug)]: 〈 ( [([([(c1, fillWith)], IFill)], Hole)]

: 〈〉V

: [([([(c2, fillWith)], IFill)], Hole)])T〉V

: [([([(c3, insertInto)], IInsert)], Plug)])T

ǫ

µ(PlugPatternPPA,PPI )

for all carrier records c0, . . . , c3 and object names p, h such that

this .c3 = phpar .c3 = h(h −>

ChasPlug).c3 = false

(p −>CinHole) .c3 = false

this .c2 = hppar .c2 = p(h −>


(p −>CinHole) .c2 = true

(p −>Chole) .c2 = h

this .c1 = hppar .c1 = p(h −>

ChasPlug).c1 = true

(h −>Cplug) .c1 = p



this .c0 = phpar .c0 = h(h −>

ChasPlug).c0 = true

(h −>Cplug) .c0 = p



c2 (−fmodifyCPPA.{〈p, inHole 〉, 〈p, hole〉} −) c3

c1 (−fmodifyCPPA.{〈h, hasPlug〉, 〈h, plug〉}−) c2

c0 (−fmodifyCPPA.©� −) c1

c0 (−modifyIC .{globalState, result}−) c3


The first four blocks of formulas correspond (in the same order, from top to bottom)to the four rectangles in the graphical representation of the trace. The fifth blockis concerned with equality of certain states with respect to certain fields. Its firstformula enforces for example that in state c2, the values of the attributes hasPlug,plug, inHole and hole of every object are equal to their values in state c3, except

270

for the attributes inHole and hole of object p. The last block enforces equality ofcertain states with respect to the carriers this and parameters.

We tried to construct a complete formal proof of the above theorem, but quicklylearned that a brute-force proof is infeasible by hand. A high-level proof theoryand/or automatic theorem prover is required for this, the construction of which weleave for future research.

Despite the fact that we do not have a formal proof theory, we can still show the mainproof obligations that we expect to obtain from such a theory. We only considerproofs about state invariants, pre-conditions, post-conditions and action clauses.Proofs about attribute types, parameter types and result types are omitted. Weleave it to the reader to verify that the proof obligations that we formulate, indeedhold.

We start with proof obligations for the state invariants. In our formalism, the stateinvariants of a role hold at the beginning and end of each of its methods. Wetherefore expect to obtain the following proof obligations:

c3 ∈ PSInv1′

c3 ∈ PSInv2′

c0 ∈ PSInv1′

c0 ∈ PSInv2′

c2 ∈ HSInv1′

c2 ∈ HSInv2′

c1 ∈ HSInv1′

c1 ∈ HSInv2′

where PSInv1′, PSInv2′, HSInv1′ and HSInv2′ are parts of the plug-pattern for-malisation. Their names suggest their origin:

PSInv1′ = {[this −>CinHole ⇒ (this −>

Chole) −>

ChasPlug ]}


Chole) −>

Cplug = this]}

HSInv1′ = {[this −>ChasPlug ⇒ (this −>

Cplug) −>

CinHole ]}


Cplug) −>

Chole = this]}

A pre-condition is something that results in proof obligations if it holds (if the preholds, the post holds). We expect to have to check if the following formulas hold:

c3 ∈ PInPreCondition ′

c2 ∈ HFiPreCondition ′

where

PInPreCondition ′ = {[¬(this −>CinHole) ∧ ¬(hpar −>

ChasPlug)]}

HFiPreCondition ′ = {[¬(this −>ChasPlug) ∧ ppar −>

CinHole


271

The reader can verify that the above two formulas indeed hold, which means that weobtain proof obligations for the corresponding post-conditions and action clauses.

With respect to post-conditions, we expect the following proof obligations:

c0 (−PInPostCondition ′ −) c3

c1 (−HFiPostCondition ′ −) c2

where

PInPostCondition ′ = [[ `this −>CinHole ∧ `this −>

Chole = `hpar ]]

HFiPostCondition ′ = [[ `this −>ChasPlug ∧ `this −>

Cplug = `ppar ]]

What is left, are the action clauses. We expect the following proof obligations:

c3′ (−fmodify

CPPA.{〈this, inHole〉, 〈this, hole〉}−) c3

c3′ (−modifyIC .{globalState, result}−) c3

c2 (−fmodifyCPPA.©� −) c3

′

ppar .c2 = this.c3′

this.c2 = (this −>Chole).c3

′

c0 (−modifyIC .{globalState, result}−) c3′

c1 (−fmodifyCPPA.{〈this, hasPlug〉, 〈this, plug〉}−) c2


for some c3′.

The first two formulas are related to the modify statement in method insertInto,the next four to the call statement in this method and the last two to the modifystatement in method fillWith.

The first formula of both modify-statement blocks expresses the core meaning of amodify statement: that with respect to some attribute signature (PPA in this case),only certain attributes of certain objects possibly change.

The last formula of each block expresses that modify statements and call statementsdo not change the value of the carriers this and parameters.

The first formula of the call-statement (middle) block expresses that, with respectto attribute signature PPA, the global state that the called method starts in, isequal to the global state at call time (the moment the call is performed). The nextformula in this block expresses that for the called method, the value of parameter pis equal to the value of the parameter expression of the call statement at call time.The third formula in this block expresses that for a called method, the value ofcarrier this is equal to the value of the object expression of the call statement atcall time.

272

11.4 Observer pattern

In this section we formalise the observer pattern. We again start with its classdiagram:

orig : void

Subject

copy : void

Observer


IUpdate update

IInsert insertInto

remove


Hole


Plug Main

PlugPattern

ObserverPattern

The observer pattern consists of two parts that are both suites. One part is theplug pattern and the other is an extension that contains observer-pattern specifics.The observer pattern itself is defined as the behavioural intersection of these twosuites:

ObserverPatternA, I = PlugPatternPPA,PPI

µ

∩ ExtensionA, I

In the following subsections we define the extension.

11.4.1 Signature

The signature of the observer pattern extends the signature of the plug pattern withattributes orig and copy and interface IUpdate:

OPA = PPA ∪ {orig, copy}OPI = PPI ∪ {IUpdate}

273

11.4.2 Hierarchy

The role-interface-method hierarchy of the extension is defined by

ExtensionA, I = suite. {〈SubjectA, I , Hole 〉, 〈ObserverA, I , Plug 〉}

SubjectA, I = role.〈 {〈SIFillA, I , IFill 〉},SRInvA, I〉ObserverA, I = role.〈 {〈PIInsertA, I , IInsert 〉

, 〈OIUpdateA, I , IUpdate 〉},ORInvA, I〉

SIFillA, I = interface.{〈SFillWithA, I, fillWith〉}, 〈HEmptyA, I , empty 〉}

OIUpdateA, I = interface.{〈OUpdateA, I , update 〉}

We use the names Hole and Plug and not Subject and Observer because ourtheory does not support renaming (see section 2.5.4).

For interface IInsert and method empty we reuse parts of the plug pattern, whichare now interpreted in the extended signature. Where a call to empty in the ob-server pattern does not change the attributes orig and copy of any object, theseattributes may change arbitrarily when the same call is performed in the plug pat-tern. Furthermore, a call to empty in the observer pattern does not result in anycall on interface IUpdate, whereas in the plug pattern these calls can occur.

11.4.3 Invariants

Because we inherit the invariants from the plug pattern, we do not need to worrymuch about how to plug observers into subjects. We can focus on the extensionthat the observer pattern provides: if an observer is plugged into a subject, thevalue of its attribute copy should be kept up to date with the value of the subject’sattribute orig. The role invariants of subjects and observers are formalised by

SRInvA, I = roleInvariant.〈{}, {}, {〈SSInv , {} 〉}, {〈SOrigT , {}〉}〉ORInvA, I = roleInvariant.〈{}, {}, {〈OSInv, {IUpdate}〉}, {〈OCopyT , {}〉}〉

The two attribute-type statements SOrigT and OCopyT are defined by

SOrigT = attributeType.〈void, orig〉OCopyT = attributeType.〈void, copy〉

The state-invariant statements SSInv and OSInv , in 2.2.4 represented by

SSInv = stateInvariant hasPlug ⇒ plug.copy = orig

OSInv = stateInvariant inHole ⇒ copy = hole.orig

274

are formalised by

SSInv = stateInvariant.{[this −>ChasPlug ⇒

(this −>Cplug) −>

Ccopy = this −>

Corig]}

OSInv = stateInvariant.{[this −>CinHole ⇒

this −>Ccopy = (this −>

Chole) −>

Corig]}

11.4.4 Methods

What is left, is the definition of the methods fillWith and update. For each of bothmethods, we give its description from section 2.2.4, followed by its formalisation:

SFillWith = method fillWith

<HFiParameter>HFiResult<SFiEffect>

SFiEffect = effect HFiPreConditionSFiActionClauseHFiPostCondition

SFiActionClause = actionClause modify{hasPlug, plug}; plug.update()

SFillWithA, I = method. 〈 SFiPostA, I

, HFiPre〉

SFiPostA, I = post. 〈 SFiActionClauseA, I

, HFiPostCondition, HFiResultType〉

SFiActionClauseA, I = actionClause. dmodifyA, I.{〈this, hasPlug〉, 〈this, plug〉}

; (this −>Cplug) −>

callA, I

Plug::IUpdate::update[]

275

OUpdate = method update

<>OUpResult<OUpEffect>

OUpResult = result valueType void

OUpEffect = effect OUpPreConditionOUpActionClauseOUpPostCondition

OUpPreCondition = preCondition inHole

OUpActionClause = actionClause modify{copy}

OUpPostCondition = postCondition copy = hole.orig

OUpdateA, I = method. 〈 OUpPostA, I

, OUpPre〉

OUpPostA, I = post. 〈 OUpActionClauseA, I

, OUpPostCondition, OUpResultType〉

OUpPre = pre. 〈 OUpPreCondition, OUpParametersType〉

OUpParametersType = parametersType.{}

OUpResultType = resultType. void

OUpPreCondition = preCondition. {[ this −>CinHole]}

OUpActionClauseA, I = actionClause. dmodifyA, I.{〈this, copy〉}

OUpPostCondition = postCondition. [[ `this −>Ccopy =

( `this −>Chole) −>

Corig]]

Although we reuse several parts of the plug pattern, we do not behaviourally inheritmuch. Every method is redefined, although we could have chosen ‘true’ for thepost-condition of fillWith and at least have behaviourally inherited that part ofbehaviour. We do however behaviourally inherit the invariants of the plug pattern.

In general it is not beneficial to inherit the behaviour of a method without imposingextra constraints on the attributes and interfaces that extend the signature. Itwould however be beneficial to behaviourally inherit methods for which the “A”

276

and “I” of modify statements and call statements are equal to the universal set I.This is similar to implementation inheritance of generic methods in object-orientedprogramming where dynamic binding (modeled by behavioural intersection in ourcase) is exploited. We leave investigation of this topic for future research.

11.4.5 A trace of insertInto

Also for the observer pattern we examine a (family of) trace(s) for insertInto. Thetrace shows the extra call to update. We again start with a graphical representationof the trace:

s.hasPlug = false s.orig = x o.inHole = false

insertInto(s)

o

o.inHole o.hole

s.hasPlug = false s.orig = x o.inHole = true o.hole = s

s

fillWith(o)

s.hasPlug s.plug

update()

s.hasPlug = true s.plug = o s.orig = x o.inHole = true o.hole = s

o.copy

s.hasPlug = true s.plug = o s.orig = x o.inHole = true o.hole = s o.copy = x



The fact that the observer-pattern suite contains this trace, is formalised by

277

( [([([(c0, insertInto)], IInsert)], Plug)]: 〈 ( [([([(c1, fillWith)], IFill)], Hole)]

: 〈 ( [([([(c2, update)], IUpdate)], Plug)]: 〈〉

V

: [([([(c3, update)], IUpdate)], Plug)])T〉V

: [([([(c4, fillWith)], IFill)], Hole)])T〉V

: [([([(c5, insertInto)], IInsert)], Plug)])T

ǫ

µ(ObserverPatternOPA,OPI )

where

this .c5 = ohpar .c5 = s(s −>


(s −>Corig) .c5 = x

(o −>CinHole) .c5 = false

this .c4 = sppar .c4 = o(s −>



(o −>CinHole) .c4 = true

(o −>Chole) .c4 = s

this .c3 = o(s −>

ChasPlug).c3 = true

(s −>Cplug) .c3 = o




this .c2 = o(s −>

ChasPlug).c2 = true





(o −>Ccopy) .c2 = x

this .c1 = sppar .c1 = o(s −>

ChasPlug).c1 = true






278

this .c0 = ohpar .c0 = s(s −>

ChasPlug).c0 = true






c4 (−fmodifyCOPA.{〈o, inHole〉, 〈o, hole〉} −) c5

c3 (−fmodifyCOPA.{〈s, hasPlug〉, 〈s, plug〉}−) c4

c2 (−fmodifyCOPA.{〈o, copy〉} −) c3

c1 (−fmodifyCOPA.©� −) c2





We again present the proof obligations that we expect to obtain from a formal prooftheory, starting with the state invariants:

c5 ∈ PSInv1′

c5 ∈ PSInv2′

c5 ∈ OSInv ′

c0 ∈ PSInv1′

c0 ∈ PSInv2′

c0 ∈ OSInv ′

c4 ∈ HSInv1′

c4 ∈ HSInv2′

c4 ∈ SSInv ′

c1 ∈ HSInv1′

c1 ∈ HSInv2′

c1 ∈ SSInv ′

c3 ∈ PSInv1′

c3 ∈ PSInv2′

—————–c3 ∈ OSInv ′

c2 ∈ PSInv1′

c2 ∈ PSInv2′

—————–c2 ∈ OSInv ′

where

279


Chole) −>

ChasPlug]}


Chole) −>

Cplug = this]}

OSInv ′ = {[this −>CinHole ⇒ this −>

Ccopy =

(this −>Chole) −>

Corig]}


Cplug) −>

CinHole]}


Cplug) −>

Chole = this]}

SSInv ′ = {[this −>ChasPlug ⇒ (this −>

Cplug) −>

Ccopy =

this −>Corig]}

The two formulas that have been blotted out, are not proof obligations becauseinterface IUpdate is excluded from invariant OSInv . The first one of these twoformulas indeed does not hold in general for our family of traces. Traces are helpfulin determining which interfaces should be excluded from which invariants. If aninterface is excluded from a certain invariant, this invariant then usually ends up inthe post-condition of the interface’s methods.

For the pre-conditions we expect to have to check:

c5 ∈ PInPreCondition ′

c4 ∈ HFiPreCondition ′

c3 ∈ OUpPreCondition ′

where

PInPreCondition ′ = {[¬(this −>CinHole) ∧ ¬(hpar −>

ChasPlug)]}

HFiPreCondition ′ = {[¬(this −>ChasPlug) ∧ ppar −>

CinHole


OUpPreCondition ′ = {[this −>CinHole]}

Remember that these are not proof obligations, but can (and again do in this case)result into proof obligations.

For the post-conditions we expect the following proof obligations:

c0 (−PInPostCondition ′ −) c5

c1 (−HFiPostCondition ′ −) c4

c2 (−OUpPostCondition ′ −) c3

where

PInPostCondition ′ = [[ `this −>CinHole ∧ `this −>

Chole = `hpar ]]

HFiPostCondition ′ = [[ `this −>ChasPlug ∧ `this −>

Cplug = `ppar ]]

OUpPostCondition ′ = [[ `this −>Ccopy = ( `this −>

Chole) −>

Corig]]

Finally for the action clauses we expect

280

c5′ (−fmodify

COPA.{〈this, inHole〉, 〈this, hole〉}−) c5



′

ppar .c4 = this.c5′

this.c4 = (this −>Chole).c5

′


c4′ (−fmodify

COPA.{〈this, hasPlug〉, 〈this, plug〉}−) c4



′

this.c3 = (this −>Cplug).c4

′


c2 (−fmodifyCOPA.{〈this, copy〉}−) c3


for some c5′ and c4

′.

11.4.6 Property

Traces are a nice way to illustrate behaviour of a specification or to test that a spec-ification exhibits intended behaviour. In this section we show how our formal ISpeclanguage can be used to describe more general properties of a suite. The followingproperty tells that, within the chosen signature, a call to method insertInto on aplug only possibly changes the attributes inHole, hole and copy of this plug andthe attributes hasPlug and plug of the hole it is being plugged into:

ModifyA, I = suite. {〈ModA, I , Plug 〉}ModA, I = role.〈 {〈MIInsertA, I , IInsert 〉},MRInv〉MIInsertA, I = interface.{〈MInsertIntoA, I, insertInto〉}

MRInv = roleInvariant.〈{}, {}, {}, {}〉

281

MInsertIntoA, I = method. 〈 MInPostA, I

, PInPre〉

MInPostA, I = post. 〈 MInActionClauseA, I

, MInPostCondition, MInResultType〉

MInActionClauseA, I = actionClause. smodifyA.{〈this, inHole〉, 〈this, hole〉, 〈this −>

Chole, hasPlug〉

, 〈this −>Chole, plug〉

, 〈this, copy〉}

MInPostCondition = postCondition.[[true]]

MInResultType = resultType. void

The fact that the observer-pattern suite satisfies this property, is formalised by

ObserverPatternOPA,OPI

µ

⊆ ModifyOPA,OPI

A proof system that enables one to prove these kinds of facts, is left for futureresearch.

11.5 Conclusions

In this chapter we used the theory of the previous chapters to construct a formallanguage for a subset of ISpec. We formalised the plug pattern and observer patternthat were introduced in chapter 2 and discussed two (families of) traces, one for theplug pattern and one for the observer pattern. We also showed how properties ofsuites can be formulated as suites. A proof system that enables us to prove theseproperties is beyond the scope of this thesis.

282

Chapter 12

Conclusions

The primary goal of our work was to investigate and formalise ISpec, a specificationapproach that is used in industry for the specification of interfaces of component-based systems. We strived to “make things as simple as possible, but not simpler”.For us, “as simple as possible” meant that we tried to construct mathematicalstructures that are simple and regular. We tried to achieve “but not simpler” bymeans of many discussions with the designer of ISpec, Hans Jonkers. Small, simpleexamples appeared to be a powerful communication means between the formaltheory and the ideas behind ISpec.

12.1 Our work

Apart from formalising ISpec, a contribution that we wanted to make with thisthesis is to provide a new and hopefully inspiring view on many well-known concepts,integrated into a single formal framework. We present a short list of what, in ourview, are new ideas that this thesis presents:

• The research into extensible typing and uniform notation for type operators,presented in chapter 4.

• The unifying view on the relational product and sum and several related newproducts like the conjoint sum, presented in chapter 5.

• A novel treatment of non-strict and non-deterministic expressions in chapter6, based on the products that are introduced in chapter 5.

• The partial- and total-correctness operators presented in sections 7.3 and 7.8.3that use binary relations for pres and posts. We found [48] to use a notion ofcorrectness that is somewhat similar to our notion of total correctness. Thisis further discussed in the next section.

283

• The pack operator that corresponds to the conjoint sum (section 5.6), enablingthe creation of hierarchically structured specifications that can be straightfor-wardly extended by means of refinement (section 7.5).

• The aspect operator, providing a simple and powerful means to add aspectsand invariants to hierarchically structured specifications (section 7.7).

• The investigation in section 8.5 of the subtle differences between behaviouralintersection and overriding we thought to be novel. The same goes for thenotion of conservative users presented in section 8.6.4. As the next sectionshows, these notions turned out to be already investigated in [41]. Our par-ticular way of formalising these notions and the way we link them to otherconcepts, can be considered a contribution though.

• The generalisation of relations to protocols and in particular the notion of con-tinuous genuine statements that captures the concept of visible calls (chapter9). This provides a model that, like process-algebras, is explicit about com-munication between components, but in a way that matches the relationalmethod-call semantics that is conventional for object-oriented systems.

The definition of the formal ISpec language and the treatment of the notoriousobserver-pattern example illustrate the use of many of these theoretical concepts.

12.2 Related work

As can be expected in the context of well-established computer-science concepts like‘object-oriented’ and ‘component-based’, much research has been performed that isrelated to our work.

Closely related to our work is of course the research carried out on the predecessorof ISpec, called COLD (Common Object-oriented Language for Design) [19]. COLDis actually not a single language, but a family of languages, defined as syntactic ex-tensions of a formally defined kernel language, called COLD-K. COLD-K is a richdesign language that allows for the definition of abstract datatypes, state-basedgeneralisations called classes, specifications built with these, called schemes, anddesigns consisting of components (specifications with an optional implementation).Our thesis can be seen as supplementary research where we disregard algebraicspecification of datatypes, only informally introducing some basic types, and focuson inter-component communication. We also try to provide some more insight intoother notions that play a role in COLD and ISpec, like non-strict expression evalua-tion, signature extension, invariants, conservative extension and field modification.

A language that is like COLD based on the notion of evolving algebras is thelanguage of Abstract State Machines (ASMs) [12]. An executable language that isbased on ASMs is the Abstract State Machine Language (AsmL) [23]. There doeshowever not seem to exist much research on ASMs that is related to our work.

284

Another well-known example of a specification approach for complex software sys-tems is Z [29]. Two derivatives are the B-method [2], focusing mainly on softwareimplementation, and Object-Z [47], that extends Z with several object-orientedconcepts. Object-Z again has a spin-off called CSP-OZ [46]. CSP-OZ combinesthe relational world of Object-Z with the process-algebraic world of communicatingsequential processes [25] (CSP). This approach is however different from the com-mon object-oriented approach where communication in a system consists of methodcalls between objects. Our notion of protocol was designed to reflect this commonobject-oriented style.

Comparable to Z is the Vienna Development Method (VDM) [30]. VDM usesthe Logical of Partial Functions (LPF) to deal with partiality in specifications.The truth tables of VDM correspond to the ones that we use (section 6.2) whichstrengthens our belief that we made proper choices. Like Z, VDM also has an object-oriented version VDM++ [18] and a related language RSL (Rigorous Approach toIndustrial Software Engineering (RAISE) Specification Language [21]) that com-bines VDM with CSP-like process-algebraic concepts. Similar to the CSP-OZ case,RSL also does not reflect the common object-oriented style.

Research into object-oriented programming has also been performed in the contextof the refinement calculus [3]. Just before the finishing of this thesis, we discovereda paper [41] that contains theory that is strikingly similar to the sections 8.5 and8.6 of this thesis. What the authors of that paper call the “flexibility property”,corresponds to the “???” in the formula

(s0 Z0©C Z1

s1)µ

⊆Z0∪Z1s

⇐ {• Z0 and Z1 are disjoint sets and ???}

s0

µ

⊆Z0s ∧ s1

µ

⊆Z1s

at the beginning of section 8.5.7 of this thesis. Furthermore, their “no cycles re-quirement” corresponds to the notion of “independence” presented in section 8.5.8.The paper also describes the notions “no revision self-calling assumptions” and “nobase class down-calling assumptions” that correspond to the notion of “conservativeusers” presented in section 8.6.4. The fact that the same concepts were discoveredin complete separation, using different formalisms, is a clear indication of the factthat these are fundamental notions in the context of object-oriented programmingand probably deserve more attention than is apparent from the number of citationsto [41].

As mentioned at the end of section 8.5.8 of this thesis, the restrictions imposedthere (and also in [41]) might be too severe for certain practical situations. Thisview seems to be supported by the fact that several researchers are working on proofsystems for non-hierarchical object-oriented systems. For a comprehensive overviewwe refer to [37] and [40]. This particular research area is focused on powerful proofsystems for object-oriented programming languages like Java and C#. From anabstract point of view, a key goal of all these proof-system developers is to findan appropriate model that abstracts from the object-oriented language in such a

285

way that it enables one to prove the correctness of intricate practical examplesin a feasible manner. Although our primary concern was not the constructionof a powerful proof system for an object-oriented programming language, enablingformal proofs was an important incentive for several design decisions and can be seenas an attempt to approximate the kind of model we just mentioned. We hope thatour notion of “visible calls” will inspire people from the proof-system communityand can help them in their quest for the ultimate proof system for object-orientedprogramming.

As mentioned in the previous section, the paper [48] presents a notion of correctnessthat is somewhat similar to our notion of total correctness. Formally, the notion ofcorrectness that is presented in [48] is

P ⊆ S˘◦R

whereas our notion of total correctness is

S ◦P ⊆ R ∧ P < ⊆ S>

Although these notions are equivalent for functional relations S, they are not forrelations S in general. To simplify things a little, assume that pre P is equal tothe identity relation I and that post R is total (P = R> = I). Our notion of totalcorrectness of body S then means that S may reduce the non-determinism that ispresent in Q. The notion of [48] is equivalent to

∀〈z |||| ∃〈y |||| y (−S −) z ∧ y (−R−) z〉〉

In other words, S is correct if it is somehow able to produce a value that adheresto the post. This is a rather unorthodox notion of correctness that is at least notsuitable for doing successive refinement, whereas our notion is suitable for thatpurpose.

12.3 Future work

This thesis only captures a small part of ISpec. There are still many concepts ofISpec missing as section 2.5 shows. These include required interfaces, parallellism,object existence, renaming, black-box semantics, activation specifications, dynamicbinding and probably many others. Next to this, there are many questions in thisthesis for which we do not give a proper answer or only hint at a possible answer, forexample how to deal with non-strictness in expressions, how to construct Hoare-likeproofs for ISpec specifications, how to deal with infinite behaviour, how to proveinvariants, how to deal with total refinement in general, how to deal with mutualdependencies between components or how to deal with pointers. Many of thesetopics have been extensively investigated by others, but for most of them there stilldoes not seem to exist a ‘definitive answer’. We hope that the formal theory that ispresented in this thesis can help researchers to obtain new insights in these areas.

286

Summary

In this thesis we formalise several concepts that can be found in practical approachesto the specification of large software systems. Our focus is ISpec, an industrialspecification approach developed within Philips Research, that is used to specifyinterfaces of component-based systems.

Our primary mathematical formalism is the calculus of relations. We develop severalnew relation-algebraic constructs that suit our needs. For example, to be able to bevery detailed in typing relations, we introduce a rich collection of type operators.A key role is fulfilled by the cylindric-type operator that generalises the co/contra-variant way in which functions are usually typed in functional programming.

The cylindric-type operator is used to define a new construct that we call the cylin-dric product. We show that the product and sum of allegory theory are constrainedforms of this cylindric product. A detailed analysis of several other constrainedforms of the cylindric product is presented. One of these constructs is the conjointsum, a construct that closely resembles the (disjoint) sum of allegory theory. How-ever, adding a relation to a conjoint sum results in a smaller relation (subrelation),just like the addition of a method to a class results in a subclass in object-orientedprogramming. It is shown how the different products can be used to model differentkinds of expression evaluation, like strict evaluation, non-strict evaluation and evenseveral kinds of non-deterministic evaluation.

All this forms the basis for the formalisation of concepts that are more well-known.Refinement plays a crucial role. It serves as basis of a Hoare-like proof systemthat is purely based on (binary) relations. We show how to construct specificationsthat consist of a declarative as well as an operational part and show how commonbehaviour of specifications can be isolated in an aspect. This enables not only theformulation of more clear specifications, but also simplifies refinement. Aspectsactually appear to be closely related to invariants. These are also investigated indetail.

Another topic of this thesis is components and their composition. We show howthese concepts can be formalised and investigate modular refinement of components.Fixed-point theory is used to enable communication between components. Theimpact of this on modular refinement of components is investigated. The use of

287

relations as semantic model has as a consequence that communication betweencomponents is invisible. We introduce a generalisation of relations, called protocols,to enable visible communication.

In object-oriented programming, several variable-concepts like attributes, a ‘this’object, parameters and results are used. These concepts are also modeled andinvestigated in this thesis.

The relation between theory and practice is made explicit by a formal language fora subset of ISpec.

288

Samenvatting

In dit proefschrift formaliseren we verscheidene concepten die te vinden zijn inpraktische aanpakken voor de specificatie van grote softwaresystemen. Onze focusis ISpec, een industriele specificatie-aanpak ontwikkeld binnen Philips Research, diegebruikt wordt om interfaces van componentgebaseerde systemen te specificeren.

Ons primaire wiskundige formalisme is de relatiecalculus. We ontwikkelen verschei-dene nieuwe relatie-algebraısche constructies die nuttig zijn voor ons doel. Bijvoor-beeld, om heel gedetailleerd te kunnen zijn bij het typeren van relaties, introdu-ceren we een rijke collectie type-operatoren. Een sleutelrol wordt vervuld door decylindrisch-type operator. Deze generaliseert de co/contra-variante wijze waaropfuncties gewoonlijk worden getypeerd in functioneel programmeren.

De cylindrisch-type operator wordt gebruikt om een nieuwe constructie te definierendie we het cylindrisch produkt noemen. We tonen aan dat het produkt en de somvan allegorie theorie ingeperkte vormen zijn van dit cylindrisch produkt. Tevenswordt een gedetailleerde analyse gepresenteerd van verscheidene andere ingeperktevormen van het cylindrisch produkt. Een van deze constructies is de conjuncte som,een constructie die veel lijkt op de (disjuncte) som van allegorie theorie. Echter, hettoevoegen van een relatie aan een conjuncte som resulteert in een kleinere relatie(subrelatie), net zoals het toevoegen van een methode aan een klasse resulteert in eensubklasse in object-georienteerd programmeren. We laten zien hoe de verschillendeprodukten gebruikt kunnen worden om verschillende soorten expressie-evaluatie temodelleren, zoals strikte evaluatie, niet-strikte evaluatie en zelfs verscheidene vor-men van niet-deterministische evaluatie.

Dit alles vormt de basis voor de formalisatie van concepten die meer bekend zijn.Verfijning speelt hierbij een cruciale rol. Het dient als basis voor een Hoare-achtigbewijssysteem dat puur gebaseerd is op (binaire) relaties. We laten zien hoe spe-cificaties kunnen worden geconstrueerd die bestaan uit zowel een declaratief als eenoperationeel gedeelte en hoe gemeenschappelijk gedrag van specificaties geısoleerdkan worden in een aspect. Dit maakt niet alleen de formulering van duidelijkerespecificaties mogelijk, maar vereenvoudigt ook verfijning. Aspecten blijken nauwverwant te zijn met invarianten. Deze worden ook in detail bestudeerd.

Een ander onderwerp van dit proefschrift is componenten en hun compositie. We

289

laten zien hoe deze concepten geformaliseerd kunnen worden en onderzoeken mo-dulaire verfijning van componenten. De theorie van vaste punten wordt gebruiktom communicatie tussen componenten mogelijk te maken. We onderzoeken deimpact die dit heeft op modulaire verfijning van componenten. Het gebruik vanrelaties als semantisch model heeft tot gevolg dat communicatie tussen componentenonzichtbaar is. We introduceren een generalisatie van relaties, genaamd protocollen,om zichtbare communicatie mogelijk te maken.

In object-georienteerd programmeren worden verscheidene variabele-concepten ge-bruikt zoals attributen, een ‘this’ object, parameters en resultaten. Deze conceptenworden ook gemodelleerd en onderzocht in dit proefschrift.

De relatie tussen theorie en praktijk wordt expliciet gemaakt door middel van eenformele taal voor een deel van ISpec.

290

Curriculum vitae

Louis van Gool was born in Venlo, the Netherlands, on the 1st of July 1976. In 1994he received his Gymnasium diploma at the Thomas College in Venlo. After thathe started a combined study in Mathematics and Computer Science at TechnischeUniversiteit Eindhoven. After receiving a first-year’s degree in each of both studies,he continued with Computer Science, receiving his Master’s degree on “CylindrischeComponenten Calculus” in 2000 (cum laude) under the supervision of dr. Jaap vander Woude.

After receiving his Master’s degree, Louis started as a Ph.D. student at TechnischeUniversiteit Eindhoven. Under the supervision of promotor prof. dr. Jos Baeten andcopromotor dr. Ruurd Kuiper and in close cooperation with dr. Hans Jonkers fromPhilips Research, he worked on an analysis and formalisation of the specificationapproach ISpec.

After his Ph.D. period, Louis started as a ‘postdoctoral’ researcher on the IDEALSproject where he has worked on software-maintainability analysis and model-drivendevelopment for ASML Litography.

291

Bibliography

[1] C.J. Aarts. Galois Connections Presented Calculationally. Master thesis. Tech-nische Universiteit Eindhoven. Year: 1992.

[2] J. Abrial. The B-Book: Assigning Programs to Meanings. Publisher: Cam-bridge University Press. Year: 1996.

[3] R.J. Back, A. Mikhajlova, J. von Wright. Class Refinement as Semantics ofCorrect Object Substitutability. Journal: Formal Aspects of Computing. Vol-ume: 12. Pages: 18–40. Year: 2000.

[4] R.C. Backhouse. Galois Connections and Fixed Point Calculus. Booktitle: Re-vised Lectures from the International Summer School and Workshop on Alge-braic and Coalgebraic Methods in the Mathematics of Program Construction.Editors: R.C. Backhouse, R.L. Crole, J. Gibbons. Series: Lecture Notes inComputer Science. Volume: 2297. Pages: 89–148. Publisher: Springer. Year:2002.

[5] R.C. Backhouse. Pair Algebras and Galois Connections. Journal: InformationProcessing Letters. Volume: 67. Number: 4. Pages: 169–173. Publisher: Else-vier. Year: 1998.

[6] R.C. Backhouse, P.J. de Bruin, P.F. Hoogendijk, G. Malcolm, T.S. Voermans,J.C.S.P. van der Woude. Polynomial Relators (Extended Abstract). Booktitle:Proceedings of the Second International Conference on Methodology and Soft-ware Technology: Algebraic Methodology and Software Technology. Editors:M. Nivat, C. Rattray, T. Rus, G. Scollo. Series: Workshops in Computing.Pages: 303–326. Publisher: Springer. Year: 1992.

[7] R.C. Backhouse, H. Doornbos. Mathematics of Recursive Program Construc-tion. Year: 2001.

[8] J.C.M. Baeten. A Brief History of Process Algebra. Journal: Theoretical Com-puter Science. Volume: 335. Number: 2-3. Pages: 131–146. Publisher: Elsevier.Year: 2005.

[9] A. Bijlsma. Specifications Involving Initial Values. Year: 2000.

293

[10] A. Bijlsma, H.P.J. van Geldrop, L.C.M. van Gool, C. Hemerik, C. Huizing, R.Kuiper, O.S. van Roosmalen, J.C.S.P. van der Woude, G. Zwaan. Model-BasedSpecification of Design Patterns. Nieuwsbrief NVTI. Pages: 9–14. Year: 1999.

[11] R.S. Bird, O. de Moor. Algebra of Programming. Publisher: Prentice Hall.Year: 1997.

[12] E. Borger, R.F. Stark. Abstract State Machines: a Method for High-Level Sys-tem Design and Analysis. Publisher: Springer. Year: 2003.

[13] J. Desharnais, B. Moller. Characterizing Determinacy in Kleene Algebras. Jour-nal: Information Sciences. Volume: 139. Number: 3-4. Pages: 253–273. Pub-lisher: Elsevier. Year: 2001.

[14] M. Deutch, M.C. Henson. An Analysis of Total Correctness Refinement Modelsfor Partial Relation Semantics I. Journal: Logic Journal of the IGPL. Volume:11. Number: 3. Pages: 287–317. Publisher: Oxford University Press. Year:2003.

[15] E.W. Dijkstra. Notational Considerations and the Relational Calculus.EWD1141. University of Texas at Austin. Year: 1992.

[16] E.W. Dijkstra, C.S. Scholten. Predicate Calculus and Program Semantics. Pub-lisher: Springer. Year: 1990.

[17] H. Doornbos, R.C. Backhouse, J.C.S.P. van der Woude. A Calculational Ap-proach to Mathematical Induction. Journal: Theoretical Computer Science.Volume: 179. Number: 1-2. Pages: 103–135. Publisher: Elsevier. Year: 1997.

[18] E. Durr, J. van Katwijk. VDM++, a Formal Specification Language for Object-Oriented Designs. Booktitle: Proceedings of the Seventh International Confer-ence on Technology of Object-Oriented Languages and Systems. Editors: G.Heeg, B. Magnusson, B. Meyer. Pages: 63–77. Publisher: Prentice Hall. Year:1992.

[19] L.M.G. Feijs, H.B.M. Jonkers. Formal Specification and Design. Publisher:Cambridge University Press. Year: 1992.

[20] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software. Publisher: Addison-Wesley. Year: 1995.

[21] C. George, A.E. Haxthausen, S. Hughes, R. Milne, S. Prehn, J. Storbank Ped-ersen. The RAISE Development Method. Publisher: Prentice Hall. Year: 1999.

[22] L.C.M. van Gool. Cylindrische Componenten Calculus (in Dutch). Master the-sis. Technische Universiteit Eindhoven. Year: 2000.

[23] Y. Gurevich, B. Rossman, W. Schulte. Semantic Essence of AsmL: ExtendedAbstract. Booktitle: FMCO 2003: Formal Methods for Components and Ob-jects: Second International Symposium. Editors: F.S. de Boer, M.M. Bon-sangue, S. Graf, W.-P. de Roever. Series: Lecture Notes in Computer Science.Volume: 3188. Pages: 240–259. Publisher: Springer. Year: 2004.

294

[24] C.A.R. Hoare. An Axiomatic Basis for Computer Programming. Journal: Com-munications of the ACM. Volume: 12. Number: 10. Pages: 576–580. Publisher:ACM Press. Year: 1969.

[25] C.A.R. Hoare. Communicating Sequential Processes. Publisher: Prentice Hall.Year: 2004.

[26] C.A.R. Hoare, H. Jifeng. The Weakest Prespecification. Journal: InformationProcessing Letters. Volume: 24. Number: 2. Pages: 127–132. Publisher: Else-vier. Year: 1987.

[27] C.A.R. Hoare. Unification of Theories: a Challenge for Computing Science.Booktitle: Selected Papers from the 11th Workshop on Specification of Ab-stract Data Types Joint with the 8th COMPASS Workshop on Recent Trendsin Data Type Specification. Editors: M. Haveraaen, O. Owe, O.-J. Dahl. Series:Lecture Notes in Computer Science. Volume: 1130. Pages: 49–57. Publisher:Springer. Year: 1996.

[28] C.A.R. Hoare. Unified Theories of Programming. Booktitle: MathematicalMethods in Program Development. Editors: M. Broy, B. Schieder. Series:NATO ASI, Series F: Computer and System Sciences. Volume: 158. Pages:313–367. Publisher: Springer. Year: 1997.

[29] ISO/IEC. Information Technology – Z Formal Specification Notation – Syntax,Type System and Semantics. Year: 2002.

[30] C.B. Jones. Systematic Software Development Using VDM. Publisher: PrenticeHall. Year: 1995.

[31] C.B. Jones. The Early Search for Tractable Ways of Reasoning about Programs.Journal: IEEE Annals of the History of Computing. Volume: 25. Number:2. Pages: 26–49. Publisher: IEEE Educational Activities Department. Year:2003.

[32] H.B.M. Jonkers. Upgrading the Pre- and Postcondition Technique. Booktitle:Proceedings of the 4th International Symposium of VDM Europe on FormalSoftware Development. Editors: S. Prehn, W.J. Toetenel. Series: Lecture Notesin Computer Science. Volume: 551. Pages: 428–456. Publisher: Springer. Year:1991.

[33] H.B.M. Jonkers. ISpec: Towards Practical and Sound Interface Specifications.Booktitle: Proceedings of the Second International Conference on IntegratedFormal Methods. Editors: W. Grieskamp, T. Santen, B. Stoddart. Series: Lec-ture Notes in Computer Science. Volume: 1945. Pages: 116–135. Publisher:Springer. Year: 2000.

[34] H.B.M. Jonkers. Interface-Centric Architecture Descriptions. Booktitle: Pro-ceedings of the Working IEEE/IFIP Conference on Software Architecture. Vol-ume: 00. Pages: 113–124. Publisher: IEEE Computer Society. Year: 2001.

[35] H.B.M. Jonkers. The ISpec Metamodel (Draft). Year: 2005.

295

[36] A. Kaldewaij. Programming: The Derivation of Algorithms. Publisher: Pren-tice Hall. Year: 1990.

[37] G.T. Leavens, K.R.M. Leino, P. Muller. Specification and Verification Chal-lenges for Sequential Object-Oriented programs. Technical Report. Iowa StateUniversity. Year: 2006.

[38] B.H. Liskov, J.M. Wing. A Behavioural Notion of Subtyping. Journal: ACMTransactions on Programming Languages and Systems. Volume: 16. Number:6. Pages: 1811–1831. Publisher: ACM Press. Year: 1994.

[39] B. Meyer. Object-Oriented Software Construction, Second edition. Publisher:Prentice Hall. Year: 1997.

[40] R. Middelkoop, C. Huizing, R. Kuiper, E. Luit. Cooperation-Based Invariantsfor OO Languages. Booktitle: FACS ’05: Proceedings of the InternationalWorkshop on Formal Aspects of Component Software. Series: Electronic Notesin Theoretical Computer Science. Publisher: Elsevier. Year: 2005.

[41] L. Mikhajlov, E. Sekerinski. A Study of The Fragile Base Class Problem. Book-title: ECOOP ’98: Proceedings of the 12th European Conference on Object-Oriented Programming. Editors: E. Jul. Series: Lecture Notes in ComputerScience. Volume: 1445. Pages: 355–382. Publisher: Springer. Year: 1998.

[42] J.M. Morris, A. Bunkenburg. Partiality and Nondeterminacy in ProgramProofs. Journal: Formal Aspects of Computing. Volume: 10. Number: 1. Pages:76–96. Publisher: Springer. Year: 1998.

[43] H.R. Nielson, F. Nielson. Semantics with Applications, A Formal Introduction.Publisher: Wiley & Sons. Year: 1996.

[44] E.E. Roubtsova, L.C.M. van Gool, R. Kuiper, H.B.M. Jonkers. A SpecificationModel for Interface Suites. Booktitle: Proceedings of the 4th InternationalConference on the Unified Modeling Language, Modeling Languages, Conceptsand Tools. Editors: M. Gogolla, C. Kobryn. Series: Lecture Notes in ComputerScience. Volume: 2185. Pages: 457–471. Publisher: Springer. Year: 2001.

[45] E.E. Roubtsova, L.C.M. van Gool, R. Kuiper, H.B.M. Jonkers. Consistent Spec-ification of Interface Suites in UML. Journal: Software and Systems Modeling.Volume: 1. Number: 2. Pages: 98–112. Publisher: Springer. Year: 2002.

[46] G. Smith, J. Derrick. Specification, Refinement and Verification of ConcurrentSystems–An Integration of Object-Z and CSP. Journal: Formal Methods inSystem Design. Volume: 18. Number: 3. Pages: 249–284. Publisher: KluwerAcademic Publishers. Year: 2001.

[47] G. Smith. The Object-Z Specification Language. Publisher: Kluwer AcademicPublishers. Year: 2000.

[48] A. Tarlecki. A Language of Specified Programs. Journal: Science of ComputerProgramming. Volume: 5. Number: 1. Pages: 59–81. Publisher: Elsevier. Year:1985.

296

[49] T.S. Voermans. Inductive Datatypes with Laws and Subtyping — A RelationalModel. Ph.D. thesis. Technische Universiteit Eindhoven. Year: 1999.

297

Index

(y, z), see connection(o, a)

F, see field name

(x, v)T, see trace

(y:v:z)T, see connection trace

[x0, . . . , xn−1], see col. enumeration{x0, . . . , xn−1}, see set enumeration〈x0, . . . , xn−1〉, see tuple〈x0, . . . , xn−1〉V, see sequence[f.x|p.x|x], see col. comprehension{f.x|p.x|x}, see set comprehension〈f.x|p.x|x〉, see fun. comprehension〈x||p.x||f.x〉, see mirrored fun. compreh.[[E]], see col.-comprehension operator{[E]}, see set-comprehension operatory (−R−) z, see connect output with inputR −−)S(−−P , see partial-correctness operatorR −−|S|−−P , see total-correctness operatorfalse , see booleantrue, see boolean∀, see universal quantification∃, see existential quantification∧, see conjunction∨, see disjunction⇒, see implication⇐, see consequence≡, see equivalence¬, see negation•, see assumption., see application, see fix notation6≃, see negated binary predicate∈, see element-of∋, see owner-ofǫ, see is-contained-by<−, see all-contained-by⊆, see subcollection-of

⊆, see statement-inclusion

µ

⊆, see behavioural refinement

⊆Z, see refinement

⊆Z, see statement-refinementµ

⊆Z, see behavioural refinement

⊑, see total refinement

⊑, see total statement-refinementµ

⊑, see total behavioural refinement

⊑p, see total protocol refinement⊑Z, see total refinement©Z, see override

©Z, see statement-override

⊇, see supercollection-of=, see equality=:, see assignmentI, see identity relation

I, see identity statement

Ip, see identity protocol

Ip, see identity protocol statement

K, see constant function©�, see empty collection

©�, see empty statement

Π, see full collection

Π, see universal statement

Πg, see universal genuine statement⋂

, see arbitrary intersectionˆ⋂, see arbitrary statement-intersection

ˆ⋂g, see arb. genuine-stat.–intersection

⋃

, see arbitrary union∩, see binary intersectionµ

∩, see binary behavioural intersection

∩, see binary statement-intersection∪, see binary union∪, see binary statement-union

298

=⊃, see then⊂=, see when

r, see removed-fromr, see without⊂==⊃, see same6⊂==⊃, see other�, see complement◦, see sequential composition◦p, see sequential protocol composition◦, see sequential stat.-composition◦p, see sequential prot.-stat. composition|◦, see confrontation/, see over/p, see protocol-over

/, see statement-over

/p, see protocol-statement–over

/g, see genuine-statement–over

\, see under\p, see protocol-under

\, see statement-under

\p, see protocol-statement–under

\g, see genuine-statement–under

;, see ISpec–sequential-composition>, see domain>p, see protocol-domain<, see range<p, see protocol-range, see converse

*, see iterationn, see power♭, see flat♯, see sharp#a, see number-of++, see concatenationC| , see context expression, see constant lift˙, see strict unary lift, see loose binary lift, see loose unary lift, see output conditioner, see input conditioner

par , see carrier−>, see field selection

−>, see field selection

−>, see field selection

−>C, see carrierised field selection



−>call

, see ISpec-call<−−−−−, see functional on

>−−−−−, see type operator−−−−−>, see type operator−−−−−<, see type operator−−−−−◦, see cylindric-type operator−−−−−�, see type operator�−−−−−, see type operator◦−−−−−, see type operator−−−−−), see total on−−−−−(, see restricted to(−−−−−, see type operator)−−−−−, see type operator−−−−−, see combined type operator−−−, see set-forcer−−−−−|, see domain)−−−−−(, see bidirectional-type operator)−−−(, see bidirectional typing)∧∨

∧

∨

∧

∨(, see connection protocol<−−−|, see type<−−−|c, see continuous<−−−|g, see genuine<−−−|m, see monotonic<−−−|⋂, see fundamental theorem<−−−|⋃, see fundamental theorem≺−−−−−, see map≺−−−, see map◮, see spick⊲, see pick⊲♯, see constrained cylindric pack

⊲♭, see constrained cylindric pack

⊲p, see protocol-pick⊲, see statement-pick⊲p, see protocol-statement–pick◭, see spack⊳, see pack⊳p, see protocol-pack⊳, see statement-pack⊳p, see protocol-statement–pack⊳g, see genuine-statement–pack©⊳ M , see constrained cylindric pack<| , see aspect operator<| p, see protocol–aspect-operator<| , see statement–aspect-operator<| p, see protocol-stat.–aspect-operator

299

<| g, see genuine-stat.–aspect-operator∆, see doubling function©∆ , see cylindric-doubling function⊗, see cylindric product⊗M , see constrained cylindric product×, see cartesian product+, see cartesian sum∩+ , see conjoint sum⊛, see loose product∗, see loose product⋆, see connectional productµ, see least fixed pointν, see greatest fixed point©0 , see default tag©1 , see default tag©2 , see default tag©C , see component composition

©C , see stat.-component composition

©O , see override operator

©O , see statement-override operator

A, see attribute nameB, see suite behaviourC, see carrier recordG, see global stateI, see interface nameM, see method nameO, see object nameP, see parameter nameR, see role name2, see default tagB, see booleanII, see identifierN, see natural numberR, see real numberZZ, see integer number℘, see setF, see field nameP, see power relatorPTi, see introspectiveT, see traceV, see sequenceActionClause, see action-clause stat.actionClause, see action-clause stat.ActionInvariant, see action-invariant stat.actionInvariant, see action-invariant stat.AttributeType, see attribute-type stat.attributeType, see attribute-type stat.

bool, see primitive typecall, see callconst, see constraindark, see universal dark protocoldark, see universal stat.-dark stat.darkI, see dark modifydarkgI , see dark modifydmodify, see dark modifyfmodify, see field-modifyfmodify

C, see carrierised field-modify

fmodifyCD, see carrierised field-modify

globalState, see carrierhide, see hide

hide, see statement-hide

if B then S0 else S1, see if-then-elsein, see occurs-inInterface, see interface statementinterface, see interface statementint, see primitive typeMethod, see method statementmethod, see method statementmodify, see modifymodifyD, see declared variableobject, see primitive typeparameters, see carrierParametersType, see param.-type stat.parametersType, see param.-type stat.pmodify, see pointer-modifyPost, see post statementpost, see post statementPostCondition, see post-condition stat.postCondition, see post-condition stat.PostInvariant, see post-invariant stat.postInvariant, see post-invariant stat.Pre, see pre statementpre, see pre statementPreCondition, see pre-condition stat.preCondition, see pre-condition stat.result, see carrierResultType, see result-type statementresultType, see result-type statementRole, see role statementrole, see role statementRoleInvariant, see role-invariant stat.roleInvariant, see role-invariant stat.show, see showshow, see statement-showsmodify, see spec-modify

300

spec, see specspec, see statement-specspecg, see genuine-statement–specStateInvariant, see state-invariant stat.stateInvariant, see state-invariant stat.Suite, see suite statementsuite, see suite statementthis, see carriervoid, see primitive typewhile B do S, see whileglobalState, see carrierparameters, see carrierresult, see carrierthis, see carrierDEQ , see domain equaleverywhere , see everywhereex i, see projection functionFUN , see constrained cylindric productFIXES , see fixed-point-of relationIC , see ISpec carrierin i, see injection functionNMP , see constrained cylindric productRESB, see constrained cylindric productRno, see range owningsomewhere , see somewhereTAGB, see constrained cyl. productTOTB, see constrained cyl. productUNI , see constrained cyl. product

abide, 60abort, 165abstract class, 3abstract metaclass, 4action clause, 150action invariant, 7, 166action-clause statement, 253, 255action-invariant statement, 253, 257activation specification, 29adjoint

lower, 61upper, 61

all-contained-by, 210antecedent, 123anti-monomorph, 57

in an argument, 57anti-monotonic, 57

in an argument, 57anti-symmetric, 56

application, 34, 36, 37arbitrary cartesian sum, 111arbitrary constrained cyl. product, 110arbitrary genuine-stat.–intersection, 249arbitrary intersection, 49arbitrary statement-intersection, 249arbitrary union, 49argument, 36aspect, 161aspect operator, 161aspect-oriented programming, 161assignment, 128, 147, 239associative, 58assumption, 44attribute, 18, 240attribute name, 240attribute-type statement, 253, 258axiom of choice, 44

base, 12behaviour of a program, 175behavioural refinement, 183, 190behavioural subtyping, 26bidirectional, 73bidirectional typing, 74bidirectional-type operator, 77binary behavioural intersection, 187binary cartesian product, 91binary cartesian sum, 93binary constrained cylindric product, 94binary cylindric product, 92binary intersection, 47binary loose product, 113binary predicate, 38binary restricted loose product, 114binary statement-intersection, 176binary statement-union, 176binary union, 47black-box semantics, 29BNF-notation, 117body, 155boolean, 31, 32, 39

call, 17, 175, 177call depth, 28call expansion, 179call statement, 24cancellation, 61, 98, 99

301

canonical behaviour, 175carrier, 243carrier name, 243carrier record, 243, 252carrier value, 243carrierised field selection, 244carrierised field-modify, 244cartesian product

binary, 91cartesian sum

arbitrary, 111binary, 93

chain, 60child, 12choice function, 44class, 155closed

subcollection, 57supercollection, 57

co/contra-variance rule, 73coarse specification, 137collection, 32collection comprehension, 41collection enumeration, 41collection-comprehension operator, 130combined type operator, 77combining suites, 12communication, 17commutation, 59commutative, 58comparability of collections, 60complement, 48completeness, 139component, 158component composition, 158, 188component-oriented programming, 158comprehension

collection, 41function, 42

mirrored, 42relation, 42set, 42

comprehension operatorcollection-, 130set-, 131

computation, 64concatenation, 210concrete metaclass, 4

confrontation, 68conjoint, 58conjoint sum, 111conjunction, 31connect output with input, 33connection, 33connection pattern, 212connection protocol, 213connection trace, 211connection-protocol picture, 213connection-trace picture, 212connectional expression, 132connectional product, 66consequence, 31conservative extension, 27, 204conservative user, 201conservativity rule, 204constant expression, 119constant function, 52, 53constant lift, 119constrain, 177constrained cylindric pack, 96constrained cylindric product


constraint, 94constructor, 165contain, 33context, 117, 178context expression, 119context preserving, 179continuity preserving, 226continuous, 60contravariant, 75converse, 51correct

partially, 139totally, 168

covariant, 75cylindric product

binary, 92constrained


cylindric typing, 74cylindric view, 20cylindric-doubling function, 125cylindric-type operator, 75

302

cylindric-type rule, 74

dark modify, 259, 260dark protocol, 215datatype-induction principle, 165declarative, 150declared attribute, 242declared interface, 259declared variable, 237decomposition, 160Dedekind, 69default tag, 32, 39define, 34defined, 121definition, 34denotational semantics, 23, 118dependency, 161dependency relation, 198dependent typing, 39depth of a trace, 224Desargues, 69diagonal preserving, 87direct instance, 4directed graph, 34disjoint, 58disjoint sum, 111disjoint-type rule, 127disjunction, 31distribution, 59

half-, 69domain, 51, 77

lower, 51upper, 51

domain equal, 58domain part, 42domain-equality relation, 58domain-inclusion, 167domain-split type rule, 126dot matrix, 34doubling function, 53dummy part, 42dynamic binding, 30

element, 32element-of, 38element-of relation, 39empty, 54empty collection, 48

empty in, 34empty on, 82empty relation, 48empty sequence, 210empty set, 48empty statement, 176enumeration

collection, 41relation, 41set, 41

equality, 32, 46equality relation, 38equivalence, 31everywhere, 53excluded interface, 22, 257existence of a variable, 236existence of an object, 19existential quantification, 31expression, 117

connectional, 132semantic, 117syntactic, 117

expression operatorloose binary, 120loose unary, 121strict unary, 119

extensibility, 73, 78extension of a suite, 25external type, 39external type system, 39

factory, 165Feijen notation, 44field, 18, 240field expression, 24field name, 240field selection, 241field value, 240field-modify, 242final global state, 18fine specification, 137fix notation, 36fixed point, 63

greatest, 63least, 63

fixed-point-of relation, 72flat, 62full, 54

303

full collection, 48full in, 35full on, 82full relation, 48function, 35function comprehension, 42

mirrored, 42functional, 35, 55functional in, 35functional on, 76fundamental theorem, 62fusion, 64

Galois connection, 61genuine, 224genuine-statement–aspect-operator, 250genuine-statement–over, 248genuine-statement–pack, 225genuine-statement–spec, 225genuine-statement–under, 248genuineness preserving, 224global state, 18, 240, 243greatest fixed point, 63greatest–fixed-point operator, 63guard, 143

half-distribution, 69hide, 233history invariant, 163Hoare logic, 139

idempotent, 58identifier, 32, 39identity protocol, 214identity protocol statement, 219identity relation, 50identity statement, 176if-then-else, 143implementation inheritance, 207implication, 31implicit typing, 39inclusion, 46independent part, 193indirect equality, 46indirect inequality, 46induction, 64infinite loop, 144infix notation, 36information preserving, 100, 110

inheritance, 13, 164syntactic, 16

initial global state, 18initialiser, 165injection function, 93injective, 55inner class, 155input, 33, 211input condition, 56input conditioner, 133input type, 75instance of a metaclass, 4integer number, 32, 39interaction, 3interaction pattern, 3interface, 18interface name, 252interface statement, 253, 254internal type, 39intersection


introspective, 223introspectivity preserving, 223invariant, 163invisible call, 185irreflexive, 56is-behavioural-refinement-of, 183, 190is-contained-by, 33is-element-of, 38is-equal-to, 38, 46is-override-of, 159is-owner-of, 38is-refinement-of, 160is-statement-override-of, 188is-statement-refinement-of, 190is-subcollection-of, 46is-supercollection-of, 46is-total-behavioural-refinement-of, 199is-total-refinement-of, 167, 171is-total-statement-refinement-of, 199isolation lemma, 195ISpec carrier, 252ISpec metamodel, 4ISpec operator, 251ISpec–sequential-composition, 259ISpec-call, 261iteration, 51

304

leapfrog, 52least fixed point, 63least–fixed-point operator, 63left-unit, 59left-zero, 59length of a sequence, 209lift

constant, 119loose binary, 120loose unary, 121strict unary, 119

lift operator, 178loop invariant, 142loose binary expression operator, 120loose binary lift, 120loose product, 113loose unary expression operator, 121loose unary lift, 121lower adjoint, 61lower domain, 51lower range, 51

main, 29, 165map, 235meaning of a suite, 25metaclass, 4metamodel, 4method, 18, 155method name, 252method statement, 253, 254mirrored function comprehension, 42modify, 236modify statement, 24monomorph, 57

anti-, 57in an argument, 57

monotonic, 57, 64anti-, 57in an argument, 57

monotonicity preserving, 177, 179multiple-argument relation, 36

name, 155natural number, 32, 39negated binary predicate, 38negation, 31new state, 236new value, 236

node, 211node element, 210node trace, 210non-determinism, 118non-empty, 54non-full, 54non-strict, 43null, 236number

integer, 32natural, 32real, 32

number-of, 210

object, 3, 18, 240object name, 240observation sequence, 212observer, 3observer pattern, 3, 13occurs-in, 210old state, 236old value, 236operational, 151order

partial, 56other, 48output, 33, 211output condition, 56output conditioner, 133output type, 75over, 50override, 159override operator, 189overriding, 26owner-of, 38owner-of relation, 39

pack, 155package, 96, 155pair, 36pair algebra, 72parameter, 18, 243parameter name, 245parameter record, 245parameter value, 245parameters-type statement, 253, 257parent, 12part

305

domain, 42dummy, 42range, 42

partial correctness, 139partial order, 56, 82partial refinement, 27, 137partial-correctness operator, 139partial-correctness rule, 139partiality, 118partially correct, 139pick, 96ping-pong, 69playing a role, 22plug pattern, 5point free, 45point to, 237point wise, 45pointer, 237pointer-assignment, 240pointer-modify, 237polymorphism, 39poset, 248post, 138post invariant, 7, 166post statement, 253, 255post-condition, 150post-condition statement, 253, 255post-invariant statement, 253, 258post-type, 150postfix notation, 36postfix point, 64power, 52power relator, 65pre, 138pre statement, 253, 256pre-condition, 150pre-condition statement, 253, 256pre-type, 150predicate, 37predicate calculus, 31prefix notation, 36prefix point, 64preorder, 56, 82primitive type, 258procedure, 155product

arbitrary constrained cylindric, 110binary constrained cylindric, 94

cartesianbinary, 91

cylindricbinary, 92

loose, 113program, 175projection function, 91proof, 44proof step, 44proper, 121propositional operator, 31protocol, 213protocol program, 219protocol statement, 219protocol–aspect-operator, 250protocol-domain, 214protocol-over, 247protocol-pack, 215protocol-pick, 215protocol-range, 214protocol-statement operator, 219protocol-statement–aspect-operator, 250protocol-statement–over, 248protocol-statement–pack, 220protocol-statement–pick, 220protocol-statement–under, 248protocol-under, 247

quantificationexistential, 31universal, 31

range, 51lower, 51upper, 51

range owning, 87range part, 42re-entrance, 22real number, 32, 39recursion, 175refinement, 137, 160refinement relation, 137reflexive, 56, 82relation, 33relation comprehension, 42relation enumeration, 41relation-comprehension operator, 132relator, 66

306

removed-from, 47restricted to, 76result, 18, 243result-type statement, 253, 256return, 17right-unit, 59right-zero, 59role, 3, 18role invariant, 7role name, 252role statement, 253, 254role-invariant statement, 253, 257root element, 210

same, 48section, 37selection, 235self, 19, 243semantic expression, 117semantic inheritance, 26semantics, 117

denotational, 118semantics function, 117semi-commutative diagram, 81sequence, 209sequential composition, 24, 50sequential prot.-stat. composition, 219sequential protocol composition, 214sequential statement-composition, 176set, 38, 40, 55set comprehension, 42set enumeration, 41set-comprehension operator, 131set-conjoint, 58set-forcer, 78set-preserving, 77shape, 118sharp, 62show, 215shunting, 67, 82, 133signature, 20, 262simple prot.-stat.–refinement rule, 229simple protocol-refinement rule, 218simple refinement rule, 183single connection, 55single element, 55single input, 55single output, 55

single-valued, 35single-valued in, 35single-valued on, 76single-valued semantics, 43single-valuedness type rules, 126singleton set, 96somewhere, 53spack, 52spec, 216spec-modify, 260specialising suites, 12, 25specification, 137spick, 52square, 56square rule, 181state, 163, 236state invariant, 7, 163state-invariant condition, 166state-invariant statement, 253, 258state-invariant type, 166statement, 175statement operator, 176statement–aspect-operator, 250statement–visual-indep. extraction, 220statement–visual-independent, 220statement-component composition, 188statement-dark, 220statement-hide, 234statement-inclusion, 176statement-intersection


statement-monotonic, 179statement-over, 247statement-override, 188statement-override operator, 189statement-pack, 177statement-pick, 177statement-refinement, 182, 190statement-show, 220statement-spec, 220statement-under, 247statement-union

binary, 176strict unary expression operator, 119strict unary lift, 119structural hierarchy, 155structure of a suite, 20

307

subclass, 4subcollection, 46subcollection closed, 57subcollection-of, 46subcollection-of relation, 46subject, 3subrelation, 46subset, 46substitutability, 204substitution, 128suite, 3suite behaviour, 252suite diagram, 4suite statement, 251, 253, 254sum

cartesianarbitrary, 111binary, 93

conjoint, 111arbitrary, 111binary, 111

supercollection, 46supercollection closed, 57supercollection-of, 46supercollection-of relation, 46superrelation, 46superset, 46supported procedure, 164surjective, 55symmetric, 56syntactic expression, 117syntactic inheritance, 16, 26syntactic subexpression, 127syntax, 117

tag, 93, 96then, 47theorem lifting, 128, 178this, 19, 243total, 35, 55total behavioural refinement, 199total correctness, 168total decomposition, 172total in, 35total on, 76total protocol refinement, 219total refinement, 27, 167, 171total statement-refinement, 199

total-correctness operator, 168total-correctness rule, 168totality, 166totality rules, 167totally correct, 168trace, 17, 210trace sequence, 17transitive, 56tree picture, 211tuple, 36, 41type, 39

external, 39input, 75internal, 39output, 75

type diagram, 79type operator, 75, 80

combined, 77cylindric-, 75

typingbidirectional, 74cylindric, 74

under, 50undirected bipartite graph, 34unidirectional, 74union


unique connection, 55unique element, 55unique input, 55unique output, 55unit, 59universal dark protocol, 215universal genuine statement, 225universal quantification, 31universal set, 40universal statement, 176universal statement-dark statement, 220upper adjoint, 61upper domain, 51upper range, 51

value, 236variable, 117, 236variable name, 117, 236variable value, 117, 236

308

visible call, 185visual, 210visual independent, 216visual-independent extraction, 217

well-founded, 144when, 47while, 143white-box semantics, 29without, 47

zero, 59

309

Titles in the IPA Dissertation Series

J.O. Blanco. The State Operator in Process

Algebra. Faculty of Mathematics and Comput-ing Science, TUE. 1996-01

A.M. Geerling. Transformational Develop-

ment of Data-Parallel Algorithms. Facultyof Mathematics and Computer Science, KUN.1996-02

P.M. Achten. Interactive Functional Pro-

grams: Models, Methods, and Implementation.Faculty of Mathematics and Computer Science,KUN. 1996-03

M.G.A. Verhoeven. Parallel Local Search.Faculty of Mathematics and Computing Sci-ence, TUE. 1996-04

M.H.G.K. Kesseler. The Implementation

of Functional Languages on Parallel Machines

with Distrib. Memory. Faculty of Mathematicsand Computer Science, KUN. 1996-05

D. Alstein. Distributed Algorithms for Hard

Real-Time Systems. Faculty of Mathematicsand Computing Science, TUE. 1996-06

J.H. Hoepman. Communication, Synchro-

nization, and Fault-Tolerance. Faculty ofMathematics and Computer Science, UvA.1996-07

H. Doornbos. Reductivity Arguments and

Program Construction. Faculty of Mathemat-ics and Computing Science, TUE. 1996-08

D. Turi. Functorial Operational Semantics

and its Denotational Dual. Faculty of Mathe-matics and Computer Science, VUA. 1996-09

A.M.G. Peeters. Single-Rail Handshake

Circuits. Faculty of Mathematics and Com-puting Science, TUE. 1996-10

N.W.A. Arends. A Systems Engineering

Specification Formalism. Faculty of Mechan-ical Engineering, TUE. 1996-11

P. Severi de Santiago. Normalisation in

Lambda Calculus and its Relation to Type In-

ference. Faculty of Mathematics and Comput-ing Science, TUE. 1996-12

D.R. Dams. Abstract Interpretation and

Partition Refinement for Model Checking.Faculty of Mathematics and Computing Sci-ence, TUE. 1996-13

M.M. Bonsangue. Topological Dualities in

Semantics. Faculty of Mathematics and Com-puter Science, VUA. 1996-14

B.L.E. de Fluiter. Algorithms for Graphs of

Small Treewidth. Faculty of Mathematics andComputer Science, UU. 1997-01

W.T.M. Kars. Process-algebraic Transfor-

mations in Context. Faculty of Computer Sci-ence, UT. 1997-02

P.F. Hoogendijk. A Generic Theory of Data

Types. Faculty of Mathematics and Comput-ing Science, TUE. 1997-03

T.D.L. Laan. The Evolution of Type Theory

in Logic and Mathematics. Faculty of Mathe-matics and Computing Science, TUE. 1997-04

C.J. Bloo. Preservation of Termination for

Explicit Substitution. Faculty of Mathematicsand Computing Science, TUE. 1997-05

J.J. Vereijken. Discrete-Time Process Alge-

bra. Faculty of Mathematics and ComputingScience, TUE. 1997-06

F.A.M. van den Beuken. A Functional Ap-

proach to Syntax and Typing. Faculty of Math-ematics and Informatics, KUN. 1997-07

A.W. Heerink. Ins and Outs in Refusal Test-

ing. Faculty of Computer Science, UT. 1998-01

G. Naumoski and W. Alberts. A

Discrete-Event Simulator for Systems Engi-

neering. Faculty of Mechanical Engineering,TUE. 1998-02

J. Verriet. Scheduling with Communica-

tion for Multiprocessor Computation. Faculty

of Mathematics and Computer Science, UU.1998-03

J.S.H. van Gageldonk. An Asynchronous

Low-Power 80C51 Microcontroller. Faculty ofMathematics and Computing Science, TUE.1998-04

A.A. Basten. In Terms of Nets: System De-

sign with Petri Nets and Process Algebra. Fac-ulty of Mathematics and Computing Science,TUE. 1998-05

E. Voermans. Inductive Datatypes with Laws

and Subtyping – A Relational Model. Facultyof Mathematics and Computing Science, TUE.1999-01

H. ter Doest. Towards Probabilistic

Unification-based Parsing. Faculty of Com-puter Science, UT. 1999-02

J.P.L. Segers. Algorithms for the Simulation

of Surface Processes. Faculty of Mathematicsand Computing Science, TUE. 1999-03

C.H.M. van Kemenade. Recombinative

Evolutionary Search. Faculty of Mathematicsand Natural Sciences, UL. 1999-04

E.I. Barakova. Learning Reliability: a Study

on Indecisiveness in Sample Selection. Facultyof Mathematics and Natural Sciences, RUG.1999-05

M.P. Bodlaender. Scheduler Optimization

in Real-Time Distributed Databases. Facultyof Mathematics and Computing Science, TUE.1999-06

M.A. Reniers. Message Sequence Chart:

Syntax and Semantics. Faculty of Mathemat-ics and Computing Science, TUE. 1999-07

J.P. Warners. Nonlinear approaches to satis-

fiability problems. Faculty of Mathematics andComputing Science, TUE. 1999-08

J.M.T. Romijn. Analysing Industrial Pro-

tocols with Formal Methods. Faculty of Com-puter Science, UT. 1999-09

P.R. D’Argenio. Algebras and Automata

for Timed and Stochastic Systems. Faculty ofComputer Science, UT. 1999-10

G. Fabian. A Language and Simulator for

Hybrid Systems. Faculty of Mechanical Engi-neering, TUE. 1999-11

J. Zwanenburg. Object-Oriented Concepts

and Proof Rules. Faculty of Mathematics andComputing Science, TUE. 1999-12

R.S. Venema. Aspects of an Integrated Neu-

ral Prediction System. Faculty of Mathematicsand Natural Sciences, RUG. 1999-13

J. Saraiva. A Purely Functional Implementa-

tion of Attribute Grammars. Faculty of Math-ematics and Computer Science, UU. 1999-14

R. Schiefer. Viper, A Visualisation Tool

for Parallel Program Construction. Facultyof Mathematics and Computing Science, TUE.1999-15

K.M.M. de Leeuw. Cryptology and State-

craft in the Dutch Republic. Faculty of Math-ematics and Computer Science, UvA. 2000-01

T.E.J. Vos. UNITY in Diversity. A stratified

approach to the verification of distributed algo-

rithms. Faculty of Mathematics and ComputerScience, UU. 2000-02

W. Mallon. Theories and Tools for the De-

sign of Delay-Insensitive Communicating Pro-

cesses. Faculty of Mathematics and NaturalSciences, RUG. 2000-03

W.O.D. Griffioen. Studies in Computer

Aided Verification of Protocols. Faculty of Sci-ence, KUN. 2000-04

P.H.F.M. Verhoeven. The Design of the

MathSpad Editor. Faculty of Mathematics andComputing Science, TUE. 2000-05

J. Fey. Design of a Fruit Juice Blending and

Packaging Plant. Faculty of Mechanical Engi-neering, TUE. 2000-06

M. Franssen. Cocktail: A Tool for Deriv-

ing Correct Programs. Faculty of Mathematicsand Computing Science, TUE. 2000-07

P.A. Olivier. A Framework for Debugging

Heterogeneous Applications. Faculty of Natu-ral Sciences, Mathematics and Computer Sci-ence, UvA. 2000-08

E. Saaman. Another Formal Specification

Language. Faculty of Mathematics and Nat-ural Sciences, RUG. 2000-10

M. Jelasity. The Shape of Evolutionary

Search Discovering and Representing Search

Space Structure. Faculty of Mathematics andNatural Sciences, UL. 2001-01

R. Ahn. Agents, Objects and Events a com-

putational approach to knowledge, observation

and communication. Faculty of Mathematicsand Computing Science, TU/e. 2001-02

M. Huisman. Reasoning about Java pro-

grams in higher order logic using PVS and Is-

abelle. Faculty of Science, KUN. 2001-03

I.M.M.J. Reymen. Improving Design Pro-

cesses through Structured Reflection. Facultyof Mathematics and Computing Science, TU/e.2001-04

S.C.C. Blom. Term Graph Rewriting: syntax

and semantics. Faculty of Sciences, Divisionof Mathematics and Computer Science, VUA.2001-05

R. van Liere. Studies in Interactive Visual-

ization. Faculty of Natural Sciences, Mathe-matics and Computer Science, UvA. 2001-06

A.G. Engels. Languages for Analysis and

Testing of Event Sequences. Faculty of Mathe-matics and Computing Science, TU/e. 2001-07

J. Hage. Structural Aspects of Switching

Classes. Faculty of Mathematics and NaturalSciences, UL. 2001-08

M.H. Lamers. Neural Networks for Analy-

sis of Data in Environmental Epidemiology: A

Case-study into Acute Effects of Air Pollution

Episodes. Faculty of Mathematics and NaturalSciences, UL. 2001-09

T.C. Ruys. Towards Effective Model Check-

ing. Faculty of Computer Science, UT. 2001-10

D. Chkliaev. Mechanical verification of con-

currency control and recovery protocols. Fac-ulty of Mathematics and Computing Science,TU/e. 2001-11

M.D. Oostdijk. Generation and presentation

of formal mathematical documents. Faculty ofMathematics and Computing Science, TU/e.2001-12

A.T. Hofkamp. Reactive machine control: A

simulation approach using χ. Faculty of Me-chanical Engineering, TU/e. 2001-13

D. Bosnacki. Enhancing state space reduc-

tion techniques for model checking. Faculty ofMathematics and Computing Science, TU/e.2001-14

M.C. van Wezel. Neural Networks for In-

telligent Data Analysis: theoretical and exper-

imental aspects. Faculty of Mathematics andNatural Sciences, UL. 2002-01

V. Bos and J.J.T. Kleijn. Formal Spec-

ification and Analysis of Industrial Systems.Faculty of Mathematics and Computer Scienceand Faculty of Mechanical Engineering, TU/e.2002-02

T. Kuipers. Techniques for Understanding

Legacy Software Systems. Faculty of NaturalSciences, Mathematics and Computer Science,UvA. 2002-03

S.P. Luttik. Choice Quantification in Process

Algebra. Faculty of Natural Sciences, Mathe-matics, and Computer Science, UvA. 2002-04

R.J. Willemen. School Timetable Construc-

tion: Algorithms and Complexity. Facultyof Mathematics and Computer Science, TU/e.2002-05

M.I.A. Stoelinga. Alea Jacta Est: Verifica-

tion of Probabilistic, Real-time and Parametric

Systems. Faculty of Science, Mathematics andComputer Science, KUN. 2002-06

N. van Vugt. Models of Molecular Comput-

ing. Faculty of Mathematics and Natural Sci-ences, UL. 2002-07

A. Fehnker. Citius, Vilius, Melius: Guid-

ing and Cost-Optimality in Model Checking

of Timed and Hybrid Systems. Faculty ofScience, Mathematics and Computer Science,KUN. 2002-08

R. van Stee. On-line Scheduling and Bin

Packing. Faculty of Mathematics and NaturalSciences, UL. 2002-09

D. Tauritz. Adaptive Information Filtering:

Concepts and Algorithms. Faculty of Mathe-matics and Natural Sciences, UL. 2002-10

M.B. van der Zwaag. Models and Logics

for Process Algebra. Faculty of Natural Sci-ences, Mathematics, and Computer Science,UvA. 2002-11

J.I. den Hartog. Probabilistic Extensions of

Semantical Models. Faculty of Sciences, Di-vision of Mathematics and Computer Science,VUA. 2002-12

L. Moonen. Exploring Software Systems.Faculty of Natural Sciences, Mathematics, andComputer Science, UvA. 2002-13

J.I. van Hemert. Applying Evolutionary

Computation to Constraint Satisfaction and

Data Mining. Faculty of Mathematics andNatural Sciences, UL. 2002-14

S. Andova. Probabilistic Process Algebra.Faculty of Mathematics and Computer Science,TU/e. 2002-15

Y.S. Usenko. Linearization in µCRL. Fac-ulty of Mathematics and Computer Science,TU/e. 2002-16

J.J.D. Aerts. Random Redundant Storage

for Video on Demand. Faculty of Mathematicsand Computer Science, TU/e. 2003-01

M. de Jonge. To Reuse or To Be Reused:

Techniques for component composition and

construction. Faculty of Natural Sciences,Mathematics, and Computer Science, UvA.2003-02

J.M.W. Visser. Generic Traversal over

Typed Source Code Representations. Facultyof Natural Sciences, Mathematics, and Com-puter Science, UvA. 2003-03

S.M. Bohte. Spiking Neural Networks. Fac-ulty of Mathematics and Natural Sciences, UL.2003-04

T.A.C. Willemse. Semantics and Verifica-

tion in Process Algebras with Data and Tim-

ing. Faculty of Mathematics and ComputerScience, TU/e. 2003-05

S.V. Nedea. Analysis and Simulations of

Catalytic Reactions. Faculty of Mathematicsand Computer Science, TU/e. 2003-06

M.E.M. Lijding. Real-time Scheduling of

Tertiary Storage. Faculty of Electrical En-gineering, Mathematics & Computer Science,UT. 2003-07

H.P. Benz. Casual Multimedia Process An-

notation – CoMPAs. Faculty of Electrical En-gineering, Mathematics & Computer Science,UT. 2003-08

D. Distefano. On Modelchecking the Dynam-

ics of Object-based Software: a Foundational

Approach. Faculty of Electrical Engineering,Mathematics & Computer Science, UT. 2003-09

M.H. ter Beek. Team Automata – A Formal

Approach to the Modeling of Collaboration Be-

tween System Components. Faculty of Mathe-matics and Natural Sciences, UL. 2003-10

D.J.P. Leijen. The λ Abroad – A Functional

Approach to Software Components. Facultyof Mathematics and Computer Science, UU.2003-11

W.P.A.J. Michiels. Performance Ratios for

the Differencing Method. Faculty of Mathe-matics and Computer Science, TU/e. 2004-01

G.I. Jojgov. Incomplete Proofs and Terms

and Their Use in Interactive Theorem Prov-

ing. Faculty of Mathematics and ComputerScience, TU/e. 2004-02

P. Frisco. Theory of Molecular Computing

– Splicing and Membrane systems. Faculty ofMathematics and Natural Sciences, UL. 2004-03

S. Maneth. Models of Tree Translation. Fac-ulty of Mathematics and Natural Sciences, UL.2004-04

Y. Qian. Data Synchronization and Brows-

ing for Home Environments. Faculty of Math-ematics and Computer Science and Faculty ofIndustrial Design, TU/e. 2004-05

F. Bartels. On Generalised Coinduction and

Probabilistic Specification Formats. Faculty ofSciences, Division of Mathematics and Com-puter Science, VUA. 2004-06

L. Cruz-Filipe. Constructive Real Analysis:

a Type-Theoretical Formalization and Appli-

cations. Faculty of Science, Mathematics andComputer Science, KUN. 2004-07

E.H. Gerding. Autonomous Agents in Bar-

gaining Games: An Evolutionary Investiga-

tion of Fundamentals, Strategies, and Business

Applications. Faculty of Technology Manage-ment, TU/e. 2004-08

N. Goga. Control and Selection Techniques

for the Automated Testing of Reactive Sys-

tems. Faculty of Mathematics and ComputerScience, TU/e. 2004-09

M. Niqui. Formalising Exact Arithmetic:

Representations, Algorithms and Proofs. Fac-ulty of Science, Mathematics and ComputerScience, RU. 2004-10

A. Loh. Exploring Generic Haskell. Facultyof Mathematics and Computer Science, UU.2004-11

I.C.M. Flinsenberg. Route Planning Algo-

rithms for Car Navigation. Faculty of Mathe-matics and Computer Science, TU/e. 2004-12

R.J. Bril. Real-time Scheduling for Me-

dia Processing Using Conditionally Guaran-

teed Budgets. Faculty of Mathematics andComputer Science, TU/e. 2004-13

J. Pang. Formal Verification of Distributed

Systems. Faculty of Sciences, Division ofMathematics and Computer Science, VUA.2004-14

F. Alkemade. Evolutionary Agent-Based

Economics. Faculty of Technology Manage-ment, TU/e. 2004-15

E.O. Dijk. Indoor Ultrasonic Position Esti-

mation Using a Single Base Station. Facultyof Mathematics and Computer Science, TU/e.2004-16

S.M. Orzan. On Distributed Verification and

Verified Distribution. Faculty of Sciences, Di-vision of Mathematics and Computer Science,VUA. 2004-17

M.M. Schrage. Proxima - A Presentation-

oriented Editor for Structured Documents.Faculty of Mathematics and Computer Science,UU. 2004-18

E. Eskenazi and A. Fyukov. Quanti-

tative Prediction of Quality Attributes for

Component-Based Software Architectures.Faculty of Mathematics and Computer Sci-ence, TU/e. 2004-19

P.J.L. Cuijpers. Hybrid Process Algebra.Faculty of Mathematics and Computer Science,TU/e. 2004-20

N.J.M. van den Nieuwelaar. Supervi-

sory Machine Control by Predictive-Reactive

Scheduling. Faculty of Mechanical Engineer-ing, TU/e. 2004-21

E. Abraham. An Assertional Proof Sys-

tem for Multithreaded Java -Theory and Tool

Support- . Faculty of Mathematics and Natu-ral Sciences, UL. 2005-01

R. Ruimerman. Modeling and Remodeling

in Bone Tissue. Faculty of Biomedical Engi-neering, TU/e. 2005-02

C.N. Chong. Experiments in Rights Con-

trol - Expression and Enforcement. Faculty ofElectrical Engineering, Mathematics & Com-puter Science, UT. 2005-03

H. Gao. Design and Verification of Lock-free

Parallel Algorithms. Faculty of Mathematicsand Computing Sciences, RUG. 2005-04

H.M.A. van Beek. Specification and Analy-

sis of Internet Applications. Faculty of Mathe-matics and Computer Science, TU/e. 2005-05

M.T. Ionita. Scenario-Based System Archi-

tecting - A Systematic Approach to Developing

Future-Proof System Architectures. Faculty ofMathematics and Computing Sciences, TU/e.2005-06

G. Lenzini. Integration of Analysis Tech-

niques in Security and Fault-Tolerance. Fac-ulty of Electrical Engineering, Mathematics &Computer Science, UT. 2005-07

I. Kurtev. Adaptability of Model Transforma-

tions. Faculty of Electrical Engineering, Math-ematics & Computer Science, UT. 2005-08

T. Wolle. Computational Aspects of

Treewidth - Lower Bounds and Network Re-

liability. Faculty of Science, UU. 2005-09

O. Tveretina. Decision Procedures for

Equality Logic with Uninterpreted Functions.Faculty of Mathematics and Computer Science,TU/e. 2005-10

A.M.L. Liekens. Evolution of Finite Popu-

lations in Dynamic Environments. Faculty ofBiomedical Engineering, TU/e. 2005-11

J. Eggermont. Data Mining using Genetic

Programming: Classification and Symbolic Re-

gression. Faculty of Mathematics and NaturalSciences, UL. 2005-12

B.J. Heeren. Top Quality Type Error Mes-

sages. Faculty of Science, UU. 2005-13

G.F. Frehse. Compositional Verification of

Hybrid Systems using Simulation Relations.

Faculty of Science, Mathematics and Com-puter Science, RU. 2005-14

M.R. Mousavi. Structuring Structural Op-

erational Semantics. Faculty of Mathematicsand Computer Science, TU/e. 2005-15

A. Sokolova. Coalgebraic Analysis of Proba-

bilistic Systems. Faculty of Mathematics andComputer Science, TU/e. 2005-16

T. Gelsema. Effective Models for the Struc-

ture of pi-Calculus Processes with Replication.Faculty of Mathematics and Natural Sciences,UL. 2005-17

P. Zoeteweij. Composing Constraint Solvers.Faculty of Natural Sciences, Mathematics, andComputer Science, UvA. 2005-18

J.J. Vinju. Analysis and Transformation of

Source Code by Parsing and Rewriting. Fac-ulty of Natural Sciences, Mathematics, andComputer Science, UvA. 2005-19

M.Valero Espada. Modal Abstraction and

Replication of Processes with Data. Faculty ofSciences, Division of Mathematics and Com-puter Science, VUA. 2005-20

A. Dijkstra. Stepping through Haskell. Fac-ulty of Science, UU. 2005-21

Y.W. Law. Key management and link-layer

security of wireless sensor networks: energy-

efficient attack and defense. Faculty of Elec-trical Engineering, Mathematics & ComputerScience, UT. 2005-22

E. Dolstra. The Purely Functional Software

Deployment Model. Faculty of Science, UU.2006-01

R.J. Corin. Analysis Models for Security

Protocols. Faculty of Electrical Engineering,Mathematics & Computer Science, UT. 2006-02

P.R.A. Verbaan. The Computational Com-

plexity of Evolving Systems. Faculty of Sci-ence, UU. 2006-03

K.L. Man and R.R.H. Schiffelers. Formal

Specification and Analysis of Hybrid Systems.Faculty of Mathematics and Computer Scienceand Faculty of Mechanical Engineering, TU/e.2006-04

M. Kyas. Verifying OCL Specifications of

UML Models: Tool Support and Composition-

ality. Faculty of Mathematics and Natural Sci-ences, UL. 2006-05

M. Hendriks. Model Checking Timed Au-

tomata - Techniques and Applications. Fac-ulty of Science, Mathematics and ComputerScience, RU. 2006-06

J. Ketema. Bohm-Like Trees for Rewriting.Faculty of Sciences, VUA. 2006-07

C.-B. Breunesse. On JML: topics in tool-

assisted verification of JML programs. Fac-ulty of Science, Mathematics and ComputerScience, RU. 2006-08

B. Markvoort. Towards Hybrid Molecular

Simulations. Faculty of Biomedical Engineer-ing, TU/e. 2006-09

S.G.R. Nijssen. Mining Structured Data.Faculty of Mathematics and Natural Sciences,UL. 2006-10

G. Russello. Separation and Adaptation of

Concerns in a Shared Data Space. Facultyof Mathematics and Computer Science, TU/e.2006-11

L. Cheung. Reconciling Nondeterministic

and Probabilistic Choices. Faculty of Sci-ence, Mathematics and Computer Science, RU.2006-12

B. Badban. Verification techniques for Ex-

tensions of Equality Logic. Faculty of Sciences,Division of Mathematics and Computer Sci-ence, VUA. 2006-13

A.J. Mooij. Constructive formal methods

and protocol standardization. Faculty of Math-ematics and Computer Science, TU/e. 2006-14

T. Krilavicius. Hybrid Techniques for Hy-

brid Systems. Faculty of Electrical Engineer-ing, Mathematics & Computer Science, UT.2006-15

M.E. Warnier. Language Based Security for

Java and JML. Faculty of Science, Mathemat-ics and Computer Science, RU. 2006-16

V. Sundramoorthy. At Home In Service

Discovery. Faculty of Electrical Engineering,Mathematics & Computer Science, UT. 2006-17

B. Gebremichael. Expressivity of Timed Au-

tomata Models. Faculty of Science, Mathemat-ics and Computer Science, RU. 2006-18

L.C.M. van Gool. Formalising Interface

Specifications. Faculty of Mathematics andComputer Science, TU/e. 2006-19