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
xvi
Make things as simple as possible, but not simpler.
Albert Einstein
xvii
xviii
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
HFillWith = method fillWith
<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
HEmpty = method empty
<>HEmResult<HEmEffect>
HEmResult = result valueType void
HEmEffect = effect HEmPreConditionHEmActionClauseHEmPostCondition
HEmPreCondition = preCondition hasPlug
HEmActionClause = actionClause modify{hasPlug, plug}
HEmPostCondition = postCondition ¬hasPlug
PInsertInto = method insertInto
<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
PRemove = method remove
<>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
IFill fillWith empty
IUpdate update
IInsert insertInto
remove
hasPlug : bool plug : Plug
Hole
inHole : bool hole : 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:
Trace ::= trace CallTrace∗Return
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”):
Trace ::= trace CallTrace∗Return
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
Trace ::= trace CallTrace∗Return
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:
Trace ::= trace CallTrace∗Return
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
IFill fillWith empty
IInsert insertInto remove
hasPlug : bool plug : Plug
Hole
inHole : bool hole : 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:
HEmpty = method empty
<>HEmResult<HEmEffect>
HEmResult = result valueType void
HEmEffect = effect HEmPreConditionHEmActionClauseHEmPostCondition
HEmPreCondition = preCondition hasPlug
HEmActionClause = actionClause modify{hasPlug, plug}
HEmPostCondition = postCondition ¬hasPlug
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.
3.4.1 Emptiness and fullness
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.
4.3.1 Emptiness and fullness
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
4.4.5 Sequential composition
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
4.4.6 Identity relation
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
90
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
5.4.6 Sequential composition
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〉
≡ {point-wise definition of⋂
}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
≡ {point-wise definition of⋂
}∀〈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〉
≡ {point-wise definition of⋂
}S (−⋂M−) Q
Putting everything together, we have proved that for eachM with
M ⊆ {UNI ,FUN ,NMP ,DEQ} ∪{TOTB | B ∈ ℘I | B}{RESB | B ∈ ℘I | B}
∪
the following abidence theorem holds:
R0◦T 0 ⊗M R1◦T 1
= {• M =⋂M}
R0⊗MR1 ◦ T 0⊗MT 1
5.4.7 Identity relation
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
M ⊆ {UNI ,FUN ,NMP ,DEQ} ∪{TOTB | B ∈ ℘I | B}{RESB | B ∈ ℘I | B}
∪
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
136
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
7.3.4 Sequential composition
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
7.3.6 Identity relation
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
= {left to the reader}
(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
174
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 = Π
8.2.4 Sequential composition
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]]
= {left to the reader}
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]]
n = const.[[C| ≥ C| ]] ◦ call⊲m
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
⇐ {• Z0 and Z1 are disjoint sets}
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
⇐ {• Z0 and Z1 are disjoint sets}
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
⇐ {• Z0 and Z1 are disjoint sets}
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)
≡ {definition ofµ
⊆}
µ(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
≡ {definition ofµ
⊆}
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 30) Z1∪Z30©C Z4
MATH 4}
(((MATH 1 Z1©C Z30
MATH 30) Z1∪Z30©C Z4
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]]
qc = c′⊳c ∩ d⊳d
c′ = const.[[C| = 3]]
qd = c⊳c ∩ d′⊳d
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
≡ {left to the reader}true
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)
≡ {definition ofµ
⊑}
µ(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
≡ {definition ofµ
⊑}
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
208
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.
9.2.1 Sequential composition
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]]
≡ {left to the reader}true
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.
9.5.1 Sequential composition
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
p1 = m⊳pm ∩ n1⊳pn
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)”:
p2 = m⊳pm ∩ n2⊳pn
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]]
n = const.[[C| ≥ C| ]] ◦ call⊲m
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
qc = c′⊳c ∩ d⊳d
c′ = const.[[C| = 3]]
d = const.[[C| ≥ 4]]
with program qd , defined by
231
qd = c⊳c ∩ d′⊳d
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.
11.2.18 Sequential composition
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:
IFill fillWith empty
IInsert insertInto remove
hasPlug : bool plug : Plug
Hole
inHole : bool hole : 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
HFillWith = method fillWith
<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
HEmpty = method empty
<>HEmResult<HEmEffect>
HEmResult = result valueType void
HEmEffect = effect HEmPreConditionHEmActionClauseHEmPostCondition
HEmPreCondition = preCondition hasPlug
HEmActionClause = actionClause modify{hasPlug, plug}
HEmPostCondition = postCondition ¬hasPlug
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
PInsertInto = method insertInto
<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
PRemove = method remove
<>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 −>
ChasPlug).c2 = false
(p −>CinHole) .c2 = true
(p −>Chole) .c2 = h
this .c1 = hppar .c1 = p(h −>
ChasPlug).c1 = true
(h −>Cplug) .c1 = p
(p −>CinHole) .c1 = true
(p −>Chole) .c1 = h
this .c0 = phpar .c0 = h(h −>
ChasPlug).c0 = true
(h −>Cplug) .c0 = p
(p −>CinHole) .c0 = true
(p −>Chole) .c0 = h
c2 (−fmodifyCPPA.{〈p, inHole 〉, 〈p, hole〉} −) c3
c1 (−fmodifyCPPA.{〈h, hasPlug〉, 〈h, plug〉}−) c2
c0 (−fmodifyCPPA.©� −) c1
c0 (−modifyIC .{globalState, result}−) c3
c1 (−modifyIC .{globalState, result}−) c2
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 ]}
PSInv2′ = {[this −>CinHole ⇒ (this −>
Chole) −>
Cplug = this]}
HSInv1′ = {[this −>ChasPlug ⇒ (this −>
Cplug) −>
CinHole ]}
HSInv2′ = {[this −>ChasPlug ⇒ (this −>
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
∧ ppar −>Chole = this]}
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
c1 (−modifyIC .{globalState, result}−) 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
IFill fillWith empty
IUpdate update
IInsert insertInto
remove
hasPlug : bool plug : Plug
Hole
inHole : bool hole : 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
s.hasPlug = true s.plug = o s.orig = x o.inHole = true o.hole = s o.copy = x
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 −>
ChasPlug).c5 = false
(s −>Corig) .c5 = x
(o −>CinHole) .c5 = false
this .c4 = sppar .c4 = o(s −>
ChasPlug).c4 = false
(s −>Corig) .c4 = x
(o −>CinHole) .c4 = true
(o −>Chole) .c4 = s
this .c3 = o(s −>
ChasPlug).c3 = true
(s −>Cplug) .c3 = o
(s −>Corig) .c3 = x
(o −>CinHole) .c3 = true
(o −>Chole) .c3 = s
this .c2 = o(s −>
ChasPlug).c2 = true
(s −>Cplug) .c2 = o
(s −>Corig) .c2 = x
(o −>CinHole) .c2 = true
(o −>Chole) .c2 = s
(o −>Ccopy) .c2 = x
this .c1 = sppar .c1 = o(s −>
ChasPlug).c1 = true
(s −>Cplug) .c1 = o
(s −>Corig) .c1 = x
(o −>CinHole) .c1 = true
(o −>Chole) .c1 = s
(o −>Ccopy) .c1 = x
278
this .c0 = ohpar .c0 = s(s −>
ChasPlug).c0 = true
(s −>Cplug) .c0 = o
(s −>Corig) .c0 = x
(o −>CinHole) .c0 = true
(o −>Chole) .c0 = s
(o −>Ccopy) .c0 = x
c4 (−fmodifyCOPA.{〈o, inHole〉, 〈o, hole〉} −) c5
c3 (−fmodifyCOPA.{〈s, hasPlug〉, 〈s, plug〉}−) c4
c2 (−fmodifyCOPA.{〈o, copy〉} −) c3
c1 (−fmodifyCOPA.©� −) c2
c0 (−fmodifyCOPA.©� −) c1
c0 (−modifyIC .{globalState, result}−) c5
c1 (−modifyIC .{globalState, result}−) c4
c2 (−modifyIC .{globalState, result}−) c3
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
PSInv1′ = {[this −>CinHole ⇒ (this −>
Chole) −>
ChasPlug]}
PSInv2′ = {[this −>CinHole ⇒ (this −>
Chole) −>
Cplug = this]}
OSInv ′ = {[this −>CinHole ⇒ this −>
Ccopy =
(this −>Chole) −>
Corig]}
HSInv1′ = {[this −>ChasPlug ⇒ (this −>
Cplug) −>
CinHole]}
HSInv2′ = {[this −>ChasPlug ⇒ (this −>
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
∧ ppar −>Chole = this]}
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
c5′ (−modifyIC .{globalState, result}−) c5
c4 (−fmodifyCOPA.©� −) c5
′
ppar .c4 = this.c5′
this.c4 = (this −>Chole).c5
′
c0 (−modifyIC .{globalState, result}−) c5′
c4′ (−fmodify
COPA.{〈this, hasPlug〉, 〈this, plug〉}−) c4
c4′ (−modifyIC .{globalState, result}−) c4
c3 (−fmodifyCOPA.©� −) c4
′
this.c3 = (this −>Cplug).c4
′
c1 (−modifyIC .{globalState, result}−) c4′
c2 (−fmodifyCOPA.{〈this, copy〉}−) c3
c2 (−modifyIC .{globalState, result}−) 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
292
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
−>C, see carrierised 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
arbitrary, 110binary, 94
constraint, 94constructor, 165contain, 33context, 117, 178context expression, 119context preserving, 179continuity preserving, 226continuous, 60contravariant, 75converse, 51correct
partially, 139totally, 168
covariant, 75cylindric product
binary, 92constrained
arbitrary, 110binary, 94
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
arbitrary, 49binary, 47
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
arbitrary, 249binary, 176
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
arbitrary, 49binary, 47
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