dines bjørner - dtu

Dines Bjørner

From Domains to Requirements

A Gentle Introduction to Domain Engineering 1

August 12, 2013: 08:17

i

Dines BjørnerFredsvej 11

DK–2840 HolteDenmark

[email protected]/˜dibj

• Assembly and writing of these lecture notes was begun on June 3, 2013.• They are composed primarily from either published or draft papers.• These lecture notes are paired with a set of lecture slides.• At present, August 12, 2013, the lecture notes comprise 125 pages and 650 slides.• The lecture notes additionally include approx. 50 pages of appendices: an RSL primer, several

domain examples and some indexes.• Margin-numbers in these lecture notes refer to slide numbers.

c© Dines Bjørner, 2013

August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark

Dedication

to Kari Skallerud Bjørner

Preface

In 2006 I published the 3 volume, approximately 2400 page, book Software Engineering ι1–ι3. In 2009Qinhua University Press, in agreement with Springer Verlag, republished these books, in English ι4–ι6,then in Chinese ι7–ι9.

In the years between 2006 and now I have lectured over these books and also rewritten major partsι10–ι13. I spent the year Feb. 2006–Jan. 2007 inclusive at JAIST∗. I used ι1–ι3 as the basis for mylectures there. A group of Chinese PhD students, led by (now) Dr. Liu BoChao, proposed to translatethe three volumes into Chinese. Dr. Liu completed this task – for which I owe him innumerable thanks.Around New Year 2008/2009 Prof. Kokichi Futatsugi, my host at JAIST, kindly asked me to editmy mostly technical reports written during my stay at JAIST in a form suitable for publication. Thatbecame [14].

There was one area of the Software Engineering which I have continued to research. It is thatof Domain Engineering ι15–ι25 in particular Domain Analysis. In addition to the above ten 2008–2013 publications I have experimentally developed a number of (unpublished) domain descriptions: forcontainer lines ι26, pipe lines ι27–ι28, financial services (stock exchanges) ι29, [road] transportationsystems ι30 and documents ι31 — to mention some.

During the spring and summer of 2013 I started on a series of domain science and engineering-related documents. First ι32, then the invited paper ι25 in which a summary of the domain analysisparts of ι32 forms a basis. That lead me to envisage a series of papers, all with an extract of ι32 as thebasis: ι33–ι37. Chapter 2 of this book is based on ι32. Chapter 3 on the second part of ι33. Chapter4 on the second parts of ι25 and ι35. Chapter 5 on the second part of ι36. Chapter 7 is based on ι16.Other chapters of this book are new. The writing of ι32–ι37 amounts to also completing this book.

I hope to be able to publish ι32–ι37, once sufficiently polished, during the next year while likewisehopefully using this book as a basis for PhD lectures around Europe.

ι1–ι9,ι14

∗ JAIST: Japan Advanced Institute of Science and Technology, Ishikawa Province, near Kanazawa, Japan

vi Preface

References

ι1. Software Engineering, Vol. 1: Abstraction andModelling. Texts in Theoretical Computer Sci-ence, the EATCS Series. Springer, 2006. .

ι2. Software Engineering, Vol. 2: Specification of Sys-tems and Languages. Texts in Theoretical Com-puter Science, the EATCS Series. Springer, 2006.Chapters 12–14 are primarily authored by Chris-tian Krog Madsen.

ι3. Software Engineering, Vol. 3: Domains, Require-ments and Software Design. Texts in TheoreticalComputer Science, the EATCS Series. Springer,2006.

ι4. Software Engineering, Vol. 1: Abstraction andModelling. Qinghua University Press, 2008.

ι5. Software Engineering, Vol. 2: Specification of Sys-tems and Languages. Qinghua University Press,2008.

ι6. Software Engineering, Vol. 3: Domains, Require-ments and Software Design. Qinghua UniversityPress, 2008.

ι7. Chinese: Software Engineering, Vol. 1: Abstrac-tion and Modelling. Qinghua University Press.Translated by Dr Liu Bo Chao et al., 2010.

ι8. Chinese: Software Engineering, Vol. 2: Specifica-tion of Systems and Languages. Qinghua Univer-sity Press. Translated by Dr Liu Bo Chao et al.,2010.

ι9. Chinese: Software Engineering, Vol. 3: Domains,Requirements and Software Design. Qinghua Uni-versity Press. Translated by Dr Liu Bo Chao et al.,2010.

ι10. Software Engineering: A Triptych Approach. In-ternet, Summer 2008. 610 pages. [Slightly in-complete draft version.: www.imm.dtu.dk/˜db/-tseb.pdf].

ι11. Domain Engineering. Internet, Summer 2008.469 pages. [Slightly incomplete draft version.:www.imm.dtu.dk/˜db/de-p.pdf].

ι12. From Domains to Requirements: The Triptych Ap-proach to Software Engineering. Internet, Sum-mer 2009. Slightly incomplete draft version, ap-proximately XXVII+160+25 pages (frontmatter,main text, appendices). [Click!: www.imm.dtu.-dk/˜db/de+re-p.pdf].

ι13. From Domains to Requirements: The Triptych Ap-proach. Internet, April 2010. Lecture notes coverthe first 150 pages of this 342 page compendium.[Slightly incomplete draft version: www.comp-lang.tuwien.ac.at/bjorner/book.pdf]. [See alsolong version of [15]: www.imm.dtu.dk/˜db/-from-domains-to-requirements.pdf] (includes for-mulas).

ι14. Domain Engineering: Technology Management,Research and Engineering. Research Monograph(# 4); JAIST Press, 1-1, Asahidai, Nomi, Ishikawa923-1292 Japan, March 2009. This ResearchMonograph contains the following main chapters:

(a) On Domains and On Domain Engineering –Prerequisites for Trustworthy Software – ANecessity for Believable Management, pages3–38.

(b) Possible Collaborative Domain Projects – AManagement Brief, pages 39–56.

(c) The Role of Domain Engineering in SoftwareDevelopment, pages 57–72.

(d) Verified Software for Ubiquitous Computing– A VSTTE Ubiquitous Computing ProjectProposal, pages 73–106.

(e) The Triptych Process Model – Process As-sessment and Improvement, pages 107–138.

(f) Domains and Problem Frames – The TriptychDogma and M.A.Jackson’s PF Paradigm,pages 139–175.

(g) Documents – A Rough Sketch Domain Anal-ysis, pages 179–200.

(h) Public Government – A Rough Sketch Do-main Analysis, pages 201–222.

(i) Towards a Model of IT Security — – TheISO Information Security Code of Practice –An Incomplete Rough Sketch Analysis, pages223–282.

(j) Towards a Family of Script Languages –– Licenses and Contracts – An IncompleteSketch, pages 283–328.

ι15. Domain Theory: Practice and Theories, Discus-sion of Possible Research Topics. In ICTAC’2007,volume 4701 of Lecture Notes in Computer Sci-ence (eds. J.C.P. Woodcock et al.), pages 1–17,Heidelberg, September 2007. Springer.

ι16. From Domains to Requirements. In MontanariFestschrift, volume 5065 of Lecture Notes in Com-puter Science (eds. Pierpaolo Degano, Rocco DeNicola and Jose Meseguer), pages 1–30, Heidel-berg, May 2008. Springer.

ι17. Compositionality: Ontology and Mereology of Do-mains. Some Clarifying Observations in the Con-text of Software Engineering in July 2008, eds.Martin Steffen, Dennis Dams and Ulrich Han-nemann. In Festschrift for Prof. Willem Paulde Roever Concurrency, Compositionality, andCorrectness, volume 5930 of Lecture Notes inComputer Science, pages 22–59, Heidelberg, July2010. Springer.

ι18. The Role of Domain Engineering in Software De-velopment. Why Current Requirements Engineer-ing Seems Flawed! In Perspectives of Systems In-formatics, volume 5947 of Lecture Notes in Com-puter Science, pages 2–34, Heidelberg, Wednes-day, January 27, 2010. Springer.

ι19. From Domains to Requirements — On a Triptychof Software Development. Research Report, Uni-versity of Edingburgh, November 2009.

ι20. Domain Engineering. In Paul Boca and JonathanBowen, editors, Formal Methods: State of the Art

c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17

Preface vii

and New Directions, Eds. Paul Boca and JonathanBowen, pages 1–42, London, UK, 2010. Springer.

ι21. Domain Science & Engineering – From ComputerScience to The Sciences of Informatics, Part I ofII: The Engineering Part. Kibernetika i sistemnyanaliz, (4):100–116, May 2010.

ι22. Domain Science & Engineering – From ComputerScience to The Sciences of Informatics Part II of II:The Science Part. Kibernetika i sistemny analiz,(2):100–120, May 2011.

ι23. Domains: Their Simulation, Monitoring and Con-trol – A Divertimento of Ideas and Suggestions.In Rainbow of Computer Science, Festschrift forHermann Maurer on the Occasion of His 70th An-niversary., Festschrift (eds. C. Calude, G. Rozen-berg and A. Saloma), pages 167–183. Springer,Heidelberg, Germany, January 2011.

ι24. A Role for Mereology in Domain Science and En-gineering. Synthese Library (eds. Claudio Calosiand Pierluigi Graziani). Springer, Amsterdam, TheNetherlands, May 2013.

ι25. Domain Analysis: Endurants – An Analysis & De-scription Process Model [Almost final draft] (pa-per: www.imm.dtu.dk/˜dibj/jaist-da.pdf., slides:www.imm.dtu.dk/˜dibj/jaist-s.pdf.). ResearchReport 2013-9, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, May 2013.

ι26. A Container Line Industry Domain. Techn. re-port, Fredsvej 11, DK-2840 Holte, Denmark, June2007. [Extensive Draft: www.imm.dtu.dk/˜db/-container-paper.pdf].

ι27. Pipe System Domain Models. Research 2012-2,DTU Informatics, May 2012.

ι28. Pipelines – a Domain Description: www.imm.dtu.-dk/˜dibj/pipe-p.pdf.. Experimental Research Re-port 2013-2, DTU Compute and Fredsvej 11, DK-2840 Holte, Denmark, Spring 2013.

ι29. The Tokyo Stock Exchange Trading Rules. R&DExperiment, Fredsvej 11, DK-2840 Holte, Den-mark, January, February 2010.

ι30. Road Transportation – a Domain Description:www.imm.dtu.dk/˜dibj/road-p.pdf.. Experimen-tal Research Report 2013-4, DTU Compute andFredsvej 11, DK-2840 Holte, Denmark, Spring2013.

ι31. Documents – a Domain Description: www.imm.-dtu.dk/˜dibj/doc-p.pdf.. Experimental ResearchReport 2013-3, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, Spring 2013.

ι32. Domain Analysis & Description: Endurants(paper: www.imm.dtu.dk/˜dibj/da-p.pdf. slides:www.imm.dtu.dk/˜dibj/da-s.pdf.). Research Re-port 2013-1, DTU Compute and Fredsvej 11, DK-2840 Holte, Denmark, April 2013.

ι33. Domain Analysis & Description: Perdu-rants [Writing to begin Summer 2013] (pa-per: www.imm.dtu.dk/˜dibj/perd-p.pdf., slides:www.imm.dtu.dk/˜dibj/perd-s.pdf.). ResearchReport 2013-7, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, Summer/Fall 2013. Afirst draft of this document might be written latesummer of 2013.

ι34. Domain Analysis: Endurants – An Analysis & De-scription Process Model [Almost final draft] (pa-per: www.imm.dtu.dk/˜dibj/jaist-da.pdf., slides:www.imm.dtu.dk/˜dibj/jaist-s.pdf.). ResearchReport 2013-9, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, May 2013.

ι35. Domain Analysis: Endurants – A Model ofPrompts [Early, incomplete draft] (paper:www.imm.dtu.dk/˜dibj/prompts-p.pdf., slides:www.imm.dtu.dk/˜dibj/prompts-s.pdf.). Re-search Report 2013-10, DTU Compute andFredsvej 11, DK-2840 Holte, Denmark, July 2013.

ι36. Domain Analysis & Description: ModellingFacets [Writing to begin Summer 2013] (pa-per: www.imm.dtu.dk/˜dibj/da-facets-p.pdf.,slides: www.imm.dtu.dk/˜dibj/da-facets-s.pdf.).Research Report 2013-7, DTU Compute andFredsvej 11, DK-2840 Holte, Denmark, Sum-mer/Fall 2013. A first draft of this documentmight be written late summer of 2013.

ι37. On Deriving Requirements from Domain Speci-fications [Writing to begin Summer 2013] (pa-per: www.imm.dtu.dk/˜dibj/da-fac-p.pdf., slides:www.imm.dtu.dk/˜dibj/da-fac-s.pdf.). ResearchReport 2013-8, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, Summer/Fall 2013. Afirst draft of this document might be written latesummer of 2013.

2


Contents

Part I Opening

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 The TripTych Approach to Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Domain Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.3 Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 An Example: Road Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Definitions of Auxiliary Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Some Derived Traffic System Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.2 Perdurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Whither Domain Science & Engineering ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Part II Domains

2 Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Formal Concept Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.1 A Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.2 Types Are Formal Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.3 Practicalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.4 Formal Concepts: A Wider Implication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Endurant Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.2 Endurants and Perdurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.3 Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.4 Atomic and Composite Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.5 On Observing Part Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Types and Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29On Discovering Part Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Part Sort Observer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29On Discovering Concrete Part Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Forms of Part Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Part Sort and Type Derivation Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Names of Part Sorts and Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

x Contents

More On Part Sorts and Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.6 Syntactic and Semantic Qualities of Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.7 Three Categories of Semantic Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.8 Unique Part Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.9 Discrete Endurant Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Inseparability of Attributes from Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Attribute Quality and Attribute Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Endurant Attributes: Types and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Attribute Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Shared Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Update of Dynamic Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.3.10 Mereology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Part Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Part Mereology: Types and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Update of Mereologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3.11 Materials: Continuous Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Material Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Materials-related Part Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Laws of Material Flows and Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.3.12 “No Junk, No Confusion” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.3.13 Discussion of Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.4 Comparison to Other Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.4.1 Ontological and Knowledge Engineering: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.4.2 Domain Analysis: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.4.3 Domain Specific Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.4.4 Feature-oriented Domain Analysis (FODA): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.5 Software Product Line Engineering: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.6 Problem Frames: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.7 Domain Specific Software Architectures (DSSA): . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.8 Domain Driven Design (DDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.9 Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3 Perdurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3 Actions, Events and Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3.1 Time Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3.3 Parts, Attributes and Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.4 Discrete Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.5 Discrete Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.6 Discrete Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6.1 Channels and Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6.2 Relations Between Attribute Sharing and Channels . . . . . . . . . . . . . . . . . . . . . . . . 59

3.7 Continuous Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.8 Perdurant Signatures and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.8.1 Function Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.8.2 Action Signatures and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.8.3 Event Signatures and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.8.4 Discrete Behaviour Signatures and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.9 Summary and Discussion of Perdurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.9.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.9.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


Contents xi

4 Models of Domain Anaysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 A Model of The Analysis & Description Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.1 A Summary of Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2.3 Initialising the Domain Analysis & Description Process . . . . . . . . . . . . . . . . . . . . 684.2.4 A Domain Analysis & Description State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2.5 Analysis & Description of Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Analysis & Description of Part Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Analysis & Description of Part Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Analysis & Description of Material Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Analysis & Description of Composite Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Analysis & Description of Concrete Sort Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Analysis & Description of Abstract Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Analysis & Description of Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Analysis & Description of Mereologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Analysis & Description of Part Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2.6 Discussion of The Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Axioms and Proof Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Order of Analysis & Description: A Meaning of ‘⊕’ . . . . . . . . . . . . . . . . . . . . . . . . 74Laws of Description Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3 A Model of The Analysis & Description Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.1 On the Domain Analyser’s Image of Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.2 An Abstract Syntax of Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Domain Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74The Root Domain Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Domain Description Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Well-formedness of Domain Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3.3 Node Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.3.4 Index of Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Analysis Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Description Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.3.5 A Formal Description of a Meaning of Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . 79The Iterative Nature of The Description Process . . . . . . . . . . . . . . . . . . . . . . . . . . 79How Are We Modelling the Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80The Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.4 Discussion of the Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1 Stake-holders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2 Domain Facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.2.1 Intrinsics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Conceptual Versus Actual Intrinsics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83On Modelling Intrinsics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2.2 Support Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84On Modelling Support Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.2.3 Management and Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Conceptual Analysis, First Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Methodological Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Conceptual Analysis, Second Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87On Modelling Management and Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.4 Rules and Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A Meta-characterisation of Rules and Regulations . . . . . . . . . . . . . . . . . . . . . . . . . 89On Modelling Rules and Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.5 Scripts and Licensing Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Licensing Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


xii Contents

On Modelling Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.2.6 Human Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A Meta-characterisation of Human Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93On Modelling Human Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2.7 Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2.8 Integrating Formal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.3 Closing Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6 Domain Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.1 Stages and Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.1.1 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.2 Stake-holder Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.3 Acquisition and Elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.4 Domain Analysis & Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.5 Description Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.1.6 Description Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2 Domain Theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.3 Domain Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Part III Requirements

7 From Domains to Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2 The Example Requirements – The General Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.3 Stages of Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.4 Business Process Re-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.4.1 Re-engineering Domain Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.4.2 Re-engineering Domain Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.4.3 Re-engineering Domain Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.4.4 Re-engineering Domain Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.5 Domain Requirements Prescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.5.1 Domain Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Domain Projection — Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Domain Projection — Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.5.2 Domain Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Domain Instantiation — Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Domain Instantiation — Formalisation, Toll Way Net . . . . . . . . . . . . . . . . . . . . . . 105Domain Instantiation — Formalisation, Well-formedness . . . . . . . . . . . . . . . . . . . 105

7.5.3 Domain Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Domain Determination — Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Domain Determination — Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.5.4 Domain Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Informal Sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Domain Extension — Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Intuition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Domain Extension — Formalisation of Support Technology . . . . . . . . . . . . . . . . 113

7.5.5 Requirements Fitting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Requirements Fitting Procedure — A Sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Requirements Fitting — Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Requirements Fitting — Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.5.6 Domain Requirements Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.6 Interface Requirements Prescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.6.1 Shared Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114


Contents xiii

Data Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Data Refreshment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.6.2 Shared Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Interactive Action Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.6.3 Shared Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.6.4 Shared Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

7.7 Machine Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Part IV Closing

8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

9 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219.1 Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Part V Appendices

A Abstraction & Modelling – using RAISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129A.1 RSL: The Raise Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

A.1.1 Type Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Atomic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Composite Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

A.1.2 Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Concrete Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Subtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Sorts — Abstract Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.1.3 The RSL Predicate Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Propositional Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Simple Predicate Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Quantified Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.1.4 Concrete RSL Types: Values and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Set Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Cartesian Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133List Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Map Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Set Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Cartesian Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136List Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Map Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

A.1.5 λ-Calculus + Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139The λ-Calculus Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Free and Bound Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139α-Renaming and β-Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Function Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Function Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

A.1.6 Other Applicative Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Simple let Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Recursive let Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Predicative let Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Pattern and “Wild Card” let Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Operator/Operand Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

A.1.7 Imperative Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142


xiv Contents

Statements and State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Variables and Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Statement Sequences and skip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Imperative Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Iterative Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Iterative Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

A.1.8 Process Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Process Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Process Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Input/Output Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Process Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

A.1.9 Simple RSL Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

B Domain Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.1 A Model of Pipeline Endurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

B.1.1 Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.1.2 Part Identification and Mereology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Unique Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Mereology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

B.1.3 Part Concepts, I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Pipe Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Wellformed Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Embedded Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148A Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

B.1.4 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149B.1.5 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Part Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Flow Laws, I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Material Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

B.2 A Model of Platoons & Platooning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151B.2.1 Vehicles and Platoons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151B.2.2 Platoon Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152B.2.3 Auxiliary Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152B.2.4 Simple Platoon Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Invariance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

B.2.5 A Model of Platoon Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157B.3 A Model of Railway Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Rail Units and Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Rail unit States and State Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Rail Unit and Rail State Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Rail Net and Unit Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Rail Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Rail Route Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Rail Tracks and Train Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Trains Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Further Rail Net Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

B.4 A Model of TSE Stock Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165B.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165B.4.2 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165B.4.3 A Domain Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Market and Limit Offers and Bids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Order Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Aggregate Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167The TSE Itayose “Algorithm” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Match Executions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170


Contents xv

Order Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

C Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171C.1 Index of RSL Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171C.2 Index of Endurant Analysis Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172C.3 Index of Attribute Analysis Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172C.4 Index of Domain Description Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173C.5 Index of Some Domain Description Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173C.6 Index of Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173C.7 Index of Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 3

4


Part I

Opening

1

Introduction 5

Usually a first major phase of software development is that of requirements engineering. In thisbook we present a more general approach to software development in which we prefix a domainengineering phase to the requirements engineering phase. 6

We shall thus present a number of techniques and tools that are of interest in “the very earlystages” of software development.

Dogma 1 TripTych: Before we can design software we must have a reasonably firm understand-ing of its requirements; and before we can prescribe requirements we must have a reasonably firmunderstanding of the domain in which that software and its supporting hardware has to reside .

So the “the very early stages” of software development are those in which one obtains a reasonablyfirm understanding of the domain. 7

Definition 1 Domain: By a ′domain′ we shall understand a set of ′entities′: ′endurant′s, that is,phenomena that “lasts”, and ′perdurant′s, that is actions, events and behaviours over endurants,where the focus (of such entities) is on domains created by humans, domains that are componentsof a ′societal infrastructure′, and where, hence, these users interact, more-or-less casually withtheir domain, and these human users are not expected to excert greater technical skills in theirinteraction with the domain .

8

Example 1 Domains Some example domains are: air traffic, airports, banking, container lines,heath care, manufacturing (e.g., wither of metal working, machining, assembly, etcetera), pipelines,railways, etcetera .

1.1 The TripTych Approach to Software Engineering 9

The key words above were ‘domain’, ‘requirements’, and software’. We shall therefore associate witheach of these separate phases of software development. These are: domain engineering, requirementsengineering, and software design.

1.1.1 Domain Engineering 10

Definition 2 Domain Engineering: By ′domain engineering′ we shall understand the process ofanalysing and describing a domain, that is, of determining the range of domain stake-holders, ofgathering and analysing information about the domain, of describing the domain, of testing, checkingand verifying the evolving domain description and of validating that description .

11

We shall define the sans serif terms used in the definition above and also in the definition givenbelow for requirements engineering.

4 1 Introduction

Definition 3 Domain [Requirements] Stake-holder: By ′domain stake-holder′ (′requirementsstake-holder′) we shall understand a person, or a group of persons, “united” somehow in theircommon interest in, or dependency on the domain (requirements); or an institution, an enterprise,or a group of such, (again) characterised (and, again, loosely) by their common interest in, ordependency on the domain (requirements) .

In this book we shall not exemplify techniques or tools for stake-holder identification.12

Example 2 Bank Stake-holders For the domain of banking one can include the following inits sets of stake-holders: bank owners, bank staff, clients, regulators, the press/media, politicians,suppliers, etcetera .

13

Definition 4 Domain Information Gathering: By ′domain information gathering′ we shallunderstand the process, through interviews, questionnaires, document (literature, etc.) reading,etcetera, of acquiring and recording facts about the domain .

In this book we shall not exemplify techniques or tools for domain information gathering.14

Definition 5 Domain Analysis: By ′domain information analysis′ (or just ′domain analysis′)we shall understand the process of asking question and, forming concepts about, and postulatingproperties of the domain .

This book is indeed about techniques and tools for domain analysis.15

Definition 6 : By a ′domain description′ we shall understand a document, both informal andformal, which describes entities endurants: parts and materials and their qualities (properties),and perdurants: actions, events and behaviours of the domain .

This book is indeed about techniques and tools for domain description16

Definition 7 Testing: By ′testing′ [a domain description (or a requirements prescription)] weshall understand the process of subjecting a domain description (or the requirements prescription)to a number of symbolic (or abstract) interpretations1given case-specific entity values with a viewtowards obtaining expected answers .

In this book we shall not exemplify techniques or tools for testing domain or requirements descrip-tions.17

Definition 8 Checking: By ′checking′ [a domain description (or a requirements prescription)] weshall understand the process of subjecting a domain description (or the requirements prescription)to a number of model checks2given case-specific domain model instantiations with a view towardsobtaining expected answers .

In this book we shall not exemplify techniques or tools for checking domain descriptions or re-quirements prescriptions.18

Definition 9 Verification: By ′verification′ [of a domain description (or a requirements prescrip-tion)] we shall understand the process of formally proving properties of a domain description (ora requirements prescription) .

In this book we shall not exemplify techniques or tools for verifying domain descriptions (orrequirements prescriptions).19

Definition 10 Validation: By ′validation′ we shall understand the process of checking with domainstake-holders that that which is described (prescribed) by a domain description (or a requirementsprescription) is commensurate with their understanding of the domain (or of their requirementsto software for that domain .

1 We assume that the concepts of symbolic or abstract interpretations, [35], are known.2 We assume that the concepts of model checking, [61, 49, 33, 62], is known.


1.2 An Example: Road Transport 5

In this book we shall not exemplify techniques or tools for validating domain descriptions (orrequirements prescriptions).

• • •

Chapter 6 summarises the concept of ‘Domain Engineering’.

1.1.2 Requirements Engineering 20

Definition 11 Requirements Engineering: By ′requirements engineering′ we shall understandthe process of analysing and prescribing the requirements, that is, of determining the range ofrequirements stake-holders, of gathering and analysing information about the requirements, of de-scribing the requirements, of testing, checking and verifying the evolving requirements prescriptionwith respect to the underlying domain description, and of validating that prescription .

21

We shall only define the requirements term.

Definition 12 Requirements: By ′requirements′ we shall understand a condition or capabilityneeded by a stake-holder to solve a problem or achieve an objective .

Chapter 7 outlines our contribution to the concept of ‘Requirements Engineering’. It is that of“deriving”, not automatically, but systematically, in an “interactive fashion”, with requirementsstake-holders, the requirements from the domain description.

1.1.3 Software Design 22

Definition 13 Software Design: By ′software design′ we shall understand the process of “trans-forming” (refining) the requirements prescription into executable code, that is, of turning ab-stract data types into concrete, machine-representable data types, of turning function pre- & post-conditions into algorithms, and of implementing behaviours .

In this book we shall not exemplify techniques or tools for software design.


This section can be skipped in any reading of this book ! The example of this book serves thefollowing purposes: to, of course, give an example of a domain description sketch, thus to familiarisethe reader to concepts of domain analysis, and to show that one can, indeed, obtain a rathercomprehensive description of domains that may, at first, seem “too big”. The reader may ascertainthe structure of this section by consulting the table-of-contents listing.

1.2.1 Endurants 24

Parts

Root Sorts

The root domain, ∆, the stepwise unfolding of whose description is to be exemplified, is that ofa composite traffic system (1a.) with a road net, (1b.) with a fleet of vehicles and (1c.) of whoseindividual position on the road net we can speak, that is, monitor. 25

1. We analyse the composite traffic system into(a) a composite road net,(b) a composite fleet (of vehicles), and(c) an atomic monitor.


6 1 Introduction

type

1. ∆1a. N1b. F1c. Mvalue

1a. obs N: ∆ → N1b. obs F: ∆ → F1c. obs M: ∆ → M

Sub-domain Sorts and Types 26

2. From the road net we can observe(a) a composite part, HS, of road (i.e., street) intersections (hubs) and(b) a composite part, LS, of road (i.e., street) segments (links).

type

2. HS, LSvalue

2a. obs HS: N → HS2b. obs LS: N → LS

27

We analyse the sub-domains of HS and LS.

3. From the hubs aggregate we decide to observe(a) the concrete type of a set of hubs,(b) where hubs are considered atomic; and

4. from the links aggregate we decide to observe(a) the concrete type of a set of links,(b) where links are considered atomic;

28

type

3a. Hs = H-set

4a. Ls = L-set

3b. H4b. Lvalue

3. obs Hs: HS → H-set

4. obs Ls: LS → L-set

29

5. From the fleet sub-domain, F, we observe a composite part, VS, of vehicles

type

5. VSvalue

5. obs VS: F → VS

30

6. From the composite sub-domain VS we observe(a) the composite part Vs, which we concretise as a set of vehicles(b) where vehicles, V, are considered atomic.



type

6a. Vs = V-set

6b. Vvalue

6a. obs Vs: VS → V-set

31

The “monitor” is considered atomic. It is an abstraction of the fact that we can speak of thepositions of each and every vehicle on the net without assuming that we can indeed pin pointthese positions by means of, for example, sensors.

Properties 32

Parts are distinguished by their properties: the types and the values of these. We consider threekinds of properties: unique identifiers, mereology and attributes.

Unique Identifications 33

There is, for any traffic system, exactly one composite aggregation, HS, of hubs, exactly onecomposite aggregation, Hs, of hubs, exactly one composite aggregation, LS, of links, exactly onecomposite aggregation, Ls, of links, exactly one composite aggregation, VS, of vehicles and ex-actly one composite aggregation, Vs, of vehicles, Therefore we shall not need to associate uniqueidentifiers with any of these.

7. We decide the following:(a) each hub has a unique hub identifier,(b) each link has a unique link identifier and(c) each vehicle has a unique vehicle identifier.

type

7a. HI7b. LI7c. VIvalue

7a. uid H: H → HI7b. uid L: L → LI7c. uid V: V → VI

Mereology 34

Road Net Mereology

By mereology we mean the study, knowledge and practice of understanding parts and part relations.The mereology of the composite parts of the road net, n:N, is simple: there is one HS part of

n:N; there is one Hs part of the only HS part of n:N; there is one LS part of n:N; and there is oneLs part of the only LS part of n:N. Therefore we shall not associate any special mereology basedon unique identifiers which we therefore also decided to not express for these composite parts. 35

8. Each link is connected to exactly two hubs, that is,(a) from each link we can observe its mereology, that is, the identities of these two distinct

hubs,(b) and these hubs must be of the net of the link;

9. and each hub is connected to zero, one or more links, that is,(a) from each hub we can observe its mereology, that is, the identities of these links,(b) and these links must be of the net of the hub.

36


8 1 Introduction

value

8a. mereo L: L → HI-setaxiom

8a. ∀ l:L•card mereo L(l)=2,8b. ∀ n:N,l:L,hi:HI •

8b. l ∈ obs Ls(obs LS(n)) ∧ hi ∈ mereo L(l)8b. ⇒ ∃ h:H•h ∈ obs Hs(obs HS(n))∧uid H(h)=hivalue

9a. mereo H: H → LI-setaxiom

9b. ∀ n:N,h:H,li:LI •

9b. h ∈ obs Hs(obs HS(n)) ∧ li ∈ mereo H(h)9b. ⇒ ∃ l:L•l ∈ obs Ls(obs LS(n))∧uid L(l)=li

37

Fleet of Vehicles Mereology

In the traffic system that we are building up there are no relations to be expressed between vehicles,only between vehicles and the (single and only) monitor. Thus there is no mereology needed forvehicles.

Attributes 38

We shall model attributes of links, hubs and vehicles. The composite parts, aggregations of hubs,HS and Hs, aggregations of links, LS and Ls and aggregations of vehicles, VS and Vs, also haveattributes, but we shall omit modelling them here.39

Attributes of Links

10. The following are attributes of links.(a) Link states, lσ:LΣ, which we model as possibly empty sets of pairs of distinct identifiers

of the connected hubs. A link state expresses the directions that are open to traffic acrossa link.

(b) Link state spaces, lω:LΩ which we model as the set of link states. A link state spaceexpresses the states that a link may attain across time.

(c) Further link attributes are length, location, etcetera.

Link states are usually dynamic attributes whereas link state spaces, link length and link location(usually some curvature rendition) are considered static attributes.40

type

10a. LΣ = (HI × HI)-setaxiom

10a. ∀ lσ:LΣ • 0 ≤ card lσ ≤ 2value

10a. attr LΣ: L → LΣaxiom

10a. ∀ l:L • let hi,hi′=mereo L(l) in attr LΣ(l)⊆(hi,hi′),(hi′,hi) end

type

10b. LΩ = LΣ-set

value

10b. attr LΩ: L → LΩaxiom

10b. ∀ l:L • let hi,hi′=mereo L(l) in attr LΣ(l)∈ attr LΩ(l) end

type

10c. LOC, LEN, ...



value

10c. attr LOC: L → LOC, attr LEN: L → LEN, ...

41

Attributes of Hubs

11. The following are attributes of hubs:(a) Hub states, hσ:HΣ, which we model as possibly empty sets of pairs of identifiers of the

connected links. A hub state expresses the directions that are open to traffic across a hub.(b) Hub state spaces, hω:HΩ which we model as the set of hub states. A hub state space

expresses the states that a hub may attain across time.(c) Further hub attributes are location, etcetera.

Hub states are usually dynamic attributes whereas hub state spaces and hub location are consideredstatic attributes. 42

type

11a. HΣ = (LI × LI)-setvalue

11a. attr HΣ: H → HΣaxiom

11a. ∀ h:H • attr HΣ(h)⊆(li,li′)|li,li′:LI•li,li′⊆mereo H(h)type

11b. HΩ = HΣ-set

value

11b. attr HΩ: H → HΩaxiom

11b. ∀ h:H • attr HΣ(h) ∈ attr HΩ(h)type

11c. LOC, ...value

11c. attr LOC: L → LOC, ...

43

Attributes of Vehicles

12. Dynamic attributes of vehicles include(a) position

i. at a hub (about to enter the hub — referred to by the link it is coming from, the hubit is at and the link it is going to, all referred to by their unique identifiers or

ii. some fraction “down” a link (moving in the direction from a from hub to a to hub —referred to by their unique identifiers)

iii. where we model fraction as a real between 0 and 1 included.(b) velocity, acceleration, etcetera.

13. All these vehicle attributes can be observed.44

type

12a. VP = atH | onL12(a)i. atH :: fli:LI × hi:HI × tli:LI12(a)ii. onL :: fhi:HI × li:LI × frac:FRAC × thi:HI12(a)iii. FRAC = Real, axiom ∀ frac:FRAC • 0 ≤ frac ≤ 112b. VEL, ACC, ...value

13. attr VP:V→VP,13. attr onL:V→onL,


10 1 Introduction

13. attr atH:V→atH13. attr VEL:V→VEL,13. attr ACC:V→ACC13. ...

45

Vehicle Positions

14. Given a net, n:N, we can define the possibly infinite set of potential vehicle positions on thatnet, vps(n).(a) vps(n) is expressed in terms of the links and hubs of the net.(b) vps(n) is the(c) union of two sets:

i. the potentially3infinite set of “on link” positionsii. for all links of the net

andiii. the finite set of “at hub” positionsiv. for all hubs in the net.

46

value

14. vps: N → VP-infset

14b. vps(n) ≡14a. let ls=obs Ls(obs LS(n)), hs=obs Hs(obs HS(n)) in

14(c)i. onL(fhi,uid(l),f,thi) | fhi,thi:HI,l:L,f:FRAC •

14(c)ii. l ∈ ls ∧ fhi,thi=mereo L(l) 14c. ∪14(c)iii. atH(fli,uid H(h),tli) | fli,tli:LI,h:H •

14(c)iv. h ∈ hs ∧ fli,tli⊆mereo H(h) 14a. end

47

Vehicle Assignments

Given a net and a finite set of vehicles we can distribute these vehicles over the net, i.e., assigninitial vehicle positions, so that no two vehicles “occupy” the same position, i.e., are “crashed” !Let us call the non-deterministic assignment function vpr.

15. vpm:VPM is a bijective map from vehicle identifiers to (distinct) vehicle positions.16. vpr has the obvious signature.

(a) vpr(vs)(n) is defined in terms of(b) a non-deterministic selection, vpa, of vehicle positions, and(c) a non-deterministic assignment of these vehicle positions to vehicle identifiers,(d) being the resulting distribution.

48

type

15. VPM′ = VI →m VP15. VPM = | vpm:VPM′

• card dom vpm = card rng vpm |value

16. vpr: V-set × N → VMP16a. vpr(vs)(n) ≡16b. let vpa:VP-set • vpa ⊆ vps(vs)(n) ∧ card vpa = vard vs in

16c. let vpm:VPM • dom vpm = vps ∧ rng vpm = vpa in

16d. vpm end end

3 The ‘potentiality’ arises from the nature of FRAC. If fractions are chosen as, for example, 1/5’th,2/5’th, ..., 4/5’th, then there are only a finite number of “on link” vehicle positions. If instead fractionare arbitrary infinitesimal quantities, then there are infinitely many such.



Definitions of Auxiliary Functions 49

17. From a net we can extract all its link identifiers.18. From a net we can extract all its hub identifiers.

value

17. xtr LIs: N → LI-set17. xtr LIs(n) ≡ uid L(l)|l:L•l ∈ obs Ls(obs LS(n))18. xtr HIs: N → HI-set18. xtr HIs(n) ≡ uid H(l)|h:H•h ∈ obs Hs(obs HS(n))

19. Given a link identifier and a net get the link with that identifier in the net.20. Given a hub identifier and a net get the hub with that identifier in the net.

50

value

22. get H: HI → N∼→ H

22. get H(hi)(n) ≡ ι h:H•h ∈ obs Hs(obs HS(n))∧uid H(h)=hi22. pre: hi ∈ xtr HIs(n)

22a. get L: LI → N∼→ L

22a. get L(li)(n) ≡ ι l:L•l ∈ obs Ls(obs LS(n))∧uid L(l)=li22a. pre: hl ∈ xtr LIs(n)

The ι a:A•P(a) expression yields the unique value a:A which satisfies the predicate P(a). If none,or more than one exists then the function is undefined.

Some Derived Traffic System Concepts 51

Maps

21. A road map is an abstraction of a road net. We define one model of maps below.(a) A road map, RM, is a finite definition set function, that is, a specification language map

from• hub identifiers (the source hub)• to finite definition set maps from link identifiers• to hub identifiers (the target hub).

type

21a. RM′ = HI →m (LI →m HI)

If a hub identifier in the definition set or an rm:RM maps into the empty map then the designatedhub is “isolated”: has no links emanating from it. 52

22. These road maps are subject to a well-formedness criterion.(a) The target hubs must be defined also as source hubs.(b) If a link is defined from source hub (referred to by its identifier) shi via link li to a target

hub thi, then, vice versa, link li is also defined from source thi to target shi.

type

22. RM = | rm:RM′• wf RM(rm) |

value

22. wf RM: RM′ → Bool

22. wf RM(rm) ≡22a. ∪ rng(rm(hi))|hi:HI•hi ∈ dom rm ⊆ dom rm22b. ∧ ∀ shi:HI•shi ∈ dom rm ⇒22b. ∀ li:LI • li ∈ dom rm(shi) ⇒22b. li ∈ dom rm((rm(shi))(li)) ∧ (rm((rm(shi))(li)))(li)=shi


12 1 Introduction

53

23. Given a road net, n, one can derive “its” road map.(a) Let hs and ls be the hubs and links, respectively of the net n.(b) Every hub with no links emanating from it is mapped into the empty map.(c) For every link identifier uid L(l) of links, l, of ls and every hub identifier, hi, in the mereology

of l(d) hi is mapped into a map from uid L(l) into hi’(e) where hi’ is the other hub identifier of the mereology of l.

54

value

23. derive RM: N → RM23. derive RM(n) ≡23a. let hs = obs Hs(obs HS(n)), ls = obs Ls(obs LS(n)) in

23b. [ hi 7→ [ ] | hi:HI • ∃ h:H • h ∈ hs ∧ mereo H(h) = ] ∪23d. [ hi 7→ [ uid L(l) 7→ hi′

23e. | hi′:HI • hi′ = mereo L(l)\hi ]23c. | l:L,hi:HI • l ∈ ls ∧ hi ∈ mereo L(l) ] end

Theorem: If the road net, n, is well-formed then wf RM(derive RM(n)).

Traffic Routes 55

24. A traffic route, tr, is an alternating sequence of hub and link identifiers such that(a) li:LI is in the mereology of the hub, h:H, identified by hi:HI, the predecessor of li:LI in route

r, and(b) hi’:HI, which follows li:LI in route r, is different from hi, and is in the mereology of the link

identified by li.

type

24. R′ = (HI|LI)∗

24. R = | r:R′• ∃ n:N • wf R(r)(n) |

value

24. wf R: R′ → N → Bool

24. wf R(r)(n) ≡24. ∀ i:Nat • i,i+1⊆inds r ⇒24a. is HI(r(i)) ⇒ is LI(r(i+1)) ∧ r(i+1) ∈ mereo H(get H(r(i))(n)),24b. is LI(r(i)) ⇒ is HI(r(i+1)) ∧ r(i+1) ∈ mereo L(get L(r(i))(n))

56

25. From a well-formed road map (i.e., a road net) we can generate the possibly infinite set of allroutes through the net.(a) Basis Clauses:

i. The empty sequence of identifiers is a route.ii. The one element sequences of link and hub identifiers of links and hubs of a road map

(i.e., a road net) are routes.iii. If hi maps into some li in rm then 〈hi,li〉 and 〈li,hi〉 are routes of the road map (i.e., of

the road net).(b) Induction Clause:

i. Let r〈i〉 and 〈i′〉r′ be two routes of the road map.ii. If the identifiers i and i′ are identical, then r〈i〉r′ is a route.

(c) Extremal Clause:

i. Only such routes that can be formed from a finite number of applications of the aboveclauses are routes.

57



value

25. gen routes: RM → Routes-infset

25. gen routes(rm) ≡25(a)i. let rs = 〈〉25(a)ii. ∪ 〈li,hi〉,〈hi,li〉|li:LI,hi:HI•hi ∈ dom rm∧rm(hi)=li25(b)i. ∪ let r〈li〉,〈li′〉r′:R • r〈li〉,〈li′〉r′⊆rs∧li=li′,25(b)i. r′′〈hi〉,〈hi′〉r′′′:R • r′′〈hi〉,〈hi′〉r′′′⊆rs∧hi=hi′ in25(b)ii. r〈li〉r′,r′′〈hi〉r′′′ end in

25(c)i. rs end

58

Circular Routes

26. A route is circular if the same identifier occurs more than once.

value

26. is circular route: R → Bool

26. is circular route(r) ≡ ∃ i,j:Nat • i,j⊆inds r ∧ i6=j ⇒ r(i)=r(j)

59

Connected Road Nets

27. A road net is connected if there is a route from any hub (or any link) to any other hub or linkin the net.

27. is conn N: N → Bool

27. is conn N(n) ≡27. let rm = derive RM(n) in

27. let rs = gen routes(rm) in

27. ∀ i,i′:(LI|HI)•i6=i′∧i,i′⊆xtr LIs(n)∪ xtr HIs(n)27. ∃ r:R • r ∈ rs ∧ r(1)=i ∧ r(len r)=i′ end end

60

Set of Connected Nets of a Net

28. The set, cns, of connected nets of a net, n, is(a) the smallest set of connected nets, cns,(b) whose hubs and links together “span” those of the net n.

value

28. conn Ns: N → N-set

28. conn Ns(n) as cns28a. pre: true

28b. post: conn spans HsLs(n)(cns)28a. ∧ ∼∃ kns:N-set • card kns < card cns28a. ∧ conn spans HsLs(n)(kns)

61

28b. conn spans HsLs: N → N → Bool

28b. conn spans HsLs(n)(cns) ≡28b. ∀ cn:N•cn ∈ cns ⇒ is connected N(n)(cn)28b. ∧ let (hs,ls) = (obs Hs(obs HS(n)),obs Ls(obs LS(n))),28b. chs = ∪obs Hs(obs HS(cn))|cn ∈ cns,28b. cls = ∪obs Ls(obs LS(cn))|cn ∈ cns in

28b. hs = chs ∧ ls = cls end

62


14 1 Introduction

Route Length

29. The length attributes of links can be(a) added and subtracted,(b) multiplied by reals to obtain lengths,(c) divided to obtain fractions,(d) compared as to whether one is shorter than another, etc., and(e) there is a “zero length” designator.

value

29a. +,− : LEN × LEN → LEN29b. ∗ : LEN × Real → LEN29c. / : LEN × LEN → Real

29d. <,≤,=,6=,≥,> : LEN × LEN → Bool

29e. ℓ0 : LEN

63

30. One can calculate the length of a route.

value

30. length: R → N → LEN30. length(r)(n) ≡30. case r of:30. 〈〉 → ℓ0,30. 〈si〉r′ →30. is LI(si)→attr LEN(get L(si)(n))+length(r′)(n)30. is HI(si)→length(r′)(n)30. end

64

Shortest Routes

31. There is a predicate, is R, which,(a) given a net and two distinct hub identifiers of the net,(b) tests whether there is a route between these.

value

31. is R: N → (HI×HI) → Bool

31. is R(n)(fhi,thi) ≡31a. fhi 6= thi ∧ fht,thi⊆xtr HIs(n)31b. ∧ ∃ r:R • r ∈ routes(n) ∧ hd r = fhi ∧ r(len r) = thi

65

32. The shortest between two given hub identifiers(a) is an acyclic route, r,(b) whose first and last elements are the two given hub identifiers(c) and such that there is no route, r′ which is shorter.

value

32. shortest route: N → (HI×HI) → R32a. shortest route(n)(fhi,thi) as r32b. pre: pre shortest route(n)(fhi,thi)32c. post: pos shortest route(n)(r)(fhi,thi)

66



32b. pre shortest route: N → (HI×HI) → Bool

32b. pre shortest route(n)(fhi,thi) ≡32b. is R(n)(fhi,thi) ∧ fhi6=thi ∧ fhi,thi⊂xtr HIs(n)

32c. pos shortest route: N → R → (HI×HI) → Bool

32c. pos shortest route(n)(r)(fhi,thi) ≡32c. r ∈ routes(n)32c. ∧ ∼∃ r′:R • r′ ∈ routes(n) ∧ length(r′) < length(r)

States 67

There are different notions of state. In our example these are some of the states: the road netcomposition of hubs and links; the state of a link, or a hub; and the vehicle position.

1.2.2 Perdurants 68

For pragmatic reasons we analyse three kinds of perdurants: actions, events and behaviours.

Actions 69

An action is what happens when a function invocation changes, or potentially changes a state.Examples of traffic system actions are: insertion of hubs, insertion of links, removal of hubs, removalof links, setting of hub state (hσ), moving a vehicle along a link, stopping a vehicle, starting avehicle, moving a vehicle from a link to a hub and moving a vehicle from a hub to a link. Here weshalljust illustrate one of these actions. Later, in Sect. 1.2.2, we shall illustrate the vehicle actions.

70

33. The insert action applies to a net and a hub and conditionally yields an updated net.(a) The condition is that there must not be a hub in the “argument” net with the same unique

hub identifier as that of the hub to be inserted and(b) the hub to be inserted does not initially designate links with which it is to be connected.(c) The updated net contains all the hubs of the initial net “plus” the new hub.(d) and the same links.

71

value

33. ins H: N → H∼→ N

33. ins H(n)(h) as n′, pre: pre ins H(n)(h), post: post ins H(n)(h)

33a. pre ins H(n)(h) ≡33a. ∼∃ h′:H • h′ ∈ obs Hs(n) ∧ uid HI(h)=uid HI(h′)33b. ∧ mereo H(h) =

33c. post ins H(n)(h)(n′) ≡33c. obs Hs(n) ∪ h = obs Hs(n′)33d. ∧ obs Ls(n) = obs Ls(n′)

We leave it as exercises to define the other hub and link actions.


16 1 Introduction

Events 72

By an event we understand a state change resulting indirectly from an unexpected application ofa function, that is, that function was performed “surreptitiously”. Events can be characterised bya pair of (before and after) states, a predicate over these and, optionally, a time or time interval.Events are thus like actions: change states, but are usually either caused by “previous” actions, orcaused by “an outside action”. 73

34. Link disappearance is expressed as a predicate on the “before” and “after” states of the net.The predicate identifies the “missing” ℓink (!).

34. link dis: N × N → Bool

34. link dis(n,n′) ≡34. ∃ ℓ:L • pre link dis(n,ℓ) ⇒ post link dis(n,ℓ,n′)35. pre link dis: N × L → Bool

35. pre link dis(n,ℓ) ≡ ℓ ∈ obs Ls(n)

74

35. Before the disappearance of link ℓ in net n(a) the hubs h′ and h′′ connected to link ℓ(b) were connected to links identified by l′1, l

′2, . . . , l

′p respectively l′′1 , l′′2 , . . . , l′′q

(c) where, for example, l′i, l′′j are the same and equal to uid Π(ℓ).

75

36. After link ℓ disappearance there are instead(a) two separate links, ℓi and ℓj , “truncations” of ℓ(b) and two new hubs h′′′ and h′′′′

(c) such that ℓi connects h′ and h′′′ and(d) ℓj connects h′′ and h′′′′.

37. Existing hubs h′ and h′′ now have mereology(a) l′1, l

′2, . . . , l

′p \ uid Π(ℓ) ∪ uid Π(ℓi) respectively

(b) l′′1 , l′′2 , . . . , l′′q \ uid Π(ℓ) ∪ uid Π(ℓj)38. All other hubs and links of n are unaffected.

We shall not express the above properties explicitly. Instead we expect such a predicate to holdfor the interpretation now give.76

39. We shall “explain” link disappearance as the combined, instantaneous effect of(a) first a remove link “event” where the removed link connected hubs hij and hik;(b) then the insertion of two new, “fresh” hubs, hα and hβ ;(c) “followed” by the insertion of two new, “fresh” links ljα and lkβ such that

i. ljα connects hij and hα andii. lkβ connects hik and hkβ .

77

value

39. post link dis(n,ℓ,n′) ≡39. let (h a,h b):H×H •

39. let li a,li b=mereo L(ℓ) in

39. (get H(li a)(n),get H(li b)(n)) end in

39a. let n′′ = rem L(n)(uid L(ℓ)) in

39b. let hα,hβ :H • hα,hβ∩obs Hs(n)= in

39b. let n′′′ = ins H(n′′)(hα) in

39b. let n′′′′ = ins H(n′′′)(hβ) in

39c. let ljα,lkβ :L • ljα,lkβ∩obs Ls(n)=39c. ∧ mereo L(ljα) = uid H(h a),uid H(hα)39c. ∧ mereo L(lkβ) = uid H(h b),uid H(hβ) in

39(c)i. let n′′′′′ = ins L(n′′′′)(ljα) in

39(c)ii. n′ = ins L(n′′′′′)(lkβ) end end end end end end end



Behaviours 78

Traffic

Continuous Traffic

For the road traffic system perhaps the most significant example of a behaviour is that of its traffic:

40. the continuous time varying discrete positions of vehicles, vp:VP4,41. where time is taken as a dense set of points.

type

41. cT

40. cRTF = cT → (V →m VP)

79

Discrete Traffic

We shall model, not continuous time varying traffic, but

42. discrete time varying discrete positions of vehicles,43. where time can be considered a set of linearly ordered points.

43. dT

42. dRTF = dT →m (V →m VP)

44. The road traffic that we shall model is, however, of vehicles referred to by their unique iden-tifiers.

type

44. RTF = dT →m (VI →m VP)

80

Time: An Aside

We shall take a rather simplistic view of time [27, 75, 86, 102].

45. We consider dT, or just T, to stand for an ordered set of time points.46. And we consider TI to stand for time intervals based on T.47. We postulate an infinitesimal small time interval δ.48. T, in our presentation, has lower and upper bounds.49. We can compare times and we can compare time intervals.50. And there are a number of “arithmetics-like” operations on times and time intervals.

81

type

45. T

46. TI

value

47. δ:TI

48. MIN, MAX: T → T

48. <,≤,=,≥,>: (T×T)|(TI×TI) → Bool

49. −: T×T → TI

50. +: T×TI,TI×T → T

50. −,+: TI×TI → TI

50. ∗: TI×Real → TI

50. /: TI×TI → Real

82

4 For VP see Item 12a on Page 9.


18 1 Introduction

Global Clock

51. We postulate a global clock behaviour which offers the current time.52. We declare a channel clk ch.

value

51. clock: T → out clk ch Unit

51. clock(t) ≡ ... ; clk ch!t ; ... ; clock(t ⌈⌉ t+δ)channnel52. clk ch:T

Globally Observable Parts 83

There is given

53. a net, n:N,54. a set of vehicles, vs:V-set, and55. a monitor, m:M.

The n:N, vs:V-set and m:M are observable from the road traffic system domain.

value

53. n:N = obs N(∆)53. ls:L-set = obs Ls(obs LS(n)), hs:H-set = obs Hs(obs HS(n)),53. lis:LI-set = uid L(l)|l:L•l ∈ ls, his:HI-set = uid H(h)|h:H•h ∈ hs54. vs:V-set = obs Vs(obs VS(obs F(∆))), vis:V-set = uid V(v)|v:V•v ∈ vs55. m:obs M(∆)

Road Traffic System Behaviours 84

56. Thus we shall consider our road traffic system, rts, as(a) the concurrent behaviour of a number of vehicles,(b) a monitor behaviour,(c) an initial vehicle position map, and(d) an initial starting time.

85

value

56c. vpm:VPM = vpr(vs)(n)56d. t0:T = clk ch?

56. rts() =56a. ‖ veh(uid V(v))(v)(vpm(uid V(v)))|v:V•v ∈ vs56b. ‖ mon(m)([ t0 7→ vpm ])

where the “extra” monitor argument, rtf:RTF, records the discrete road traffic initially set to thesingleton map from an initial start time, t0 to the initial assignment of vehicle positions.

Channels 86

In order for the monitor behaviour to assess the vehicle positions these vehicles communicate theirpositions to the monitor via a vehicle to monitor channel. In order for the monitor to time-stampthese positions it must be able to “read” a clock.

57. Thus we declare a set of channels indexed by the unique identifiers of vehicles and communi-cating vehicle positions.

channel

57. vm ch[ vi ]|vi:VI•vi ∈ vis:VP



Behaviour Signatures 87

58. The road traffic system behaviour, rts, takes no arguments (hence the first Unit); and “be-haves”, that is, continues, forever (hence the last Unit).

59. The vehicle behaviours are indexed by the unique identifier, uid V(v):VI, the vehicle part, v:Vand the vehicle position; offers communication to the monitor behaviour (on channel vm ch[vi]);and behaves “forever”.

60. The monitor behaviour takes the so far unexplained monitor part, m:M, as one argumentand the discrete road traffic, drtf:dRTF, being repeatedly “updated” as the result of inputcommunications from (all) vehicles; the behaviour otherwise runs forever.

value

58. rts: Unit → Unit

59. veh: vi:VI → v:V → VP → out vm ch[ vi ],mi:MI Unit

60. mon: m:M → RTF → in vm ch[ vi ]|vi:VI•vi ∈ vis,clk ch Unit

The Vehicle Behaviour 88

61. A vehicle process is indexed by the unique vehicle identifier vi:VI, the vehicle “as such”, v:Vand the vehicle position, vp:VPos.The vehicle process communicates with the monitor process on channel vm[vi] (sends, butreceives no messages), and otherwise evolves “in[de]finitely” (hence Unit). 89

62. We describe here an abstraction of the vehicle behaviour at a Hub (hi).(a) Either the vehicle remains at that hub informing the monitor,(b) or, internally non-deterministically,

i. moves onto a link, tli, whose “next” hub, identified by thi, is obtained from the mere-ology of the link identified by tli;

ii. informs the monitor, on channel vm[vi], that it is now on the link identified by tli,iii. whereupon the vehicle resumes the vehicle behaviour positioned at the very beginning

(0) of that link,(c) or, again internally non-deterministically,(d) the vehicle “disappears — off the radar” !

90

62. veh(vi)(v)(vp:atH(fli,hi,tli)) ≡62a. vm ch[ vi ]!vp ; veh(vi)(v)(vp)62b. ⌈⌉62(b)i. let hi′,thi=mereo L(get L(tli)(n)) in assert: hi′=hi62(b)ii. vm ch[ vi ]!onL(tli,hi,0,thi) ;62(b)iii. veh(vi)(v)(onL(tli,hi,0,thi)) end

62c. ⌈⌉62d. stop

91

63. We describe here an abstraction of the vehicle behaviour on a Link (ii).Either(a) the vehicle remains at that link position informing the monitor,(b) or, internally non-deterministically,(c) if the vehicle’s position on the link has not yet reached the hub,

i. then the vehicle moves an arbitrary increment δ along the link informing the monitorof this, or

ii. else, while obtaining a “next link” from the mereology of the hub (where that nextlink could very well be the same as the link the vehicle is about to leave),A. the vehicle informs the monitor that it is now at the hub identified by thi,B. whereupon the vehicle resumes the vehicle behaviour positioned at that hub.


20 1 Introduction

64. or, internally non-deterministically,65. the vehicle “disappears — off the radar” !

92

61. veh(vi)(v)(vp:onL(fhi,li,f,thi)) ≡63a. vm ch[ vi ]!vp ; veh(vi)(v)(vp)63b. ⌈⌉63c. if f + δ<163(c)i. then vm ch[ vi ]!onL(fhi,li,f+δ,thi) ;63(c)i. veh(vi)(v)(onL(fhi,li,f+δ,thi))63(c)ii. else let li′:LI•li′ ∈ mereo H(get H(thi)(n)) in

63(c)iiA. vm ch[ vi ]!atH(li,thi,li′);63(c)iiB. veh(vi)(v)(atH(li,thi,li′)) end end

64. ⌈⌉65. stop

The Monitor Behaviour 93

66. The monitor behaviour evolves around the attributes of an own “state”, m:M, a table of tracesof vehicle positions, while accepting messages about vehicle positions and otherwise progressing“in[de]finitely”.

67. Either the monitor “does own work”68. or, internally non-deterministically accepts messages from vehicles.

(a) A vehicle position message, vp, may arrive from the vehicle identified by vi.(b) That message is appended to that vehicle’s movement trace,(c) whereupon the monitor resumes its behaviour —(d) where the communicating vehicles range over all identified vehicles.

94

66. mon(m)(rtf) ≡67. mon(own mon work(m))(rtf)68. ⌈⌉68a. ⌈⌉⌊⌋ let ((vi,vp),t) = (vm ch[ vi ]?,clk ch?) in

68b. let rtf′ = rtf † [ t 7→ rtf(max dom rtf) † [ vi 7→ vp ] ] in

68c. mon(m)(rtf′) end

68d. end | vi:VI • vi ∈ vis

67. own mon work: M → RTF → M

1.3 Whither Domain Science & Engineering ? 95

In a 2006 e-mail, in response, undoubtedly to my steadfast, perhaps conceived as stubborn in-sistence, on domain engineering, Tony Hoare summed up his reaction to domain engineering asfollows, and I quote5:

“There are many unique contributions that can be made by domain modelling.

1. The models describe all aspects of the real world that are relevant for any good software design inthe area. They describe possible places to define the system boundary for any particular project.

2. They make explicit the preconditions about the real world that have to be made in any embeddedsoftware design, especially one that is going to be formally proved.96

5 E-Mail to Dines Bjørner, CC to the late Robin Milner et al., July 19, 2006


1.3 Whither Domain Science & Engineering ? 21

3. They describe the whole range of possible designs for the software, and the whole range of tech-nologies available for its realisation.

4. They provide a framework for a full analysis of requirements, which is wholly independent of thetechnology of implementation.

5. They enumerate and analyse the decisions that must be taken earlier or later in any design project,and identify those that are independent and those that conflict. Late discovery of feature interac-tions can be avoided.”

All of these issues are dealt with, one-by-one, and in depth, in Vol. 3 of the three volume 2006book [13]. Some of them are dealt with in this book.


Part II

Domains

2

Endurants 97

We split the treatment of domain analysis and description into two chapters. In this chapterwe treat ′endurants′, that is, those entities which endure: are lasting, and in Chap. 3 we treat′perdurants′, that is, those entities which are momentary (changes as time passes: actions, eventsand behaviours).

2.1 Introduction 98

This chapter consists of basically three sections. In Sect. 2.2 we provide a theoretical foundationfor the analysis of endurants. Section 2.3 is the main section of this chapter. In 13 subsections itunravels a methodology for the analysis and description of domain endurants. Subsections 2.3.1–2.3.5 deal with what we shall call the external qualities of endurants while Subsections 2.3.7–2.3.12 deal with the “corresponding” internal qualities. And in Sect. 2.4 we bring a review of ourcontribution, i.e., Sect. 2.3 in the form of a comparison to earlier work on domain analysis.

2.2 Formal Concept Analysis 99

2.2.1 A Formalisation

This section is a transcription of Ganter & Wille’s [47] Formal Concept Analysis, MathematicalFoundations, the 1999 edition, Pages 17–18.

Definition: 1 Formal Context: A ′formal context′ K := (ES, I, QS) consists of two sets; ES ofentities and QS of qualities, and a relation I between E and Q.

To express that E is in relation I to a Quality Q we write E · I ·Q, which we read as “entity E has

quality Q”. 100

Example endurant entities are a specific vehicle, another specific vehicle, etcetera; a specific streetsegment (link), another street segment, etcetera; a specific road intersection (hub), another specificroad intersection, etcetera, a monitor. One can also list perdurant entities. Example endurant entityqualities are has mobility, has velocity (≥0), has acceleration (≥0), has length (>0), has location, hastraffic state, etcetera. One can also list perdurant entity qualities. 101

Definition: 2 Qualities Common to a Set of Entities: For any subset, sES ⊆ ES, of entities wecan define DQ for “derive set of qualities”.

DQ : E-set → (E-set × I × Q-set) → Q-set

DQ(sES)(ES, I, QS) ≡ Q | Q:Q, E:E • E∈sES ∧ E · I · Qpre: sES ⊆ ES

“the set of qualities common to entities in sES”.

26 2 Endurants

Definition: 3 Entities Common to a Set of Qualities: For any subset, sQS ⊆ QS, of qualities wecan define DE for “derive set of entities”.

DE : Q-set → (E-set × I × Q-set) → E-set

DE(sQS)(ES, I, QS) ≡ E | E:E , Q:Q • Q∈sQ ∧ E · I · Q ,pre: sQS ⊆ QS

“the set of entities which have all qualities in sQ”.102

Definition: 4 Formal Concept: A ′formal concept′ of a context K is a pair:

• (sQ, sE) where⋄⋄ DQ(sE)(E, I, Q) = sQ and⋄⋄ DE(sQ)(E, I, Q) = sE;

• sQ is called the ′intent′ of K and sE is called the ′extent′ of K.

2.2.2 Types Are Formal Concepts 103

Now comes the “crunch”: In the TripTych domain analysis we strive to find formal concepts and,when we think we have found one, we assign a type (or a sort) and qualities to it !

2.2.3 Practicalities 104

There is a little problem. To search for all those entities of a domain which each have the samesets of qualities is not feasible. So we do a combination of two things: (i) we identify a small setof entities all having the same qualities and tentatively associate them with a type, and (ii) weidentify certain nouns of our national language and if such a noun does indeed designate a set ofentities all having the same set of qualities then we tentatively associate the noun with a type.Having thus, tentatively, identified a type we conjecture that type and search for counterexamples,105

that is, entities whichthat is, refutations to the claim. This “process” of conjectures and refutations is iterated until

some satisfaction is arrived at that the postulated type constitutes a reasonable conjecture.

2.2.4 Formal Concepts: A Wider Implication 106

The formal concepts of a domain form Galois Connections. We must admit that this fact is one ofthe reasons that we emphasise formal concept analysis. At the same time we must admit that thisbook does not do justice to this fact. We have experimented with the analysis & description of anumber of domains and have noticed such Galois connections but it is, for us, too early to reporton this. Thus we invite the reader to study this aspect of domain analysis.

2.3 Endurant Entities 107

2.3.1 General

Definition 14 Entity: By an ′entity′ we shall understand a ′phenomenon′, i.e., something thatcan be observed, i.e., be seen or touched by humans, or that can be conceived as an abstraction ofan entity .

108

Endurant Analysis Prompt 1 is entity: The domain analyser analyses “things” (θ) into eitherentities or non-entities. The method can thus be said to provide the ′domain analysis prompt′:

• is entity — where is entity(θ) holds if θ is an entity .

is entity is said to be a ′prerequisite prompt′ for all other prompts.



2.3.2 Endurants and Perdurants 109

Definition 15 Endurant: By an ′endurant′ we shall understand an entity that can be observed orconceived, as a “complete thing”, at no matter which given snapshot of time. Were we to “freeze”time we would still be able to observe the entire endurant .

110

Example 3 Road Traffic Endurants: Examples of road traffic endurants are: road nets, fleets ofvehicles, sets of hubs (i.e., street intersections), sets of links (i.e., street segments [between hubs])hubs, links, vehicles. .

111

Definition 16 Perdurant: By a ′perdurant′ we shall understand an entity for which only a frag-ment exists if we look at or touch them at any given snapshot in time, that is, where we to freezetime we would only see or touch a fragment of the perdurant.

Example 4 Road Traffic Perdurants: Examples of road net perdurants are: insertion and removalsof hubs or links (actions), disappearance of links (events), vehicles entering or leaving the road net(actions), vehicles crashing (events) and road traffic (behaviour). .

112

Endurant Analysis Prompt 2 is endurant: The domain analyser analyses entities e into en-durants as prompted by the ′domain analysis prompt′:

• is endurant — φ is an endurant if is endurant(φ) holds.

is entity is a ′prerequisite prompt′ for is endurant .

Endurant Analysis Prompt 3 is perdurant: The domain analyser analyses entities e into per-durants as prompted by the ′domain analysis prompt′:

• is perdurant — φ is a perdurant if is perdurant(φ) holds.

is entity is a ′prerequisite prompt′ for is perdurant .

2.3.3 Endurants 113

Now follows the main sections of this chapter.

Definition 17 Parts: By a ′discrete endurant′ we shall understand something which is separateor distinct in form or concept, consisting of distinct or separate parts. We use the term ′part′ fordiscrete endurants.

Example 5 Parts: Example 3 illustrated, and examples 8 on the following page and 9 on the nextpage illustrate discrete endurants. .

114

Definition 18 Material: By a ′continuous endurant′ we shall understand something which isprolonged without interruption, in an unbroken series or pattern . We use the term ′material′ forcontinuous endurants .

Example 6 Materials: Examples of material endurants are: air of an air conditioning system,grain of a silo, gravel of a barge, oil (or gas) of a pipeline, sewage of a waste disposal system, andwater of a hydro-electric power plant. .

115

Endurant Analysis Prompt 4 is discrete: The domain analyser analyse endurants e into discreteentities as prompted by the ′domain analysis prompt′:

• is discrete — e is discrete if is discrete(e) holds .


28 2 Endurants

Endurant Analysis Prompt 5 is continuous: The domain analyser analyse endurants e into con-tinuous entities as prompted by the ′domain analysis prompt′:

• is continuous — e is continuous if is continuous(e) holds .

We shall call discrete endurants ′part′s, i.e., is part(e) ≡ is discrete(e) and continuous en-durants ′material′s, i.e., is material(e) ≡ is continuous(e) Discrete endurants, i.e., parts, may 116

contain continuous endurants, i.e., material.

Example 7 Parts Containing Materials: Pipeline units, u, are here considered discrete, i.e., parts.Pipeline units serve to convey material, i.e., continuous endurants. .

So which is the result of applying the is discrete prompt to a pipeline unit u ? The answer is: it alldepends ! That is, it is the domain analyser who decides on which one phenomenon is subordinatedthe other, that is, whether the material is an aspect of a part, or the part is subservient to thematerial !

• • •

In this chapter we shall focus mostly on discrete endurants. Section 2.3.11 on Page 45 will coverparts containing materials in a bit more detail.

2.3.4 Atomic and Composite Parts 117

Definition 19 Discrete Endurant: By a ′part′, to recall, we mean a discrete endurant .

A distinguishing quality of discrete endurants, is whether they are atomic or composite.118

Definition 20 Atomic Part: ′Atomic part′s are those which, in a given context, are deemed tonot consist of meaningful, separately observable proper sub-parts .

119

Example 8 Atomic Parts: Examples of atomic parts of the above mentioned domains are: aircraft(of air traffic), demand/deposit accounts (of banks), containers (of container lines), documents(of document systems), hubs, links and vehicles (of road traffic), patients, medical staff and beds(of hospitals), pipes, valves and pumps (of pipeline systems), and rail units and locomotives (ofrailway systems). .

120

Definition 21 Composite Part: ′Composite part′s are those which, in a given context, are deemedto indeed consist of meaningful, separately observable proper sub-parts . A ′sub-part′ is a part .

121

Example 9 Composite Parts: Examples of atomic parts of the above mentioned domains are:airports and air lanes (of air traffic), banks (of a financial service industry), container vessels(of container lines), dossiers of documents (of document systems), routes (of road nets), medicalwards (of hospitals), pipelines (of pipeline systems), and trains, rail lines and train stations (ofrailway systems). .

122

Endurant Analysis Prompt 8 is atomic: The domain analyser analyses a discrete endurant, i.e.,a part p into an atomic endurant:

• is atomic(p): p is an atomic endurant if is atomic(p) holds .

Endurant Analysis Prompt 9 is composite: The domain analyser analyses a discrete endurant,i.e., a part p into a composite endurant:

• is composite(p): p is a composite endurant if is composite(p) holds .

is discrete is a ′prerequisite prompt′ of both is atomic and is composite.



2.3.5 On Observing Part Sorts 123

Types and Sorts

We use the term ‘sort’ when we wish to speak of an abstract type [93], that is, a type for whichwe have no model1. We shall use the term ‘type’ to cover both abstract types and concrete types.

On Discovering Part Sorts 124

Recall from Sect. 2.2 that we “equate” a formal concept with a type (i.e., a sort). Thus, to us, apart sort is a set of all those entities which all have exactly the same qualities.

Our aim is to present the basic principles that let the domain analyser decide on part sorts. We 125

observe parts (i.e., discrete, manifest endurants), one-by-one. (α) Our analysis of parts concludeswhen we have “lifted” our examination of a particular part instance to the conclusion that it is of agiven sort, that is, reflects, or is, a formal concept.

Thus there is, in this analysis, a “eureka”, a step where we shift focus from the concrete to theabstract, from observing specific part instances to postulating a sort, from one to the many. 126

Endurant Analysis Prompt 10 observe parts: The ′domain analysis prompt′:

• observe parts(pi)

directs the domain analyser to observe the subparts of pi; let us say they are: pi1 ,pi2 ,. . . ,pim .

(β) The analyser analyses, for each of these parts, pik, which formal concept, i.e., sort it belongs

to; let us say that it is of sort Pk; thus the subparts of pi are of sorts P1,P2,. . . ,Pm. Some Pk

may be atomic sorts, some may be composite sorts. 127

The domain analyser continues to examine a finite number of other composite parts: pj, pℓ,. . . , pn. It is then “discovered”, that is, decided, that they all consists of the same number ofsubparts pi1 ,pi2 ,. . . ,pim, pj1 ,pj2 ,. . . ,pjm, pℓ1 ,pℓ2 ,. . . ,pℓm, ..., pn1

,pn2,. . . ,pnm, of the same,

respective, part sorts. (γ) It is therefore concluded, that is, decided, that pi, pj ,pℓ,. . . ,pn are all ofthe same part sort P with observable part sub-sorts P1,P2,. . . ,Pm. 128

Above we have type-font-highlighted three sentences: (α, β, γ). When you analyse what they“prescribe” you will see that they entail a “depth-first search” for part sorts. The β sentence saysit rather directly: “The analyser analyses, for each of these parts, pik

, which formal concept, i.e., partsort it belongs to.” To do this analysis in a proper way, the analyser must (“recursively”) analysethe parts “down” to their atomicity, and from the atomic parts decide on their part sort, and work(“recurse”) their way “back”, through possibly intermediate composite parts, to the pik

s.

Part Sort Observer Functions 129

The above analysis amounts to the analyser first “applying” the domain analysis prompt is compo-

site(p) to a discrete endurant, where we now assume that the obtained truth value is true. Let usassume that parts p:P consists of subparts of sorts P1,P2,. . . ,Pm. Since we cannot automaticallyguarantee that our domain descriptions secure that P and each Pi ([ 1≤i≤m ]) denotes disjoint setsof entities we must prove it. 130

Domain Description Prompt 1 observe part sortsobserve-part-sortsIf is composite(p) holds, thenthe analyser “applies” the description language observer prompt

• observe part sorts(p) [a.]

resulting in the analyser writing down the part sorts and part sort observers domain description textaccording to the followig schema: 131

1 for example, in terms of the concrete types: sets, Cartesians, lists, maps, or other.


30 2 Endurants

1. observe part sorts schema

Narration:

[ s ] ... narrative text on sorts ...[ o ] ... narrative text on sort observers ...[ i ] ... narrative text on sort recognisers ...[ p ] ... narrative text on proof obligations ...

Formalisation:

type

[ s ] P,[ s ] Pi [ 1≤i≤m ] comment: Pi [ 1≤i≤m ] abbreviates P1, P2, ..., Pm

value

[ o ] obs Pi: P → Pi [ 1≤i≤m ][ i ] is Pi: Pi → Bool [ 1≤i≤m ]

proof obligation [ Disjointness of part sorts ][ p ] ∀ p:(P1|P2|...|Pm) •

[ p ]∧

is Pi(p) ≡∨

∼ is Pj(p) | j ∈ 1..m \ i | i ∈ 1..m

is composite is a ′prerequisite prompt′ of observe part sorts .We do not here state guidelines for discharging these kinds of proof obligations. But we will veryinformally sketch such discharges, see below.132

Example 10 Composite and Atomic Part Sorts of Transportation The following exampleillustrates the multiple use of the observe part sorts function: first to δ, a specific transportdomain, Item 69, then to an n : N , the net of that domain, Item 70, and then to an f : F , the fleetof that domain, Item 71.

69. A transportation domain is viewed as composed from a net (of hubs and links), a fleet (ofvehicles) and a monitor.

70. A transportation net is here seen as composed from a collection of hubs and a collection oflinks.

71. A fleet is here seen as a collection of vehicles.

The monitor is considered an atomic part.133

type

69. N, F, Mvalue

69. obs N:∆→N, obs F:∆→F, obs M:∆→Mtype

70. HC, LCvalue

70. obs HC:N→HC, obs LC:N→LCtype

71. VCvalue

71. obs VC:F→VC134

A proof obligation has to be discharged, one that shows disjointness of sorts N, F and M. Aninformal sketch is: entities of sort N are composite and consists of two parts: aggregations of hubs,HS, and aggregations of links, LS. Entities of sort F consists of an aggregation, VS, of vehicles. Soalready that makes N and F disjoint. M is an atomic entity — where N and F are both composite.Hence the three sorts N, F and M are disjoint. Experimental research report [22] covers [road]transportation in some detail. .



Part sort identifiers P1, P2, ..., Pm are distinct and are chosen by the domain describer. So wasthe composite part sort identifier P. When the domain analyser decides that two or more proper 135

parts, pi:Pi, pj:Pj , ..., pj :Pk of P are really of the same type, for example named Pijk (chosen bythe domain describer), then the domain analyser must still name them by the distinct Pi, Pj , ...,Pk and then augment the above description text by:

type

Pijk

value

obs Pijk: Pi → Pijk

obs Pijk: Pj → Pijk

...obs Pijk: Pk → Pijk

On Discovering Concrete Part Types 136

Endurant Analysis Prompt 11 has concrete type: The domain analyser may decide that it isexpedient, i.e., pragmatically sound, to render a part sort, P, whether atomic or composite, as aconcrete type, T. That decision is prompted by the holding of the ′domain analysis prompt′:

• has concrete type(p).

is discrete is a ′prerequisite prompt′ of has concrete type .137

Domain Description Prompt 2 observe part type : Then the domain analyser applies the′domain description prompt′:

• observe part type2[b.]

to parts p:P which then yield the part type and part type observers domain description text accordingto the followig schema: 138

2. observe part type schema

Narration:

[ t ] ... narrative text on types ...[ t ] ... narrative text on types ...[ o ] ... narrative text on type observers ...

Formalisation:

type

[ t ] Q, R, ..., S[ t ] T = E(Q,R,...,S)value

[ o ] obs T: P → T

where E(Q,R,...,S) is a type expression and Q, R, . . . , S may any types, including part sorts .139

The type names, T, of the concrete type, as well as those of the auxiliary types, Q, R, . . . , S,are chosen by the domain describer: they may have already been chosen for other sort–to–typedescriptions, or they may be new. 140

Example 11 Concrete Part Types of Transportation: We continue Example 10 on the precedingpage:

2 has concrete type is a ′prerequisite prompt′ of observe part type.


32 2 Endurants

72. A collection of hubs is here seen as a set of hubs and a collection of links is here seen as a setof links.

73. Hubs and links are, until further analysis, part sorts.74. A collection of vehicles is here seen as a set of vehicles.75. Vehicles are, until further analysis, part sorts.

type

72. Hs = H-set, Ls = L-set

73. H, L74. Vs = V-set

75. Vvalue

72. obs Hs:HC→H-set, obs Ls:LC→L-set

74. obs Vs:VC→V-set

.

Forms of Part Types 141

Usually it is wise to restrict the part type definitions, Ti = Ei(Q,R,...,S), to simple type expressions.T=A-set or T=A∗ or T=ID→m A or T=At|Bt|...|Ct where ID is a sort of unique identifiers,T=At|Bt|...|Ct defines the disjoint types At==mkAs(s:As), Bt==mkBs(s:Bs), ..., Ct==mkCs(s:Cs),and where A, As, Bs, ..., Cs are sorts. Instead of At==mkA(a:As), etc., we may write At::As etc.

Part Sort and Type Derivation Chains 142

Let P be a composite sort. Let P1, P2, . . . , Pm be the part sorts “discovered” by means ofobserve part sorts(p) where p:P. We say that P1, P2, . . . , Pm are (immediately) ′derived′ fromP. If Pk is derived from Pj and Pj is derived from Pi, then, by transitivity, Pk is ′derived′ fromPi.143

No Recursive Derivations

We “mandate” that if Pk is derived from Pj then there can be no P derived from Pj such that Pis Pk, and, generally, Pj cannot be derived from Pj .

That is, we do not allow recursive domain sorts.It is not a question, actually of allowing recursive domain sorts. It is, we claim to have observed,

in very many domain modelling experiments, that there are no recursive domain sorts !

Names of Part Sorts and Types 144

The domain analysis and domain description text prompts observe part sorts, observe ma-

terial sorts and observe part type — as well as the attribute names, observe materi-

al sorts, observe unique identifier, observe mereology and observe attributes promptsintroduced below — generate type names. That is, it is as if there is a reservoir of an indefinite-size set of such names from which these names are “pulled”, and once obtained are never “pulled”again. There may be domains for which two distinct part sorts may be composed from identical part145

sorts. In this case the domain analyser indicates so by prescribing a part sort already introduced.

Example 12 Container Line Sorts Our example is that of a container line with container vesselsand container terminal ports.146

76. A container line contains a number of container vessels and a number of container terminalports, as well as other components.

77. A container vessel contains a container stowage area, etc.



78. A container terminal port contains a container stowage area, etc.79. A container stowage ares contains a set of uniquely identified container bays.80. A container bay contains a set of uniquely identified container rows.81. A container row contains a set of uniquely identified container stacks.82. A container stack contains a stack, i.e., a first-in, last-out sequence of containers.83. Containers are further undefined.

After a some slight editing we get: 147

type

CLVS, VI, V, Vs = VI →m V,PS, PI, P, Ps = PI →m P

valueobs VS: CL → VSobs Vs: VS → Vsobs PS: CL → PSobs Ps: CTPS → CTPs

type

CSAvalue

obs CSA: V → CSAobs CSA: P → CSA

type

BAYS, BI, BAY, Bays=BI →m BAYROWS, RI, ROW, Rows=RI →m ROWSTKS, SI, STK, Stks=SI →m STKC

valueobs BAYS: CSA → BAYS,obs Bays: BAYS → Baysobs ROWS: BAY → ROWS,obs Rows: ROWS → Rowsobs STKS: ROW → STKS,obs Stks: STKS → Stksobs Stk: STK → C∗

Note that observe part sorts(v:V) and observe part sorts(p:P) both yield CSA .

More On Part Sorts and Types 148

The above “experimental example” motivates the below. We can always assume that compositeparts p:P abstractly consists of a definite number of subparts.

Example 13. We comment on Example 10 on Page 30: parts of type ∆ and N are composed fromthree, respectively two abstract subparts of distinct types .

Some of the parts, say piz of pi1 ,pi2 ,. . . ,pim, of p:P , may themselves be composite.

Example 14. We comment on Example 10 on Page 30: parts of type N, F, HC, LC and VC are allcomposite .

149

There are, pragmatically speaking, two cases for such compositionality. Either the part, piz , oftype tiz , is is composed from a definite number of abstract or concrete subparts of distinct types.

Example 15. We comment on Example 10 on Page 30: parts of type N are composed from threesubparts .

Or it is composed from an indefinite number of subparts of the same sort.

Example 16. We comment on Example 10 on Page 30: parts of type HC, LC and VC are composedfrom an indefinite numbers of hubs, links and vehicles, respectively .

150

Example 17 Pipeline Parts

84. A pipeline consists of an indefinite number of pipeline units.85. A pipeline units is either a well, or a pipe, or a pump, or a valve, or a fork, or a join, or a

sink.86. All these unit sorts are atomic and disjoint.


34 2 Endurants

type

84. PL, U, We, Pi, Pu, Va, Fo, Jo, Si84. Well, Pipe, Pump, Valv, Fork, Join, Sinkvalue

84. obs Us: PL → U-set

type

85. U == We | Pi | Pu | Va | Fo | Jo | Si86. We::Well, Pi::Pipe, Pu::Pump, Va::Valv, Fo:Fork, Jo::Join, Si::Sink

The experimental research report [21] covers pipelines in some detail .151

Derivation Lattices

Derivation chains start with the domain name, say ∆, and (definitively) end with the name of anatomic sort. Sets of derivation chains form join lattices [9].

Example 18 Derivation Chains Figure 2.1 illustrates two part sort and type derivation chains.based on Examples 10 on Page 30 and 12 on Page 32, respectively.152

RTS

Hs=H−set

Legend:

F MN

HS LS VS

Hs Ls Vs

H L V

Ls=L−setVs=V−set

A

B

A

B=I−>C

means:

means: obs_B: A −> B

obs_B: A −> B

CL

VS PS

CSA

BAYS

Bays=BI−>BAY

Vs=VI−>V Ps=PI−>P

where:

ROWS

Rows=RI−>ROW

STKS

Stks=SI−>STK

Stk=SI−>C*

C

Fig. 2.1. Two Domain Lattices: Examples 10 on Page 30 and 12 on Page 32

The “–>” of Fig. 2.1 stands for →m .

2.3.6 Syntactic and Semantic Qualities of Endurants 153

By an ′external endurant quality′ we shall understand the is atomic, is composite, is

discrete and is continuous qualities. We consider these to reflect ′syntactic qualities′. Byan ′internal endurant quality′ we shall understand the endurant qualities to be outlined in thenext sections: unique identification, mereology and attributes. By ′part qualities′ we meanthe sum total of external endurant and internal endurant qualities. We consider these toreflect ′semantic qualities′.



2.3.7 Three Categories of Semantic Qualities 154

We suggest that the internal qualities of parts be analysed into three categories: (i) a categoryof unique part identifiers, (ii) a category of general attributes and (iii) a category of mereologicalquantities. Part mereologies are about sharing qualities between parts. Some such sharing expresses155

spatio-topological properties of how parts are organised. Other part sharing aspects express rela-tions (like equality) of part attributes. We base our modelling of mereologies on the notion ofunique part identifiers. Hence we cover semantic qualities in the order (i–ii–iii).

2.3.8 Unique Part Identifiers 156

We can assume, without any loss of generality, that all parts, p, of any domain P, have uniqueidentifiers, that unique identifiers (of parts p:P) are abstract values (of the unique identifier sort PIof P), such that distinct part sorts, Pi and Pj , have distinctly named unique identifier sorts, sayPIi PIj , and that all πi:PIi and πj :PIj are distinct, and that the observer function uid P appliedto p yields the unique identifier, say π:PI, of p. 157

Domain Description Prompt 3 observe unique identifier : We can therefore apply the ′domaindescription prompt′:

• observe unique identifier [c.]

to parts p:P resulting in the analyser writing down the unique identifier types and observers domaindescription text according to the followig schema:3 158

3. observe unique identifier schema

Narration:

[ s ] ... narrative text on unique identifier sorts ...[ u ] ... narrative text on unique identifier observers ...[ a ] ... axiom on uniqueness of unique identifiers ...

Formalisation:

type

[ s ] PIvalue

[ u ] uid P: P → PIaxiom

[ a ] U

159

U is a predicate over part sorts and unique part identifier sorts. The unique part identifier sort, PI,is unique, as are all part sort names, P. The has unique identifier is a ′prerequisite prompt′

of observe unique identifier .160

Example 19 Unique Transportation Net Part Identifiers: We continue Example 10 on Page 30.

87. Links and hubs have unique identifiers88. and unique identifier observers.

type

87. LI, HIvalue

88. uid LI: L → LI88. uid HI: H → HIaxiom [ Well−formedness of Links, L, and Hubs, H ]87. ∀ l,l′:L • l6=l′⇒uid LI(l)6=uid LI(l′),87. ∀ h,h′:H • h6=h′⇒uid HI(h) 6=uid HI(h′)

3 Note: Do we need to secure disjointness of all unique identifier sorts ?


36 2 Endurants

.

2.3.9 Discrete Endurant Attributes 161

To recall: there are three sets of internal (i.e., semantic) endurant qualities: unique part identifiers,attributes and part mereology. Unique part identifiers and part mereology are rather definite kinds ofinternal qualities. Part attributes form more “free-wheeling” sets of internal qualities.

Inseparability of Attributes from Endurants

Endurants are typically recognised because of their spatial form (parts or materials) and areotherwise characterised by their intangible, but measurable attributes. That is, whereas endurants,whether discrete (as are parts) or continuous (as are materials), are physical, tangible, in thesense of being spatial [or being abstractions, i.e., concepts, of spatial endurants], attributes areintangible: cannot normally be touched4, or seen5, but can be objectively measured6. Thus, in ourquest for describing domains where humans play an active role, we rule out subjective “attributes”:feelings, sentiments, moods. Thus we shall abstain, in our domain science also from matters ofaesthetics. We learned from Sect. 2.2 that a formal concept, that is, a type, consists of all theentities which all have the same qualities. Thus removing a quality from an entity makes no sense:the entity of that type either becomes an entity of another type or ceases to exist (i.e., becomes anon-entity) !

Attribute Quality and Attribute Value 162

We distinguish between an attribute, as a logical proposition, and an attribute value, as a valuein some not necessarily Boolean value space.

Example 20 Attribute Propositions and Other Values: A particular street segment (i.e., a link),say ℓ, satisfies the proposition (attribute) has length, and may then have value length 90 meterfor that attribute. Another link satisfies the same proposition but has another value; And yetanother link satisfies the same proposition and may have the same value. That is: all links sat-isfies has length and has some value for that attribute. A particular road transport domain, δ,has three immediate sub-parts: net, n, fleet, f , and monitor m; typically nets has net name andhas net owner proposition attributes with, for example, US Interstate Highway System respec-tively US Department of Transportation as values for those attributes. There will be other com-ponents of the n value. .

Endurant Attributes: Types and Functions 163

Let us recall that attributes cover qualities other than unique identifiers and mereology. Let usthen consider that parts have one or more attributes. These attributes are qualities which helpcharacterise “what it means” to be a part, that is, a discrete endurant.164

Example 21 Atomic Part Attributes: Examples of attributes of atomic parts such as a humanare: name, gender, birth-date, birth-place, nationality, height, weight, eye colour, hair colour, etc.Examples of attributes of transport net links are: length, location, 1 or 2-way link, link condition,etc. .

165

4 One can see the red colour of a wall, but one touches the wall.5 One cannot see electric current, and one may touch an electric wire, but only if it conducts reasonably

high voltage can one feel it.6

philosophical note: That is, we restrict our domain analysis with respect to attributes to suchquantities which are observable, say by mechanical, electrical or chemical instruments.



Example 22 Composite Part Attributes: Examples of attributes of composite parts such as a roadnet are: owner, public or private net, free-way or toll road, a map of the net, etc. Examples ofattributes of a group of people could be: statistic distributions of gender, age, income, education,nationality, religion, etc. .

166

We now assume that all parts (and materials, see Sect. 2.3.11 on Page 45), have attributes. Thequestion is now, in general, how many and, particularly, which.

Endurant Analysis Prompt 12 attribute names: The ′domain analysis prompt′ attribute names

when applied to a part p yields the set of names of its attribute types:

• attribute names(p): ηA1, ηA2, ..., ηAn.

η is a type operator. Applied to a type A it yields is name7.167

We cannot automatically, that is, syntactically, guarantee that our domain descriptions securethat the various attribute types for the emerging part sorts denote disjoint sets of values. Thereforewe must prove it. 168

The Attribute Value Observer

The “built-in” description language operator

• attr A

applies to parts, p:P, where ηA∈attribute names(p). It yields the value of attribute A of p. 169

A Comprehensive Attributes Observer

The “built-in”, part sort independent description language operator

• obs attribs

when applied, obs attribs(e), to an endurant entity (part or material) e of type P (or M) yieldsthe set, attrs:P ATTRS, of attributes of that part such that if A1, A2, . . . , An are the types of then attributes of e then for all i (1≤i≤n) attr Ai(e) = attr Ai(obs attribs(e)). 170

Domain Description Prompt 4 observe attributes : The domain analyser experiments, thinksand reflects about part (and material, see later) attributes. That process is initated by the ′domaindescription prompt′:

• observe attributes. [d.]

The result of that ′domain description prompt′ writes down the attribute types and observersdomain description text according to the followig schema: 171

d. observe attributes schema

Narration:

[ t ] ... narrative text on attribute sorts ...[ o ] ... narrative text on attribute sort observers ...[ i ] ... narrative text on attribute sort recognisers ...[ p ] ... narrative text on attribute sort proof obligations ...

Formalisation:

type

[ t ] Ai [ 1≤i≤n ][ t ] P ATTRSvalue

[ o ] obs attribs:P→P ATTRS

7 Normally, in non-formula texts, type A is referred to by ηA. In formulas A denote a type, that is, a setof entities. Hence, when we wish to emphasize that we speak of the name of that type we use ηA.


38 2 Endurants

[ o ] attr Ai:(P|P ATTRS)→Ai [ 1≤i≤n ][ i ] is Ai:Ai→Bool [ 1≤i≤n ]axiom ∀ i:Nat • 1≤i≤n ⇒ attr Ai(p) = attr Ai(obs attribs(p))proof obligation [ Disjointness of Attribute Types ][ p ] ∀ δ:∆[ p ] let P be any part sort in [the ∆ domain description][ p ] let a:(A1|A2|...|An) in is Ai(a) 6= is Aj(a) end end [ i 6=j, 1≤i,j≤n ]

172

The type (or rather sort) definitions: A1, A2, ..., An inform us that the domain analyser

has decided to focus on the distinctly named A1, A2, ..., An attributes.8And the value clausesattr A1:(P|P ATTRS)→A1, attr A2:(P|P ATTRS)→A2, ..., attr An:(P|P ATTRS)→An are then“automatically” given: if a part (type P) has an attribute Ai then there is postulated, “by defi-nition” [eureka] an attribute observer function attr Ai:(P|P ATTRS)→Ai etcetera .

173

The fact that, for example, A1, A2, ..., An are attributes of p:P, means that the propositions

• has attribute A1(p), has attribute A2(p), ..., and has attribute An(p)

holds. Thus the observer functions attr A1, attr A2, ..., attr An can be applied to p s in P andyield attribute values a1:A1, a2:A2, ..., an:An respectively.174

Example 23 Road Hub Attributes: After some analysis a domain analyser may arrive at someinteresting hub attributes:

89. hub state: from which links (by reference) can one reach which links (by reference),90. hub state space: the set of all potential hub states that a hub may attain,91. such that

(a) the links referred to in the state are links of the hub mereology(b) and the state is in the state space.

92. Etcetera — i.e., there are other attributes not mentioned here.175

type

89. HΣ = (LI×LI)set90. HΩ = HΣ-set

value

89. attr HΣ:H→HΣ90. attr HΩ:H→HΩaxiom [ Well−formedness of Hub States, HΣ ]91. ∀ h:H • let lis = mereo H(h) in

91. let hσ = attr HΣ(h) in

91a. li,li′|li,li′:LI•(li,li′)∈ hσ⊆lis91b. ∧ hσ ∈ attr HΩ(h)91. end end

type

92. ..., ...value

92. attr ..., ...

.

8 The attribute type names are not like type names of, for example, a programming language. Insteadthey are chosen by the domain analyser to reflect on domain phenomena. Cf. Example 21 on Page 36and Example 22.



Attribute Categories 176

One can suggest a hierarchy of part attribute categories: discrete or continuous (including chaotic)values, static or dynamic values (and within the dynamic value category: inert values or reactivevalues or active values (and within the dynamic active value category: autonomous values orbiddable values or programmable values)). We now review these attribute value types. (Thereview is inspired by [67, M.A. Jackson].) 177

Part attributes are either discrete or continuous or chaotic attributes. A part attribute issaid to be a ′discrete attribute′, is discrete attribute, if it takes on a finite or countablyinfinite number of distinct or unconnected elements. A part attribute is said to be a ′continuousattribute′, is continuous attribute, if a suitable abstract model describes it as a continuousfunction from some point set value type A (A could be time) to some not necessarily point setvalue type (B): A → B. We shall not explain concepts of chaotic attributes. 178

Discrete or continuous part attributes are either constant or a variable, i.e., static or dynamicattributes. By a ′static attribute′ is static attribute, we shall understand an attribute whosevalues are constants, i.e., cannot change. By a ′dynamic attribute′, is dynamic attribute, weshall understand an attribute whose values are variable, i.e., can change. 179

Dynamic attributes are either inert, reactive or active attributes. By an ′inert attribute′,is inert attribute, we shall understand a dynamic attribute whose values only change as theresult of external stimuli where these stimuli prescribe exactly these new values. By a ′reactiveattribute′, is reactive attribute, we shall understand a dynamic attribute whose values, if theyvary, change value in response to the change of other attribute values. By an ′active attribute′,is active attribute, we shall understand a dynamic attribute whose values change (also) of itsown volition. 180

Example 24 Inert and Reactive Attributes: Busses (i.e., vehicles) have a timetable attributewhich is dynamic, i.e., can change, namely when the operator of the bus decides so, thus thebus timetable attribute is inert. Pipeline valve units include the two attributes of valve opening(open, close) and internal flow (measured, say gallons per second). The valve opening attributeis of the programmable attribute category. The flow attribute is reactive (flow changes with valveopening/closing). .

181

Active attributes are either autonomous, biddable or programmable attributes. By an ′autonomousattribute′, is autonomous attribute, we shall understand a dynamic active attribute whose val-ues change value only “on their own volition”. The values of an autonomous attributes are a“law onto themselves and their surroundings”. By a ′biddable attribute′, is biddable attribute

(of a part) we shall understand a dynamic active attribute whose values may be subjectto a contract as to which values it is expected to exhibit. By a ′programmable attribute′,is programmable attribute. we shall understand a dynamic active attribute whose values canbe accurately prescribed. 182

Example 25 Static and Dynamic Link Attributes:

93. Some link attributes(a) (link) length,(b) (link) name, e.g., Fifth Ave. between 50th and 51st Streets),can be considered static,

94. whereas other link attributes(a) (link) state (one-way: say from 51st to 50th),(b) (link) state space (one single state, one-way: say from 51st to 50th)can be considered programmable,

95. Finally link attributes(a) link state–of–repair,(b) date last maintained,can be considered inert.

183


40 2 Endurants

type

93a. LENvalue

93a. obs LEN: L → LENtype

93b. Namevalue

93b. obs Name: L → Nametype

94a. LΣ′=(HI×HI)-set94a. LΣ=|lσ:LΣ • card lσ ≤ 2|value

94a. obs LΣ: L → LΣtype

94b. LΩ′=LΣ-set

94b. LΩ=|lω:LΩ • card lω = 1|value

94b. obs LΩ: L → LΩtype

95a. LSoR95b. DLMvalue

95a. obs LSoR: L → LSoR95b. obs DLM: L → DLM

.184

Example 26 Autonomous and Programmable Hub Attributes: We continue Example 25. Timeprogresses autonomously, Hub states are programmed (traffic signals): changing from red to greenvia yellow, in one pair of (co-linear) directions, while changing, in the same time interval, fromgreen via yellow to red in the “perpendicular” directions. .

Shared Attributes 185

Normally part attributes of different part sorts are distinctly named. If, however, observe attri-

butes(pik:Pi) and observe attributes(pjℓ:Pj), for any two distinct part sorts, Pi and Pj , of adomain, “discovers” identically named attributes, say A, then we say that parts pi:Pi and pj :Pj′share′ attribute A. that is, that a:attr A(pi) (and a′:attr A(pj)) is a ′shared attribute′ (witha=a′ always () holding).186

Example 27. Shared Attributes. Examples of shared attributes: (i) Bus timetable attributes havethe same value as the regional transport system timetable attribute. (ii) Bus clock attributes havethe same value as the regional transport system clock attribute. (iii) Bus owner attributes have thesame value as the regional transport system owner attribute. (iv) Bank customer passbooks recordbank transactions on, for example, demand/deposit accounts share values with the bank generalledger passbook entries. (v) A link incident upon or emanating from a hub shares the connectionbetween that link and the hub as an attribute. (vi) Two pipeline units9, pi, pj , that are connected,such that an outlet πj of pi “feeds into” an inlet πi of pj, are said to share the connection (modelledby, e.g., (πi, πj).

187

Example 28 Shared Timetables: The fleet and vehicles of Example 10 on Page 30 and Exam-ple 11 on Page 31 is that of a bus company.

96. From the fleet and from the vehicles we observe unique identifiers.97. Every bus mereology records the same one unique fleet identifier.98. The fleet mereology records the set of all unique bus identifiers.99. A bus timetable is a share fleet and bus attribute.

188

type

96. FI, VI, BTvalue

96. uid F: F → FI96. uid V: V → VI97. mereo F: F → VI-set [cf. Sect. 2.3.10 on Page 43]

9 See upcoming Example 34 on Page 44



98. mereo V: V → FI99. attr BT: (F|V) → BTaxiom

∀ f:F ⇒ ∀ v:V • v ∈ obs Vs(obs VC(f)) • attr BT(f) = attr BT(v)[which is the same as]

∀ f:F ⇒ attr BT(f)=attr BT(v):v:V•v ∈ obs Vs(obs VC(f))

.189

Part attributes of one sort, Pi, may be simple type expressions such as A-set, where A may be anattribute of some other part sort, Pj , in which case we say that part attributes A-set and A areshared. 190

Example 29 Shared Passbooks:

100. A banking system contains• an administration and• a set of customers.

101. The administration contains a general ledger.102. An attribute of a general ledger is a set of passbooks.103. An attribute of a customer is that of a passbook.104. Passbooks are uniquely identified by unique customer identifiers.

191

type

100. [ parts ] BS, AD, GL, CS, Cs = C-set

103. [ attributes ] PBvalue

100. obs AD: BS → AD101. obs GL: AD → GL102. attr PBs: GL → PB-set

100. obs CS: BS → CS100. obs Cs: BS → Cs103. attr PB: C → PBaxiom

∀ bs:BS •

attr PBs(attr GL(obs AD(bs)))= attr PB(c)|c:C•c ∈ obs Cs(obs CS(bs))

.

Update of Dynamic Attributes 192

In order to update values of dynamic attributes the description language offers the “built-in”operator:

Attribute Update Function: upd attr

• upd attr: P × A → P

for all relevant A and P. The meaning of upd attr is, informally: 193

type

P, Avalue

upd attr: P × A → Pupd attr(p)(a) as p′


42 2 Endurants

pre: ηA ∈ attribute names(p)post: attr A(p′) = a ∧ no other qualities of P than A are affected

The above is a simplification. It lacks explaining that all other aspects of the part p:P are left194

unchanged. It also omits mentioning some proof obligations. The updated mereology must, forexample, only specify such unique identifiers of parts that are indeed existing parts.

A proper formal explication requires that we set up a formal model of the domain/method/-analyser/description quadrangle. We shall presently leave it with the above !195

Example 30 Hub State Update: We continue Example 23 on Page 38. Hub states can be con-sidered abstractions of road intersection signals, you know: red/yellow/green.

105. We consider set hub state are primitive operation(a) which takes a hub, h, and a hub state, hσ, as arguments(b) and “delivers the same” hub(c) with unchanged hub state space (etcetera)(d) but with hσ being the new value of the HΣ attribute of h.

196

value

105. set hub state:105a. H → HΣ →105b. H105. set hub state(h)(hσ) as h′

105. pre: hσ ∈ attr HΩ(h)105. post: hσ ∈ attr HΩ(h′)105c. ∧ h′ = upd HΣ of H(h)(hσ)

.

2.3.10 Mereology 197

Mereology is the study and knowledge of parts and part relations. Mereology as a logical/philoso-phical discipline can perhaps best be attributed to the Polish mathematician/logician Stanis lawLesniewski [74, 97, 98].

Part Relations 198

Which are the relations that can be relevant for part-hood ? We give some examples.

• Two otherwise distinct parts may share attribute values. 10

Example 31 Shared Attribute Mereology: Examples: (i) two or more distinct public transportbusses may run according to the same, thus “shared”, bus time table; (ii) all vehicles in a trafficparticipate in that traffic each with their “share”: that is, position on links or at hubs – asobserved by the (thus postulated) traffic observer. etcetera. .

199

• Two otherwise distinct parts may be said to, for example, be topologically “adjacent” or one“embedded” within the other.

Example 32 Topological Connectedness Mereology: Examples: (i) two rail units may beconnected (i.e., adjacent), (ii) a road link may be connected to two road hubs; (iii) a roadhub may be connected to zero or more road links; etcetera. .

The above examples are in no way indicative of the “space” of part relations that may be relevantfor part-hood ? The domain analyser is expected to do a bit of experimental research in order todiscover necessary, sufficient and pleasing “mereology-hoods” !

10 For the concept of attribute value see Sect. 2.3.9 on Page 36.



Part Mereology: Types and Functions 200

If a composite part p consists of a definite number of sub-parts: a, ..., c, then that is the mereologyof any p with respect to any a, ..., c, and we need not bother about unique identifiers for p. In thiscase we have the situation that:

type

P, A, ..., Cvalue

obs A: P → A, ..., obs C: P → C.201

If, however, a composite part p consists of an indefinite number of sub-parts, q1, ..., qn, that is, ifwe have the situation that:

type

P, Q, Ps = Q-set

value

obs Ps: P → Q-set,

then the mereology need to be further elaborated.

Endurant Analysis Prompt 13 has mereology: To do so the analyser can be said to endow atruth value true to the ′domain analysis prompt′:

• has mereology202

When the domain analyser decides that some parts are related in a specifically enunciatedmereology, then the analyser has to decide on suitable mereology types and mereology (i.e., partrelation) observers.

We can define a ′mereology type′ as a type Expression over unique [part] identifier types. Wegeneralise to unique [part] identifier over a definite collection of part sorts, P1, P2, ..., Pn, wherethe parts p1:P1, p2:P2, ..., pn:Pn are not necessarily (immediate) sub-parts of some part p:P.

type

PI1, PI2, ..., PInMT = E(PI1, PI2, ..., PIn),

203

Domain Description Prompt 5 observe mereology : If has mereology(p) holds for parts p oftype P, then the analyser can apply the ′domain description prompt′:

• observe mereology [e.]

to parts of that type and write down the mereology types and observers domain description textaccording to the followig schema: 204

5. observe mereology schema

Narration:

[ t ] ... narrative text on mereology type ...[ m ] ... narrative text on mereology observer ...[ a ] ... narrative text on mereology type constraints ...

Formalisation:

type

[ t ] MT = E(PI1,PI2,...,PIm)value

[ m ] mereo P: P → MTaxiom [ Well−formedness of Domain Mereologies ][ a ] A(PI1,PI2,...,PIm)


44 2 Endurants

205

Here E(PI1,PI2,...,PIm) is a type expression over possibly all unique identifier types of the domaindescription, and A(PI1,PI2,...,PIm) is a predicate over possibly all unique identifier types of thedomain description. To write down the concrete type definition for MT requires a bit of analysisand thinking. has mereology is a ′prerequisite prompt′ for observe mereology .

206

Example 33 Road Net Part Mereologies: We continue Example 10 on Page 30 and Example 19on Page 35.

106. Links are connected to exactly two distinct hubs.107. Hubs are connected to zero or more links.108. For a given net the link and hub identifiers of the mereology of hubs and links must be those

of links and hubs, respectively, of the net.

type

106. LM′ = HI-set, LM = |his:HI-set • card(his)=2|107. HM = LI-setvalue

106. mereo L: L → LM107. mereo H: H → HMaxiom [ Well−formedness of Road Nets, N ]108. ∀ n:N,l:L,h:H• l ∈ obs Ls(obs LC(n))∧h ∈ obs Hs(obs GC(n))108. let his=mereology H(l), lis=mereology H(h) in

108. his⊆∪uid H(h) | h ∈ obs Hs(obs HC(n))108. ∧ lis⊆∪uid H(l) | l ∈ obs Ls(obs LC(n)) end

The experimental research report [22] covers well-formedness of road nets. .207

Example 34 Pipeline Parts Mereology: We continue Example 17 on Page 33. Pipeline unitsserve to conduct fluid or gaseous material. The flow of these occur in only one direction: fromso-called input to so-called output.

109. Wells have exactly one connection to an output unit.110. Pipes, pumps and valves have exactly one connection from an input unit and one connection

to an output unit.111. Forks have exactly one connection from an input unit and exactly two connections to distinct

output units.112. Joins have exactly one two connection from distinct input units and one connection to an

output unit.113. Sinks have exactly one connection from an input unit.114. Thus we model the mereology of a pipeline unit as a pair of disjoint sets of unique pipeline

unit identifiers.208

type

114. UM′=(UI-set×UI-set)114. UM=|(iuis,ouis):UI-set×UI-set•iuis ∩ ouis=|value

114. mereo U: UMaxiom [ Well−formedness of Pipeline Systems, PLS (0) ]

∀ pl:PL,u:U • u ∈ obs Us(pl) ⇒let (iuis,ouis)=mereo U(u) in

case (card iuis,card ouis) of

109. (0,1) → is We(u),110. (1,1) → is Pi(u)∨is Pu(u)∨is Va(u),



111. (1,2) → is Fo(u),112. (2,1) → is Jo(u),113. (1,0) → is Si(u)

end end

Example 40 on Page 48 (axiom Page 48), Example 41 on Page 48 (axiom Page 49) and Example 42on Page 49 (axiom Page 51) illustrates the need to constrain the sets of endurant entities denotedby definitions of part sort, unique identifier and mereology attribute definitions. .

Update of Mereologies 209

We normally consider a part’s mereology to be constant. There may, however, be cases where themereology of a part changes. In order to update mereology values the description language offersthe “built-in” operator:

Mereology Update Function: upd mereology

• upd mereology: P → M → P

for all relevant M and P. The meaning of upd mereology is, informally: 210

type

P, Mvalue

upd mereology: P → M → Pupd mereology(p)(m) as p′

post: mereo (p′) = m

Again, the above is a simplification. Remarks similar to those given for upd attr apply (Page 42).211

Example 35 Mereology Update: The example is that of updating the mereology of a hub.Cf. Example 33 on the facing page.

115. Inserting a link, l:L, between two hubs, ha:H,hb:H require the update of the mereologies of thesetwo existing hubs.

116. The unique identifier of the inserted link, l:L, is li, li=uid L(l) and h is either ha or hb;117. li is joined to the mereology of either ha or hb; and respective hubs are updated accordingly.

value

115. update hub mereology: H → LI → H116. update hub mereology(h)(li) ≡117. let m = li ∪ mereo (h) in upd mereology(h)(m) end

.

2.3.11 Materials: Continuous Endurants 212

We refer to Page27 for a first coverage of the concept of materials.Continuous endurants (i.e., ′material′s) are entities, m, which satisfy:

• is material(m) ≡ is endurant(m)∧is continuous(m)

Example 36 Parts and Materials: We observe materials as components of parts: Thus liquid orgaseous materials are observed in pipeline units. We can also observe parts immersed in materials:container vessels “floats” on the oceans; aircrafts flies in the air ! .

We shall in this book not cover the case of parts being immersed in materials11. 213

11 Most such cases have the material play a minor, an abstract role with respect to the immersed parts.That is, we presently leave it to hydro- and aerodynamics to domain analyse those cases.


46 2 Endurants

We now complement the observe part sorts (of Sect. 2.3.5). We assume, without loss ofgenerality, that only atomic parts ay contain materials. Let p:P be some atomic part.

Endurant Analysis Prompt 14 has materials: The ′domain analysis prompt′:

• has materials(p)

yields true if a component m of the atomic p:P satisfies is material(m), otherwise false .214

Let us assume that parts p:P embodies materials of sorts M1,M2,. . . ,Mn. Since we cannotautomatically guarantee that our domain descriptions secure that each Mi ([ 1≤i≤n ]) denotesdisjoint sets of entities we must prove it.

Domain Description Prompt 6 observe material sorts : The ′domain description prompt′:

• observe material sorts(e)[f.]

yields the material sorts and material sort observers domain description text according to the followigschema:215

6. observe material sorts schema

Narration:

[ s ] ... narrative text on material sorts ...[ o ] ... narrative text on material sort observers ...[ i ] ... narrative text on material sort recognisers ...[ p ] ... narrative text on material sort proof obligations ...

Formalisation:

type

[ t ] Mi [ 1≤i≤n ]value

[ o ] obs Mi: P → Mi [ 1≤i≤n ][ i ] is Mi: M → Bool [ 1≤i≤n ]

proof obligation [ Disjointness of Material Sorts ][ p ] ∀ mi:(M1|M2|...|Mn) •

[ p ]∧

is Mi(mi) ≡∨∼is Mj(mi)|j ∈ 1..m\i|i ∈ 1..m

216

The Mi are all distinct .

Example 37 Pipeline Material: We continue Example 17 on Page 33 and Example 34 onPage 44.

118. When we apply obs material sorts U to any unit u:U we obtain(a) a type clause stating the material sort LoG for some further undefined liquid or gaseous

material, and(b) a material observer function signature.

type

118a LoGvalue

118b obs LoG: U → LoG

.



Material Qualities 217

It seems that we do not need to model unique identifier nor mereology qualities of materials12. Butmaterials do have attributes. We extend the usual attribute-related analysis and synthesis prompts(observe attributes) to apply also to materials. 218

Example 38 Pipeline Material Attributes: We continue Examples 17, 34 and 37 on the precedingpage. One possible attribute of the liquid material of pipelines are liquid type: organic oil ormineral oil, For, for example, mineral oil there are many, many petrochemical attributes. Werefer to standard work on petrochemistry for details. .

Materials-related Part Attributes 219

It seems that the “interplay” between parts and materials is an area where domain analysis in thesense of this book is relevant. 220

Example 39 Pipeline Material Flow: We continue Examples 17, 34, 37 and 38. Let us postulatea[n attribute] sort Flow. We now wish to examine the flow of liquid (or gaseous) material in pipelineunits. We use two types

119. F for “productive” flow, and L for wasteful leak.

Flow and leak is measured, for example, in terms of volume of material per second. We thenpostulate the following unit attributes “measured” at the point of in- or out-flow or in the interiorof a unit. 221

120. current flow of material into a unit input connector,121. maximum flow of material into a unit input connector while maintaining laminar flow,122. current flow of material out of a unit output connector,123. maximum flow of material out of a unit output connector while maintaining laminar flow,124. current leak of material at a unit input connector,125. maximum guaranteed leak of material at a unit input connector,126. current leak of material at a unit input connector,127. maximum guaranteed leak of material at a unit input connector,128. current leak of material from “within” a unit, and129. maximum guaranteed leak of material from “within” a unit.

222

type

119. F, Lvalue

120. attr cur iF: U → UI → F121. attr max iF: U → UI → F122. attr cur oF: U → UI → F123. attr max oF: U → UI → F124. attr cur iL: U → UI → L125. attr max iL: U → UI → L126. attr cur oL: U → UI → L127. attr max oL: U → UI → L128. attr cur L: U → L129. attr max L: U → L

The maximum flow attributes are static attributes and are typically provided by the manufactureras indicators of flows below which laminar flow can be expected. The current flow attributes aredynamic attributes. .

12 Note: We might be persuaded to call the isotope marking of a liquid (for the purposes of tracing thesources or sinks of that liquid) a unique identifier.


48 2 Endurants

Laws of Material Flows and Leaks 223

It may be difficult or costly, or both, to ascertain flows and leaks in materials-based domains. Butone can certainly speak of these concepts. This casts new light on domain modelling. That is incontrast to incorporating such notions of flows and leaks in requirements modelling where one hasto show implementability.

Modelling flows and leaks is important to the modelling of materials-based domains.224

Example 40 Pipelines: Intra Unit Flow and Leak Law:

130. For every unit of a pipeline system, except the well and the sink units, the following law apply.131. The flows into a unit equal

(a) the leak at the inputs(b) plus the leak within the unit(c) plus the flows out of the unit(d) plus the leaks at the outputs.

225

axiom [ Well−formedness of Pipeline Systems, PLS (1) ]130. ∀ pls:PLS,b:B\We\Si,u:U •

130. b ∈ obs Bs(pls)∧u=obs U(b)⇒130. let (iuis,ouis) = mereo U(u) in

131. sum cur iF(iuis)(u) =131a. sum cur iL(iuis)(u)131b. ⊕ attr cur L(u)131c. ⊕ sum cur oF(ouis)(u)131d. ⊕ sum cur oL(ouis)(u)130. end

226

132. The sum cur iF (cf. Item 131) sums current input flows over all input connectors.133. The sum cur iL (cf. Item 131a) sums current input leaks over all input connectors.134. The sum cur oF (cf. Item 131c) sums current output flows over all output connectors.135. The sum cur oL (cf. Item 131d) sums current output leaks over all output connectors.

132. sum cur iF: UI-set → U → F132. sum cur iF(iuis)(u) ≡ ⊕ attr cur iF(ui)(u)|ui:UI•ui ∈ iuis133. sum cur iL: UI-set → U → L133. sum cur iL(iuis)(u) ≡ ⊕ attr cur iL(ui)(u)|ui:UI•ui ∈ iuis134. sum cur oF: UI-set → U → F134. sum cur oF(ouis)(u) ≡ ⊕ attr cur iF(ui)(u)|ui:UI•ui ∈ ouis135. sum cur oL: UI-set → U → L135. sum cur oL(ouis)(u) ≡ ⊕ attr cur iL(ui)(u)|ui:UI•ui ∈ ouis

⊕: (F|L) × (F|L) → F

where ⊕ is both an infix and a distributed-fix function which adds flows and or leaks. .227

Example 41 Pipelines: Inter Unit Flow and Leak Law:

136. For every pair of connected units of a pipeline system the following law apply:(a) the flow out of a unit directed at another unit minus the leak at that output connector(b) equals the flow into that other unit at the connector from the given unit plus the leak at

that connector.



axiom [ Well−formedness of Pipeline Systems, PLS (2) ]136. ∀ pls:PLS,b,b′:B,u,u′:U•

136. b,b′⊆obs Bs(pls)∧b6=b′∧u′=obs U(b′)136. ∧ let (iuis,ouis)=mereo U(u),(iuis′,ouis′)=mereo U(u′),136. ui=uid U(u),ui′=uid U(u′) in

136. ui ∈ iuis ∧ ui′ ∈ ouis′ ⇒136a. attr cur oF(u′)(ui′) − attr leak oF(u′)(ui′)136b. = attr cur iF(u)(ui) + attr leak iF(u)(ui)136. end

136. comment: b′ precedes b

228

From the above two laws one can prove the theorem: what is pumped from the wells equals whatis leaked from the systems plus what is output to the sinks. We need formalising the flow and leaksummation functions. .

2.3.12 “No Junk, No Confusion” 229

Domain descriptions are, as we have already shown, formulated, both informally and formally,by means of abstract types, that is, by sorts for which no concrete models are usually given. Sortsare made to denote possibly empty, possibly infinite, rarely singleton, sets of entities on the basisof the qualities defined for these sorts, whether external or internal. By ′junk′ we shall understand 230

that the domain description unintentionally denotes undesired entities. By ′confusion′ we shallunderstand that the domain description unintentionally have two or more identifications of thesame entity or type. The question is can we formulate a [formal] domain description such that it doesnot denote junk or confusion ? The short answer to this is no ! So, since one naturally wishes “no 231

junk, no confusion” what does one do ? The answer to that is one proceeds with great care ! Toavoid junk we have stated a number of sort well-formedness axioms, for example:

• Page35 for Well-formedness of Links, L, and Hubs, H,• Page43 for Well-formedness of Domain Mereologies,• Page44 for Well-formedness of Road Nets, N,• Page44 for Well-formedness of Pipeline Systems, PLS (0),• Page38 for Well-formedness of Hub States, HΣ,• Page48 for Well-formedness of Pipeline Systems, PLS (1),• Page49 for Well-formedness of Pipeline Systems, PLS (2),• Page50 for Well-formedness of Pipeline Route Descriptors and• Page51 for Well-formedness of Pipeline Systems, PLS (3).

232

To avoid confusion we have stated a number of proof obligations:

• Page30 for Disjointness of Part Sorts,• Page38 for Disjointness of Attribute Types and• Page46 for Disjointness of Material Sorts.

233

Example 42 No Pipeline Junk: We continue Example 17 on Page 33 and Example 34 on Page 44.We define a pipeline route to be a sequence of connected pipeline units in the direction of the flow.

137. A well-formed pipeline system is then one that does not allow “junky” routes, i.e., routes(a) that are circular,(b) that requires each well to be connected to at least one sink, and(c) where each sink is reachable from at least one well.

To formalise the above we describe some auxiliary notions. 234


50 2 Endurants

Pipe Routes

138. A route (of a pipeline system) is a sequence of connected units (of the pipeline system).139. A route descriptor is a sequence of unit identifiers and the connected units of a route (of a

pipeline system).

type

138. R′ = Uω

138. R = | r:Route′•wf Route(r) |139. RD = UIω

axiom [ Well−formedness of Pipeline Route Descriptors, RD ]139. ∀ rd:RD • ∃ r:R•rd=descriptor(r)

value

139. descriptor: R → RD139. descriptor(r) ≡ 〈uid UI(r[ i ])|i:Nat•1≤i≤len r〉

235

140. Two units are adjacent if the output unit identifiers of one shares a unique unit identifier withthe input identifiers of the other.

value

140. adjacent: U × U → Bool

140. adjacent(u,u′) ≡140. let (,ouis)=mereo U(u),140. (iuis,)=mereo U(u′) in

140. ouis ∩ iuis 6= end

236

141. Given a pipeline system, pls, one can identify the (possibly infinite) set of (possibly infinite)routes of that pipeline system.(a) The empty sequence, 〈〉, is a route of pls.(b) Let u be a unit of pls, then 〈uid UI(u)〉 is a route of pls.(c) Let u, u′ be any units of pls, such that an output unit identifier of u is the same as an

input unit identifier of u′ then 〈u, u′〉 is a route of pls.(d) If r and r′ are routes of pls such that the last element of r is the same as the first element

of r′, then rtl r′ is a route of pls.(e) No sequence of units is a route unless it follows from a finite (or an infinite) number of

applications of the basis and induction clauses of Items 141a–141d.

value

141. Routes: PLS → RD-infset

141. Routes(pls) ≡141a. let rs = 〈〉141a. ∪ 〈uid UI(u)〉|u:U•u ∈ obs Us(pls)141c. ∪ 〈uid UI(u),uid UI(u′)〉|u,u′:U•u,u′⊆obs Us(pls) ∧ adjacent(u,u′)141d. ∪ rtl r′|r,r′:R•r,r′⊆rs∧r[ len r ]=hd r′141e. in rs end

237

Well-formed Routes

142. A route is acyclic if no two route positions reveal the same unique unit identifier.

value

142. acyclic Route: R → Bool

142. acyclic Route(r) ≡ ∼∃ i,j:Nat•i,j⊆inds r ∧ i6=j ∧ r[ i ]=r[ j ]

238



Well-formed Pipeline Systems

143. A pipeline system is well-formed if(a) none of its routes are circular and(b) all of its routes embedded in well-to-sink routes.

axiom [ Well−formedness of Pipeline Systems, PLS (3) ]143. ∀ pls:PLS •

143a. non circular(pls)143b. ∧ are embedded in well to sink Routes(pls)

value

143. non circular PLS: PLS → Bool

143. non circular PLS(pls) ≡143. ∀ r:R•r ∈ routes(p)∧acyclic Route(r)

239

144. We define well-formedness in terms of well-to-sink routes, i.e., routes which start with a wellunit and end with a sink unit.

value

144. well to sink Routes: PLS → R-set

144. well to sink Routes(pls) ≡144. let rs = Routes(pls) in

144. r|r:R•r ∈ rs ∧ is We(r[ 1 ]) ∧ is Si(r[ len r ]) end

240

145. A pipeline system is well-formed if all of its routes are embedded in well-to-sink routes.

145. are embedded in well to sink Routes: PLS → Bool

145. are embedded in well to sink Routes(pls) ≡145. let wsrs = well to sink Routes(pls) in

145. ∀ r:R • r ∈ Routes(pls) ⇒145. ∃ r′:R,i,j:Nat •

145. r′ ∈ wsrs145. ∧ i,j⊆inds r′∧i≤j145. ∧ r = 〈r′[ k ]|k:Nat•i≤k≤j〉 end

241

Embedded Routes

146. For every route we can define the set of all its embedded routes.

value

146. embedded Routes: R → R-set

146. embedded Routes(r) ≡146. 〈r[ k ]|k:Nat•i≤k≤j〉 | i,j:Nat• i i,j⊆inds(r) ∧ i≤j

242

A Theorem

147. The following theorem is conjectured:(a) the set of all routes (of the pipeline system)(b) is the set of all well-to-sink routes (of a pipeline system) and(c) all their embedded routes


52 2 Endurants

theorem:

147. ∀ pls:PLS •

147. let rs = Routes(pls),147. wsrs = well to sink Routes(pls) in

147a. rs =147b. wsrs ∪147c. ∪ r′|r′:R • r′ ∈ embedded Routes(r′′) | r′′:R • r′′ ∈ wsrs146. end

.243

The above example, besides illustrating one way of coping with “junk”, also illustrated the needfor introducing a number of auxiliary notions: types, functions, axioms and theorems.

2.3.13 Discussion of Endurants 244

In Sect. 2.3.5 on Page 29 a “depth-first” search for part sorts was hinted at. It essentially expressedthat we discover domains epistemologically but understand them ontologically. The Danish philoso-pher Søren Kirkegaard (1813–1855) expressed it this way: Life is lived forwards, but is understoodbackwards. The presentation of the of the ′domain analysis prompt′s and the ′domain descriptionprompt′s is based on resulting in a domain description which is ontological. The “depth-first”search recognizes the epistemological nature of bringing about understanding. This “depth-first”245

search that ends with the analysis of atomic part sorts can be guided, i.e., hastened (shortened),by postulating composite sorts that “correspond” to vernacular nouns: everyday nouns that standfor classes of endurants.246

We could have chosen our ′domain analysis prompt′s and ′domain description prompt′s toreflect a “bottom-up” epistemology, one that reflected how we composed composite understandingsfrom initially atomic parts. We leave such a collection of ′domain analysis prompt′s and ′domaindescription prompt′s to the reader.

2.4 Comparison to Other Work 247

Section 2.3 outlined the TripTych modelling approach to domain endurants. We shall now comparethat approach to a number of techniques and tools that are somehow related — if only by theterm ‘domain’ !

2.4.1 Ontological and Knowledge Engineering: 248

Ontological engineering [8] build ontologies. Ontologies are “formal representations of a set of conceptswithin a domain and the relationships between those concepts” — expressed usually in some logic.Published ontologies usually consists of thousands of logical expressions. These are represented insome, for example, low-level mechanisable form so that they can be interchanged between ontologyresearch groups and processed by various tools. There does not seem to be a concern for “deriving”249

such ontologies into requirements for software. Usually ontology presentations either start withthe presentation of, or makes reference to its reliance on, an upper ontology. Instead the ontologydatabases appear to be used for the computerised discovery and analysis of relations betweenontologies.250

The aim of knowledge engineering was formulated, in 1983, by an originator of the concept,Edward A. Feigenbaum [43]: knowledge engineering is an engineering discipline that involves inte-grating knowledge into computer systems in order to solve complex problems normally requiringa high level of human expertise. A seminal text is that of [41]. Knowledge engineering focus on251

continually building up (acquire) large, shared data bases (i.e., knowledge bases), their continuedmaintenance, testing the validity of the stored ‘knowledge’, continued experiments with respect to



knowledge representation, etcetera. Knowledge engineering can, perhaps, best be understood in con-252

trast to algorithmic engineering: In the latter we seek more-or-less conventional, usually imperativeprogramming language expressions of algorithmswhose algorithmic structure embodies the knowledgerequired to solve the problem being solved by the algorithm. The former seeks to solve problems basedon an interpreter inferring possible solutions from logical data. This logical data has three parts:acollection that “mimics” the semantics of, say, the imperative programming language, a collection thatformulates the problem, and a collection that constitutes the knowledge particular to the problem. Werefer to [25]. 253

The concerns of TripTych domain science & engineering is based on that of algorithmic engi-neering. Domain science & engineering is not aimed at letting the computer solve problems basedon the knowledge it may have stored. Instead it builds models based on knowledge of the do-main. The TripTych form of domain science & engineering differs from conventional ontological 254

engineering in the following, essential ways: The TripTych domain descriptions rely essentiallyon a “built-in” upper ontology: types, abstract as well as model-oriented (i.e., concrete) and ac-tions, events and behaviours. Domain science & engineering is not, to a first degree, concernedwith modalities, and hence do not focus on the modelling of knowledge and belief, necessity andpossibility, i.e., alethic modalities, epistemic modality (certainty), promise and obligation (deonticmodalities), etcetera.

2.4.2 Domain Analysis: 255

Domain analysis, or product line analysis (see below), as it was then conceived in the early 1980sby James Neighbors is the analysis of related software systems in a domain to find their commonand variable parts. It is a model of wider business context for the system. This form of domainanalysis turns matters “upside-down”: it is the set of software “systems” (or packages) that issubject to some form of inquiry, albeit having some domain in mind, in order to find commonfeatures of the software that can be said to represent a named domain. In this section we shall 256

mainly be comparing the TripTych approach to domain analysis to that of Reuben Prieto-Dıaz’sapproach [83, 84, 85]. Firstly, the two meanings of domain analysis basically coincide. Secondly,in, for example, [83], Prieto-Dıaz’s domain analysis is focused on the very important stages thatprecede the kind of domain modelling that we have described: major concerns are selection of whatappears to be similar, but specific entities, identification of common features, abstraction of entities andclassification. Selection and identification is assumed in our approach, but we suggest to follow theideas of Prieto-Dıaz. Abstraction (from values to types and signatures) and classification into parts,materials, actions, events and behaviours is what we have focused on. All-in-all we find Prieto- 257

Dıaz’s work very relevant to our work: relating to it by providing guidance to pre-modelling steps,thereby emphasising issues that are necessarily informal, yet difficult to get started on by mostsoftware engineers. Where we might differ is on the following: although Prieto-Dıaz does mentiona need for domain specific languages, he does not show examples of domain descriptions in suchDSLs. We, of course, basically use mathematics as the DSL. In our approach we do not considerrequirements, let alone software components, as do Prieto-Dıaz, but we find that that is not animportant issue.

2.4.3 Domain Specific Languages 258

Martin Fowler13defines a Domain-specific language (DSL) as a computer programming language oflimited expressiveness focused on a particular domain [45]. Other references are [78, 96]. Common to[96, 78, 45] is that they define a domain in terms of classes of software packages; that they neverreally “derive” the DSL from a description of the domain; and that they certainly do not describethe domain in terms of that DSL, for example, by formalising the DSL.

13 http://martinfowler.com/dsl.h


54 2 Endurants

2.4.4 Feature-oriented Domain Analysis (FODA): 259

Feature oriented domain analysis (FODA) is a domain analysis method which introduced featuremodelling to domain engineering FODA was developed in 1990 following several U.S. Governmentresearch projects. Its concepts have been regarded as critically advancing software engineeringand software reuse. The US Government supported report [70] states: “FODA is a necessary firststep” for software reuse. To the extent that TripTych domain engineering with its subsequent260

requirements engineering indeed encourages reuse at all levels: domain descriptions and requirementsprescription, we can only agree. Another source on FODA is [36]. Since FODA “leans” quite heavilyon ‘Software Product Line Engineering’ our remarks in that section, next, apply equally well here.

2.4.5 Software Product Line Engineering: 261

Software product line engineering, earlier known as domain engineering, is the entire process ofreusing domain knowledge in the production of new software systems. Key concerns of softwareproduct line engineering are reuse, the building of repositories of reusable software components,and domain specific languages with which to more-or-less automatically build software based onreusable software components. These are not the primary concerns of TripTych domain science &262

engineering. But they do become concerns as we move from domain descriptions to requirementsprescriptions. But it strongly seems that software product line engineering is not really focused on theconcerns of domain description — such as is TripTych domain engineering. It seems that softwareproduct line engineering is primarily based, as is, for example, FODA: Feature-oriented Domain

Analysis, on analysing features of software systems. Our [17] puts the ideas of software productlines and model-oriented software development in the context of the TripTych approach.

2.4.6 Problem Frames: 263

The concept of problem frames is covered in [68]. Jackson’s prescription for software developmentfocus on the “triple development” of descriptions of the problem world, the requirements and themachine (i.e., the hardware and software) to be built. Here domain analysis means, the same as forus, the problem world analysis. In the problem frame approach the software developer plays three,264

that is, all the TripTych roles: domain engineer, requirements engineer and software engineer, “allat the same time”, iterating between these roles repeatedly. So, perhaps belabouring the point,domain engineering is done only to the extent needed by the prescription of requirements and thedesign of software. These, really are minor points. But in “restricting” oneself to consider only those265

aspects of the domain which are mandated by the requirements prescription and software design oneis considering a potentially smaller fragment [66] of the domain than is suggested by the TripTychapproach. At the same time one is, however, sure to consider aspects of the domain that might havebeen overlooked when pursuing domain description development in the “more general” TripTych

approach.

2.4.7 Domain Specific Software Architectures (DSSA): 266

It seems that the concept of DSSA was formulated by a group of ARPA14project “seekers” who alsoperformed a year long study (from around early-mid 1990s); key members of the DSSA projectwere Will Tracz, Bob Balzer, Rick Hayes-Roth and Richard Platek [101]. The [101] definition ofdomain engineering is “the process of creating a DSSA: domain analysis and domain modelling followedby creating a software architecture and populating it with software components.” This definition267

is basically followed also by [79, 95, 76]. Defined and pursued this way, DSSA appears, notably inthese latter references, to start with the analysis of software components, “per domain”, to identifycommonalities within application software, and to then base the idea of software architecture onthese findings. Thus DSSA turns matter “upside-down” with respect to TripTych requirements268

14 ARPA: The US DoD Advanced Research Projects Agency



development by starting with software components, assuming that these satisfy some requirements,and then suggesting domain specific software built using these components. This is not what weare doing: we suggest that requirements can be “derived” systematically from, and related back,formally to domain descriptionss without, in principle, considering software components, whetheralready existing, or being subsequently developed. Of course, given a domain description it is 269

obvious that one can develop, from it, any number of requirements prescriptions and that thesemay strongly hint at shared, (to be) implemented software components; but it may also, as well,be the case two or more requirements prescriptions “derived” from the same domain description mayshare no software components whatsoever ! It seems to this author that had the DSSA promoters 270

based their studies and practice on also using formal specifications, at all levels of their study andpractice, then some very interesting insights might have arisen.

2.4.8 Domain Driven Design (DDD) 271

Domain-driven design (DDD)15“is an approach to developing software for complex needs by deeplyconnecting the implementation to an evolving model of the core business concepts; the premiseof domain-driven design is the following: placing the project’s primary focus on the core domainand domain logic; basing complex designs on a model; initiating a creative collaboration betweentechnical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.”16

We have studied some of the DDD literature, mostly only accessible on the Internet, but see also 272

[56], and find that it really does not contribute to new insight into domains such as wee see them:it is just “plain, good old software engineering cooked up with a new jargon.

2.4.9 Unified Modelling Language (UML) 273

Three books representative of UML are [28, 91, 69]. The term domain analysis appears numeroustimes in these books, yet there is no clear, definitive understanding of whether it, the domain, standsfor entities in the domain such as we understand it, or whether it is wrought up, as in several of the‘approaches’ treated in this section, to wit, Items [3,4,5,7,8], with either software design (as it mostoften is), or requirements prescription. Certainly, in UML, in [28, 91, 69] as well as in most published 274

papers claiming “adherence” to UML, that domain analysis usuallyis manifested in some UML textwhich “models” some requirements facet. Nothing is necessarily wrong with that, but it is thereforenot really the TripTych form of domain analysis with its concepts of abstract representations ofendurant and perdurants, and with its distinctions between domain and requirements, and withits possibility of “deriving” requirements prescriptions from domain descriptions. The UML notion of 275

class diagrams is worth relating to our structuring of the domain. Class diagrams appear to beinspired by [6, Bachman, 1969] and [31, Chen, 1976]. It seems that each part sort — as well as otherthan part (or material) sorts — deserves a class diagram (box), that (assignable) attributes — aswell as other non-part (or material) types — are written into the diagram box — as are actionsignatures — as well as other function signatures. Class diagram boxes are line connected with 276

annotations where some annotations are as per the mereology of the part type and the connectedpart types and others are not part related. The class diagrams are said to be object-oriented butit is not clear how objects relate to parts as many are rather implementation-oriented quantities.All this needs looking into a bit more, for those who care.

• • •277

Summary of Comparisons: It should now be clear from the above that basically only Jackson’sproblem frames really take the same view of domains and, in essence, basically maintain similarrelations between requirements prescription and domain description. So potential sources of, weshould claim, mutual inspiration ought be found in one-another’s work — with, for example,[50, 66], and the present document, being a good starting point. 278

15 Eric Evans: http://www.domaindrivendesign.org/16 http://en.wikipedia.org/wiki/Domain-driven design


56 2 Endurants

But none of the referenced works make the distinction between discrete endurants (parts) andtheir qualities, with their further distinctions between unique identifiers, mereology andattributes.And none of them makes the distinction between parts and materials. Therefore our contribu-tion can include the mapping of parts into behaviours interacting as per the part mereologies ashighlighted in the process schemas of Sect. 3.8.4 Pages63–63.


3

Perdurants 279

3.1 Introduction

We shall give only a cursory overview of perdurants. That is, we shall not systematically present aset of ′domain analysis prompt′s and a set of ′domain description prompt′s leading to descriptionlanguage, i.e., RSL texts describing perdurant entities. 280

The reason for giving this albeit cursory overview of perdurants is that we can justify our de-tailed study of endurants, their part and subparts, their unique identifiers, attributes and mereol-ogy. This justification is found in expressing the types of signatures, in basing behaviours on parts,in basing the for need CSP-oriented inter-behaviour communications on shared part attributes, inindexing behaviours as are parts, i.e., on unique identifiers, and in directing inter-behaviour com-munications across channel arrays indexed as per the mereology of the part behaviours. These are 281

all notion related to endurants and now justified by their use in describing perdurants.Perdurants can perhaps best be explained in terms of a notion of time and a notion of state.

We shall in this book not go into notions of time, but refer to [57, 42, 27, 102].

3.2 States 282

Definition 22 State: By a ′state′ we shall understand any collection of endurants each of whichhas at least one dynamic attribute.

Example 43 States Some examples of states are: A road hub can be a state, cf. Hub State, LΣ,Example 23 on Page 38. A road net can be a state – since its hubs can be. Container stowageareas. CSA, Example 12 on Page 32, of container vessels and container terminal ports can bestates as containers can be removed from and put on top of container stacks .

3.3 Actions, Events and Behaviours 283

To us perdurants are further analysed into actions, events, and behaviours. Common to all of themis that they potentially change a state. Actions and events are here considered atomic perdurants.For behaviours we distinguish between discrete and continuous behaviours.

3.3.1 Time Considerations 284

We shall, without loss of generality, assume that actions and events are atomic and that behavioursare composite. Atomic perdurants may “occur” during some time interval, but we omit consid-eration of and concern for what actually goes on during such an interval. Composite perdurantscan be analysed into “constituent” actions, events and “sub-behaviours”. We shall also omit con-sideration of temporal properties of behaviours. Instead we shall refer to two seminal textbooks: 285

Duration Calculus: A Formal Approach to Real-Time Systems [108, Zhou ChaoChen and MichaelRweichhardt Hansen] and Specifying Systems [73, Leslie Lamport]

58 3 Perdurants

3.3.2 Actors 286

Definition 23 Actor: By an ′actor′ we shall understand something that is capable of initiatingand/or carrying out actions, events or behaviours.

287

Example 44 Actors We refer to the road transport and the pipeline systems examples of earlier.The fleet, each vehicle and the road management of the Transportation system of Examples 10on Page 30 and 28 on Page 40 can be considered actors; so can the net and its links and hubs.The pipeline monitor and each pipeline unit of the Pipeline System, Example 17 on Page 33 andExamples 17 on Page 33 and 34 on Page 44 will be considered actors. The bank general ledger andeach bank customer of the Shared Passbooks example, Example 29 on Page 41, will be consideredactors .

3.3.3 Parts, Attributes and Behaviours 288

Example 44 focused on what shall soon become a major relation within domains: that of partsbeing also considered actors, or more specifically, being also considered to be behaviours.

Example 45 Parts, Attributes and Behaviours Consider the term ‘train’1. It has several possible“meanings”. (i) the train as a part, viz., as standing on a train station platform; (ii) the trainas listed in a timetable (an attribute of a transport system part), (iii) the train as a behaviour:speeding down the rail track .

3.4 Discrete Actions 289

Definition 24 Discrete Action: By a ′discrete action′ [104] we shall understand some foreseeablething which deliberately, that is, on purpose, potentially changes a well-formed state, in one step,usually into another, still well-formed state, and for which an actor can be made responsible .

An action is what happens when a function invocation changes, or potentially changes a state.290

Example 46 Road Net Actions Examples of road net actions initiated by the net actor are:insertion of hubs, insertion of links, removal of hubs, removal of links, setting of hub states. Exam-ples of traffic system actions initiated by vehicle actors are: moving a vehicle along a link, stoppinga vehicle, starting a vehicle, moving a vehicle from a link to a hub and moving a vehicle from ahub to a link .

3.5 Discrete Events 291

Definition 25 Event: By an ′event′ we shall understand some unforeseen thing, that is, someunplanned-for “action” which surreptitiously, non-deterministically changes a well-formed stateinto another, but usually not a well-formed state, and for which no particular actor can be maderesponsible .

Events can be characterised by a pair of (before and after) states, a predicate over these and,optionally, a time or time interval. The notion of event continues to puzzle philosophers [40, 88, 77,38, 53, 7, 71, 30, 81, 29]. We note, in particular, [38, 7, 71].292

Example 47 Road Net and Road Traffic Events Some road net events are: “disappearance”of a hub or a link, failure of a hub state to change properly when so requested, and occurrence of ahub state leading traffic into “wrong-way” links. Some road traffic events are: the crashing of oneor more vehicles (whatever ‘crashing’ means), a car moving in the wrong direction of a one-waylink, and the clogging of a hub with too many vehicles .1 This example is due to Paul Lindgreen, a Danish computer scientist. It dates from the late 1970s.


3.6 Discrete Behaviours 59

3.6 Discrete Behaviours 293

Definition 26 Discrete Behaviour: By a ′discrete behaviour′ we shall understand a set of se-quences of potentially interacting sets of discrete actions, events and behaviours .

294

Example 48 Behaviours Examples of behaviours: Road Nets: A sequence of hub and link in-sertions and removals, link disappearances, etc. Road Traffic: A sequence of movements of vehiclesalong links, entering, circling and leaving hubs, crashing of vehicles, etc. Pipelines: A sequenceof pipeline pump and valve openings and closings, and failures to do so (events), etc. ContainerVessels and Ports: Sequences of movements (by container terminal port cranes) of containers fromvessel to port (unloading), interleaved by sequences of movements (by cranes) from port to vessel(loading), including the dropping of containers by cranes .

3.6.1 Channels and Communication 295

Behaviours usually communicate. Communication is abstracted as the sending (ch !m) and receipt(ch ?) of messages, m:M, over channels, ch.

type Mchannel ch M

Communication between (unique identifier) indexed behaviours have their channels modelled assimilarly indexed channels:

out: ch[ idx ]!min: ch[ idx ]?channel ch[ ide ]|ide:IDE:M

where IDE typically is some type expression over unique identitifer types.

3.6.2 Relations Between Attribute Sharing and Channels 296

We shall now interpret the syntactic notion of attribute sharing with the semantic notion ofchannels. This is in line with the above hinted interpretation of parts with behaviours, and, as weshall soon see part attributes with behaviour states. 297

Thus, for every pair of parts, pik:Pi and pjℓ:Pj , of distinct sorts, Pi and Pj which share attributevalues in A we are going to associate a channel. If there is only one pair of parts, pik:Pi and pjℓ:Pj ,of these sorts, then just a simple channel, say chPi,Pj .

channel chPi,Pj :A.

If there is only one part, pi:Pi, but a definite set of parts pjk:Pj , with shared attributes, then avector of channels. Let pj1, pj2, ..., pjn be all the part of the domain of sort Pj . Then uids :uidpj1 , uidpj2 , ..., uidpjn is the set of their unique identifiers. Now a schematic channel arraydeclaration can be suggested:

channel ch[ πi,πj ]|πi=uid Pi(pi)∧πj ∈ uids:A.

The above can be extended from channel matrices to channel tensors, etc., hence the term channel‘array’. 298

Example 49 Bus System Channels We extend Example 28 on Page 40. We consider the fleetand the vehicless to be behaviours.

148. We assume some transportation system, δ. From that system we observe149. the fleet and150. the vehicles.


60 3 Perdurants

151. The fleet to vehicle channel array is indexed by the 2-element sets of the unique fleet iden-tifier and the unique vehicle identifiers. We consider bus timetables to be the only messagecommunicated between the fleet and the vehicle behaviours.

299

value

148. δ:∆,149. f:F = obs F(δ),150. vs:V-set = obs Vs(obs VC((obs F(δ))))

channel

151. fch[ uid F(f),uid V(v) ]|v:V•v ∈ vs:BT .

300

Example 50 Bank System Channels We extend Example 29 on Page 41. We consider thegeneral ledger and the customers to be behaviours.

152. We assume some bank system. From the bank system153. we observe the general ledger.154. and the set of customers.155. We consider passbooks to be the only message communicated between the general ledger and

the customer behaviours.

value

152. bs:BS153. gl=obs GL(obs AD(bs)):GL154. cs=obs Cs(obs CS(bs)):C-set

channel

155. bsch[ uid GL(gl),uid C(c) ]|c:C•c ∈ cs:PB .

3.7 Continuous Behaviours 301

By a ′continuous behaviour′ we shall understand a continuous time sequence of state changes. Weshall not go into what cause these state changes.302

Example 51 Flow in Pipelines We refer to Examples 34, 37, 39, 40 and 41. Let us assume thatoil is the (only) material of the pipeline units. Let us assume that there is a sufficient volume of oilin the pipeline units leading up to a pump. Let us assume that the pipeline units leading from thepump (especially valves and pumps) are all open for oil flow. Whether or not that oil is flowing,if the pump is pumping (with a sufficient head2) then there will be oil flowing from the pump outletinto adjacent pipeline units. .303

To describe the flow of material (say in pipelines) requires knowledge about a number ofmaterial attributes — not all of which have been covered in the above-mentioned examples. Toexpress flows one resorts to the mathematics of hydro-dynamics using such second order differentialequations as first derived by Bernoulli (1700–1782) and Navier–Stokes (1785–1836 and 1819–1903).

3.8 Perdurant Signatures and Definitions 304

We shall treat perdurants as functions. In our cursory overview of perdurants we shall focus onone perdurant quality: function signatures.

2 The ′pump head′ is the linear vertical measurement of the maximum height a specific pump can delivera liquid to the pump outlet.



3.8.1 Function Signatures 305

Definition 27 Function Signature: By a ′function signature′ we shall understand a functionname and a function type expression.

Definition 28 Function Type Expression: By a ′function type expression′ we shall understanda pair of type expressions. separated by a function type constructor either → (total function) or

∼→

(partial function).

The type expressions are usually part sort or type, material sort or attribute type names, butmay, occasionally be expressions over respective type names involving -set, ×, ∗, →m and | typeconstructors.

3.8.2 Action Signatures and Definitions 306

Actors usually provide its initiated actions with arguments, say of type VAL. Hence the schematicfunction (action) signature and schematic definition:

action: VAL → Σ∼→ Σ

action(v)(σ) as σ′

pre: P(v,σ)post: Q(v,σ,σ′)

expresses that a selection of the domain as provided by the Σ type expression is acted upon andpossibly changed. The partial function type operator

∼→ shall indicate that action(v)(σ) may not be 307

defined for the argument, i.e., initial state σ and/or the argument v:VAL, hence the preconditionP(v,σ). The postcondition Q(v,σ, σ′) characterises the “after” state, σ′:Σ, with respect to the“before” state, σ:Σ, and possible arguments (v:VAL). 308

Example 52 Insert Hub Action Formalisation We formalise aspects of the above-mentionedhub and link actions:

156. Insertion of a hub requires157. that no hub exists in the net with the unique identifier of the inserted hub,158. and then results in an updated net with that hub.

value

156. insert H: H → N∼→ N

156. insert H(h)(n) as n′

157. pre: ∼∃ h′:H•h′ ∈ obs Hs(obs HS(n))•uid H(h)=uid H(h′)158. post: obs Hs(obs HS(n′))=obs Hs(obs HS(n))∪h .

309Which could be the argument values, v:VAL, of actions ? Well, there can basically be only twokinds of argument values: parts and materials, respectively unique part identifiers, mereologiesand attribute values. It basically has to be so since there are no other kinds of values in domains.There can be exceptions to the above (Booleans, natural numbers), but they are rare ! 310

Perdurant analysis thus proceeds as follows: identifying relevant actions, assigning names tothese, delineating the “smallest” relevant state3, ascribing signatures to action functions, and deter-mining action pre-conditions and action post-conditions. Of these, ascribing signatures is, perhapsthe most crucial: In the process of determining the action signature one oftentimes discovers thatpart or material attributes have been left “undiscovered”. 311

Example 53 shows examples of signatures whose arguments are either parts, or parts and uniqueidentifiers, or parts and unique identifiers and attributes.

Example 53 Some Function Signatures Inserting a link between two identified hubs in a net:

3 Experience shows that the domain analyser cum describer should strive for identifying the smalleststate.


62 3 Perdurants

value insert L: L × (HI × HI) → N∼→ N

Removing a hub and removing a link:

value remove H: HI → N∼→ N

remove L: LI → N∼→ N

Changing a hub state.

value change HΣ: HI × HΣ → N∼→ N .

3.8.3 Event Signatures and Definitions 312

Events are usually characterised by the absence of known actors and the absence of explicit “ex-ternal” arguments. Hence the schematic function (event) signature:

value

event: Σ × Σ → Bool

event(σ,σ′) as true⌈⌉falsepre: P (σ)post: Q(σ,σ′)

313

The event signature expresses that a selection of the domain as provided by the Σ type expressionis “acted” upon, by unknown actors, and possibly changed. The partial function type operator

∼→

shall indicate that event(σ) may not be defined for some states σ. The resulting state may, or maynot, satisfy axioms and well-formedness conditions over Σ — as expressed by the postconditionQ(σ, σ′). Events may thus cause well-formedness of states to fail. Subsequent actions once actors314

discover such “disturbing events”, are therefore expected to remedy that situation, that is, torestore well-formedness. We shall not illustrate this point.315

Example 54 Link Disappearence Formalisation We formalise aspects of the above-mentionedlink disappearance event:

159. The result net is not well-formed.160. For a link to disappear there must be at least one link in the net;161. and such a link may disappear such that162. it together with the resulting net makes up for the “original” net.

value

159. link diss event: N × N′ × Bool

159. link diss event(n,n′) as tf160. pre: obs Ls(obs LS(n)) 6=161. post: ∃ l:L•l ∈ obs Ls(obs LS(n)) ⇒162. l 6∈ obs Ls(obs LS(n′)) ∧ n′ ∪ l = obs Ls(obs LS(n)) .

3.8.4 Discrete Behaviour Signatures and Definitions 316

We shall only cover behaviour signatures when expressed in RSL/CSP [48]. The behaviour functionsare now called processes. As shown in [18] we can, without loss of generality, associate witheach part and sub-part a behaviour; parts which share attributes and are therefore referred to insome parts’ mereology, can communicate (their “sharing”) via channels. A behaviour signature is317

therefore:

behaviour: π:Π × p:P × VAL → out ochs in ichns → process

where π:Π is the unique identifier of part p, i.e., π=uid P(p), and ochs, ichs are channel expressions,generally of the form



ochs,ichs: ch[ i ]|i:IDE•P(i)

where P(i) is some predicate expression. Let P be a composite sort. Let P be defined in terms of318

sub-sorts PA, PB, . . . , PC. Proces p “derived” from p:P, is composed from a process, MP , relyingon and handling the attributes of process p as defined by P operating in parallel with processespa, pb, . . . , pc: The domain description “compilation” schematic below “formalises” the above. 319

Process Schema I

value

p a:PA=obs PA(p),p b:PB=obs PB(p),...,p c:PC=obs PC(p),comp process(p) ≡

p: π:Π × p:P × attrs:P ATTRS →in,out ch[ π,pi ]•pi ∈ mereo P(p) process

p(π:uid (p),p,attrs:obs attribs(p)) ≡MP (π,p,attrs)‖ comp process(p a)‖ comp process(p b)‖ ...‖ comp process(p c)

320

Let P be a composite sort. Let P be defined in terms of the concrete type Q-set. Proces p “derived”from p:P, is composed from a process, MP , relying on and handling the attributes of process p asdefined by P operating in parallel with processes q:obs Qs(p). The domain description “compila-tion” schematic below “formalises” the above. 321

Process Schema II

type

Qs = Q-set

value

qs:Q-set = obs Qs(p) in

comp process(p) ≡p: π:Π × p:P × attrs:P ATTRS →

in,out ch[ π,pi ]•pi ∈ mereo P(p) process

p(π:uid (p),p,attrs:obs attribs(p)) ≡MP (π,p,attrs)

‖ ‖comp process(q)|q:Q•q ∈ qs

322

Example 55 Bus Timetable Coordination We refer to Examples 10 on Page 30, 11 onPage 31, 28 on Page 40 and 49 on Page 59.

163. δ is the transportation system; f is the fleet part of that system; vs is the set of vehicles of thefleet; bt is the shared bus timetable of the fleet and the vehicles.

164. The fleet process is compiled as per Process Schema II (Page 63)323

type

∆, F, VC [Example 10 on Page 30]V, Vs=V-set [Example 11 on Page 31]FI, VI, BT [Example 28 on Page 40]

channel


64 3 Perdurants

fch... [Example 49 on Page 59]value

163. δ:∆,163. f:F = obs F(δ),163. vs:V-set = obs Vs(obs VC(f)),163. bt:BT = attr BT(f)

axiom

163. ∀ v:V•v ∈ vs ⇒ bt = attr BT(v) [Example 28 on Page 40]value

164. fleet: fi:FI×f:F×BT → in,out fch[ fi,uid V(v) ]|v:V•v ∈ vs process

164. fleet(fi,f,bt) ≡ MF (fi,f,bt) ‖ ‖ vehicle(uid V(v),v,bt)|v:V•v ∈ vs164. vehicle: vi:VI×v:V×bt:BT → in,out fch[ fi,vi ] process

164. vehicle(vi,v,bt) ≡ MV (vi,v,bt)

324

Fleet and vehicle processes MF and MV are both “never-ending” processes:

value

MF : FI×F×BT → in,out fch[ fi,uid V(v)|v:V•v ∈ vs process

MF (fi,f,bt) ≡ let bt′ = F(fi,f,bt) in MF (fi,f,bt′) end

MV : VI×V×BT → in,out fch[ fi,vi ] process

MV (vi,v,bt) ≡ let bt′ = V(vi,v,bt) in MV (vi,v,bt′) end

The “core” processes, F and V , are simple actions. In this example we simplify them to change325

only bus timetables. The actual synchronisation and communication between the fleet and thevehicle processes are expressed in F and V .

value

F : FI×F×BT → in,out fch[ fi,uid V(v)|v:V•v ∈ vs BTF(fi,f,bt) ≡ ...

V : VI×V×BT → in,out fch[ fi,vi ] BTV(vi,v,bt) ≡ ...

What the synchronisation and communication between the fleet and the vehicle processes consistsof we leave to the reader ! .326

Example 56 Client Bank Transactions We refer to Example 29 on Page 41.

165. bs is the bank system,166. gl is the general ledger of the bank administration,167. pbs is the set of passbooks attribute of the general ledger and168. cs is the set of bank customers.169. bank is the overall bank system behaviour.170. gen ldgr is the behaviour of the general ledger, that is, the demand/deposit activities of the

bank.171. clients is the overall behaviour of the ensemble of bank demand/deposit [account] customers.172. customer is the behaviour of the individual bank customer. It is here simplified to just the

customer behaviour with respect to the demand/deposit account as manifested by the passbookattribute.

The processes are compiled as per Process Schema I (Page 63) – two “compilations” !327

type

[parts] BS, AD, GL, CS, Cs, C [Example 29 on Page 41][attribute] PB [Example 29 on Page 41]

value


3.9 Summary and Discussion of Perdurants 65

165. bs:BS166. gl:GL = obs GL(obs AD(bs)), glid:GLI = uid GL(gl)167. pbs:PB-set = attr PSs(gl)168. cs:C-set = obs Cs(obs CS(bs))axiom

167. pbs = attr PS(c)|c:C:0c ∈ cs [Example 29 on Page 41]

328

value

167. bank: bs:BS → process

167. bank(bs) ≡ gen ldgr(glid)(gl)(pbs) ‖ clients(cs)168. gen ldgr: π:GLI × GL × PB-set → in,out bch[ π,uid C(c) ]|c:C•c ∈ cs process

168. gen ldgr(π,gl,pbs) ≡ MGL(π,gl,pbs)169. clients: C-set → in,out bch[ π,uid C(c) ]|c:C•c ∈ cs process

169. clients(cs) ≡ ‖customer(uid C(c),c,attr PB(c))|c:C•c ∈ cs170. customer: π:CI × C × PB → in,out bsch[ glid,π ] process

170. customer(uid C(c),c,attr PB(c)) ≡ MC(uid C(c),c,attr PB(c))

329

The MGL and MC behaviours are seen as “never-ending”. We leave their definition to the readerwho is expected to model simple deposit, withdraw and inter-account transfer transactions. Wehave here assumed that each such transactions all lead to update of both the client and the generalledger passbooks .

3.9 Summary and Discussion of Perdurants 330

3.9.1 Summary

to be written

3.9.2 Discussion

to be written


4

Models of Domain Anaysis 331

4.1 Introduction 332

4.2 A Model of The Analysis & Description Process 333

4.2.1 A Summary of Prompts

In Chap. 2 we outlined two classes of prompts: the domain [endurant] analysis prompts:

a. is entity, 26b. is endurant, 27c. is perdurant, 27d. is discrete, 27e. is continuous, 28f. is part, 28g. is material, 28

h. is atomic, 28i. is composite, 28j. observe parts, 29k. has concrete type, 31l. attribute names, 37m. has mereology, 43n. has materials, 46

and the domain [endurant] description prompts:

1. observe part sorts, 292. observe part type, 313. observe unique identifier, 35

4. observe attributes, 375. observe mereology, 436. observe material sorts, 46

334

These prompts are imposed upon the domain analyser cum describer. They are “figuratively”applied to the domain. Their orderly, sequenced application follows the method hinted at in theprevious section and expressed in a pseudo-formal notation in this section. The notation looksformal but since we have not formalised these prompts it is only pseudo-formal. In [19] we shallformalise these prompts.

4.2.2 Preliminaries 335

Let P be a sort, that is, a collection of endurants. By ηP we shall understand a syntactic quantity:the name of P. By ιp:P we shall understand the semantic quantity: an (arbitrarily selected)endurant in P. And by η−1ηP we shall understand P. To guide our analysis & description process we 336

decompose it into steps. Each step “handles” a sort p:P or a material m:M. Steps handling discoveryof composite sorts generates a set of sort names ηP1, ηP2, . . . , ηPn and ηM1, ηM2, . . . , ηMn.These are put in a reservoir for sorts to be inspected. The handled sort ηP or ηM is removed fromthat reservoir. Handling of material sorts concerns only their attributes. Each domain descriptionprompt results in domain specification text (here we show only the formal texts) being deposited inthe domain description reservoir, a global variable τ . The clause: domain description prompt(p) 337

: τ := τ ⊕ [ ”text ; ”] means that the formal text ”text ; ” is joined to the global variable τwhere that ”text ; ” is prompted by domain description prompt(p). The meaning of ⊕ will bediscussed at the end of this section.

68 4 Models of Domain Anaysis

4.2.3 Initialising the Domain Analysis & Description Process 338

We remind the reader that we are dealing only with endurant domain entities. The domain analysisapproach covered in Chap. 2 was based on decomposing an understanding of a domain from the“overall domain” into its components, and these, if not atomic, into their subcomponents. So weneed to initialise the domain analysis & description by selecting (or choosing) the domain ∆.339

Here is how we think of that “initialisation” process. The domain analyser[s] & describer[s]spends some time focusing on the domain, maybe at the “white board”1, rambling, perhaps in anun-structured manner, across its domain, ∆, and its sub domains. Informally jotting down more-or-less final sort names, building, in the domain analysers’ & describers’ mind an image of thatdomain. After some time doing this the domain analyser[s] & describer[s] is/are ready. An image340

of the domain in the form of “a domain” endurant, δ:∆. Those are the quantities, η∆ (name of∆) [Item 173] and ιp:P (for (δ:∆)) [Item 180], referred to below.

Thus this initialisation process is truly a creative one.

4.2.4 A Domain Analysis & Description State 341

173. A global variable αps will accumulate all the sort names being discovered.174. A global variable νps will hold names of sorts yet to be analysed and described.175. A global variable τ will hold the (so far) generated (in this case only) formal domain description

text.

variable

173. αps := [ η∆ ] ηP-set or ηP∗

174. νps := [ η∆ ] (ηP|ηM)-set or (ηP|ηM)∗

175. τ := [ ] Text-set or Text∗

We shall explain the use of [...]s and the operations of \ and ⊕ on the above variables in Sect. 4.2.6on Page 74.

4.2.5 Analysis & Description of Endurants 342

176. To analyse and describe endurants means to first177. examine those endurant which have yet to be so analysed and described178. by selecting (and removing from νps) a yet unexamined sort (by name);179. then analyse and describe an endurant entity (ιp:P) of that sort — this analysis, when applied

to composite parts, leads to the insertion of zero2or more sort names3;180. then to analyse and describe the mereology of each part sort,181. and finally to analyse and describe the attributes of each sort.

343

value

176. analyse and describe endurants: Unit → Unit

176. analyse and describe endurants() ≡177. while ∼is empty(νps) do

178. let ηS = select and remove ηS() in

179. analyse and describe endurant sort(ιs:S) end end ;180. for all ηP • ηP ∈ αps do analyse and describe mereology(ιp:P) end

181. for all ηP • ηP ∈ αps do analyse and describe attributes(ιp:P) end

1 Here ‘white board’ is a conceptual notion. It could be physical, it could be yellow “post-it” stickers, orit could be an electronic conference “gadget”.

2 If the sub-parts of p are all either atomic or already analysed, then no new sort names are added to therepository νps).

3 These new sort names are then “picked-up” for sort analysis &c. in a next iteration of the while loop.



The ι of Items 179, 180 and 181 are crucial. The domain analyser is focused on sort S (and P) andis “directed” (by those items) to choose (select) an endurant ιs (ιp) of that sort. The ability ofthe domain analyser to find such an entity is a measure of that person’s professional creativity. 344

As was indicated in Chap. 2, the mereology of a part may involve unique identifiers of anypart sort, hence must be done after all such part sort unique identifiers have been identi-fied. Similarly for attributes which also may involve unique identifiers Each iteration of anal-yse and describe endurant sort(ιp:P) involves the selection of a sort (by name) (which is that ofeither a part sort or a material sort) with this sort name then being removed.

182. The selection occurs from the global state (hence: ()) and changes that (hence Unit).183. The affected global state component is that of the reservoir, νps.

345

value

182. select and remove ηS: Unit → ηP182. select and remove ηS() ≡183. let ηS • ηS ∈ νps in νps := νps \ ηS ; ηS end

The analysis and description of all sorts also performs an analysis and description of their possibleunique identifiers (if part sorts) and attributes. The analysis and description of sort mereologiespotentially requires the unique identifiers of any set of sorts. Therefore the analysis and descriptionof sort mereologies follows that of analysis and description of all sorts. 346

184. To analyse and describe an endurant185. is to find out whether it is a part.186. If so then it is to analyse and describe it as a part,187. else it is to analyse and describe it as a material.

184. analyse and describe endurant sort: (P|M) → Unit

184. analyse and describe endurant sort(e:(P|M)) ≡185. if is part(e)185. assert: is part(e) ≡ is endurant(e)∧is discrete(e)186. then analyse and describe part sort(e:P)187. else analyse and describe material parts(e:M)184. end

Analysis & Description of Part Sorts 347

188. The analysis and description of a part sort189. is based on there being a set, ps, of parts4to analyse —190. of which an archetypal one, p′, is arbitrarily selected.191. analyse and describe part p′

188. analyse and describe part sort: P → Unit

188. analyse and describe part sort(p:P) ≡189. let ps = observe parts(p) in

190. let p′:P • p′ ∈ ps in

191. analyse and describe part(p′)188. end end

348

192. The analysis (&c.) of a part

4 We can assume that there is at least one element of that set. For the case that the sort being analysedis a domain ∆, say “The Transport Domain”, p′ is some representative “transport domain” δ. Similarlyfor any other sort for which ps is now one of the sorts of δ.



193. first analyses and describes its unique identifiers.194. If atomic195. and196. if the part embodies materials,197. we analyse and describe these.198. If not atomic then the part is composite199. and is analysed and described as such.

349

192. analyse and describe part: P → Unit

192. analyse and describe part(p) ≡193. analyse and describe unique identifier(p) ;194. if is atomic(p)195. then

196. if has materials(p)197. then analyse and describe part materials(p) end

198. else assert: is composite(p)199. analyse and describe composite endurant(p) end

192. pre: is discrete(p)

We do not associate materials with composite parts.

Analysis & Description of Part Materials 350

200. The analysis and description of the material part sorts, one or more, of atomic parts p of sortP containing such materials,

201. simply observes the material sorts of p,202. that is generates the one or more continuous endurants203. and the corresponding observer function text.204. The reservoir of sorts to be inspected is augmented by the material sorts — except if already

previously entered (the \ αps clause).

200. analyse and describe part materials: P → Unit

200. analyse and describe part materials(p) ≡201. observe material sorts(p) :202. τ := τ ⊕ [ ”type M1,M2,...,Mm;203. value obs M1:P→M1,obs M2:P→M2,...,obs Mm:P→Mm;” ]204. νps := νps ⊕ ([ M1,M2,...,Mm ] \ αps)200. pre: has materials(p)

Analysis & Description of Material Parts 351

205. To analyse and describe materials, m, i.e., continuous endurants,206. is only necessary if m has parts.207. Then we observe the sorts of these parts.208. The identified part sort names update both name reservoirs.

205. analyse and describe material parts: M → Unit

205. analyse and describe material parts(m:M) ≡206. if has parts(m)207. then observe part sorts(m):207. τ := τ ⊕ [ ” type P1,P2,...,PN ;207. value obs Pi: M→Pi i:1..N;” ]208. ‖ νps := νps ⊕ ([ ηP1,ηP2,...,ηPN ]\ αps)



208. ‖ αps := αps ⊕ [ ηP1,ηP2,...,ηPN ]205. end

205. assert: is continuous(m)

Analysis & Description of Composite Endurants 352

209. To analyse and describe a composite endurant of sort P210. is to (we choose first) to analyse and describe the unique identifier of that composite endurant,211. then to analyse and describe the sort. If the sort has a concrete type212. then we analyse and describe that concrete sort type213. else we analyse and describe the abstract sort.

209. analyse and describe composite endurant: P → Unit

209. analyse and describe composite endurant(p) ≡210. analyse and describe unique identifier(p) ;211. if has concrete type(p)212. then analyse and describe concrete sort(p)213. else analyse and describe abstract sort(p)211. end

Analysis & Description of Concrete Sort Types 353

214. The concrete sort type being analysed and described is215. either216. expressible by some compound type expression215. or is217. expressible by some alternative type expression.

214. analyse and describe concrete sort: P → Unit

214. analyse and describe concrete sort(p:P) ≡216. analyse and describe concrete compound type(p)215. ⌈⌉217. analyse and describe concrete alternative type(p)214. pre: has concrete type(p)

354

218. The concrete compound sort type219. is expressible by some simple type expression, T=E(Q,R,...,S) over either concrete types or

existing or new sorts Q, R, ..., S.220. The emerging sort types are identified221. and assigned to both νps222. and αps.

355

216. analyse and describe concrete compound type: P → Unit

216. analyse and describe concrete compound type(p:P) ≡218. observe part type(p):218. τ := τ ⊕ [ ”type Q,R,..,S, T = E(Q,R,...,S);218. value obs T: P → T ;” ] ;219. let Pa,Pb,...,Pc = sorts of(Q,R,...,S)220. assert: Pa,Pb,...,Pc ⊆ Q,R,...,S in

221. νps := νps ⊕ [ ηPa, ηPb, ..., ηPc ] ‖222. αps := αps ⊕ ([ ηPa, ηPb, ..., ηPc ] \ αps) end

216. pre: has concrete type(p)



356

223. The concrete alternative sort type expression224. is expressible by an alternative type expression T=P1|P2|...|PN where each of the alternative

types is made disjoint wrt. existing types by means of the description language Pi::mkPi(su:Pi)construction.

225. The emerging sort types are identified and assigned226. to both νps227. and αps.

357

217. analyse and describe concrete alternative type: P → Unit

217. analyse and describe concrete alternative type(p:P) ≡223. observe part type(p):224. τ := τ ⊕ [ ”type T=P1 | P2 | ... | PN, Pi::mkPi(s u:Pi) (1≤i≤N);224. value obs T: P→T ;” ] ;225. let Pa,Pb,...,Pc = sorts of(Pi|1≤i≤n)225. assert: Pa,Pb,...,Pc ⊆ Pi|1≤i≤n in

226. νps := νps ⊕ ([ ηPa, ηPb, ..., ηPc ] \ αps) ‖227. αps := αps ⊕ [ ηPa, ηPb, ..., ηPc ] end

214. pre: has concrete type(p)

Analysis & Description of Abstract Sorts 358

228. To analyse and describe an abstract sort229. amounts to observe part sorts and to230. update the sort name repositories.

228. analyse and describe abstract sort: P → Unit

228. analyse and describe abstract sort(p:P) ≡229. observe part sorts(p):229. τ := τ ⊕ [ ”type P1, P2, ..., Pn;229. value obs Pi:P→Pi (0≤i≤n);” ]230. ‖ νps := νps ⊕ ([ ηP1, ηP2, ..., ηPn ] \ αps)230. ‖ αps := αps ⊕ [ ηP1, ηP2, ..., ηPn ]

Analysis & Description of Unique Identifiers 359

231. To analyse and describe the unique identifier of parts of sort P is232. to observe the unique identifier of parts of sort P233. where we assume that all parts have unique identifiers.

231. analyse and describe unique identifier: P → Unit

231. analyse and describe unique identifier(p) ≡232. observe unique identifier(p):232. τ := τ ⊕ [ ”type PI; value uid P:P→PI;” ]233. assert: has unique identifier(p)



Analysis & Description of Mereologies 360

234. To analyse and describe a part mereology235. if it has one236. amounts to observe that mereology237. and otherwise do nothing.238. The analysed quantity must be a part.

234. analyse and describe mereology: P → Unit

234. analyse and describe mereology(p) ≡235. if has mereology(p)236. then observe mereology(p) :236. τ := τ ⊕ ”type MT = E(PIa,PIb,...,PIc) ;236. value mereo P: P→MT ;”237. else skip end

234. pre: is part(p)

Analysis & Description of Part Attributes 361

239. To analyse and describe the attributes of parts of sort P is240. to observe the attributes of parts of sort P241. where we assume that all parts have attributes.

239. analyse and describe part attributes: P → Unit

239. analyse and describe part attributes(p) ≡240. observe attributes(p):240. τ := τ ⊕ [ ”type A1, A2,..., Am ;240. value attr A1:P→A1,attr A2:P→A2,...,attr Am:P→Am;” ]241. assert: has attributes(p)

4.2.6 Discussion of The Model 362

The above model lacks a formal understanding of the individual prompts as listed in Sect. 4.2.1;such an understanding is attempted in [19].

Termination 363

The sort name reservoir νps is “reduced” by one name in each iteration of the while loop ofthe analyse and describe endurants, cf. Item 178 on Page 68, and is augmented by new part andmaterial sort names in some iterations of that loop, cf. formula Items 204 on Page 70, 208 onPage 70, 221 on Page 71, 226 on the facing page and 221 on Page 71. It remains to prove that theanalysis & description process terminates.

Axioms and Proof Obligations 364

We have omitted from the above treatment of axioms concerning well-formedness of parts, ma-terials and attributes and proof obligations concerning disjointness of observed part and materialsorts and attribute types. A more proper treatment would entail adding a line of proof obligationtext right after Item lines 237 and 240. and of axiom text right after Item lines 203 (Page 70), 207(Page 70), 218 (Page 71), 220 (Page 71), 232 (Page 72) and 240 (Page 73). No axiom is needed inconnection with Item line 224 on the facing page.

[20] covers axioms and proof obligations in some detail.



Order of Analysis & Description: A Meaning of ‘⊕’ 365

The variables αps, νps and τ are defined to hold either sets or lists. The operator ⊕ can be thoughtof as either set union (∪ and [,]≡, ) — in which case the domain description text in τ is a set ofdomain description texts or as list concatenation ( and [,]≡〈,〉) of domain description texts. Theoperator ℓ1⊕ ℓ2 now has at least two interpretations: either ℓ1ℓ2 or ℓ2ℓ1. In the case of lists the⊕ (i.e., ) does not (suffix or prefix) append ℓ2 elements already in ℓ1. The select and remove ηP366

function on Page 69 applies to the set interpretation. A list interpretation is:

value

178. select and remove ηP: Unit → ηP178. select and remove ηP() ≡178. let ηP = hd νps in νps := tl νps; ηP end

In the first case (ℓ1ℓ2) the analysis and description process proceeds from the root, breadth first,In the second case (ℓ2ℓ1) the analysis and description process proceeds from the root, depth first..

Laws of Description Prompts 367

The domain ‘method’ outlined in the previous section suggests that many different orders ofanalysis & description may be possible. But are they ? That is, will they all result in “similar”descriptions ? That is, if Da and Db are two domain description prompts where Da and Db canbe pursued in any order will that yield the same description ? And what do we mean by ‘can bepursued in any order’, and ‘same description’ ? Let us assume that sort P decomposes into sorts368

Pa and Pb (etcetera). Let us assume that the domain description prompt Da is related to thedescription of Pa and Db to Pb. Here we would expect Da and Db to commute, that is Da;Db

yields same result as does Db;Da. In [16] we made an early exploration of such laws of domaindescription prompts.

To answer these questions we need a reasonably precise model of domain prompts. We attemptsuch a model in [19].

4.3 A Model of The Analysis & Description Prompts 369

to be written

4.3.1 On the Domain Analyser’s Image of Domains 370

4.3.2 An Abstract Syntax of Domains 371

Domain Nodes

The core quantity of the domain analyser’s image of domains is here called a node. Nodes designateentities. Some designated nodes are so-called duplicate nodes. A ′duplicate node′ designates a sortname that is defined elsewhere in the domain description tree. See Sect. 4.3.2 on Page 76. Five372

kinds of nodes are said to define sorts. Atomic nodes, Item 246 Page 75, define some qualities, Q(cf. Item 253 Page 75), and may refer to material nodes (either directly or by reference (#Mn)).Material nodes, Item 247 Page 75, define material qualities, MAT, Item 253 on the facing page,and may refer to part nodes (either directly or by reference (#Pn)). Composite nodes, Item 249Page 75, define define some qualities and a set of entity nodes (either directly or by reference(#Sn)). Type nodes, Item 251 Page 75, define define some qualities, a concrete type, and a set373

of part nodes (either directly or by reference (#Pn)) — where their part names occur in thetype expression. Alternative nodes, Item 252 Page 75, define define some qualities and a set of[alternative] part nodes (either directly or by reference (#Pn)) A more tersely expressed narrativeand the a;ready reference formalisation follows.374



242. A node is either an endurant or a perdurant node.243. An endurant node is either a discrete (i.e., a part) or a continuous (i.e., a material) node.244. We shall not consider perdurant nodes in this book.245. A part node is either an atomic node or a composite node or a duplicate node (represented as

[#Sn]).246. An atomic node contains some quality description and a usually empty set of uniquely material-

named material nodes, some may be duplicate such nodes.247. A material node contains some material attributes and a possibly empty set of uniquely part-

named part nodes. 375

248. A composite type node is either a compound node or is a [concrete] type node.249. A composite node contains a set of uniquely sort-named nodes and some quality description.250. A “k”oncrete type node is either a simple compound type node or is an alternative sorts node.251. A type node is some type expression over sorts and concrete type names and a possibly empty

set of uniquely part-named endurants and some quality description.252. An alternative node is a set of two or more uniquely named endurant nodes.253. A quality description consists of a unique identifier, a possibly “empty” mereology, and some

attributes.376

type

242. N == mkEnN(EnN) | mkPeN(PeN)5

243. EnN == mkPaN(PaN) | mkMaN(MaN)244. PeN245. PaN == mkAtN(AtN) | mkCoN(CoN)246. AtN = Q × ((Mn →m MaN)6×[#Mn]-set)247. MaN = MAT × ((Pn →m PaN)×[#Pn]-set)248. CoN == mkCmN(CmN)| mkKTN(KTN)249. CmN = Q × ((Sn →m EnN)7×[#Sn]-set)250. KTN == mkTyN(st:TyN) | mkAlT(AlT)251. TyN = Q × TE × ((Pn →m PaN)8×[#Pn]-set)252. AlT = Q × ((Pn →m PaN)9×[#Pn]-set)253. Q = UI × ME × PAT

Sn=Pn|Mn10, Pn, Mn, Tn, TE, UI, MAT, PAT

Part and material names, Pn, Mn, type expressions, TE, and unique identifiers, UI, are furtherundefined quantities. We shall define mereology and material and part attributes, MAT and PAT,below.

The Root Domain Node 377

254. The root domain node is a singleton map from a sort name to an endurant node.

type

254. RDN = Sn →m EnN axiom ∀ rdn:RDN • card dom rdn = 1value

254. rdn:RDN = [ sn7→mkEnN(en) ]254. sn:Sn, en:EnN

5 The type equation A=mkB(...)|mkC(...)|...|mkD(...) defines A to consist of the disjoint types designatedby mkB(...), mkC(...), ... and mkD(...). In mkE(s:E) s denotes a selector function. mkB, etc., are calledconstructor functions. s(mkX(x))≡. isX(mkX(x))≡true. isX, etc., are discriminator predicates.

6 Empty map when part “carries” no materials. Usually a singleton map if it does carry materials.7 The sort names are those sort names of the type expression which are being defined here (i.e., “appear”

for the first time).8 See footnote 7.9 At least two map elements

10 The part name and the material name types are disjoint, that is M(Pn)∩M(Mn)



Domain Description Trees 378

Due to the recursive definition of sort nodes the abstract syntax can be visualised as defining′description trees′ . Endurant nodes of a part node and part nodes of a material node can be saidto designate subtrees. We can therefore define a notion of ′description tree path′s.379

Syntax

255. A description [tree] path is a sequence of one or more sort names.

type

255. DP = (Sn|[#Sn])∗

axiom

255. ∀ dtp:DTP •

255. dtp6=〈〉255. ∧ ∃ sn:Sn•[#sn]∈ elems dtp ⇒255. [#sn] 6∈ elems fst11dtp

380

Generating Description Tree Paths

256.257.258.259.260.261.262.263.264.

381

value

256. G: EnN → DP-infset

256. G(en) ≡257. case en of

259. mkPaN(mkAtN( ,m)) → G(m),260. mkPaN(mkMaN( ,m)) → G(m),261. mkPaN(mkCoN(mkCmN( ,m))) → G(m),262. mkPaN(mkCoN(mkKTN(mkTyN( , ,m)))) → G(m),263. mkPaN(mkCoN(mkKTN(mkAlT( ,m)))) → G(m),264. mkMaN( ,m) → G(m)256. end ∪ 〈〉

382

The Generate path function is overload-defined, four variantsthe above and the three below:

265. for the root node,266. for the six node-defining nodes, and267. their duplicate components.

265. G: RDN → DP-infset

265. G([ n7→en ]) ≡ 〈n〉dp|dp:DP•n′ ∈ dom rdn∧dp ∈ G(en)

266. G: Nodes × Duplicates → DP-infset

11 fst list is the list of all but the last element of list.



266. G(ns,ds) ≡266. 〈n〉dp|n:Sn,dp:DP•n ∈ dom ns∧dp ∈ G(ns(n))∪ G(ds)

267. G: Duplicates → DP-set

267. G(ds) ≡ 〈[#sn]〉|[#sn] ∈ ds

Well-formedness of Domain Nodes 383

Well-formed Composite and Material Nodes

268. Composite nodes must contain at least one sort node;269. material nodes may contain no part nodes.

value

268. wf comp nds: CmN → Bool

268. wf comp nds( ,(sm,ss)) ≡ dom sm ∩ Sns(ss) 6=

268. Sns: [#Sn]-set −< Sn-set

268. Sns(msn) ≡ sn|sn:Sn•[#sn]∈ msn

269. wf mat nds: MaN ×[#Pn]-set →Bool

269. wf mat nds( , ) ≡ true

384

No Recursively Defined Sorts

Sorts, whether parts sorts or material sorts, cannot be recursively defined.

270. A sort is recursively defined if its name occur more than once on any path,271. by properties of lists and sets this is tantamount to saying that the length of a violating path

is higher than the cardinality of the set of all names in the path.

270. no recursively defined sorts: DPN → Bool

270. no recursively defined sorts(dpn) ≡270. let paths = G(dpn) in

270. ∼∃ path:DP • path ∈ paths271. ⇒ len path > card elems path end

385

No Duplicate Definitions

Once a part node has been defined it cannot be redefined. The purpose of the ”#” “blocks” in thepart node maps is to mark where a sort name would otherwise be redefined.

272. We check for duplicate definitions across domain description nodes.273. Let dps be the set of all root-to-leaf paths of a domain tree.274. There does not exist two paths dp′,dp′′ in dps275. with distinct prefixes276. such that there exists a common sort name, sn, which when appended to dp′,dp′′ is a path in

the domain.277. A path dp′ is a prefix of a peth dp if the exists a path dp′′ when when appended to dp′ becomes

dp.386



272. no duplicate definitions: DPN → Bool

272. no duplicate definitions(dpn) ≡273. let dps = G(dpn) in

274. ∼ ∃ dp′,dp′′:DP • dp′,dp′′⊆dps ⇒275. let pdps′=prefixes(dp′),pdps′′=prefixes(dp′′) in

275. ∃ pdp′,pdp′′:DP•pdp′ ∈ pdps′∧pdp′′ ∈ pdps′′ ⇒ pdp′ 6=pdp′′

276. ⇒ ∃ sn:SN•pdp′〈sn〉∈ pdps′∧pdp′′〈sn〉∈ pdps′′

272. end end

277. prefixes: DP → DP-set

277. prefixes(dp) ≡ dp′|dp′,dp′′:DP•dp′dp′′ = dp

387

Defined Duplicate Sort Names

278. defined sorts is defined over root domain nodes.279. If, for some sort name, sn:Sn, and some domain tree path, dtp, of a domain rdn:RDN, the last

elements of dtp is [#sn] then sn must be defined elsewhere in the domain tree of rdn:RDN.280. In this case there must exist a unique another path, dtp′,281. such that sn is properly defined withing dtp′.

value

278. defined sorts: RDN → Bool

278. defined sorts([ sn7→en ]) ≡278. let dtps = paths(en) in

279. if ∃ dtp:DTP,sn:Sn•dtp〈[#sn]〉∈ dtps280. then ∃!12dtp′:DTP•dtp′isin dtps281. sn ∈ elems fst dtp′ else skip end end

4.3.3 Node Selection 388

282.283.284.285.286.

389

282. select node: DP × DPN∼→ EnN

282. select node(dp)([ sn7→en ]) ≡283. case dp of

283. 〈[#sn]〉 → select node([#sn])(en),283. 〈sn〉 → en,283. 〈sn′〉dp′ →257. case en of

259. mkPaN(mkAtN( ,[ sn′7→en′ ]∪m)) → select node(dp′)([ sn′ 7→en′ ]),260. mkPaN(mkMaN([ sn′7→en′ ]∪m, )) → select node(dp′)([ sn′ 7→en′ ]),261. mkPaN(mkCoN(mkSCN([ sn′7→en′ ]∪m, ))) → select node(dp′)([ sn′ 7→en′ ]),262. mkPaN(mkCoN(mkKTN(mkCmpT( ,[ sn′7→en′ ]∪m, ))))259. → select node(dp′)([ sn′ 7→en′ ]),263. mkPaN(mkCoN(mkKTN(mkAlT([ sn′7→en′ ]∪m, ))))259. → select node(dp′)([ sn′ 7→en′ ]),264. mkMaN([ sn′7→en′ ]∪m, ) → select node(dp′)([ sn′7→en′ ]),

12 ∃!... reads: there exists a unique ...



255. → chaos

257. end

257. → chaos end

390

283. select node: |[#sn]| → DPN → EnN283. select node([#sn])([ sn7→en ]) ≡283. let dp:DP • dp ∈ paths([ sn7→en ])283. ∧ ∃ i:Nat•i ∈ inds dp\len dp∧dp(i)=sn in

283. select node(dp)([ sn7→en ]) end

4.3.4 Index of Prompts 391

In Chap. 2 we motivated and briefly explained a number of domain analysis and domain descriptionprompts.

Analysis Prompts 392



Description Prompts 393



• • •

We shall now present a formal description of a meaning for these prompts.

4.3.5 A Formal Description of a Meaning of Prompts 394

The Iterative Nature of The Description Process

Assume that the domain analysers cum describers are analysing & describing a particular endurant; thatis, as we shall understand it, are examining a given endurant node in the domain description tree ! 395

To make this claim: the domain analysers cum describers are examining a given endurant node in thedomain description tree amounts to saying that the domain analysers cum describers have in their mind areasonably “stable” “picture” of a domain in terms of a domain description tree. 396

We need explain this assumption. In this assumption there is “buried” an understanding that the do-main analysers cum describers during the — what we can call “the final” — domain analysis & descriptionprocess, that leads to a “deliverable” domain description, are not investigating the domain to be describedfor the first time. That is, we certainly assume that any “final” domain analysis & description processhas been preceded by a number of iterations of “trial” domain analysis & description processes. 397

Hopefully this iteration of experimental domain analysis & description processes converges. Eachiteration leads to some domain description, that is, some domain description tree. A first iteration isthus based on a rather incomplete domain description tree which, however, “quickly” emerges into a lessincomplete one in that first iteration. When the domain analysers cum describers decide that a “final”iteration seems possible then a “final” description emerges If acceptable, OK, otherwise yet an “final”iteration must be performed. Common to all iterations is that the domain analysers cum describers have in 398

mind some more-or-less “complete” domain description tree and apply the prompts introduces in Chap. 2.



How Are We Modelling the Prompts 399

to be written

The Model 400

to be written

4.3.6 Discussion 401

to be written

4.4 Discussion of the Models 402


5

Facets 403

The domain analysis & description method outlined in Chaps. 2–4 was idealised ! It did not take intoaccount the views that anyone particular stake-holder might have on that stake-holder’s understanding ofthe domain. The techniques and tools of the domain analysis & description approach appear “technical”in the sense that they could be applied without considering such state-holder views. This chapter attemptsto remedy that problem.

5.1 Stake-holders 404

The key concept above was that of stake-holder. Let us define and examine that concept.

Definition 29 State-holder: By a ′domain stake-holder′ we shall understand a person, or a group of persons,“united” somehow in their common interest in, or dependency on the domain; or an institution, an enterprise,or a group of such, (again) characterised (and, again, loosely) by their common interest in, or dependency onthe domain .

405

Example 57 Some Stake-holders: For the domain of banking we can list at least the following distinct, i.e.,different stake-holder groups: clients, i.e., customers how have demand/deposit accounts, etc., bank teller,“back office”bank clerks, bank managers (at various levels). bank owners, suppliers (of banking equipment),banking regulators1, politicians, etcetera. They are distinct in that no two of these groups appears to haveexactly and only the same concerns. .

406

What separates one group of stake-holders from other groups are that they each put different emphasison the inclusion or understanding of a number for domain facets (to be defined immediately below). Inthis chapter we shall now concern ourselves with the concept of facets.

5.2 Domain Facets 407

Definition 30 Facet: By a ′domain facet′ we shall understand one amongst a finite set of generic ways ofanalysing a domain: a view of the domain, such that the different facets cover conceptually different views, andsuch that these views together cover the domain .

The hedge here is “finite set of generic ways”. Thus there is an assumption, a conjecture to be possiblyrefuted. Namely the postulate that there is a finite number of facets. We shall offer the following facets:intrinsics, support technology, management and organisation, rules and regulations (and scripts), andhuman behaviour.

1 In the US: the Federal Deposit Insurance Corporation, the Federal Reserve Board, and the Office ofthe Comptroller of the Currency; in Great Britain: Financial Services Authority.

82 5 Facets

5.2.1 Intrinsics 408

Definition 31 Intrinsics: By ′domain intrinsics′ we shall understand those phenomena and concepts of adomain which are basic to any of the other facets (listed earlier and treated, in some detail, below), with suchdomain intrinsics initially covering at least one specific, hence named, stake-holder view .

409

Example 58. Railway Net Intrinsics. We narrate and formalise three railway net intrinsics.

• From the view of potential train passengers a railway net consists of lines, stations and trains. A lineconnects exactly two distinct stations.

• From the view of actual train passengers a railway net — in addition to the above — allows for severallines between any pair of stations and, within stations, provides for one or more platform tracks fromwhich to embark or alight a train.410

• From the view of train operating staff a railway net — in addition to the above — has lines andstations consisting of suitably connected rail units. A rail unit is either a simple (i.e., linear, straight)unit, or is a switch unit, or is a simple crossover unit, or is a switchable crossover unit, etc. Simpleunits have two connectors. Switch units have three connectors. Simple and switchable crossover unitshave four connectors. A path (through a unit) is a pair of connectors of that unit. A state of a unitis the set of paths, in the direction of which a train may travel. A (current) state may be empty: Theunit is closed for traffic. A unit can be in either one of a number of states of its state space.

A summary formalisation of the three narrated railway net intrinsics could be:411

• Potential train passengers:

type

N, L, S, Sn, Lnvalue

obs Ls: N → L-set, obs Ss: N → S-setobs Ln: L → Ln, obs Sn: S → Snobs Sns: L → Sn-set, obs Lns: S → Ln-set

axiom...

N, L, S, Sn and Ln designate nets, lines, stations, station names and line names. One can observe linesand stations from nets, line and station names from lines and stations, pair sets of station names fromlines, and lines names (of lines) into and out from a station from stations. Axioms ensure proper graphproperties of these concepts.412

• Actual train passengers:

type

Tr, Trnvalue

obs Trs: S → Tr-set, obs Trn: Tr → Trnaxiom

...

The only additions are that of track and track name sorts, related observer functions and axioms.413

• Train operating staff:

type

U, CP′ = U × (C×C)P = | p:P′ • let (u,(c,c′))=p in (c,c′)∈ ∪ obs Ω(u) end |Σ = P-setΩ = Σ-set

valueobs Us: (N|L|S) → U-setobs Cs: U → C-setobs Σ: U → Σobs Ω: U → Ω

axiom...



Unit and connector sorts have been added as have concrete types for paths, unit states, unit state spacesand related observer functions, including unit state and unit state space observers. The reader is invitedto compare the three narrative descriptions with the three formal descriptions, line by line

414

Different stake-holder perspectives, not only of intrinsics, as here, but of any facet, lead to a numberof different models. The name of a phenomenon of one perspective, that is, of one model, may coincidewith the name of a “similar” phenomenon of another perspective, that is, of another model, and so on. Ifthe intention is that the “same” names cover comparable phenomena, then the developer must state thecomparison relation. 415

Example 59. Comparable Intrinsics. We refer to Example 58. We claim that the concept of nets, linesand stations in the three models of Example 58 must relate. The simplest possible relationships are to letthe third model be the common “unifier” and to mandate

• that the model of nets, lines and stations of the potential train passengers formalisation is that of nets,lines and stations of the train operating staff model; and

• that the model of nets, lines, stations and tracks of the actual train passengers formalisation is thatof nets, lines, stations of the train operating staff model.

Thus the third model is seen as the definitive model for the stake-holder views416

Example 60. Intrinsics of Switches. The intrinsic attribute of a rail switch is that it can take on a number

of states. A simple switch (c|Y

c/

c) has three connectors: c, c|, c/. c is the connector of the common rail

from which one can either “go straight” c|, or “fork” c/ (Fig. 5.1). So we have that a possible state spaceof such a switch could be ωgs :

,(c, c|), (c|, c), (c, c|), (c|, c),(c, c/), (c/, c), (c, c/), (c/, c), (c/, c), (c|, c),(c, c|), (c|, c), (c/, c), (c, c/), (c/, c), (c|, c), (c/, c), (c, c|), (c, c/), (c|, c)

417

C C

CCC

C

C

C

C C C

Closed

C

C/

C|

C/ C/ C/

C/C/C/C/

C/ C/ C/ C/

C| C| C|

C|C|C|C|

C| C| C| C|

Fig. 5.1. Possible states of a rail switch

418The above models a general switch ideally. Any particular switch ωps may have ωps⊂ωgs . Nothing is saidabout how a state is determined: who sets and resets it, whether determined solely by the physical positionof the switch gear, or also by visible or virtual (i.e., invisible, intangible) signals up or down the rail, awayfrom the switch .

Conceptual Versus Actual Intrinsics 419

In order to bring an otherwise seemingly complicated domain across to the reader, one may decide topresent it piecemeal:2First, one presents the very basics, the fewest number of inescapable entities, functionsand behaviours. Then, in a step of enrichment, one adds a few more (intrinsic) entities, functions andbehaviours. And so forth. In a final step one adds the last (intrinsic) entities, functions and behaviours.In order to develop what initially may seem to be a complicated domain, one may decide to develop 420

it piecemeal: We basically do as for the presentation steps: Steps of enrichment — from a big lie, viaincreasingly smaller lies, till one reaches a truth!

2 That seemingly complicated domain may seem very complicated, containing hundreds of entities. In-stead of presenting all the entities in one “fell swoop”, one presents them in stages.


84 5 Facets

On Modelling Intrinsics 421

Domains can be characterised by intrinsically being endurant, or function, or event, or behaviour intensive.Software support for activities in such domains then typically amount to database systems, computation-bound systems, real-time embedded systems, respectively distributed process monitoring and control sys-tems. Modelling the domain intrinsics in respective cases can often be done property-oriented specification422

languages (like CafeOBJ [46] or CASL [34]), model-oriented specification languages (like Alloy [65], B [1],VDM [23, 24, 44], RSL [48], or Z [106]), event-based languages (like Petri nets [89] or CSP [58]), respec-tively process-based specfication languages (like MSCs [64], LSCs [37, 55, 72], statecharts [54], or CSP[58]).

5.2.2 Support Technologies 423

Definition 32 Support technology: By a domain support technology we shall understand ways and meansof implementing certain observed phenomena or certain conceived concepts .

424

Example 61. Railway Support Technology. We give a rough sketch description of possible rail unit switchtechnologies.

(i) In “ye olde” days, rail switches were “thrown” by manual labour, i.e., by railway staff assigned toand positioned at switches.

(ii) With the advent of reasonably reliable mechanics, pulleys and levers3(and steel wires), switcheswere made to change state by means of “throwing” levers in a cabin tower located centrally at the station(with the lever then connected through wires etc., to the actual switch).

(iii) This partial mechanical technology then emerged into electro-mechanics, and cabin tower staffwas “reduced” to pushing buttons.

(iv) Today, groups of switches, either from a station arrival point to a station track, or from a stationtrack to a station departure point, are set and reset by means also of electronics, by what is known asinterlocking (for example, so that two different routes cannot be open in a station if they cross one another)

425

It must be stressed that Example 61 is just a rough sketch. In a proper narrative description the software(cum domain) engineer must describe, in detail, the subsystem of electronics, electro-mechanics and thehuman operator interface (buttons, lights, sounds, etc.).

An aspect of supporting technology includes recording the state-behaviour in response to externalstimuli. We give an example.426

Example 62. Probabilistic Rail Switch Unit State Transitions. Figure 5.2 indicates a way of formalisingthis aspect of a supporting technology. Figure 5.2 intends to model the probabilistic (erroneous and correct)behaviour of a switch when subjected to settings (to switched (s) state) and resettings (to direct (d) state).A switch may go to the switched state from the direct state when subjected to a switch setting s withprobability psd .

427

sed

sw/esd sw/ess

di/edd di/eds

di/1-pdd-edd

sw/psd

di/pds

sw/1-psd-esd

di/pdd

sw/pss

di/1-pds-eds

sw/1-pss-ess

Input stimuli:sw: Switch to switched state

di: Revert to direct state

Probabilities:pss: Switching to switched state from switched state

psd: Switching to switched state from direct state

pds: Reverting to direct state from switched state

pds: Reverting to direct state from direct state

esd: Switching to error state from direct state

edd: Reverting to error state from direct state

ess: Switching to error state from switched state

eds: Reverting to error state from switched state

0 <= p.. <= 1

States:s: Switched state

d: Direct (reverted) state

e: Error state

Fig. 5.2. Probabilistic state switching



428

Another example shows another aspect of support technology: Namely that the technology must guaranteecertain of its own behaviours, so that software designed to interface with this technology, together withthe technology, meets dependability requirements. 429

Example 63. Railway Optical Gates. Train traffic (itf:iTF), intrinsically, is a total function over some timeinterval, from time (t:T) to continuously positioned (p:P) trains (tn:TN).

Conventional optical gates sample, at regular intervals, the intrinsic train traffic. The result is a sampledtraffic (stf:sTF). Hence the collection of all optical gates, for any given railway, is a partial function fromintrinsic to sampled train traffics (stf).

We need to express quality criteria that any optical gate technology should satisfy — relative to anecessary and sufficient description of a closeness predicate. The following axiom does that: 430

For all intrinsic traffics, itf, and for all optical gate technologies, og, the following must hold: Let stfbe the traffic sampled by the optical gates. For all time points, t, in the sampled traffic, those timepoints must also be in the intrinsic traffic, and, for all trains, tn, in the intrinsic traffic at that time,the train must be observed by the optical gates, and the actual position of the train and the sampledposition must somehow be checkable to be close, or identical to one another.

Since units change state with time, n:N, the railway net, needs to be part of any model of traffic. 431

type

T, TNP = U∗

NetTraffic == net:N trf:(TN →m P)iTF = T → NetTrafficsTF = T →m NetTraffic

oG = iTF∼→ sTF

value

[ close ] c: NetTraffic × TN × NetTraffic∼→ Bool

axiom∀ itt:iTF, og:OG • let stt = og(itt) in

∀ t:T • t ∈ dom stt •

t ∈ D itt ∧ ∀ Tn:TN • tn ∈ dom trf(itt(t))⇒ tn ∈ dom trf(stt(t)) ∧ c(itt(t),tn,stt(t)) end

D is not an RSL operator. It is a mathematical way of expressing the definition set of a general function. 432

Hence it is not a computable function. Check-ability is an issue of testing the optical gates when deliveredfor conformance to the closeness predicate, i.e., to the axiom .

On Modelling Support Technologies 433

Support technologies in their relation to the domain in which they reside typically reflect real-time em-beddedness. As such the techniques and languages for modelling support technologies resemble those formodelling event and process intensity, while temporal notions are brought into focus. Hence typical mod-elling notations include event-based languages (like Petri nets [89] or CSP [58]), respectively process-basedspecification languages (like MSCs [64], LSCs [37, 55, 72], Statecharts [54], or CSP [58]), as well as temporallanguages (like the Duration Calculus, DC [108] and Temporal Logic of Actions, TLA+ [73]).

5.2.3 Management and Organisation 434

Example 64. Train Monitoring, I. In China, as an example, rescheduling of trains occurs at stations andinvolves telephone negotiations with neighbouring stations (“up and down the lines”). Such reschedulingnegotiations, by phone, imply reasonably strict management and organisation (M&O). This kind of M&Oreflects the geographical layout of the rail net .

435


86 5 Facets

Definition 33 Domain Management: By domain management we shall understand such people (suchdecisions) (i) who (which) determine, formulate and thus set standards (cf. rules and regulations, Sect. 5.2.4)concerning strategic, tactical and operational decisions; (ii) who ensure that these decisions are passed on to(lower) levels of management, and to floor staff; (iii) who make sure that such orders, as they were, are indeedcarried out; (iv) who handle undesirable deviations in the carrying out of these orders cum decisions; and (v)who “backstop” complaints from lower management levels and from floor staff .

436

Definition 34 Domain Organisation: By domain organisation we shall understand the structuring of man-agement and non-management staff levels; the allocation of strategic, tactical and operational concerns towithin management and non-management staff levels; and hence the “lines of command”: who does what, andwho reports to whom, administratively and functionally .

437

Example 65. Railway Management and Organisation: Train Monitoring, II. We single out a rather spe-cial case of railway management and organisation. Certain (lowest-level operational and station-located)supervisors are responsible for the day-to-day timely progress of trains within a station and along itsincoming and outgoing lines, and according to given timetables. These supervisors and their immediate(middle-level) managers (see below for regional managers) set guidelines (for local station and incomingand outgoing lines) for the monitoring of train traffic, and for controlling trains that are either ahead of orbehind their schedules. By an incoming and an outgoing line we mean part of a line between two stations,438

the remaining part being handled by neighbouring station management. Once it has been decided, by sucha manager, that a train is not following its schedule, based on information monitored by non-managementstaff, then that manager directs that staff: (i) to suggest a new schedule for the train in question, aswell as for possibly affected other trains, (ii) to negotiate the new schedule with appropriate neighbour-ing stations, until a proper reschedule can be decided upon, by the managers at respective stations, (iii)and to enact that new schedule.4A (middle-level operations) manager for regional traffic, i.e., train trafficinvolving several stations and lines, resolves possible disputes and conflicts .

439

The above, albeit rough-sketch description, illustrated the following management and organisation issues:There is a set of lowest-level (as here: train traffic scheduling and rescheduling) supervisors and theirstaff. They are organised into one such group (as here: per station). There is a middle-level (as here:regional train traffic scheduling and rescheduling) manager (possibly with some small staff), organisedwith one such per suitable (as here: railway) region. The guidelines issued jointly by local and regional(...) supervisors and managers imply an organisational structuring of lines of information provision andcommand.

Conceptual Analysis, First Part 440

People staff enterprises, the components of infrastructures with which we are concerned, i.e., for which wedevelop software. The larger these enterprises — these infrastructure components — the more need thereis for management and organisation. The role of management is roughly, for our purposes, twofold: first,441

to perform strategic, tactical and operational work, to set strategic, tactical and operational policies —and to see to it that they are followed. The role of management is, second, to react to adverse conditions,that is, to unforeseen situations, and to decide how they should be handled, i.e., conflict resolution.

Policy-setting should help non-management staff operate normal situations — those for which nomanagement interference is thus needed. And management “backstops” problems: management takesthese problems off the shoulders of non-management staff.442

To help management and staff know who’s in charge wrt. policy setting and problem handling, aclear conception of the overall organisation is needed. Organisation defines lines of communication withinmanagement and staff, and between these. Whenever management and staff has to turn to others forassistance they usually, in a reasonably well-functioning enterprise, follow the command line: the paths oforganigrams — the usually hierarchical box and arrow/line diagrams.

4 That enactment may possibly imply the movement of several trains incident upon several stations: theone at which the manager is located, as well as possibly at neighbouring stations.



Methodological Consequences 443

The management and organisation model of a domain is a partial specification; hence all the usual ab-straction and modelling principles, techniques and tools apply. More specifically, management is a set ofpredicates, observer and generator functions which either parameterise other, the operations functions,that is, determine their behaviour, or yield results that become arguments to these other functions

Organisation is thus a set of constraints on communication behaviours. Hierarchical, rather than linear,and matrix structured organisations can also be modelled as sets (of recursively invoked sets) of equations.

Conceptual Analysis, Second Part 444

To relate classical organigrams to formal descriptions we first show such an organigram (Fig. 5.3), and thenwe show schematic processes which — for a rather simple scenario — model managers and the managed! 445

.

Director

Board

Staff bStaff a Manager

Staff 1 Staff 2 Staff 3

Unit

A Matrix OrganisationA Hierarchical Organisation

Board

Director

Unit

Unit Unit

UnitUnit

Unit

Unit

Manager Manager Manager

Functional

Functional

Functional

Admin. Admin. Admin.

Manager

Manager

Manager

.....

.....

.......... .....

Fig. 5.3. Organisational structures

446

Based on such a diagram, and modelling only one neighbouring group of a manager and the staffworking for that manager we get a system in which one manager, mgr, and many staff, stf, coexist or workconcurrently, i.e., in parallel. The mgr operates in a context and a state modelled by ψ. Each staff, stf(i)operates in a context and a state modelled by sσ(i). 447

type

Msg, Ψ , Σ, SxSΣ = Sx →m Σ

channel ms[ i ]:Msg | i:Sx

valuesσ:SΣ, ψ:Ψ

sys: Unit → Unitsys() ≡ ‖ st(i)(sσ(i)) | i:Sx ‖ mg(ψ)

448In this system the manager, mgr, (1) either broadcasts messages, m, to all staff via message channelms[i]. The manager’s concoction, m out(ψ), of the message, msg, has changed the manager state. Or (2)is willing to receive messages, msg, from whichever staff i the manager sends a message. Receipt of themessage changes, m in(i,m)(ψ), the manager state. In both cases the manager resumes work as from thenew state. The manager chooses — in this model — which of thetwo things (1 or 2) to do by a so-callednondeterministic internal choice (⌈⌉). 449

mg: Ψ → in,out ms[ i ]|i:Sx Unitmg(ψ) ≡

(1) (let (ψ′,m)=m out(ψ) in ‖ms[ i ]!m|i:Sx;mg(ψ′)end)


88 5 Facets

⌈⌉(2) (let ψ′=⌈⌉⌊⌋let m=ms[ i ]? in m in(i,m)(ψ) end|i:Sx in mg(ψ′) end)

m out: Ψ → Ψ × MSG,m in: Sx × MSG → Ψ → Ψ

450And in this system, staff i, stf(i), (1) either is willing to receive a message, msg, from the manager, and thento change, st in(msg)(σ), state accordingly, or (2) to concoct, st out(σ), a message, msg (thus changingstate) for the manager, and send it ms[i]!msg. In both cases the staff resumes work as from the new state.The staff member chooses — in this model — which of thetwo “things” (1 or 2) to do by a nondeterministicinternal choice (⌈⌉).451

st: i:Sx → Σ → in,out ms[ i ] Unitst(i)(σ) ≡

(1) (let m = ms[ i ]? in st(i)(stf in(m)(σ)) end)⌈⌉

(2) (let (σ′,m) = st out(σ) in ms[ i ]!m; st(i)(σ′) end)

st in: MSG → Σ → Σ,st out: Σ → Σ × MSG

452Both manager and staff processes recurse (i.e., iterate) over possibly changing states. The managementprocess nondeterministically, external choice, “alternates” between “broadcast”-issuing orders to staff andreceiving individual messages from staff. Staff processes likewise nondeterministically, external choice,alternate between receiving orders from management and issuing individual messages to management.

The conceptual example also illustrates modelling stake-holder behaviours as interacting (here CSP-like[58]) processes.

On Modelling Management and Organisation 453

Management and organisation basically spans entity, function, event and behaviour intensities and thustypically require the full spectrum of modelling techniques and notations — summarised in the two “OnModelling ...” paragraphs at the end of the two previous sections.

5.2.4 Rules and Regulations 454

Definition 35 Domain Rules: By a domain rule we shall understand some text (in the domain) whichprescribes how people or equipment are expected to behave when dispatching their duty, respectively whenperforming their function .

Definition 36 Domain Regulation: By a domain regulation we shall understand some text (in the domain)which prescribes what remedial actions are to be taken when it is decided that a rule has not been followedaccording to its intention .

455

Example 66. Trains at Stations.

• Rule: In China the arrival and departure of trains at, respectively from, railway stations is subject tothe following rule:

In any three-minute interval at most one train may either arrive to or depart from a railwaystation.

• Regulation: If it is discovered that the above rule is not obeyed, then there is some regulation whichprescribes administrative or legal management and/or staff action, as well as some correction to therailway traffic .

456

Example 67. Trains Along Lines.

• Rule: In many countries railway lines (between stations) are segmented into blocks or sectors. Thepurpose is to stipulate that if two or more trains are moving along the line, then:



There must be at least one free sector (i.e., without a train) between any two trains along aline.

• Regulation: If it is discovered that the above rule is not obeyed, then there is some regulation whichprescribes administrative or legal management and/or staff action, as well as some correction to therailway traffic .

A Meta-characterisation of Rules and Regulations 457

At a meta-level, i.e., explaining the general framework for describing the syntax and semantics of thehuman-oriented domain languages for expressing rules and regulations, we can say the following: Thereare, abstractly speaking, usually three kinds of languages involved wrt. (i.e., when expressing) rules andregulations (respectively when invoking actions that are subject to rules and regulations). Two languages,Rules and Reg, exist for describing rules, respectively regulations; and one, Stimulus, exists for describingthe form of the [always current] domain action stimuli. 458

A syntactic stimulus, sy sti, denotes a function, se sti:STI: Θ → Θ, from any configuration to a nextconfiguration, where configurations are those of the system being subjected to stimulations. A syntacticrule, sy rul:Rule, stands for, i.e., has as its semantics, its meaning, rul:RUL, a predicate over current andnext configurations, (Θ × Θ) → Bool, where these next configurations have been brought about, i.e.,caused, by the stimuli. These stimuli express: If the predicate holds then the stimulus will result in a validnext configuration. 459

type

Stimulus, Rule, ΘSTI = Θ → ΘRUL = (Θ × Θ) → Bool

valuemeaning: Stimulus → STImeaning: Rule → RUL

valid: Stimulus × Rule → Θ → Boolvalid(sy sti,sy rul)(θ) ≡ meaning(sy rul)(θ,(meaning(sy sti))(θ))

valid: Stimulus × RUL → Θ → Boolvalid(sy sti,se rul)(θ) ≡ se rul(θ,(meaning(sy sti))(θ))

460A syntactic regulation, sy reg:Reg (related to a specific rule), stands for, i.e., has as its semantics, its mean-ing, a semantic regulation, se reg:REG, which is a pair. This pair consists of a predicate, pre reg:Pre REG,where Pre REG = (Θ × Θ) → Bool, and a domain configuration-changing function, act reg:Act REG,where Act REG = Θ → Θ, that is, both involving current and next domain configurations. The two kinds 461

of functions express: If the predicate holds, then the action can be applied.The predicate is almost the inverse of the rules functions. The action function serves to undo the

stimulus function. 462

type

RegRul and Reg = Rule × RegREG = Pre REG × Act REGPre REG = Θ × Θ → BoolAct REG = Θ → Θ

valueinterpret: Reg → REG

463The idea is now the following: Any action of the system, i.e., the application of any stimulus, may be anaction in accordance with the rules, or it may not. Rules therefore express whether stimuli are valid ornot in the current configuration. And regulations therefore express whether they should be applied, and,if so, with what effort. 464

More specifically, there is usually, in any current system configuration, given a set of pairs of rulesand regulations. Let (sy rul,sy reg) be any such pair. Let sy sti be any possible stimulus. And let θ be


90 5 Facets

the current configuration. Let the stimulus, sy sti, applied in that configuration result in a next config-uration, θ′, where θ′ = (meaning(sy sti))(θ). Let θ′ violate the rule, ∼valid(sy sti,sy rul)(θ), then if pred-icate part, pre reg, of the meaning of the regulation, sy reg, holds in that violating next configuration,pre reg(θ,(meaning(sy sti))(θ)), then the action part, act reg, of the meaning of the regulation, sy reg, mustbe applied, act reg(θ), to remedy the situation.465

axiom∀ (sy rul,sy reg):Rul and Regs •

let se rul = meaning(sy rul),(pre reg,act reg) = meaning(sy reg) in

∀ sy sti:Stimulus, θ:Θ •

∼valid(sy sti,se rul)(θ)⇒ pre reg(θ,(meaning(sy sti))(θ))

⇒ ∃ nθ:Θ • act reg(θ)=nθ ∧ se rul(θ,nθ)end

466It may be that the regulation predicate fails to detect applicability of regulations actions. That is, theinterpretation of a rule differs, in that respect, from the interpretation of a regulation. Such is life in thedomain, i.e., in actual reality

On Modelling Rules and Regulations 467

Usually rules (as well as regulations) are expressed in terms of domain entities, including those groupedinto “the state”, functions, events, and behaviours. Thus the full spectrum of modelling techniques andnotations may be needed. Since rules usually express properties one often uses some combination of axiomsand well-formedness predicates. Properties sometimes include temporality and hence temporal notations468

(like Duration Calculus [108] or Temporal Logic of Actions [73]) are used. And since regulations usuallyexpress state (restoration) changes one often uses state changing notations (such as found in B [1], RSL[48], VDM-SL [23, 24, 44], and Z [106]). In some cases it may be relevant to model using some constraintsatisfaction notation [3] or some Fuzzy Logic notations [103].

5.2.5 Scripts and Licensing Languages 469

Definition 37 Domain Script: By a domain script we shall understand the structured, almost, if not outright,formally expressed, wording of a rule or a regulation that has legally binding power, that is, which may becontested in a court of law .

470

Example 68. A Casually Described Bank Script. We deviate, momentarily, from our line of railway ex-amples, to exemplify one from banking. Our formulation amounts to just a (casual) rough sketch. It isfollowed by a series of four large examples. Each of these elaborate on the theme of (bank) scripts.

The problem area is that of how repayments of mortgage loans are to be calculated. At any one timea mortgage loan has a balance, a most recent previous date of repayment, an interest rate and a handlingfee. When a repayment occurs, then the following calculations shall take place: (i) the interest on the471

balance of the loan since the most recent repayment, (ii) the handling fee, normally considered fixed, (iii)the effective repayment — being the difference between the repayment and the sum of the interest andthe handling fee — and the new balance, being the difference between the old balance and the effectiverepayment. We assume repayments to occur from a designated account, say a demand/deposit account.We assume that bank to have designated fee and interest income accounts. (i) The interest is subtracted472

from the mortgage holder’s demand/deposit account and added to the bank’s interest (income) account.(ii) The handling fee is subtracted from the mortgage holder’s demand/deposit account and added tothe bank’s fee (income) account. (iii) The effective repayment is subtracted from the mortgage holder’sdemand/deposit account and also from the mortgage balance. Finally, one must also describe deviationssuch as overdue repayments, too large, or too small repayments, and so on .

473

Example 69. A Formally Described Bank Script. First we must informally and formally define the bankstate:

There are clients (c:C), account numbers (a:A), mortgage numbers (m:M), account yields (ay:AY)and mortgage interest rates (mi:MI). The bank registers, by client, all accounts (ρ:A Register) and all



mortgages (µ:M Register). To each account number there is a balance (α:Accounts). To each mortgagenumber there is a loan (ℓ:Loans). To each loan is attached the last date that interest was paid on the loan.

474

type

C, A, MAY′ = Real, AY = | ay:AY′ • 0<ay≤10 |MI′ = Real, MI = | mi:MI′ • 0<mi≤10 |Bank′ = A Register × Accounts × M Register × LoansBank = | β:Bank′ • wf Bank(β)|A Register = C →m A-setAccounts = A →m BalanceM Register = C →m M-setLoans = M →m (Loan × Date)Loan,Balance = PP = Nat

475Then we must define well-formedness of the bank state:

valueay:AY, mi:MI

wf Bank: Bank → Boolwf Bank(ρ,α,µ,ℓ) ≡ ∪ rng ρ = dom α ∧ ∪ rng µ = dom ℓ

axiomai<mi

476Operations on banks are denoted by the commands of the bank script language. First the syntax:

type

Cmd = OpA | CloA | Dep | Wdr | OpM | CloM | PayOpA == mkOA(c:C)CloA == mkCA(c:C,a:A)Dep == mkD(c:C,a:A,p:P)Wdr == mkW(c:C,a:A,p:P)OpM == mkOM(c:C,p:P)Pay == mkPM(c:C,a:A,m:M,p:P)CloM == mkCM(c:C,m:M,p:P)Reply = A | M | P | OkNokOkNok == ok | notok

477And then the semantics:

int Cmd(mkPM(c,a,m,p,d′))(ρ,α,µ,ℓ) ≡let (b,d) = ℓ(m) inif α(a)≥p

thenlet i = interest(mi,b,d′−d),

ℓ′ = ℓ † [m 7→ℓ(m)−(p−i) ]α′ = α † [ a7→α(a)−p,ai 7→α(ai)+i ] in

((ρ,α′,µ,ℓ′),ok) endelse

((ρ,α′,µ,ℓ),nok)end endpre c ∈ dom µ ∧ m ∈ µ(c)

And so forth for remaining commands .

The idea about scripts is that they can somehow be objectively enforced: that they can be precisely 478

understood and consistently carried out by all stakeholders, eventually leading to computerisation. Butthey are, at all times, part of the domain.


92 5 Facets

Licensing Languages 479

A special form of scripts are increasingly appearing in some domains, notably the domain of electronic,or digital media, where these licenses express that the licensor permits the licensee to render (i.e., play)works of proprietary nature CD ROM-lile music, DVD-like movies, ec. while obligating the licensee to paythe licensor on behalf of the owners of these, usually artistic works. We refer to [51, 87, 92, 26, 5, 32, 107]for papers and reports on license languages.

On Modelling Scripts 480

Scripts (as are licenses) are like programs (respectively like prescriptions for program executions). Hencethe full variety of techniques and notations for modelling programming (or specification) languages apply[39, 52, 90, 94, 100, 105]. Chapters 6–9 of Vol. 2 of [10, 12, 13] cover pragmatics, semantics and syntaxtechniques for defining languages.

5.2.6 Human Behaviour 481

Definition 38 Human Behaviour: By domain human behaviour we shall understand any of a quality spec-trum of carrying out assigned work: from (i) careful, diligent and accurate, via (ii) sloppy dispatch, and (iii)delinquent work, to (iv) outright criminal pursuit .

482

Example 70. Banking — or Programming — Staff Behaviour. Let us assume a bank clerk, “in ye olde”days, when calculating, say mortgage repayments (cf. Example 68).

We would characterise such a clerk as being diligent, etc., if that person carefully follows the mortgagecalculation rules, and checks and double-checks that calculations “tally up”, or lets others do so. We wouldcharacterise a clerk as being sloppy if that person occasionally forgets the checks alluded to above. Wewould characterise a clerk as being delinquent if that person systematically forgets these checks. And wewould call such a person a criminal if that person intentionally miscalculates in such a way that the bank(and/or the mortgage client) is cheated out of funds which, instead, may be diverted to the cheater. Let us,483

instead of a bank clerk, assume a software programmer charged with implementing an automatic routinefor effecting mortgage repayments (cf. Example 69). We would characterise the programmer as beingdiligent if that person carefully follows the mortgage calculation rules, and throughout the developmentverifies and tests that the calculations are correct with respect to the rules. We would characterise theprogrammer as being sloppy if that person forgets certain checks and tests when otherwise correcting thecomputing program under development. We would characterise the programmer as being delinquent ifthat person systematically forgets these checks and tests. And we would characterise the programmer asbeing a criminal if that person intentionally provides a program which miscalculates the mortgage interest,etc., in such a way that the bank (and/or the mortgage client) is cheated out of funds .

484

Example 71. A Human Behaviour Mortgage Calculation. Example 69 gave a semantics to the mortgagecalculation request (i.e., command) as would a diligent bank clerk be expected to perform it. To express,that is, to model, how sloppy, delinquent, or outright criminal persons (staff?) could behave we mustmodify the int Cmd(mkPM(c,a,m,p,d′))(ρ,α,µ,ℓ) definition.485

int Cmd(mkPM(c,a,m,p,d′))(ρ,α,µ,ℓ) ≡let (b,d) = ℓ(m) inif q(α(a),p) /∗ α(a)≤p∨α(a)=p∨α(a)≤p∨... ∗/

thenlet i = f1(interest(mi,b,d′−d)),

ℓ′ = ℓ † [m 7→f2(ℓ(m)−(p−i)) ]α′ = α † [ a7→f3(α(a)−p),ai 7→f4(α(ai)+i),

a“staff” 7→f“staff”(α(ai)+i) ] in((ρ,α′,µ,ℓ′),ok) end

else((ρ,α′,µ,ℓ),nok)

end endpre c ∈ dom µ ∧ m ∈ µ(c)



486The predicate q and the functions f1, f2, f3, f4 and f“staff” of Example 71 are deliberately left undefined.

q: P × P∼→ Bool

f1,f2,f3,f4,f“staff”: P∼→ P

They are being defined by the “staffer” when performing (incl., programming) the mortgage calculationroutine .

487

The point of Example 71 is that one must first define the mortgage calculation script precisely as onewould like to see the diligent staff (programmer) to perform (incl., correctly program) it before one can“pinpoint” all the places where lack of diligence may “set in”. The invocations of q, f1, f2, f3, f4 andf“staff” designate those places. 488

The point of Example 71 is also that we must first domain-define, “to the best of our ability” all theplaces where human behaviour may play other than a desirable role. If we cannot, then we cannot claimthat some requirements aim at countering undesirable human behaviour.

A Meta-characterisation of Human Behaviour 489

Commensurate with the above, humans interpret rules and regulations differently, and not always “con-sistently” — in the sense of repeatedly applying the same interpretations.

Our final specification pattern is therefore: 490

type

Action = Θ∼→ Θ-infset

valuehum int: Rule → Θ → RUL-infsetaction: Stimulus → Θ → Θ

hum beha: Stimulus × Rules → Action → Θ∼→ Θ-infset

hum beha(sy sti,sy rul)(α)(θ) as θsetpost

θset = α(θ) ∧ action(sy sti)(θ) ∈ θset∧ ∀ θ′:Θ•θ′ ∈ θset ⇒

∃ se rul:RUL•se rul ∈ hum int(sy rul)(θ)⇒se rul(θ,θ′)

491The above is, necessarily, sketchy: There is a possibly infinite variety of ways of interpreting some rules. Ahuman, in carrying out an action, interprets applicable rules and chooses one which that person believessuits some (professional, sloppy, delinquent or criminal) intent. “Suits” means that it satisfies the intent,i.e., yields true on the pre/post-configuration pair, when the action is performed — whether as intendedby the ones who issued the rules and regulations or not. We do not cover the case of whether an appropriateregulation is applied or not 492

The above-stated axioms express how it is in the domain, not how we would like it to be. For that wehave to establish requirements.

On Modelling Human Behaviour 493

To model human behaviour is, “initially”, much like modelling management and organsiation. But only ‘ini-tially’. The most significant human behaviour modelling aspects is then that of modelling non-determinismand looseness, even ambiguity. So a specification language which allows specifying non-determinism andlooseness (like CafeOBJ [46] and RSL [48]) is to be preferred.

5.2.7 Completion 494

Domain acquisition resulted in typically up to thousands of units of domain descriptions. Domain analysissubsequently also serves to classify which facet any one of these description units primarily characterise.But some such “compartmentalisations” may be difficult, and may be deferred till the step of “completion”.It may then be — “at the end of the day”, that is, after all of the above facets have been modelled —that some description units are left as not having been described, not deliberately, but “circumstantially”.It then behooves the domain engineer to fit these “dangling” description units into suitable parts of the 495


94 5 Facets

domain description. This “slotting in” may be simple, and all is fine. Or it may be difficult. Such difficultymay be a sign that the chosen model, the chosen description, in its selection of endurants, functions, eventsand behaviours to model — in choosing these over other possible selections of phenomena and conceptsis not appropriate. Another attempt must be made. Another selection, another abstraction of entities,496

functions, etc., may need be chosen. Usually however, after having chosen the abstractions of the intrinsicphenomena and concepts, one can start checking whether “dangling” description units can be fitted in“with ease”.

5.2.8 Integrating Formal Descriptions 497

We have seen that to model the full spectrum of domain facets one needs not one, but several specificationlanguages. No single specification language suffices. It seems highly unlikely and it appears not to bedesirable to obtain a single, “universal” specification language capable of “equally” elegantly, suitablyabstractly modelling all aspects of a domain. Hence one must conclude that the full modelling of domainsshall deploy several formal notations. The issues are then the following which combinations of notations to498

select, and how to make sure that the combined specification denotes something meaningful. The ongoingseries of “Integrating Formal Methods” conferences [4] is a good source for technques, compositions andmeaning.

5.3 Closing Discussion 499


6

Domain Engineering 500

Chapters 2–5 presented a method for describing domains. Some questions are now:

• Who develops domain descriptions ?• How do we actually pursue the task of constructing a domain description ?• If available, do we re-use existing domain descriptions ?

We intend to discuss possible answers to these (and other [un-asked]) questions in this chapter. Westructure our answers around an outline of the various stages and steps of the domain enginering phase.

6.1 Stages and Steps 501

We consider the processes of domain engineering to constitute a phase of development. Requirementsengineering and software design constitute subsequent development phases. 502

Definition 39 A ‘Development Phase’ Concept: By a development ′phase′ we shall understand .503

Definition 40 A ‘Development Stage’ Concept: By a development ′stage′ we shall understand .504

The domain engineering phase consists, roughly, of the following development stages:

(Sect. 6.1.1) domain phase preparation;(Sect. 6.1.2) stake-holder identification;(Sect. 6.1.3) domain capture: acquisition and elicitation,(Sect. 6.1.4) domain analysis & description;(Sect. 6.1.5) domain description analysis:(Sect. 6.1.6) domain validation.

505

Definition 41 A ‘Development Step’ Concept: By a development ′step′ we shall understand .

96 6 Domain Engineering

6.1.1 Preparation 506

6.1.2 Stake-holder Identification 507

6.1.3 Acquisition and Elicitation 508

6.1.4 Domain Analysis & Description 509

6.1.5 Description Analysis 510

Testing 511

Model Checking 512

Verification 513

6.1.6 Description Validation 514

6.2 Domain Theories 515

6.3 Domain Science 516

6.4 Discussion 517


Part III

Requirements

7

From Domains to Requirements 518

7.1 Introduction 519

Definition 42 Requirements (I): By a ′requirements′ we understand (cf. IEEE Standard 610.12 [63]):“A condition or capability needed by a user to solve a problem or achieve an objective” .

520

Example 72 First ‘Requirements’ Examples We give a few examples of requirements. The examplesare very brief, hence they are far from representative of comprehensive requirements prescriptions. Theexamples below are meant to give some very first hints as to what requirements prescriptions may look like.Take them as rough sketches.

1. Administrative forms processing: Office managers shall be able to design forms, aggregations offorms and routines for extracting information from forms and their aggregations.

2. Airport: Boarding cards shall be electronic cards that automatically register where in, or near anairport, or in an aircraft the card is located.

3. Air traffic: The aircraft tracking system shall alert the terminal control centre operator responsiblefor handling certain aircraft if any of these deviate significantly from their planned routes. 521

4. Container terminal: The bar-code system which registers each and every container subject to un-loading or loading shall fail at most once in every 200,000 registrations.

5. Document system: Each and every (electronic) document shall contain its entire history: from someoriginal as first created, via all intervening editing and/or copying, etc., including the location, timeand person responsible for creation, copying and editing.

6. Freight logistics: The freight logistics system, relying on each freight item being suitably equippedwith a GPS system responder, is allowed to miss at most one in every 300,000 traced items. 522

7. Financial service system: The stock exchange (system) shall be able to trace all buy and sell orders,as well as all withdrawn such, and all actual transactions, by buyer and seller identification.

8. Hospital: The hospitalisation system which to every actual and scheduled patient provides a (flowchart-like) hospitalisation plan, shall be able, at any moment, to estimate and plan for (allocate and schedule)current, immediate and longer-term resource needs: beds, staff (of all categories), medicine, food andbeverages, and operating theatres.

9. Manufacturing company: For each production cell its current, immediate and longer-term uses,supply of production parts, preventive maintenance schedules, as well as staffing, shall be computable(hence displayable) at any moment. 523

10. Market: Retailer orders with wholesalers, and wholesaler orders with producers (i.e., distributors)shall be automatically issued subject to precisely stated script constraints, and as prompted by “lowstock” of certain composites of merchandise.

11. Metropolitan area tourism: The MetaTourism system shall enable any suitably equipped (home PC +special GPS, display screen + software controlled mobile phone) person to plan and execute a sequenceof visits to places (hotels, restaurants, shops, museums, etc.) and the transport between these. 524

12. Railways: The train monitoring and control system, RaCoSy, being required, shall be able to monitortrains and, if needed, reschedule train traffic, and to do so continuously, and thus to set signals, switchesand train speeds accordingly, and to inform all relevant stake-holders (passengers, train driver, andline and station staff) of any such changes.

The above examples were presented, at this early stage, just to give you a first “feel” for what we are talkingabout .

100 7 From Domains to Requirements

525

The objective of requirements engineering is to create a requirements prescription: A requirementsprescription specifies externally observable properties of entities, functions, events and behaviours of themachine such as the requirements stake-holders wish them to be. The machine is what is required: thatis, the hardware and software that is to be designed and which are to satisfy the requirements. A re-quirements prescription thus (putatively) expresses what there should be. A requirements prescriptionexpresses nothing about the design of the possibly desired (required) software. We shall show how a majorpart of a requirements prescription can be “derived” from “its” prerequisite domain description.526

Rule 1 The “Golden Rule” of Requirements Engineering: Prescribe only those requirements that can beobjectively shown to hold for the designed software .

“Objectively shown” means that the designed software can either be proved (verified), or be model checked,or be tested, to satisfy the requirements.527

Rule 2 An “Ideal Rule” of Requirements Engineering: When prescribing (including formalising) require-ments, also formulate tests (theorems, properties for model checking) whose actualisation should showadherence to the requirements .

The rule is labelled “ideal” since such precautions will not be shown in this volume. It ought be shown, buteither we would show one, or a few instances, and they would “drown” in the mass of material otherwisepresented. Or they would, we claim, trivially take up too much space. The rule is clear. It is a questionfor proper management to see that it is adhered to.528

Example 73 Analysis of First ‘Requirements’ Examples We analyse the examples of Example 72. Ouranalysis merely consists in listing the domain-specific terms that need to have been precisely described ina prior domain description:

1. Administrative forms processing: (i) office managers, (ii) design, (iii) forms, (iv) aggregations offorms, (v) routines (scripts) for extracting information from forms and their aggregations.

2. Airport: (i) boarding cards, (ii) where (i.e., airport and aircraft locations).529

3. Air traffic: (i) terminal control centre operator, (ii) responsible for handling certain aircraft, (iii)aircraft, (iv) deviate significantly, (v) planned route.

4. Container terminal: (i) bar-code system, (ii) register, (iii) container, (iv) unloading, (v) loading,(vi) registration.

5. Document system: (i) document (ii) [document] history, (iii) original, (iv) created, (v) editing, (vi)copying, (vii) location, (viii) time, (ix) person, (x) responsible.530

6. Freight logistics: (i) freight logistics system, (ii) freight item, (iii) GPS system responder, (iv) trace.7. Financial service system: (i) stock exchange, (ii) trace, (iii) buy order, (iv) sell order, (v) with-

drawals, (vi) actual transactions, (vii) buyer and seller identification.8. Hospital: (i) hospitalisation system, (ii) actual patient, (iii) scheduled patient, (iv) hospitalisation

plan, (v) allocate and schedule resources, (vi) current, immediate and longer-term resources, (vii) bed,(viii) staff, (ix) medicine, (x) food and beverages, (xi) operating theatre.531

9. Manufacturing company: (i) production cell, (ii) current, immediate and longer-term use, (iii) use,(iv) supply, (v) production part, (vi) preventive maintenance schedules, (vii) staffing.

10. Market: (i) Retailer, (ii) orders, (iii) wholesaler, (iv) producer, (v) distributors, (vi) ordering (“is-sued”), (vii) ordering constraint, (viii) “low stock”, (ix) composite of merchandise.

11. Metropolitan area tourism: (i) person (i.e., potential or actual tourist), (ii) plan, (iii) execute, (iv)visit, (v) place, (vi) hotels, (vii) restaurant, (viii) shop, (ix) museum, etc. (. . . ), (x) transport.532

12. Railways: (i) monitor train, (ii) reschedule, (iii) train traffic, (iv) set, (v) signal, (vi) switch, (vii)train speed, (viii) inform, (ix) relevant stake-holders, (x) passenger, (xi) train driver, (xii) line staff,(xiii) station staff, (xiv) change.

The above examples were presented, at this early stage, to let you see why we need a precise domaindescription .533

Rule 3 Requirements Adequacy: Make sure that requirements cover what users expect .

That is, do not express a requirement for which you have no users, but make sure that all users’ require-ments are represented or somehow accommodated. In other words: the requirements gathering processneeds to be like an extremely “fine-meshed net”: One must make sure that all possible stake-holders havebeen involved in the requirements acquisition process, and that possible conflicts and other inconsistencieshave been obviated.534


7.3 Stages of Requirements Engineering 101

Rule 4 Requirements Implementability: Make sure that requirements are implementable .

That is, do not express a requirement for which you have no assurance that it can be implemented. Inother words, although the requirements phase is not a design phase, one must tacitly assume, perhapseven indicate, somehow, that an implementation is possible. But the requirements in and by themselves,stay short of expressing such designs. 535

Rule 5 Requirements Verifiability and Validability: Make sure that requirements are verifiable and canbe validated .

That is, do not express a requirement for which you have no assurance that it can be verified and validated.In other words, once a first-level software design has been proposed, one must show that it satisfies therequirements. Thus specific parts of even abstract software designs are usually provided with referencesto specific parts of the requirements that they are (thus) claimed to implement. 536

We repeat the characterisation of the concept of ‘requirements’.

Definition 43 Requirements (II): By ′requirements′ we shall understand a document which prescribesdesired properties of a machine: (i) what entities the machine shall “maintain”, and what the machineshall (must; not should) offer of (ii) functions and of (iii) behaviours (iv) while also expressing whichevents the machine shall “handle” .

537

By a machine that “maintains” entities we shall mean: a machine which, “between” users’ use of thatmachine, “keeps” the data that represents these entities. From earlier we repeat: 538

Definition 44 Machine: By machine we shall understand a, or the, combination of hardware and softwarethat is the target for, or result of the required computing systems development .

539

So this, then, is a main objective of requirements development: to start towards the design of the hardware+ software for the computing system.

Definition 45 Requirements (III): To specify the machine .

When we express requirements and wish to “convert” such requirements to a realisation, i.e., an imple-mentation, then we find that some requirements (parts) imply certain properties to hold of the hardwareon which the software to be developed is to “run”, and, obviously, that remaining — probably the largerparts of the — requirements imply certain properties to hold of that software. So we find that although 540

we may believe that our job is software engineering, important parts of our job are to also “design themachine”!

7.2 The Example Requirements – The General Setting 541

The domain was that of transportation. The requirements is now basically related to the issuance of ticketsupon vehicle entry to a toll road net1and payment of tickets upon the vehicle leaving the toll road netboth issuance and collection/payment of tickets occurring at toll booths2which are hubs somehow linkedto the toll road net proper. Add to this that vehicle tickets are sensed and updated whenever the vehiclecrosses an intermediate toll road intersection. 542

7.3 Stages of Requirements Engineering 543

The following are the stages of requirements engineering:

• stake-holder identification,• business process re-engineering ,• domain requirements development,• interface development,• machine requirements development,• requirements verification and validation, and• requirements satisfiability and feasibility.



tp1 tp2 tp3 tpntpn−1tpj

l12

l21 l32

l23 l34 lj−1j

ljj−1l43 lj+1j

ljj+1

ln−1n−2

ln−1n

lnn−1

ln−2n−1ti1 tinii2 ii3 iij iin−1

Fig. 7.1. A simple, linear toll road net:tpi: toll plaza i,ti1, tin: terminal intersection k,iik: intermediate intersection k, 1<k<nlxy: tollway link from ix to iy , y=x+1 or y=x-1 and 1≤x<n.

544

The domain requirements development stage consists of a number of steps:

• projection,• instantiation,• determination,• extension,• fitting and• consolidation.

We shall basically only cover business process re-engineering, domain requirements development, andinterface development.

7.4 Business Process Re-engineering 545

Business process re-engineering (BPR) re-evaluates the intrinsics, support technologies, management &organisation, rules & regulations, scripts, and human behaviour facets while possibly changing some orall of these, that is, possibly rewriting the corresponding parts of the domain description.

7.4.1 Re-engineering Domain Entities 546

The net is arranged as a linear sequence of two or more (what we shall call) intersection hubs. Eachintersection hub has a single two-way link to (what we shall call) an entry/exit hub (toll plaza); andeach intersection hub has either two or four one-way (what we shall call) tollway links: the first and thelast intersection hub (in the sequence) has two tollway links and all (what we shall call) intermediateintersections has four tollway links. We introduce a pragmatic notion of net direction: “up” and “down”the net, “from one end to the other”. This is enough to give a hint at the re-engineered domain.

7.4.2 Re-engineering Domain Actions 547

We first briefly sketch the tollgate actions. Vehicles enter and leave the tollway net only at entry/exithubs (toll plazas). Vehicles collect and return their tickets from and to tollgate ticket issuing, respectivelypayment machines. Tollgate ticket-issuing machines respond to sensor pressure from “passing” vehicles orby vehicle drivers pressing ticket-issuing machine buttons. Tollgate payment machines accept credit cards,bank notes or coins in designated currencies as payment and returns any change.548

We then briefly introduce and sketch an operation performed when vehicles cross intersections: Thevehicle is assumed to possess the ticket issued upon entry (in)to the net (at a tollgate). At the crossingof each intersection, by a vehicle, its ticket is sensed and is updated with the fact that the vehicle crossedthe intersection.

The updated domain description section on support technology will detail the exact workings of thesetollgate and internal intersection machines and the domain description section on human behaviour willlikewise explore the man/machine facet.

1 Toll road: in other forms of English; toll-way, turnpike, pike or toll-pike, in French peage.2 Toll plazas, toll stations, or toll gates


7.5 Domain Requirements Prescription 103

7.4.3 Re-engineering Domain Events 549

The intersections are highway-engineered in such a way as to deter vehicle entry into opposite directiontollway links, yet, one never knows, there might still be (what we shall call ghost) vehicles, that is vehicleswhich have somehow defied the best intentions, and are observed moving along a tollway link in the wrongdirection.

7.4.4 Re-engineering Domain Behaviours 550

The intended behaviour of a vehicle of the tollway is to enter at an entry hub (collecting a ticket atthe toll gate), to move to the associated intersection, to move into, where relevant, either an upward or adownward tollway link, to proceed (i.e., move) along a sequence of one or more tollway links via connectingintersections, until turning into an exit link and leaving the net at an exit hub (toll plaza) while payingthe toll.

• • •

This should be enough of a BPR rough sketch for us to meaningfully proceed to requirements prescriptionproper.


Definition 46 Requirements Prescription: A ′domain requirements prescription′ is that part of the re-quirements prescription which can be expressed solely using terms from the domain description .

Thus to construct the domain requirements prescription all we need is collaboration with the requirementsstake-holders (who, with the requirements engineers, developed the BPR) and the possibly rewritten(resulting) domain description.

7.5.1 Domain Projection 552

Definition 47 Domain Projection: By a ′domain projection′ we mean a subset of the domain description,one which leaves out all those entities, functions, events, and (thus) behaviours that the stake-holders donot wish represented by the machine. The resulting document is a partial domain requirements prescription.

Domain Projection — Narrative 553

We copy the domain description and call the copy a 0th version domain requirements prescription. Fromthat document we remove all mention of link insertion and removal functions, to obtain a 1st versiondomain requirements prescription.3

Domain Projection — Formalisation 554

Root Sorts

type

1. ∆1a. Nvalue1a. obs N: ∆ → N

Sub-domain Sorts and Types

type

2. HS, LSvalue2a. obs HS: N → HS2b. obs LS: N → LS

3 Restrictions of the net to the toll road nets hinted at earlier will follow in the next domain requirementssteps.



555

type

3a. Hs = H-set4a. Ls = L-set3b. H4b. Lvalue3. obs Hs: HS → H-set4. obs Ls: LS → L-set

Unique Identifications

type

7a. HI7b. LI7c. VIvalue7a. uid H: H → HI7b. uid L: L → LI7c. uid V: V → VI

556

Road NetMereology

value8a. mereo L: L → HI-set9a. mereo H: H → LI-set

Attributes of Links

type

10a. LΣ = (HI × HI)-set10b. LΩ = LΣ-set10c. LOC, LEN, ...value10a. attr LΣ: L → LΣ10b. attr LΩ: L → LΩ10c. attr LOC: L → LOC,10c. attr LEN: L → LEN, ...

557

Attributes of Hubs

type

11a. HΣ = (LI × LI)-set11b. HΩ = HΣ-set11c. LOC

value11a. attr HΣ: H → HΣ11b. attr HΩ: H → HΩ11c. attr LOC: L → LOC

558

Auxiliary Functions

value17. xtr LIs: N → LI-set17. xtr LIs(n) ≡17. uid L(l)|l:L•l ∈ obs Ls(obs LS(n))

18. xtr HIs: N → HI-set18. xtr HIs(n) ≡18. uid H(l)|h:H•h ∈ obs Hs(obs HS(n))

559

value

22. get H: HI → N∼→ H

22. get H(hi)(n) ≡22. ι h:H•h ∈ obs Hs(obs HS(n))∧uid H(h)=hi22. pre: hi ∈ xtr HIs(n)

22a. get L: LI → N∼→ L

22a. get L(li)(n) ≡22a. ι l:L•l ∈ obs Ls(obs LS(n))∧uid L(l)=li22a. pre: hl ∈ xtr LIs(n)

7.5.2 Domain Instantiation 560

Definition 48 Instantiation: By ′domain instantiation′ we mean a refinement of the partial do-main requirements prescription, resulting from the projection step, in which the refinements aimat rendering the entities, functions, events, and (thus) behaviours of the partial domain require-ments prescription more concrete, more specific. Instantiations usually render these concepts lessgeneral .



Domain Instantiation — Narrative 561

The 1st version domain requirements prescription is now updated with respect to the propertiesof the toll way net: We refer to Fig. 7.1 and the preliminary description given in Sect. 7.4.1.There are three kinds of hubs: tollgate hubs and intersection hubs: terminal intersection hubsand proper, intermediate intersection hubs. Tollgate hubs have one connecting two way link.linking the tollgate hub to its associated intersection hub. Terminal intersection hubs have three 562

connecting links: (i) one, a two-way link, to a tollgate hub, (ii) one one-way link emanating to anext up (or down) intersection hub, and (iii) one one-way link incident upon this hub from a nextup (or down) intersection hub. Proper intersection hubs have five connecting links: one, a two way 563

link, to a tollgate hub, two one way links emanating to next up and down intersection hubs, andtwo one way links incident upon this hub from next up and down intersection hub. (Much moreneed be narrated.) As a result we obtain a 2nd version domain requirements prescription.

Domain Instantiation — Formalisation, Toll Way Net 564

We simplify the model of nets. Instead of observing hubs and links from nets, n:N, these now arepairs of sets of hubs and links !

type

cN = H-set × L-set

TN = ((H × L) × (H × L × L))∗ × H × (L × H)value

abs cN: TN → cNabs cN(tn) ≡ (tn hubs(tn),tn links(tn))pre: wf TN(tn)

tn hubs: TN → H-set,tn hubs(hll,h,( ,hn)) ≡

h,hn ∪ thj,hj|((thj,tlj),(hj,lj,lj′)):((H×L)×(H×L×L))•((thj,tlj),(hj,lj,lj′))∈ elems hllltn links: TN → L-set

tn links(hll, ,(ln, )) ≡ln ∪ tlj,lj,lj′|((thj,tlj),(hj,lj,lj′)):((H×L)×(H×L×L))•((thj,tlj),(hj,lj,lj′))∈ elems hlll

theorem ∀ tn:TN • wf TN(tn) ⇒ wf aN(abs cN(tn))

where wf aN is expressed in the form of axioms: 8a, 8b, 9b, 10a, 10b, 11a, 11b, Pages 7–9. 565

Domain Instantiation — Formalisation, Well-formedness 566

type

LnkM == plaza | wayvalue

wf TN: TN → Bool

wf TN(tn:(hll,h,(ln,hn))) ≡wf Toll Lnk(h,ln,hn)(plaza) ∧ wf Toll Ways(hll,h) ∧wf State Spaces(tn) [ to be defined under Determination ]

567

value

wf Toll Ways: ((H×L)×(H×L×L))∗ × H → Bool

wf Toll Ways(hll,h) ≡∀ j:Nat • j,j+1⊆inds hll ⇒

let ((thj,tlj),(hj,ljj′,lj′j)) = hll(j),



ti1

l21

l12

l32

l23

tlj’

hj’ljj’

lj’j lj’’j’

lj’j’’hj

th1

tl1 tl2

h2

th2

hk

thk

lklnk

lkn

thn

ln

hn

lkk−1

lk−1k

hll(1) hll(2)

hll(1),hll(2)

hll(j) hll(j+1)

hll(j),hll(j+1)

hll(len hll)hll(len hll −1)

hll(len h −1),hll(len hll)

thj’

Fig. 7.2. A simple, linear toll road net:thi: toll plaza i,h1, hn: terminal intersections,h2, hj , h

′j , hk: intermediate intersections, 1<j≤k, k=n-1

lxy, lyx: tollway link from hx to hy and from hy to hx, 1≤x<n.lx−1x, lxx−1: tollway link from hx−1 to hx and hx to hx−1, 1≤x<n,dashed links are not in formulas.

( ,(hj′, , )) = hll(j+1) in

wf Toll Lnk(thj,tlj,hj)(plaza) ∧wf Toll Lnk(hj,ljj′,hj′)(way) ∧ wf Toll Lnk(hj′,lj′j,hj)(way) end ∧

let ((thk,tlk),(hk,lk,lk′)) = hll(len hll) in

wf Toll Lnk(thk,tlk,hk)(plaza) ∧wf Toll Lnk(hk,lk,hk′)(way) ∧ wf Toll Lnk(hk′,lk′,hk)(way) end

568

valuewf Toll Lnk: (H×L×H) → LnkM → Bool

wf Toll Lnk(h,l,h′)(m) ≡obs Ps(l)=(obs HI(h),obs LI(l),obs HI(h′)),

(obs HI(h′),obs LI(l),obs HI(h)) ∧obs Σ(l) = case m of

plaza → obs Ps(l),way → (obs HI(h),obs LI(l),obs HI(h′)) end

7.5.3 Domain Determination 569

Definition 49 Determination: By ′domain determination′ we mean a refinement of the partialdomain requirements prescription, resulting from the instantiation step, in which the refinementsaim at rendering the entities, functions, events, and (thus) behaviours of the partial domainrequirements prescription less non-determinate, more determinate. Instantiations usually renderthese concepts less general .

Domain Determination — Narrative 570

We single out only two ’determinations’: The link state spaces. There is only one link state: the setof all paths through the link, thus any link state space is the singleton set of its only link state. Thehub state spaces are the singleton sets of the “current” hub states which allow these crossings:(i) from terminal link back to terminal link, (ii) from terminal link to emanating tollway link,(iii) from incident tollway link to terminal link, and (iv) from incident tollway link to emanatingtollway link. Special provision must be made for expressing the entering from the outside andleaving toll plazas to the outside.



Domain Determination — Formalisation 571

wf State Spaces: TN → Bool

wf State Spaces(hll,hn,(thn,tln)) ≡let ((th1,tl1),(h1,l12,l21)) = hll(1),

((thk,ljk),(hk,lkn,lnk)) = hll(len hll) in

wf Plaza(th1,tl1,h1) ∧ wf Plaza(thn,tln,hn) ∧wf End(h1,tl1,l12,l21,h2) ∧ wf End(hk,tln,lkn,lnk,hn) ∧∀ j:Nat • j,j+1,j+2⊆inds hll ⇒

let (,(hj,ljj,lj′j)) = hll(j),((thj′,tlj′),(hj′,ljj′,lj′j′)) = hll(j+1) in

wf Plaza(thj′,tlj′,hj′) ∧ wf Interm(ljj,lj′j,hj′,tlj′,ljj′,lj′j′) end end

572

wf Plaza(th,tl,h) ≡obs HΣ(th) = [ crossings at toll plazas ]

(′′external′′,obs HI(th),obs LI(tl)),(obs LI(tl),obs HI(th),′′external′′),

(obs LI(tl),obs HI(th),obs LI(tl)) ∧obs HΩ(th) = obs HΣ(th) ∧ obs LΩ(tl) = obs LΣ(tl)

wf End(h,tl,l,l′) ≡obs HΣ(h) = [ crossings at 3−link end hubs ]

(obs LI(tl),obs HI(h),obs LI(tl)),(obs LI(tl),obs HI(h),obs LI(l)),(obs LI(l′),obs HI(h),obs LI(tl)),(obs LI(l′),obs HI(h),obs LI(l)) ∧

obs HΩ(h) = obs HΣ(h) ∧obs LΩ(l) = obs LΣ(l) ∧ obs LΩ(l′) = obs LΣ(l′)

573

wf Interm(ul 1,dl 1,h,tl,ul,dl) ≡obs HΣ(h) = [ crossings at properly intermediate, 5−link hubs ]

(obs LI(tl),obs HI(h),obs LI(tl)),(obs LI(tl),obs HI(h),obs LI(dl 1)),(obs LI(tl),obs HI(h),obs LI(ul)),(obs LI(ul 1),obs HI(h),obs LI(tl)),(obs LI(ul 1),obs HI(h),obs LI(ul)),(obs LI(ul 1),obs HI(h),obs LI(dl 1)),(obs LI(dl),obs HI(h),obs LI(tl)),(obs LI(dl),obs HI(h),obs LI(dl 1)),(obs LI(dl),obs HI(h),obs LI(ul)) ∧obs HΩ(h) = obs HΣ(h) ∧ obs LΩ(tl) = obs LΣ(tl) ∧obs LΩ(ul) = obs LΣ(ul) ∧ obs LΩ(dl) = obs LΣ(dl)

574

and add:

value

xtr HIs: (H × L × L)∗

xtr HIs(hlll) ≡ h|(h,l,l′):(H×L×L)•(h,l,l′)∈ elems hlll

Not all determinism issues above have been fully explained. But for now we should — in principle— be satisfied.

7.5.4 Domain Extension 575

Definition 50 Extension: By ′domain extension′ we understand the introduction of endurants,functions, events and behaviours that were not feasible in the original domain, but for which, withcomputing and communication, there is the possibility of feasible implementations, and such thatwhat is introduced become part of the emerging domain requirements prescription .



Informal Sketch 576

The following is a prolonged example. It contains three kinds of formalisations: a RAISE/CSPmodel,a Duration Calculus model [108, 80] and a Timed Automata model [2, 80]. The narrative for allthree models are given when narrating the RAISE/CSP model.

Domain Extension — Narrative 577

The domain extension is that of the controlled access of vehicles to and departure from the toll roadnet: the entry to (and departure from) tollgates from (respectively to) an "an external" net —which we do not describe; the new entities of tollgates with all their machinery; the user/machinefunctions: upon entry: driver pressing entry button, tollgate delivering ticket; upon exit: driverpresenting ticket, tollgate requesting payment, driver providing payment, etc.578

One added (extended) domain requirements: as vehicles are allowed to cruise the entire netpayment is a function of the totality of links traversed, possibly multiple times. This requires, inour case, that tickets be made such as to be sensed somewhat remotely, and that intersectionsbe equipped with sensors which can record and transmit information about vehicle intersectioncrossings. (When exiting the tollgate machine can then access the exiting vehicles sequence ofintersection crossings — based on which a payment fee calculation can be done.)

All this to be described in detail — including all the thinks that can go wrong (in the domain)and how drivers and tollgates are expected to react.

Intuition 579

A toll road system is delimited by toll plazas with entry and exit booths with their gates. To getaccess, from outside, to the roads within the toll road system, a car must pass through an entrybooth and its entry gate. To leave the roads within the toll road system a car must pass throughan exit booth and its exit gate. Cars collect tickets upon entry and return these tickets upon exitand pay a fee for having driven on the toll roads. The gates help ensure that cars have collectedtickets and have paid their dues.580

exit sensorgateticket dispenserentry sensor

Car

Fig. 7.3. A toll plaza entry booth

Descriptions 581

A RAISE/CSP Model

We use the CSP property [11, 60] of RSL.

Toll Booth Plazas

With respect to toll road systems we focus on just their plazas: that is, where cars enter and leavethe systems. The below description is grossly simplified: instead of plazas having one or more entryand one or more exit booths (both with gates), we just assume one (pair: booth/gate) of each.582



287. A toll plaza consists of a one pair of an entry booth and and entry gate and one pair of anexit booth and an exit gate.

288. Entry booths consist of an entry sensor, a ticket dispenser and an exit sensor.289. Exit booths consist of an entry sensor, a ticket collector, a payment display and a payment

component.

type

287. PZ = (EB×G) × (XB×G)288. EB = ...289. XB = ...

583

Cars

290. There are vehicles.291. Vehicles have unique vehicle identifications.

type

290. V291. VIdvalue

291. obs VId: V → VIdaxiom

291. ∀ v,v′:V • v 6=v′ ⇒ obs VId(v) 6= obs VId(v′)

584

Entry Booths

The description now given is an idealisation. It assumes that everything works: that the vehiclesbehave as expected and that the electro-mechanics of booths and gates do likewise.

292. An entry sensor registers whether a car is entering the entry booth or not,(a) that is, for the duration of the car passing the entry sensor that sensor senses the car

identification cid(b) otherwise it senses “nothing”. 585

293. A ticket dispenser(a) either holds a ticket or does not hold a ticket, i.e., no ticket;(b) normally it does not hold a ticket;(c) the ticket dispenser holds a ticket soon after a car has passed the entry sensor;(d) the passing car collects the ticket –(e) after which the ticket dispenser no longer holds a ticket.

294. An exit sensor(a) registers the identification of a car leaving the toll booth(b) otherwise it senses “nothing”.

586

Gates

295. A gate(a) is either closed or open;(b) it is normally closed;(c) if a car is entering it is secured set to close (as a security measure);(d) once a car has collected a ticket it is set to open;(e) and once a car has passed the exit sensor it is again set to close.

587



The Entry Plaza System

type

C, CIG = open | closeTK == Ticket | no ticket

value

obs CI: (C|Ticket) → CIchannel

entry sensor:CIticket dispenser:Ticketexit sensor:CIgate ch:G

value

vs:V-set

eb:EB,xb:XB,eg,xg:G

588

system: G × EB × V-set × XB × Gsystem(eg,eb,vs,xb,xg) ≡

‖car(obs CI(c),c)|c:C•c ∈ cs ‖ entry booth(eb) ‖ entry gate(eg) ‖ ...

car: CI × C → out entry sensor,exit sensorin ticket dispenser Unit

car(ci,c) ≡entry sensor ! ci ;let ticket = ticket dispenser ? assert: ticket 6= no ticket in

ticket dispenser ! no ticket ;exit sensor ! ci ;car(add(ticket,c)) end

589

entry booth: Unit → in entry sensor, exit sensorout ticket dispenserout gate ch Unit

entry booth(b) ≡gate ch ! close ;let ci = entry sensor ? in

ticket dispenser ! make ticket(cid) ;let res = ticket dispenser ? in assert: res = no ticket ;gate ch ! open ;let ci′ = exit sensor ? in assert: ci′ = ci ;gate ch ! close ;entry booth(add Ticket(ticket,b)) end end end

590

entry gate: G → in gate Unit

entry gate(g) ≡case gate ch ? of

close → exit gate(close) assert: g = open,open → exit gate(open) assert: g = close

end

add Ticket: Ticket × C∼→ C

pre add Ticket(t,c): ∼has Ticket(c)post: add Ticket(t,c): has Ticket(c)



591

has Ticket: (C|B) → Bool

obs Ticket: (C|B)∼→ Ticket

pre obs Ticket(cb): has Ticket(cb)

rem Ticket: (C∼→ C) | (B

∼→ B)

pre rem Ticket(cb): has Ticket(cb)post rem Ticket(cb): ∼has Ticket(cb)

In the next section, “A Duration Calculus Model”, we shall start refining the descriptions givenabove. We do so in order to handle failures of vehicles to behave as expected and of the electro-mechanics of booths and gates. 592

A Duration Calculus Model

We use the Duration Calculus [108, 80] extension to RSL. We abstract the channels of theRAISE/CSP model to now be Boolean-valued variables. 593

type

ES = Bool [ true=passing, false=not passing ]TD = Bool [ true=ticket, false=no ticket ]G = Bool [ true=open, false=closing⌈⌉closed⌈⌉opening ]XS = Bool [ true=car has just passed, false=car passing⌈⌉no−one passing ]

variable

entry sensor:ES := false ;ticket dispenser:TD := false ;gate:G := false ;exit sensor:XS := false ;

594

296. No matter its position, the gate must be closed within no more than δeg time units after theentry sensor has registered that a car is entering the toll booth.

297. A ticket must be in the ticket dispenser within δet time units after the entry sensor has registeredthat a car is entering the toll booth.

298. The ticket is in the ticket dispenser at most δtdc time units299. The gate must be open within δgo time units after a ticket has been collected.300. The exit sensor is registering (i.e., is on) the identification of exiting cars and is not registering

anything when no car is passing (i.e., is off).595

296. ∼(⌈entry sensor⌉ ; (ℓ = δeg ∧ ⌈gate⌉))297. ∼(⌈entry sensor⌉ ; (ℓ = δet ∧ ⌈∼ticket dispenser⌉))298. (⌈∼ticket dispenser⌉ ⇒ ℓ < δtdc)299. ∼(⌈ticket dispenser⌉ ; (⌈∼ticket dispenser ∧ ∼gate⌉ ∧ ℓ ≥ δgo))300. (⌈gate=closing⌉ ⇒ ⌈∼ exit sensor⌉)

596

A Timed Automata Model

A timed automaton [2, 80] for a configuration of an entry gate, its entry booth and a car is shownin Fig. 7.4 on the following page. Figure 7.5 on the next page shows the a car, an exit booth andits exit gate interactions. They are more-or-less “derived” from the example of Sect. 7.5 of [2, Alur& Dill, 1994] (Pages 42–45). The right half of the car timed automaton of Fig. 7.4 on the followingpage is to be thought of as the same as the left half of the car timed automaton of Fig. 7.5 on the

next page, cf. the vertical dotted (...)line. 597

598



x

e

c

td

tc

o

tc

x

e

c

Entry Booth Car

ig

ca

ca

o:open, ig: idle gate, c:close, ib: idle booth, ca:cruise around,e:entry, td:ticket deposit, tc:ticket collection, x:exit

ib

c

o

_

_

Cd

On

Cd: closed, Cg:closing, On:open, Og:opening

Plaza j

Entry Gate

keg > 5

keg < 7_

keg:=0

keg < 7

keg:=0 keg > 5_

Og Cg

ig o

Fig. 7.4. A timed automata model of gate, entry booth and car interactions

value

eg,xg:G, eb:EB, xb:XB, vs:V-set

System: G×EV×V-set×XB×G → Unit

System(eg,eb,vs,xb,xg) ≡Entry Gate(eg) ‖ Entry Booth(eb) ‖‖Car(obs CId(c),c)|ci:C,v:C•c ∈ cs ‖Exit Booth(xb) ‖ Exit Gate(xg)

599

e

pd

td

x

o

pd

etc

c

pp

Car

Plaza k

Exit Booth

x

Exit Gate

ca

ca

ib

ig c

ig

ca:cruise around, ib:idle, e:entry, td:ticket deposit, pd:payment display, p: payment, x:exit, c:close, o:open, ig:idle gate

kxg:=0c

kxg < 7_

okxg:=0

kxg < 7

kxg > 5

kxg > 5_

_

o

On

Cd

Cg Og

Fig. 7.5. A timed automata model of car, exit booth and gate interactions

[80]



Domain Extension — Formalisation of Support Technology 600

This example provides a classical requirements engineering setting for embedded, safety critical,real-time systems, requiring, ultimately, the techniques and tools of such things as Petri nets,state-charts, message sequence charts or live sequence charts and temporal logics (DC, TLA+).

7.5.5 Requirements Fitting 601

The issue of requirements fitting arises when two or more software development projects are basedon what appears to be the same domain. The problem then is to harmonise the two or moresoftware development projects by harmonising, if not too late, their requirements developments. 602

We thus assume that there are n domain requirements developments, dr1, dr2

, . . . , drn , beingconsidered, and that these pertain to the same domain — and can hence be assumed covered bya same domain description. 603

By requirements fitting we mean a harmonisation of n > 1 domain requirements that haveoverlapping (common) not always consistent parts and which results in n ‘modified and partialdomain requirements’, and m ‘common domain requirements’ that “fit into” two or more of the‘modified and partial domain requirements’. 604

By a modified and partial domain requirements we mean a domain requirements which isshort of (that is, is missing) some description parts: text and formula. By a common domainrequirements we mean a domain requirements. By the m common domain requirements parts,cdrs, fitting into the n modified and partial domain requirements we mean that there is for eachmodified and partial domain requirements, mapdri, an identified subset of cdrs (could be all ofcdrs), scdrs, such that textually conjoining scdrs to mapdr can be claimed to yield the “original”dri .

Requirements Fitting Procedure — A Sketch 605

Requirements fitting consists primarily of a pragmatically determined sequence of analytic andsynthetic (‘fitting’) steps. It is first decided which n domain requirements documents to fit. Thena ‘manual’ analysis is made of the selected, n domain requirements. During this analysis tentativecommon domain requirements are identified. It is then decided which m common domain require-ments to single out. This decision results in a tentative construction of n modified and partialdomain requirements. An analysis is made of the tentative modified and partial and also commondomain requirements. A decision is then made whether to accept the resulting documents or toiterate the steps above.

Requirements Fitting — Narrative 606

We postulate two domain requirements: We have outlined a domain requirements developmentfor software support for a toll road system. We have earlier hinted at domain operations relatedto insertion of new and removal of existing links and hubs. We can therefore postulate that thereare two domain requirements developments, both based on the transport domain: one, drtoll

, for

a toll road computing system monitoring and controlling vehicle flow in and out of toll plazas,and another, drmaint.

, for a toll link and intersection (i.e., hub) building and maintenance system

monitoring and controlling link and hub quality and for development. 607

The fitting procedure now identifies the shared of awareness of the net by both drtolland

drmaint.of nets (N), hubs (H) and links (L). We conclude from this that we can single out a

common requirements for software that manages net, hubs and links. Such software requirementsbasically amounts to requirements for a database system. A suitable such system, say a relationaldatabase management system, DBrel, may already be available with the customer. 608

In any case, where there before were two requirements (drtoll, drmaint.

) there are now four:

(i) d′rtoll, a modification of drtoll

which omits the description parts pertaining to the net; (ii)



d′rmaint., a modification of drmaint.

which likewise omits the description parts pertaining to the

net; (iii) drnet, which contains what was basically omitted in d′rtoll

and d′rmaint.; and (iv) dr

db:i/f(for database interface) which prescribes a mapping between type names of drnet

and relation and

attribute names of DBrel.Much more can and should be said, but this suffices as an example in a software engineering

methodology paper.

Requirements Fitting — Formalisation 609

We omit lengthy formalisation.

7.5.6 Domain Requirements Consolidation 610

After projection, instantiation, determination, extension and fitting, it is time to review, consoli-date and possibly restructure (including re-specify) the domain requirements prescription beforethe next stage of requirements development.

7.6 Interface Requirements Prescription 611

By an interface requirements we mean a requirements prescription which refines and extendsthe domain requirements by considering those requirements of the domain requirements whoseentities, operations, events and behaviours are “shared” between the domain and the machine(being requirements prescribed).612

‘Sharing’ means (a) that an entity is represented both in the domain and “inside” the machine,and that its machine representation must at suitable times reflect its state in the domain; (b) thatan operation requires a sequence of several “on-line” interactions between the machine (beingrequirements prescribed) and the domain, usually a person or another machine; (c) that an event613

arises either in the domain, that is, in the environment of the machine, or in the machine, andneed be communicated to the machine, respectively to the environment; and (d) that a behaviouris manifested both by actions and events of the domain and by actions and events of the machine.614

So a systematic reading of the domain requirements shall result in an identification of all sharedentities, operations, events and behaviours.615

Each such shared phenomenon shall then be individually dealt with: entity sharing shall leadto interface requirements for data initialisation and refreshment; operation sharing shall lead tointerface requirements for interactive dialogues between the machine and its environment; eventsharing shall lead to interface requirements for how such event are communicated between the en-vironment of the machine and the machine. behaviour sharing shall lead to interface requirementsfor action and event dialogues between the machine and its environment.616

• • •

We shall now illustrate these domain interface requirements development steps with respect to ourongoing example.

7.6.1 Shared Entities 617

The main shared entities are the net, hence the hubs and the links. As domain entities they contin-uously undergo changes with respect to the values of a great number of attributes and otherwisepossess attributes — most of which have not been mentioned so far: length, cadestral informa-tion, names, wear and tear (where-ever applicable), last/next scheduled maintenance (where-everapplicable), state and state space, and many others.618


7.6 Interface Requirements Prescription 115

We “split” our interface requirements development into two separate steps: the development ofdrnet

(the common domain requirements for the shared hubs and links), and the co-development

of drdb:i/f

(the common domain requirements for the interface between drnetand DBrel — under

the assumption of an available relational database system DBrel) 619

When planning the common domain requirements for the net, i.e., the hubs and links, weenlarge our scope of requirements concerns beyond the two so far treated (drtoll

, drmaint.) in

order to make sure that the shared relational database of nets, their hubs and links, may beuseful beyond those requirements. We then come up with something like hubs and links are tobe represented as tuples of relations; each net will be represented by a pair of relations a hubsrelation and a links relation; each hub and each link may or will be represented by several tuples;etcetera. In this database modelling effort it must be secured that “standard” operations on nets,hubs and links can be supported by the chosen relational database system DBrel.

Data Initialisation 620

As part of drnetone must prescribe data initialisation, that is provision for an interactive user

interface dialogue with a set of proper display screens, one for establishing net, hub or link at-tributes (names) and their types and, for example, two for the input of hub and link attributevalues. Interaction prompts may be prescribed: next input, on-line vetting and display of evolvingnet, etc. These and many other aspects may therefore need prescriptions.

Essentially these prescriptions concretise the insert link operation.

Data Refreshment 621

As part of drnetone must also prescribe data refreshment: an interactive user interface dialogue

with a set of proper display screens one for updating net, hub or link attributes (names) and theirtypes and, for example, two for the update of hub and link attribute values. Interaction promptsmay be prescribed: next update, on-line vetting and display of revised net, etc. These and manyother aspects may therefore need prescriptions.

These prescriptions concretise remove and insert link operations.

7.6.2 Shared Actions 622

The main shared operations are related to the entry of a vehicle into the toll road system and theexit of a vehicle from the toll road system.

Interactive Action Execution

As part of drtollwe must therefore prescribe the varieties of successful and less successful sequences

of interactions between vehicles (or their drivers) and the toll gate machines.The prescription of the above necessitates determination of a number of external events, see

below.(Again, this is an area of embedded, real-time safety-critical system prescription.)

7.6.3 Shared Events 623

The main shared external events are related to the entry of a vehicle into the toll road system, thecrossing of a vehicle through a toll way hub and the exit of a vehicle from the toll road system.

As part of drtollwe must therefore prescribe the varieties of these events, the failure of all

appropriate sensors and the failure of related controllers: gate opener and closer (with sensors andactuators), ticket “emitter” and “reader” (with sensors and actuators), etcetera.

The prescription of the above necessitates extensive fault analysis.



7.6.4 Shared Behaviours 624

The main shared behaviours are therefore related to the journey of a vehicle throw the toll roadsystem and the functioning of a toll gate machine during “its lifetime”. Others can be thought of,but are omitted here.

In consequence of considering, for example, the journey of a vehicle behaviour, we may “add”some further, extended requirements: (a) requirements for a vehicle statistics “package”; (b) re-quirements for tracing supposedly “lost” vehicles; (c) requirements limiting toll road system accessin case of traffic congestion; etcetera.

7.7 Machine Requirements 625

to be written

7.8 Conclusion 626


Part IV

Closing

8

Conclusion 627

9

Bibliography 628

9.1 Bibliographical Notes 629

9.2 References

1. Jean-Raymond Abrial. The B Book: Assigning Programs to Meanings and Modeling in Event-B: Systemand Software Engineering. Cambridge University Press, Cambridge, England, 1996 and 2009.

2. Rajeev Alur and David L. Dill. A Theory of Timed Automata. Theoretical Computer Science, 126(2):183–235, 1994. (Preliminary versions appeared in Proc. 17th ICALP, LNCS 443, 1990, and Real Time: Theoryin Practice, LNCS 600, 1991).

3. Krzysztof R. Apt. Principles of Constraint Programming. Cambridge University Press, August 2003. ISBN0521825830.

4. K. Araki et al., editors. IFM 1999–2009: Integrated Formal Methods, volume 1945, 2335, 2999, 3771,4591, 5423 (only some are listed) of Lecture Notes in Computer Science. Springer, 1999–2009.

5. Yasuhito Arimoto and Dines Bjørner. Hospital Healthcare: A Domain Analysis and a License Language.Technical note, JAIST, School of Information Science, 1-1, Asahidai, Tatsunokuchi, Nomi, Ishikawa, Japan923-1292, Summer 2006.

6. C. Bachman. Data structure diagrams. Data Base, Journal of ACM SIGBDP, 1(2), 1969.7. Alain Badiou. Being and Event. Continuum, 2005. (Letre et l’evenements, Edition du Seuil, 1988).8. V. Richard Benjamins and Dieter Fensel. The Ontological Engineering Initiative (KA)2. Internet publica-

tion + Formal Ontology in Information Systems, University of Amsterdam, SWI, Roetersstraat 15, 1018WB Amsterdam, The Netherlands and University of Karlsruhe, AIFB, 76128 Karlsruhe, Germany, 1998.http://www.aifb.uni-karlsruhe.de/WBS/broker/KA2.htm.

9. G. Birkhoff. Lattice Theory. American Mathematical Society, Providence, R.I., 3 edition, 1967.10. Dines Bjørner. Software Engineering, Vol. 1: Abstraction and Modelling. Texts in Theoretical Computer

Science, the EATCS Series. Springer, 2006. .11. Dines Bjørner. Software Engineering, Vol. 1: Abstraction and Modelling; Vol. 2: Specification of Systems

and Languages; ol. 3: Domains, Requirements and Software Design. Texts in Theoretical ComputerScience, the EATCS Series. Springer, 2006.

12. Dines Bjørner. Software Engineering, Vol. 2: Specification of Systems and Languages. Texts in TheoreticalComputer Science, the EATCS Series. Springer, 2006. Chapters 12–14 are primarily authored by ChristianKrog Madsen.

13. Dines Bjørner. Software Engineering, Vol. 3: Domains, Requirements and Software Design. Texts inTheoretical Computer Science, the EATCS Series. Springer, 2006.

14. Dines Bjørner. Domain Engineering: Technology Management, Research and Engineering. ResearchMonograph (# 4); JAIST Press, 1-1, Asahidai, Nomi, Ishikawa 923-1292 Japan, This Research Monographcontains the following main chapters:1. On Domains and On Domain Engineering – Prerequisites for Trustworthy Software – A Necessity for

Believable Management, pages 3–38.2. Possible Collaborative Domain Projects – A Management Brief, pages 39–56.3. The Role of Domain Engineering in Software Development, pages 57–72.4. Verified Software for Ubiquitous Computing – A VSTTE Ubiquitous Computing Project Proposal,

pages 73–106.5. The Triptych Process Model – Process Assessment and Improvement, pages 107–138.

122 References

6. Domains and Problem Frames – The Triptych Dogma and M.A.Jackson’s PF Paradigm, pages 139–175.

7. Documents – A Rough Sketch Domain Analysis, pages 179–200.8. Public Government – A Rough Sketch Domain Analysis, pages 201–222.9. Towards a Model of IT Security — – The ISO Information Security Code of Practice – An Incomplete

Rough Sketch Analysis, pages 223–282.10. Towards a Family of Script Languages – – Licenses and Contracts – An Incomplete Sketch, pages

283–328.2009.

15. Dines Bjørner. From Domains to Requirements — On a Triptych of Software Development. ResearchReport, University of Edingburgh, November 2009.

16. Dines Bjørner. Domain Science & Engineering – From Computer Science to The Sciences of InformaticsPart II of II: The Science Part. Kibernetika i sistemny analiz, (2):100–120, May 2011.

17. Dines Bjørner. Domains: Their Simulation, Monitoring and Control – A Divertimento of Ideas andSuggestions. In Rainbow of Computer Science, Festschrift for Hermann Maurer on the Occasion of His70th Anniversary., Festschrift (eds. C. Calude, G. Rozenberg and A. Saloma), pages 167–183. Springer,Heidelberg, Germany, January 2011.

18. Dines Bjørner. A Role for Mereology in Domain Science and Engineering. Synthese Library (eds. ClaudioCalosi and Pierluigi Graziani). Springer, Amsterdam, The Netherlands, May 2013.

19. Dines Bjørner. Domain Analysis: Endurants – A Model of Prompts [Early, incomplete draft] (paper1,slides2). Research Report 2013-10, DTU Compute and Fredsvej 11, DK-2840 Holte, Denmark, July 2013.

20. Dines Bjørner. Domain Analysis (paper3slides4). Research Report 2013-1, DTU Compute and Fredsvej 11,DK-2840 Holte, Denmark, April 2013.

21. Dines Bjørner. Pipelines – a Domain Description5. Experimental Research Report 2013-2, DTU Computeand Fredsvej 11, DK-2840 Holte, Denmark, Spring 2013.

22. Dines Bjørner. Road Transportation – a Domain Description6. Experimental Research Report 2013-4,DTU Compute and Fredsvej 11, DK-2840 Holte, Denmark, Spring 2013.

23. Dines Bjørner and Cliff B. Jones, editors. The Vienna Development Method: The Meta-Language, vol-ume 61 of LNCS. Springer, 1978.

24. Dines Bjørner and Cliff B. Jones, editors. Formal Specification and Software Development. Prentice-Hall,1982.

25. Dines Bjørner and Jørgen Fischer Nilsson. Algorithmic & Knowledge Based Methods — Do they “Unify” ?In International Conference on Fifth Generation Computer Systems: FGCS’92, pages 191–198. ICOT, June1–5 1992.

26. Dines Bjørner, Arimoto Yasuhito, Chen Xiaoyi, and Xiang Jianwen. A Family of License Languages.Technical report, JAIST, Graduate School of Information Science, 1-1, Asahidai, Tatsunokuchi, Nomi,Ishikawa, Japan 923-1292, August 2006.

27. Wayne D. Blizard. A Formal Theory of Objects, Space and Time. The Journal of Symbolic Logic,55(1):74–89, March 1990.

28. Grady Booch, Jim Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998.

29. Roberto Casati and Achille Varzi. Events. In Edward N. Zalta, editor, The Stanford Encyclopedia ofPhilosophy. Spring 2010 edition, 2010.

30. Roberto Casati and Achille C. Varzi, editors. Events. Ashgate Publishing Group – Dartmouth PublishingCo. Ltd., Wey Court East, Union Road, Farnham, Surrey, GU9 7PT, United Kingdom, 23 March 1996.

31. Peter P. Chen. The Entity-Relationship Model - Toward a Unified View of Data. ACM Trans. DatabaseSyst, 1(1):9–36, 1976.

32. XiaoYi Chen and Dines Bjørner. Public Government: A Domain Analysis and a License Language. Tech-nical note, JAIST, School of Information Science, 1-1, Asahidai, Tatsunokuchi, Nomi, Ishikawa, Japan923-1292, Summer 2006.

33. Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. The MIT Press, FiveCambridge Center, Cambridge, MA 02142-1493, USA, January 2000. ISBN 0-262-03270-8.

1 http://www.imm.dtu.dk/˜dibj/prompts-p.pdf2 http://www.imm.dtu.dk/˜dibj/prompts-s.pdf3 http://www.imm.dtu.dk/˜dibj/da-p.pdf4 http://www.imm.dtu.dk/˜dibj/da-s.pdf5 http://www.imm.dtu.dk/˜dibj/pipe-p.pdf6 http://www.imm.dtu.dk/˜dibj/road-p.pdf


References 123

34. CoFI (The Common Framework Initiative). Casl Reference Manual, volume 2960 of Lecture Notes inComputer Science (IFIP Series). Springer–Verlag, 2004.

35. P. Cousot. Abstract Interpretation. ACM Computing Surveys, 28(2):324–328, 1996.36. Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming: Methods, Tools, and Applica-

tions. Addison Wesley, 2000.37. Werner Damm and David Harel. LSCs: Breathing life into Message Sequence Charts. Formal Methods

in System Design, 19:45–80, 2001. Early version appeared as Weizmann Institute Tech. Report CS98-09,April 1998. An abridged version appeared in Proc. 3rd IFIP Int. Conf. on Formal Methods for OpenObject-based Distributed Systems (FMOODS’99), Kluwer, 1999, pp. 293–312.

38. Donald Davidson. Essays on Actions and Events. Oxford University Press, 1980.39. J.W. de Bakker. Control Flow Semantics. The MIT Press, Cambridge, Mass., USA, 1995.40. F. Dretske. Can Events Move? Mind, 76(479-492), 1967. reprinted in [30], pp. 415-428.41. Ronald Fagin, Joseph Y. Halpern, Yoram Moses, and Moshe Y. Vardi. Reasoning about Knowledge. The

MIT Press, Massachusetts Institute of Technology, Cambridge, Massachusetts 02142, 1996. 2nd printing.42. David John Farmer. Being in time: The nature of time in light of McTaggart’s paradox. University Press

of America, Lanham, Maryland, 1990. 223 pages.43. Edward A. Feigenbaum and Pamela McCorduck. The fifth generation. Addison-Wesley, Reading, MA,

USA, 1st ed. edition, 1983.44. John Fitzgerald and Peter Gorm Larsen. Modelling Systems – Practical Tools and Techniques in Software

Development. Cambridge University Press, The Edinburgh Building, Cambridge CB2 2RU, UK, 1998.ISBN 0-521-62348-0.

45. Martin Fowler. Domain Specific Languages. Signature Series. Addison Wesley, October 20120.46. K. Futatsugi, A.T. Nakagawa, and T. Tamai, editors. CAFE: An Industrial–Strength Algebraic Formal

Method, Sara Burgerhartstraat 25, P.O. Box 211, NL–1000 AE Amsterdam, The Netherlands, 2000.Elsevier. Proceedings from an April 1998 Symposium, Numazu, Japan.

47. Bernhard Ganter and Rudolf Wille. Formal Concept Analysis — Mathematical Foundations. Springer-Verlag, January 1999. ISBN: 3540627715, 300 pages, Amazon price: US $ 44.95.

48. Chris W. George, Peter Haff, Klaus Havelund, Anne Elisabeth Haxthausen, Robert Milne, Claus BendixNielsen, Søren Prehn, and Kim Ritter Wagner. The RAISE Specification Language. The BCS PractitionerSeries. Prentice-Hall, Hemel Hampstead, England, 1992.

49. J.-C. Gregoire, G. J. Holzmann, and D. Peled, editors. The SPIN Verification System, volume 32 ofDIMACS series. American Mathematical Society, 1997. ISBN 0-8218-0680-7, 203p.

50. Carl A. Gunter, Elsa L. Gunter, Michael A. Jackson, and Pamela Zave. A Reference Model for Require-ments and Specifications. IEEE Software, 17(3):37–43, May–June 2000.

51. Carl A. Gunter, Stephen T. Weeks, and Andrew K. Wright. Models and Languages for Digtial Rights.In Proc. of the 34th Annual Hawaii International Conference on System Sciences (HICSS-34), pages4034–4038, Maui, Hawaii, USA, January 2001. IEEE Computer Society Press.

52. C.A. Gunther. Semantics of Programming Languages. The MIT Press, Cambridge, Mass., USA, 1992.53. P.M.S. Hacker. Events and Objects in Space and Time. Mind, 91:1–19, 1982. reprinted in [30], pp.

429-447.54. David Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming,

8(3):231–274, 1987.55. David Harel and Rami Marelly. Come, Let’s Play – Scenario-Based Programming Using LSCs and the

Play-Engine. Springer-Verlag, 2003.56. Dan Haywood. Domain-Driven Design Using Naked Objects. The Pragmatic Bookshelf (an imprint of

‘The Pragmatic Programmers, LLC.’), http://pragprog.com/, 2009.57. Martin Heidegger. Sein und Zeit (Being and Time). Oxford University Press, 1927, 1962.58. C.A.R. Hoare. Communicating Sequential Processes. C.A.R. Hoare Series in Computer Science. Prentice-

Hall International, 1985. Published electronically: http://www.usingcsp.com/cspbook.pdf (2004).59. Tony Hoare. Communicating Sequential Processes. C.A.R. Hoare Series in Computer Science. Prentice-

Hall International, 1985.60. Tony Hoare. Communicating Sequential Processes. Published electronically: http://www.usingcsp.-

com/cspbook.pdf, 2004. Second edition of [59]. See also http://www.usingcsp.com/.61. G. J. Holzmann. Design and Validation of Computer Protocols. Prentice-Hall, Englewood Cliffs, New

Jersey, 1991.62. Gerard J. Holzmann. The SPIN Model Checker, Primer and Reference Manual. Addison-Wesley, Reading,

Massachusetts, 2003.63. IEEE Computer Society. IEEE–STD 610.12-1990: Standard Glossary of Software Engineering Terminology.

Technical report, IEEE, IEEE Headquarters Office, 1730 Massachusetts Avenue, N.W., Washington, DC20036-1992, USA. Phone: +1-202-371-0101, FAX: +1-202-728-9614, 1990.


124 References

64. ITU-T. CCITT Recommendation Z.120: Message Sequence Chart (MSC), 1992, 1996, 1999.65. Daniel Jackson. Software Abstractions: Logic, Language, and Analysis. The MIT Press, Cambridge,

Mass., USA, April 2006. ISBN 0-262-10114-9.66. Michael Jackson. Program Verification and System Dependability. In Paul Boca and Jonathan Bowen,

editors, Formal Methods: State of the Art and New Directions, pages 43–78, London, UK, 2010. Springer.67. Michael A. Jackson. Software Requirements & Specifications: a lexicon of practice, principles and preju-

dices. ACM Press. Addison-Wesley, Reading, England, 1995.68. Michael A. Jackson. Problem Frames — Analyzing and Structuring Software Development Problems.

ACM Press, Pearson Education. Addison-Wesley, England, 2001.69. Ivar Jacobson, Grady Booch, and Jim Rumbaugh. The Unified Software Development Process. Addison-

Wesley, 1999.70. Kyo C. Kang, SholomG. Cohen, James A. Hess, William E. Novak, and A. Spenser Peterson. Feature-

Oriented Domain Analysis (FODA). Feasibility Study CMU/SEI-90-TR-021, note =, Software EngineeringInstitute, Carnegie Mellon University.

71. Jaegwon Kim. Supervenience and Mind. Cambridge University Press, 1993.72. Jochen Klose and Hartmut Wittke. An automata based interpretation of Live Sequence Charts. In

T. Margaria and W. Yi, editors, TACAS 2001, LNCS 2031, pages 512–527. Springer-Verlag, 2001.73. Leslie Lamport. Specifying Systems. Addison–Wesley, Boston, Mass., USA, 2002.74. E.C. Luschei. The Logical Systems of Lesniewksi. North Holland, Amsterdam, The Netherlands, 1962.75. J. M. E. McTaggart. The Unreality of Time. Mind, 18(68):457–84, October 1908. New Series. See also:

[82].76. Neno Medvidovic and Edward Colbert. Domain-Specific Software Architectures (DSSA). Power Point

Presentation, found on The Internet, Absolute Software Corp., Inc.: Abs[S/W], 5 March 2004.77. D.H. Mellor. Things and Causes in Spacetime. British Journal for the Philosophy of Science, 31:282–288,

1980.78. Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific lan-

guages. ACM Computing Surveys, 37(4):316–344, December 2005.79. Erik Mettala and Marc H. Graham. The Domain Specific Software Architecture Program. Project Report

CMU/SEI-92-SR-009, Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania15213, June 1992.

80. Ernst-Rudiger Olderog and Henning Dierks. Real-Time Systems: Formal Specification and AutomaticVerification. Cambridge University Press, UK, 2008.

81. Chia-Yi Tony Pi. Mereology in Event Semantics. Phd, McGill University, Montreal, Canada, August 1999.82. Robin Le Poidevin and Murray MacBeath, editors. The Philosophy of Time. Oxford University Press,

1993.83. Ruben Prieto-Dıaz. Domain Analysis for Reusability. In COMPSAC 87. ACM Press, 1987.84. Ruben Prieto-Dıaz. Domain analysis: an introduction. Software Engineering Notes, 15(2):47–54, 1990.85. Ruben Prieto-Dıaz and Guillermo Arrango. Domain Analysis and Software Systems Modelling. IEEE

Computer Society Press, 1991.86. Arthur N. Prior. Papers on Time and Tense. Clarendon Press, Oxford, UK, 1968.87. Riccardo Pucella and Vicky Weissman. A Logic for Reasoning about Digital Rights. In Proc. of the 15th

IEEE Computer Security Foundations Workshop (CSFW’02), pages 282–294. IEEE Computer SocietyPress, 2002.

88. A. Quinton. Objects and Events. Mind, 88:197–214, 1979.89. Wolfang Reisig. Petrinetze: Modellierungstechnik, Analysemethoden, Fallstudien. Leitfaden der Infor-

matik. Vieweg+Teubner, 1st edition, 15 June 2010. 248 pages; ISBN 978-3-8348-1290-2.90. John C. Reynolds. The Semantics of Programming Languages. Cambridge University Press, 1999.91. Jim Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual.

Addison-Wesley, 1998.92. Pamela Samuelson. Digital rights management and, or, vs. the law. Communications of ACM, 46(4):41–

45, Apr 2003.93. Donald Sannela and Andrzej Tarlecki. Foundations of Algebraic Semantcs and Formal Software Develop-

ment. Monographs in Theoretical Computer Science. Springer, Heidelberg, 2012.94. David A. Schmidt. Denotational Semantics: a Methodology for Language Development. Allyn & Bacon,

1986.95. Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice

Hall, 1996.96. Diomidis Spinellis. Notable design patterns for domain specific languages. Journal of Systems and

Software, 56(1):91–99, February 2001.


References 125

97. J.T.J. Srzednicki and Z. Stachniak, editors. Lesniewksi’s Lecture Notes in Logic. Dordrecht, 1988.98. S. J. Surma, J. T. Srzednicki, D. I. Barnett, and V. F. Rickey, editors. Stanis law Lesniewksi: Collected

works (2 Vols.). Dordrecht, Boston – New York, 1988.99. Tetsuo Tamai. Social Impact of Information System Failures. Computer, IEEE Computer Society Journal,

42(6):58–65, June 2009.100. Robert Tennent. The Semantics of Programming Languages. Prentice–Hall Intl., 1997.101. Will Tracz. Domain-specific software architecture (DSSA) frequently asked questions (FAQ). Software

Engineering Notes, 19(2):52–56, 1994.102. Johan van Benthem. The Logic of Time, volume 156 of Synthese Library: Studies in Epistemology, Logic,

Methhodology, and Philosophy of Science (Editor: Jaakko Hintika). Kluwer Academic Publishers, P.O.Box17, NL 3300 AA Dordrecht, The Netherlands, second edition, 1983, 1991.

103. F. Van der Rhee, H.R. Van Nauta Lemke, and J.G. Dukman. Knowledge based fuzzy control of systems.IEEE Trans. Autom. Control, 35(2):148–155, February 1990.

104. George Wilson and Samuel Shpall. Action. In Edward N. Zalta, editor, The Stanford Encyclopedia ofPhilosophy. Summer 2012 edition, 2012.

105. G. Winskel. The Formal Semantics of Programming Languages. The MIT Press, Cambridge, Mass., USA,1993.

106. J. C. P. Woodcock and J. Davies. Using Z: Specification, Proof and Refinement. Prentice Hall InternationalSeries in Computer Science, 1996.

107. JianWen Xiang and Dines Bjørner. The Electronic Media Industry: A Domain Analysis and a LicenseLanguage. Technical note, JAIST, School of Information Science, 1-1, Asahidai, Tatsunokuchi, Nomi,Ishikawa, Japan 923-1292, Summer 2006.

108. Chao Chen Zhou and Michael R. Hansen. Duration Calculus: A Formal Approach to Real–time Systems.Monographs in Theoretical Computer Science. An EATCS Series. Springer–Verlag, 2004.


Part V

Appendices

A

Abstraction & Modelling – using RAISE 630

A.1 RSL: The Raise Specification Language 631

A.1.1 Type Expressions

Type expressions are expressions whose value are type, that is, possibly infinite sets of values (of “that”type).

Atomic Types

Atomic types have (atomic) values. That is, values which we consider to have no proper constituent(sub-)values, i.e., cannot, to us, be meaningfully “taken apart”.

RSL has a number of built-in atomic types. There are the Booleans, integers, natural numbers,reals, characters, and texts. 632

type[ 1 ] Bool true, false[ 2 ] Int ... , −2, −2, 0, 1, 2, ...[ 3 ] Nat 0, 1, 2, ...[ 4 ] Real ..., −5.43, −1.0, 0.0, 1.23· · · , 2,7182· · · , 3,1415· · · , 4.56, ...[ 5 ] Char ”a”, ”b”, ..., ”0”, ...[ 6 ] Text ”abracadabra”

Composite Types 633

Composite types have composite values. That is, values which we consider to have proper con-stituent (sub-)values, i.e., can be meaningfully “taken apart”. There are two ways of expressingcomposite types: either explicitly, using concrete type expressions, or implicitly, using sorts (i.e.,abstract types) and observer functions. 634

Concrete Composite Types

From these one can form type expressions: finite sets, infinite sets, Cartesian products, lists, maps,etc.

Let A, B and C be any type names or type expressions, then:

[ 7 ] A-set

[ 8 ] A-infset

[ 9 ] A × B × ... × C[ 10 ] A∗

[ 11 ] Aω

130 A Abstraction & Modelling – using RAISE

[ 12 ] A →m B[ 13 ] A → B

[ 14 ] A∼→ B

[ 15 ] (A)[ 16 ] A | B | ... | C[ 17 ] mk id(sel a:A,...,sel b:B)[ 18 ] sel a:A ... sel b:B

The following are generic type expressions:

301. The Boolean type of truth values false and true.302. The integer type on integers ..., –2, –1, 0, 1, 2, ... .303. The natural number type of positive integer values 0, 1, 2, ...304. The real number type of real values, i.e., values whose numerals can be written as an integer,

followed by a period (“.”), followed by a natural number (the fraction).305. The character type of character values ′′a′′, ′′b′′, ...306. The text type of character string values ′′aa′′, ′′aaa′′, ..., ′′abc′′, ...307. The set type of finite cardinality set values.308. The set type of infinite and finite cardinality set values.309. The Cartesian type of Cartesian values.310. The list type of finite length list values.311. The list type of infinite and finite length list values.312. The map type of finite definition set map values.313. The function type of total function values.314. The function type of partial function values.315. In (A) A is constrained to be:

• either a Cartesian B × C × ... × D, in which case it is identical to type expression kind 9,• or not to be the name of a built-in type (cf., 1–6) or of a type, in which case the paren-

theses serve as simple delimiters, e.g., (A →m B), or (A∗)-set, or (A-set)list, or (A|B) →m(C|D|(E →m F)), etc.

316. The postulated disjoint union of types A, B, . . . , and C.317. The record type of mk id-named record values mk id(av,...,bv), where av, . . . , bv, are values of

respective types. The distinct identifiers sel a, etc., designate selector functions.318. The record type of unnamed record values (av,...,bv), where av, . . . , bv, are values of respective

types. The distinct identifiers sel a, etc., designate selector functions.635

Sorts and Observer Functions

type

A, B, C, ..., Dvalue

obs B: A → B, obs C: A → C, ..., obs D: A → D

The above expresses that values of type A are composed from at least three values — and theseare of type B, C, . . . , and D. A concrete type definition corresponding to the above presupposingmaterial of the next section

type

B, C, ..., DA = B × C × ... × D



A.1.2 Type Definitions 636

Concrete Types

Types can be concrete in which case the structure of the type is specified by type expressions:

type

A = Type expr

Some schematic type definitions are:

[ 1 ] Type name = Type expr /∗ without | s or subtypes ∗/[ 2 ] Type name = Type expr 1 | Type expr 2 | ... | Type expr n[ 3 ] Type name ==

mk id 1(s a1:Type name a1,...,s ai:Type name ai) |... |mk id n(s z1:Type name z1,...,s zk:Type name zk)

[ 4 ] Type name :: sel a:Type name a ... sel z:Type name z[ 5 ] Type name = | v:Type name′ • P(v) |

637

where a form of [2–3] is provided by combining the types:

Type name = A | B | ... | ZA == mk id 1(s a1:A 1,...,s ai:A i)B == mk id 2(s b1:B 1,...,s bj:B j)...Z == mk id n(s z1:Z 1,...,s zk:Z k)

Types A, B, ..., Z are disjoint, i.e., shares no values, provided all mk id k are distinct and due tothe use of the disjoint record type constructor ==.

axiom

∀ a1:A 1, a2:A 2, ..., ai:Ai •

s a1(mk id 1(a1,a2,...,ai))=a1 ∧ s a2(mk id 1(a1,a2,...,ai))=a2 ∧... ∧ s ai(mk id 1(a1,a2,...,ai))=ai ∧

∀ a:A • let mk id 1(a1′,a2′,...,ai′) = a in

a1′ = s a1(a) ∧ a2′ = s a2(a) ∧ ... ∧ ai′ = s ai(a) end

Subtypes 638

In RSL, each type represents a set of values. Such a set can be delimited by means of predicates.The set of values b which have type B and which satisfy the predicate P , constitute the subtypeA:

type

A = | b:B • P(b) |

Sorts — Abstract Types 639

Types can be (abstract) sorts in which case their structure is not specified:

type

A, B, ..., C



A.1.3 The RSL Predicate Calculus 640

Propositional Expressions

Let identifiers (or propositional expressions) a, b, ..., c designate Boolean values (true or false [orchaos]). Then:

false, true

a, b, ..., c ∼a, a∧b, a∨b, a⇒b, a=b, a 6=b

are propositional expressions having Boolean values. ∼, ∧, ∨, ⇒, = and 6= are Boolean connectives(i.e., operators). They can be read as: not, and, or, if then (or implies), equal and not equal.

Simple Predicate Expressions 641

Let identifiers (or propositional expressions) a, b, ..., c designate Boolean values, let x, y, ..., z (orterm expressions) designate non-Boolean values and let i, j, . . ., k designate number values, then:

false, true

a, b, ..., c∼a, a∧b, a∨b, a⇒b, a=b, a 6=bx=y, x 6=y,i<j, i≤j, i≥j, i6=j, i≥j, i>j

are simple predicate expressions.

Quantified Expressions 642

Let X, Y, . . ., C be type names or type expressions, and let P(x), Q(y) and R(z) designate predicateexpressions in which x, y and z are free. Then:

∀ x:X • P(x)∃ y:Y • Q(y)∃ ! z:Z • R(z)

are quantified expressions — also being predicate expressions.They are “read” as: For all x (values in type X) the predicate P(x) holds; there exists (at

least) one y (value in type Y ) such that the predicate Q(y) holds; and there exists a unique z(value in type Z) such that the predicate R(z) holds.

A.1.4 Concrete RSL Types: Values and Operations 643

Arithmetic

type

Nat, Int, Real

value

+,−,∗: Nat×Nat→Nat | Int×Int→Int | Real×Real→Real

/: Nat×Nat∼→Nat | Int×Int

∼→Int | Real×Real

∼→Real

<,≤,=,6=,≥,> (Nat|Int|Real) → (Nat|Int|Real)



Set Expressions 644

Set Enumerations

Let the below a’s denote values of type A, then the below designate simple set enumerations:

, a, e1,e2,...,en, ... ∈ A-set

, a, e1,e2,...,en, ..., e1,e2,... ∈ A-infset

645

Set Comprehension

The expression, last line below, to the right of the ≡, expresses set comprehension. The expression“builds” the set of values satisfying the given predicate. It is abstract in the sense that it does notdo so by following a concrete algorithm.

type

A, BP = A → Bool

Q = A∼→ B

value

comprehend: A-infset × P × Q → B-infset

comprehend(s,P,Q) ≡ Q(a) | a:A • a ∈ s ∧ P(a)

Cartesian Expressions 646

Cartesian Enumerations

Let e range over values of Cartesian types involving A, B, . . ., C, then the below expressions aresimple Cartesian enumerations:

type

A, B, ..., CA × B × ... × C

value

(e1,e2,...,en)

List Expressions 647

List Enumerations

Let a range over values of type A, then the below expressions are simple list enumerations:

〈〉, 〈e〉, ..., 〈e1,e2,...,en〉, ... ∈ A∗

〈〉, 〈e〉, ..., 〈e1,e2,...,en〉, ..., 〈e1,e2,...,en,... 〉, ... ∈ Aω

〈 a i .. a j 〉

The last line above assumes ai and aj to be integer-valued expressions. It then expresses the setof integers from the value of ei to and including the value of ej. If the latter is smaller than theformer, then the list is empty. 648



List Comprehension

The last line below expresses list comprehension.

type

A, B, P = A → Bool, Q = A∼→ B

value

comprehend: Aω × P × Q∼→ Bω

comprehend(l,P,Q) ≡〈 Q(l(i)) | i in 〈1..len l〉 • P(l(i))〉

Map Expressions 649

Map Enumerations

Let (possibly indexed) u and v range over values of type T 1 and T 2, respectively, then the belowexpressions are simple map enumerations:

type

T1, T2M = T1 →m T2

value

u,u1,u2,...,un:T1, v,v1,v2,...,vn:T2[ ], [ u7→v ], ..., [ u1 7→v1,u2 7→v2,...,un7→vn ] ∀ ∈ M

650

Map Comprehension

The last line below expresses map comprehension:

type

U, V, X, YM = U →m V

F = U∼→ X

G = V∼→ Y

P = U → Bool

value

comprehend: M×F×G×P → (X →m Y)comprehend(m,F,G,P) ≡

[ F(u) 7→ G(m(u)) | u:U • u ∈ dom m ∧ P(u) ]

Set Operations 651

Set Operator Signatures

value

319 ∈: A × A-infset → Bool

320 6∈: A × A-infset → Bool

321 ∪: A-infset × A-infset → A-infset

322 ∪: (A-infset)-infset → A-infset

323 ∩: A-infset × A-infset → A-infset

324 ∩: (A-infset)-infset → A-infset

325 \: A-infset × A-infset → A-infset

326 ⊂: A-infset × A-infset → Bool



327 ⊆: A-infset × A-infset → Bool

328 =: A-infset × A-infset → Bool

329 6=: A-infset × A-infset → Bool

330 card: A-infset∼→ Nat

652

Set Examples

examples

a ∈ a,b,ca 6∈ , a 6∈ b,ca,b,c ∪ a,b,d,e = a,b,c,d,e∪a,a,b,a,d = a,b,da,b,c ∩ c,d,e = c∩a,a,b,a,d = aa,b,c \ c,d = a,ba,b ⊂ a,b,ca,b,c ⊆ a,b,ca,b,c = a,b,ca,b,c 6= a,bcard = 0, card a,b,c = 3

653

Informal Explication

319. ∈: The membership operator expresses that an element is a member of a set.320. 6∈: The nonmembership operator expresses that an element is not a member of a set.321. ∪: The infix union operator. When applied to two sets, the operator gives the set whose

members are in either or both of the two operand sets.322. ∪: The distributed prefix union operator. When applied to a set of sets, the operator gives the

set whose members are in some of the operand sets.323. ∩: The infix intersection operator. When applied to two sets, the operator gives the set whose

members are in both of the two operand sets.324. ∩: The prefix distributed intersection operator. When applied to a set of sets, the operator

gives the set whose members are in some of the operand sets. 654

325. \: The set complement (or set subtraction) operator. When applied to two sets, the operatorgives the set whose members are those of the left operand set which are not in the rightoperand set.

326. ⊆: The proper subset operator expresses that all members of the left operand set are also inthe right operand set.

327. ⊂: The proper subset operator expresses that all members of the left operand set are also inthe right operand set, and that the two sets are not identical.

328. =: The equal operator expresses that the two operand sets are identical.329. 6=: The nonequal operator expresses that the two operand sets are not identical.330. card: The cardinality operator gives the number of elements in a finite set.

655

Set Operator Definitions

The operations can be defined as follows (≡ is the definition symbol):

value

s′ ∪ s′′ ≡ a | a:A • a ∈ s′ ∨ a ∈ s′′ s′ ∩ s′′ ≡ a | a:A • a ∈ s′ ∧ a ∈ s′′ s′ \ s′′ ≡ a | a:A • a ∈ s′ ∧ a 6∈ s′′ s′ ⊆ s′′ ≡ ∀ a:A • a ∈ s′ ⇒ a ∈ s′′



s′ ⊂ s′′ ≡ s′ ⊆ s′′ ∧ ∃ a:A • a ∈ s′′ ∧ a 6∈ s′

s′ = s′′ ≡ ∀ a:A • a ∈ s′ ≡ a ∈ s′′ ≡ s⊆s′ ∧ s′⊆ss′ 6= s′′ ≡ s′ ∩ s′′ 6= card s ≡

if s = then 0 else

let a:A • a ∈ s in 1 + card (s \ a) end end

pre s /∗ is a finite set ∗/card s ≡ chaos /∗ tests for infinity of s ∗/

Cartesian Operations 656

type

A, B, Cg0: G0 = A × B × Cg1: G1 = ( A × B × C )g2: G2 = ( A × B ) × Cg3: G3 = A × ( B × C )

value

va:A, vb:B, vc:C, vd:D(va,vb,vc):G0,

(va,vb,vc):G1((va,vb),vc):G2(va3,(vb3,vc3)):G3

decomposition expressions

let (a1,b1,c1) = g0,(a1′,b1′,c1′) = g1 in .. end

let ((a2,b2),c2) = g2 in .. end

let (a3,(b3,c3)) = g3 in .. end

List Operations 657

List Operator Signatures

value

hd: Aω ∼→ A

tl: Aω ∼→ Aω

len: Aω ∼→ Nat

inds: Aω → Nat-infset

elems: Aω → A-infset

.(.): Aω × Nat∼→ A

: A∗ × Aω → Aω=: Aω × Aω → Bool6=: Aω × Aω → Bool

658

List Operation Examples

examples

hd〈a1,a2,...,am〉=a1tl〈a1,a2,...,am〉=〈a2,...,am〉len〈a1,a2,...,am〉=minds〈a1,a2,...,am〉=1,2,...,melems〈a1,a2,...,am〉=a1,a2,...,am〈a1,a2,...,am〉(i)=ai〈a,b,c〉〈a,b,d〉 = 〈a,b,c,a,b,d〉〈a,b,c〉=〈a,b,c〉〈a,b,c〉 6= 〈a,b,d〉

659



Informal Explication

• hd: Head gives the first element in a nonempty list.• tl: Tail gives the remaining list of a nonempty list when Head is removed.• len: Length gives the number of elements in a finite list.• inds: Indices give the set of indices from 1 to the length of a nonempty list. For empty lists,

this set is the empty set as well.• elems: Elements gives the possibly infinite set of all distinct elements in a list.• ℓ(i): Indexing with a natural number, i larger than 0, into a list ℓ having a number of elements

larger than or equal to i, gives the ith element of the list. 660

• : Concatenates two operand lists into one. The elements of the left operand list are followedby the elements of the right. The order with respect to each list is maintained.

• =: The equal operator expresses that the two operand lists are identical.• 6=: The nonequal operator expresses that the two operand lists are not identical.

The operations can also be defined as follows: 661

List Operator Definitions

value

is finite list: Aω → Bool

len q ≡case is finite list(q) of

true → if q = 〈〉 then 0 else 1 + len tl q end,false → chaos end

inds q ≡case is finite list(q) of

true → i | i:Nat • 1 ≤ i ≤ len q ,false → i | i:Nat • i6=0 end

elems q ≡ q(i) | i:Nat • i ∈ inds q

662

q(i) ≡if i=1

then

if q 6=〈〉then let a:A,q′:Q • q=〈a〉q′ in a end

else chaos end

else q(i−1) end

fq iq ≡〈 if 1 ≤ i ≤ len fq then fq(i) else iq(i − len fq) end

| i:Nat • if len iq 6=chaos then i ≤ len fq+len end 〉pre is finite list(fq)

iq′ = iq′′ ≡inds iq′ = inds iq′′ ∧ ∀ i:Nat • i ∈ inds iq′ ⇒ iq′(i) = iq′′(i)

iq′ 6= iq′′ ≡ ∼(iq′ = iq′′)



Map Operations 663

Map Operator Signatures and Map Operation Examples

value

m(a): M → A∼→ B, m(a) = b

dom: M → A-infset [ domain of map ]dom [ a1 7→b1,a2 7→b2,...,an7→bn ] = a1,a2,...,an

rng: M → B-infset [ range of map ]rng [ a1 7→b1,a2 7→b2,...,an7→bn ] = b1,b2,...,bn

†: M × M → M [ override extension ][ a 7→b,a′7→b′,a′′ 7→b′′ ] † [ a′7→b′′,a′′7→b′ ] = [ a 7→b,a′7→b′′,a′′ 7→b′ ]

664

∪: M × M → M [ merge ∪ ][ a 7→b,a′7→b′,a′′ 7→b′′ ] ∪ [ a′′′7→b′′′ ] = [ a 7→b,a′7→b′,a′′7→b′′,a′′′ 7→b′′′ ]

\: M × A-infset → M [ restriction by ][ a 7→b,a′7→b′,a′′ 7→b′′ ]\a = [ a′7→b′,a′′ 7→b′′ ]

/: M × A-infset → M [ restriction to ][ a 7→b,a′7→b′,a′′ 7→b′′ ]/a′,a′′ = [ a′7→b′,a′′ 7→b′′ ]

=,6=: M × M → Bool

: (A →m B) × (B →m C) → (A →m C) [ composition ][ a 7→b,a′7→b′ ] [ b7→c,b′7→c′,b′′7→c′′ ] = [ a 7→c,a′7→c′ ]

665

Map Operation Explication

• m(a): Application gives the element that a maps to in the map m.• dom: Domain/Definition Set gives the set of values which maps to in a map.• rng: Range/Image Set gives the set of values which are mapped to in a map.• †: Override/Extend. When applied to two operand maps, it gives the map which is like an

override of the left operand map by all or some “pairings” of the right operand map.• ∪: Merge. When applied to two operand maps, it gives a merge of these maps.• \: Restriction. When applied to two operand maps, it gives the map which is a restriction of

the left operand map to the elements that are not in the right operand set.666

• /: Restriction. When applied to two operand maps, it gives the map which is a restriction ofthe left operand map to the elements of the right operand set.

• =: The equal operator expresses that the two operand maps are identical.• 6=: The nonequal operator expresses that the two operand maps are not identical.• : Composition. When applied to two operand maps, it gives the map from definition set

elements of the left operand map, m1, to the range elements of the right operand map, m2,such that if a is in the definition set of m1 and maps into b, and if b is in the definition set ofm2 and maps into c, then a, in the composition, maps into c.

667



Map Operation Redefinitions

The map operations can also be defined as follows:

value

rng m ≡ m(a) | a:A • a ∈ dom m

m1 † m2 ≡[ a 7→b | a:A,b:B •

a ∈ dom m1 \ dom m2 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]

m1 ∪ m2 ≡ [ a 7→b | a:A,b:B •

a ∈ dom m1 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]

m \ s ≡ [ a 7→m(a) | a:A • a ∈ dom m \ s ]m / s ≡ [ a 7→m(a) | a:A • a ∈ dom m ∩ s ]

m1 = m2 ≡dom m1 = dom m2 ∧ ∀ a:A • a ∈ dom m1 ⇒ m1(a) = m2(a)

m1 6= m2 ≡ ∼(m1 = m2)

mn ≡[ a 7→c | a:A,c:C • a ∈ dom m ∧ c = n(m(a)) ]pre rng m ⊆ dom n

A.1.5 λ-Calculus + Functions 668

The λ-Calculus Syntax

type /∗ A BNF Syntax: ∗/〈L〉 ::= 〈V〉 | 〈F〉 | 〈A〉 | ( 〈A〉 )〈V〉 ::= /∗ variables, i.e. identifiers ∗/〈F〉 ::= λ〈V〉 • 〈L〉〈A〉 ::= ( 〈L〉〈L〉 )

value /∗ Examples ∗/〈L〉: e, f, a, ...〈V〉: x, ...〈F〉: λ x • e, ...〈A〉: f a, (f a), f(a), (f)(a), ...

Free and Bound Variables 669

Let x, y be variable names and e, f be λ-expressions.

• 〈V〉: Variable x is free in x.• 〈F〉: x is free in λy •e if x 6= y and x is free in e.• 〈A〉: x is free in f(e) if it is free in either f or e (i.e., also in both).

Substitution 670

In RSL, the following rules for substitution apply:

• subst([N/x]x) ≡ N;



• subst([N/x]a) ≡ a,for all variables a 6= x;

• subst([N/x](P Q)) ≡ (subst([N/x]P) subst([N/x]Q));• subst([N/x](λx•P )) ≡ λ y•P;• subst([N/x](λ y•P)) ≡ λy• subst([N/x]P),

if x6=y and y is not free in N or x is not free in P;• subst([N/x](λy•P)) ≡ λz•subst([N/z]subst([z/y]P)),

if y6=x and y is free in N and x is free in P(where z is not free in (N P)).

α-Renaming and β-Reduction 671

• α-renaming: λx•MIf x, y are distinct variables then replacing x by y in λx•M results in λy•subst([y/x]M). We canrename the formal parameter of a λ-function expression provided that no free variables of itsbody M thereby become bound.

• β-reduction: (λx•M)(N)All free occurrences of x in M are replaced by the expression N provided that no free variablesof N thereby become bound in the result. (λx•M)(N) ≡ subst([N/x]M)

Function Signatures 672

For sorts we may want to postulate some functions:

type

A, B, Cvalue

obs B: A → B,obs C: A → C,gen A: B×C → A

Function Definitions 673

Functions can be defined explicitly:

value

f: Arguments → Resultf(args) ≡ DValueExpr

g: Arguments∼→ Result

g(args) ≡ ValueAndStateChangeClausepre P(args)

674

Or functions can be defined implicitly:

value

f: Arguments → Resultf(args) as resultpost P1(args,result)

g: Arguments∼→ Result

g(args) as resultpre P2(args)post P3(args,result)



The symbol∼→ indicates that the function is partial and thus not defined for all arguments. Partial

functions should be assisted by preconditions stating the criteria for arguments to be meaningfulto the function.

A.1.6 Other Applicative Expressions 675

Simple let Expressions

Simple (i.e., nonrecursive) let expressions:

let a = Ed in Eb(a) end

is an “expanded” form of:

(λa.Eb(a))(Ed)

Recursive let Expressions 676

Recursive let expressions are written as:

let f = λa:A • E(f) in B(f,a) end

is “the same” as:

let f = YF in B(f,a) end

where:

F ≡ λg•λa•(E(g)) and YF = F(YF)

Predicative let Expressions 677

Predicative let expressions:

let a:A • P(a) in B(a) end

express the selection of a value a of type A which satisfies a predicate P(a) for evaluation in thebody B(a).

Pattern and “Wild Card” let Expressions 678

Patterns and wild cards can be used:

let a ∪ s = set in ... end

let a, ∪ s = set in ... end

let (a,b,...,c) = cart in ... end

let (a, ,...,c) = cart in ... end

let 〈a〉ℓ = list in ... end

let 〈a, ,b〉ℓ = list in ... end

let [ a 7→b ] ∪ m = map in ... end

let [ a 7→b, ] ∪ m = map in ... end



Conditionals 679

Various kinds of conditional expressions are offered by RSL:

if b expr then c expr else a exprend

if b expr then c expr end ≡ /∗ same as: ∗/if b expr then c expr else skip end

if b expr 1 then c expr 1elsif b expr 2 then c expr 2elsif b expr 3 then c expr 3...elsif b expr n then c expr n end

case expr of

choice pattern 1 → expr 1,choice pattern 2 → expr 2,...choice pattern n or wild card → expr n

end

Operator/Operand Expressions 680

〈Expr〉 ::=〈Prefix Op〉〈Expr〉| 〈Expr〉〈Infix Op〉〈Expr〉| 〈Expr〉〈Suffix Op〉| ...

〈Prefix Op〉 ::=− | ∼ | ∪ | ∩ | card | len | inds | elems | hd | tl | dom | rng

〈Infix Op〉 ::== | 6= | ≡ | + | − | ∗ | ↑ | / | < | ≤ | ≥ | > | ∧ | ∨ | ⇒| ∈ | 6∈ | ∪ | ∩ | \ | ⊂ | ⊆ | ⊇ | ⊃ | | † |

〈Suffix Op〉 ::= !

A.1.7 Imperative Constructs 681

Statements and State Changes

Often, following the RAISE method, software development starts with highly abstract-applicativeconstructs which, through stages of refinements, are turned into concrete and imperative con-structs. Imperative constructs are thus inevitable in RSL.

Unit

value

stmt: Unit → Unit

stmt()

• Statements accept no arguments.• Statement execution changes the state (of declared variables).• Unit → Unit designates a function from states to states.• Statements, stmt, denote state-to-state changing functions.• Writing () as “only” arguments to a function “means” that () is an argument of type Unit.



Variables and Assignment 682

0. variable v:Type := expression1. v := expr

Statement Sequences and skip 683

Sequencing is expressed using the ‘;’ operator. skip is the empty statement having no value orside-effect.

2. skip

3. stm 1;stm 2;...;stm n

Imperative Conditionals 684

4. if expr then stm c else stm a end

5. case e of : p 1→S 1(p 1),...,p n→S n(p n) end

Iterative Conditionals 685

6. while expr do stm end

7. do stmt until expr end

Iterative Sequencing 686

8. for e in list expr • P(b) do S(b) end

A.1.8 Process Constructs 687

Process Channels

Let A and B stand for two types of (channel) messages and i:KIdx for channel array indexes, then:

channel c:Achannel k[ i ]:B • i:KIdx

declare a channel, c, and a set (an array) of channels, k[i], capable of communicating values of thedesignated types (A and B).

Process Composition 688

Let P and Q stand for names of process functions, i.e., of functions which express willingness toengage in input and/or output events, thereby communicating over declared channels. Let P() andQ stand for process expressions, then:

P ‖ Q Parallel compositionP ⌈⌉⌊⌋ Q Nondeterministic external choice (either/or)P ⌈⌉ Q Nondeterministic internal choice (either/or)P –‖ Q Interlock parallel composition

express the parallel (‖) of two processes, or the nondeterministic choice between two processes:either external (⌈⌉⌊⌋) or internal (⌈⌉). The interlock (–‖) composition expresses that the two processesare forced to communicate only with one another, until one of them terminates.



Input/Output Events 689

Let c, k[i] and e designate channels of type A and B, then:

c ?, k[ i ] ? Inputc ! e, k[ i ] ! e Output

expresses the willingness of a process to engage in an event that “reads” an input, respectively“writes” an output.

Process Definitions 690

The below signatures are just examples. They emphasise that process functions must somehowexpress, in their signature, via which channels they wish to engage in input and output events.

value

P: Unit → in c out k[ i ]Unit

Q: i:KIdx → out c in k[ i ] Unit

P() ≡ ... c ? ... k[ i ] ! e ...Q(i) ≡ ... k[ i ] ? ... c ! e ...

The process function definitions (i.e., their bodies) express possible events.

A.1.9 Simple RSL Specifications 691

Often, we do not want to encapsulate small specifications in schemes, classes, and objects, as isoften done in RSL. An RSL specification is simply a sequence of one or more types, values (includingfunctions), variables, channels and axioms:

type

...variable

...channel

...value

...axiom

...

In practice a full specification repeats the above listings many times, once for each “module” (i.e.,aspect, facet, view) of specification. Each of these modules may be “wrapped” into scheme, classor object definitions.1

1 For schemes, classes and objects we refer to [12, Chap. 10]


B

Domain Examples 692

B.1 A Model of Pipeline Endurants 693

B.1.1 Parts

Pump

Valve

Join

Fork

Pipe

JoinForkPumpValve

Units

Connection

Oil Well

Oil (Depot) Sink

Fig. B.1. An oil pipeline system

694

331. A pipeline system contains a set of pipeline units and a pipeline system monitor.332. The well-formedness of a pipeline system depends on its mereology (cf. Sect. B.1.2) and the

routing of its pipes (cf. Sect. B.1.3).333. A pipeline unit is either a well, a pipe, a pump, a valve, a fork, a join, or a sink unit.334. We consider all these units to be distinguishable, i.e., the set of wells, the set pipe, etc., the

set of sinks, to be disjoint.695

type

331. PLS′, U, M332. PLS = | pls:PLS′

•wf PLS(pls) |value

332. wf PLS: PLS → Bool

332. wf PLS(pls) ≡ wf Mereology(pls) ∧ wf Routes(pls)331. obs Us: PLS → U-set

331. obs M: PLS → Mtype

333. U = We | Pi | Pu | Va | Fo | Jo | Si

146 B Domain Examples

334. We :: Well334. Pi :: Pipe334. Va :: Valv334. Fo :: Fork334. Jo :: Join334. Si :: Sink

B.1.2 Part Identification and Mereology 696

Unique Identification

335. Each pipeline unit is uniquely distinguished by its unique unit identifier.

type

335. UIvalue

335. uid UI: U → UIaxiom

335. ∀ pls:PLS,u,u′:U•u,u′⊆obs Us(pls)⇒u6=u′⇒uid UI(u)6=uid UI(u′)

Unique Identifiers 697

336. From a pipeline system one can observe the set of all unique unit identifiers.

value

336. xtr UIs: PLS → UI-set336. xtr UIs(pls) ≡ uid UI(u)|u:U•u ∈ obs Us(pls)

337. We can prove that the number of unique unit identifiers of a pipeline system equals that ofthe units of that system.

theorem:

337. ∀ pls:PLS•card obs Us(pl)=card xtr UIs(pls)

Mereology 698

338. Each unit is connected to zero, one or two other existing input units and zero, one or twoother existing output units as follows:(a) A well unit is connected to exactly one output unit (and, hence, has no “input”).(b) A pipe unit is connected to exactly one input unit and one output unit.(c) A pump unit is connected to exactly one input unit and one output unit.(d) A valve is connected to exactly one input unit and one output unit.(e) A fork is connected to exactly one input unit and two distinct output units.(f) A join is connected to exactly two distinct input units and one output unit.(g) A sink is connected to exactly one input unit (and, hence, has no “output”).

699

type

338. MER = UI-set × UI-setvalue

338. mereo U: U → MERaxiom



338. wf Mereology: PLS → Bool

338. wf Mereology(pls) ≡338. ∀ u:U•u ∈ obs Us(pls)⇒338. let (iuis,ouis) = mereo U(u) in iuis ∪ ouis ⊆ xtr UIs(pls) ∧338. case (u,(card uius,card ouis)) of

338a. (mk We(we),(0,1)) → true,338b. (mk Pi(pi),(1,1)) → true,338c. (mk Pu(pu),(1,1)) → true,338d. (mk Va(va),(1,1)) → true,338e. (mk Fo(fo),(1,1)) → true,338f. (mk Jo(jo),(1,1)) → true,338g. (mk Si(si),(1,1)) → true,338. → false end end

B.1.3 Part Concepts, I 700

Pipe Routes

339. A route (of a pipeline system) is a sequence of connected units (of the pipeline system).340. A route descriptor is a sequence of unit identifiers and the connected units of a route (of a

pipeline system).

type

339. R′ = Uω

339. R = | r:Route′•wf Route(r) |340. RD = UIω

axiom

340. ∀ rd:RD • ∃ r:R•rd=descriptor(r)value

340. descriptor: R → RD340. descriptor(r) ≡ 〈uid UI(r[ i ])|i:Nat•1≤i≤len r〉

701

341. Two units are adjacent if the output unit identifiers of one shares a unique unit identifier withthe input identifiers of the other.

value

341. adjacent: U × U → Bool

341. adjacent(u,u′) ≡ let (,ouis)=mereo U(u),(iuis,)=mereo U(u′) in ouis ∩ iuis 6= end

702

342. Given a pipeline system, pls, one can identify the (possibly infinite) set of (possibly infinite)routes of that pipeline system.(a) The empty sequence, 〈〉, is a route of pls.(b) Let u, u′ be any units of pls, such that an output unit identifier of u is the same as an

input unit identifier of u′ then 〈u, u′〉 is a route of pls.(c) If r and r′ are routes of pls such that the last element of r is the same as the first element

of r′, then rtlr′ is a route of pls.(d) No sequence of units is a route unless it follows from a finite (or an infinite) number of

applications of the basis and induction clauses of Items 342a–342c.

value

342. Routes: PLS → RD-infset

342. Routes(pls) ≡342a. let rs = 〈〉 ∪



342b. 〈uid UI(u),uid UI(u′)〉|u,u′:U•u,u′⊆obs Us(pls) ∧ adjacent(u,u′)342c. ∪ rtl r′|r,r′:R•r,r′⊆rs342d. in rs end

Wellformed Routes 703

343. A route is acyclic if no two route positions reveal the same unique unit identifier.

value

343. acyclic Route: R → Bool

343. acyclic Route(r) ≡ ∼∃ i,j:Nat•i,j⊆inds r ∧ i6=j ∧ r[ i ]=r[ j ]

704

344. A pipeline system is well-formed if none of its routes are circular (and all of its routes embeddedin well-to-sink routes).

value

344. wf Routes: PLS → Bool

344. wf Routes(pls) ≡344. non circular(pls) ∧ are embedded in well to sink Routes(pls)

344. non circular PLS: PLS → Bool

344. non circular PLS(pls) ≡344. ∀ r:R•r ∈ routes(p)∧acyclic Route(r)

705

345. We define well-formedness in terms of well-to-sink routes, i.e., routes which start with a wellunit and end with a sink unit.

value

345. well to sink Routes: PLS → R-set

345. well to sink Routes(pls) ≡345. let rs = Routes(pls) in

345. r|r:R•r ∈ rs ∧ is We(r[ 1 ]) ∧ is Si(r[ len r ]) end

706

346. A pipeline system is well-formed if all of its routes are embedded in well-to-sink routes.

346. are embedded in well to sink Routes: PLS → Bool

346. are embedded in well to sink Routes(pls) ≡346. let wsrs = well to sink Routes(pls) in

346. ∀ r:R • r ∈ Routes(pls) ⇒346. ∃ r′:R,i,j:Nat •

346. r′ ∈ wsrs346. ∧ i,j⊆inds r′∧i≤j346. ∧ r = 〈r′[ k ]|k:Nat•i≤k≤j〉 end

Embedded Routes 707

347. For every route we can define the set of all its embedded routes.

value

347. embedded Routes: R → R-set

347. embedded Routes(r) ≡347. 〈r[ k ]|k:Nat•i≤k≤j〉 | i,j:Nat• i i,j⊆inds(r) ∧ i≤j



A Theorem 708

348. The following theorem is conjectured:(a) the set of all routes (of the pipeline system)(b) is the set of all well-to-sink routes (of a pipeline system) and(c) all their embedded routes

theorem:

348. ∀ pls:PLS •

348. let rs = Routes(pls),348. wsrs = well to sink Routes(pls) in

348a. rs =348b. wsrs ∪348c. ∪ r′|r′:R • r′ ∈ embedded Routes(r′′) | r′′:R • r′′ ∈ wsrs347. end

B.1.4 Materials 709

349. The only material of concern to pipelines is the gas1or liquid2which the pipes transport3.

type

349. GoLvalue

349. obs GoL: U → GoL

B.1.5 Attributes 710

Part Attributes

350. These are some attribute types:(a) estimated current well capacity (barrels of oil, etc.),(b) pipe length,(c) current pump height,(d) current valve open/close status and(e) flow (e.g., volume/second).

711

type

350a. WellCap350b. LEN350c. Height350d. ValSta == open | close350e. Flow

351. Flows can be added (also distributively) and subtracted, and352. flows can be compared.

value

351. ⊕,⊖: Flow×Flow → Flow351. ⊕: Flow-set → Flow352. <,≤,=,6=,≥,>: Flow × Flow → Bool



712

353. Properties of pipeline units include(a) estimated current well capacity (barrels of oil, etc.),(b) pipe length,(c) current pump height,(d) current valve open/close status,(e) current Laminar in-flow at unit input,(f) current Laminar in-flow leak at unit input,(g) maximum Laminar guaranteed in-flow leak at unit input,(h) current Laminar leak unit interior,(i) current Laminar flow in unit interior,(j) maximum Laminar guaranteed flow in unit interior,(k) current Laminar out-flow at unit output,(l) current Laminar out-flow leak at unit output,

(m) maximum guaranteed Laminar out-flow leak at unit output.713

value

353a. attr WellCap: We → WellCap353b. attr LEN: Pi → LEN353c. attr Height: Pu → Height353d. attr ValSta: Va → VaSta353e. attr In FlowL: U → UI → Flow353f. attr In LeakL: U → UI → Flow353g. attr Max In LeakL: U → UI → Flow353h. attr body FlowL: U → Flow353i. attr body LeakL: U → Flow353j. attr Max FlowL: U → Flow353k. attr Out FlowL: U → UI → Flow353l. attr Out LeakL: U → UI → Flow353m. attr Max Out LeakL: U → UI → Flow

Flow Laws, I 714

354. “What flows in, flows out !”. For Laminar flows: for any non-well and non-sink unit the sumsof input leaks and in-flows equals the sums of unit and output leaks and out-flows.

Law:

354. ∀ u:U\We\Si •

354. sum in leaks(u) ⊕ sum in flows(u) =354. attr body LeakL(u) ⊕354. sum out leaks(u) ⊕ sum out flows(u)

715

value

sum in leaks: U → Flowsum in leaks(u) ≡

let (iuis,) = mereo U(u) in

⊕ attr In LeakL(u)(ui)|ui:UI•ui ∈ iuis end

sum in flows: U → Flow

1 Gaseous materials include: air, gas, etc.2 Liquid materials include water, oil, etc.3 The description of this document is relevant only to gas or oil pipelines.


B.2 A Model of Platoons & Platooning 151

sum in flows(u) ≡let (iuis,) = mereo U(u) in

⊕ attr In FlowL(u)(ui)|ui:UI•ui ∈ iuis end

sum out leaks: U → Flowsum out leaks(u) ≡

let (,ouis) = mereo U(u) in

⊕ attr Out LeakL(u)(ui)|ui:UI•ui ∈ ouis end

sum out flows: U → Flowsum out flows(u) ≡

let (,ouis) = mereo U(u) in

⊕ attr Out LeakL(u)(ui)|ui:UI•ui ∈ ouis end

716

355. “What flows out, flows in !”. For Laminar flows: for any adjacent pairs of units the output flowat one unit connection equals the sum of adjacent unit leak and in-flow at that connection.

Law:

355. ∀ u,u′:U•adjacent(u,u′) ⇒355. let (,ouis)=mereo U(u), (iuis′,)=mereo U(u′) in

355. assert: uid U(u′) ∈ ouis ∧ uid U(u) ∈ iuis ′

355. attr Out FlowL(u)(uid U(u′)) =355. attr In LeakL(u)(uid U(u))⊕attr In FlowL(u′)(uid U(u)) end

Material Attributes 717


B.2.1 Vehicles and Platoons

356. There are vehicles357. and vehicles have unique identities.358. There are platoons and unique platoon identifiers.359. From a platoon one can observe a sequence of zero, one or more distinctly identified vehicles.360. and a unique identifier.

719

type

356. V, VI356. VE = VI × Vvalue

357. obs VI: VE → VI, obs VI(vi, ) ≡ vi357. obs V: VE → V, obs V( ,v) ≡ vtype

358. P = VE∗

358. PI358. PL = PI × Pvalue

360. uid PI: PL → PI, uid PI(pi, ) ≡ pi360. obs P: PL → P, obs PI( ,p) ≡ paxiom

359. ∀ p:P • ∀ i,j:Nat • i,j⊆inds obs P(p) ∧ i6=j ⇒359. uid VI((obs P(p))(i))6=uid VI(obs P(p))(j)



B.2.2 Platoon Systems 720

361. There are platoon systems and from a platoon system362. one can observe of, as we shall call it, a base set of unique identified vehicles363. and a set of, as we shall call it, a base set of uniquely identified platoons.

type

361. PlSy = VM × PM362. VM = VI →m V363. PM = PI →m Pvalue

362. obs VM: PlSy → VM, obs Vs(vm, ) ≡ vm363. obs PM: PlSy → PM, obs Vs( ,pm) ≡ pm

364. All vehicles are distinctly identified.

axiom

364. ∀ (vm,pm):PlSy • unique vehicles(vm,pm)

B.2.3 Auxiliary Functions 721

365. The following function is useful:

value

365. unique platoon identifiers: PM → PI-set365. unique platoon identifiers(pm) ≡ dom pm

366. From Item 364:

value

366. unique vehicle: VM × PM → Bool

366. unique vehicles(vm,pm) ≡366. let vis = vehicle identifiers(vs),366. ∩ vehicle identifiers(p)|p:P•p ∈ rng pm = 366. ∧ vis ∩ vehicle identifiers(pm) = end

722

The following are auxiliary functions:

367. extracting the set of vehicle identifiers from the base set of vehicles,368. extracting the set of vehicle identifiers from the “body” of a platoon, and369. extracting the set of vehicle identifiers from the base set of platooons.

value

367. vehicle identifiers: VM → VI-set367. vehicle identifiers(vm) ≡ dom vm

368. vehicle identifiers: P → VI-set368. vehicle identifiers(p) ≡ vi|vi:VI•(vi, ) ∈ elems vl

369. vehicle identifiers: PM → VI-set369. vehicle identifiers(pm) ≡ ∪vehicle identifiers(p)|p:P•p ∈ rng pm

723

370. From a platoon one can form a contribution to the base vehicles component.



370. re form VEs: P → VM370. re form VEs(p) ≡370. [ vi7→v|v:V,(vi′,v′):VE•(vi′,v′)∈ elems p ∧ vi′=vi ∧ v=v′ ]

371. One appends a vehicle to the tail of a platoon.

371. append: VE × P → P371. append(ve,p) ≡ p〈ve〉

372. One appends a platoon to the tail of a[nother] platoon.

372. append: P × P → P372. append(p,p′) ≡ pp′

724

373. An identified vehicle, vi, is in a platoon, p, if there exists a vehicle, Ve=(vi,v), in the platoon.

value

373. is vehicle in platoon: VI × P → Bool

373. is vehicle in platoon(vi,p) ≡ ∃ (vi′,v′):VE•vi=vi′∧(vi′,v′) ∈ elems p

374. If an identified vehicle, vi, is in a platoon, p,375. then there exists an index, i, into the platipn that selects that vehcile.

value

374. vehicle index: VI × P∼→ Nat

374. vehicle index(vi,p) as i374. pre: is vehicle in platoon(vi,p)375. post: ∃ v:V•p(i)=(vi,v)

725

376. If an identified vehicle, vi, is in a platoon, p,377. then it is selected by that vehicle’s index into that platoon.

376. identified vehicle: VI × P∼→ VE

376. identified vehicle(vi,p) as ve376. pre: is vehicle in platoon(vi,p)377. post: ve=p(vehicle index(vi,p))

726

378. Splitting a platoon at the index, i, of some identified vehicle, vi,379. results in two platoons, , p′ and , p′′,380. that are formed from the argument platoon by the first i-1 elements of that platoon381. and the remaining elements.

378. split: Nat × P → (P × P)379. split(i,p) as (p′,p′′)378. pre: ∃ vi:VI•vehicle index(vi,p) = i380. post: p′= 〈p(j)|1≤j≤i−1〉381. ∧ p′′ = 〈p(k)|i≤k≤len p〉

727

382. To remove an identified vehicle, vi, from a platoon, p,383. results in a changed platoon, , p′,384. provided the vehicle is in the platoon;385. the vehicle to be removed has index i,



386. and the element removed is the first in the second of the platoon split at i, hence the tail ofthat second platoon.

382. remove vehicle: VI × P∼→ P

383. remove vehicle(vi,p) as p′

384. pre: is vehicle in platoon(vi,p)385. post: let i = vehicle index(vi,p) in

386. let (p′′,p′′′) = split(i.p) in p′=p′′tl p′′′ end end

B.2.4 Simple Platoon Operations 728

Invariance

The axiom of Item 364 on Page 152 can be assumed to hold before each platoon system operation— and can be proven to hold after each platoon system operation. But we can formulate a strongerproposition (theorem, if you like).

387. Let (vm,pm) and (vm′,pm′) be any platoon systems.388. We say that an operation that transforms (vm,pm) into (vm′,pm′) is an acceptable operation.

387. theorem: TH((vm,pm)(vm′,pm′)) ≡387. vehicle identifiers(vm,pm) = vehicle identifiers((vm′,pm′))

Signatures 729

389. Formation of a platoon from a set of identified, existing (platoon system “reservoir” of) vehiclesand yielding, beside the platoon system change, a “fresh” platoon identifier.

390. Dissolving an existing platoon into its constituent vehicles.391. Join an identified, existing vehicles into an existing, identified platoon.392. Leaving an identified vehicle from an identified, existing platoon, “reverting” that vehicle to

the platoon system “reservoir” of vehicles.393. Splitting an identified, existing platoon, at a given position, into two platoons, considering the

first part to be “the same” platoon as being split, while yielding also a new, “fresh” platoonidentifier.

394. Combining two identified, existing platoons into one, considering the first of the identifiedplatoons to be the “surviving” one.

730

value

389. form: VI-set → PlSy∼→ PlSy × PI

390. dissolve: PI → PlSy∼→ PlSy

391. join: VI× PI → PlSy∼→ PlSy

392. leave: VI× PI → PlSy∼→ PlSy

393. split: PI × Nat → PlSy∼→ PlSy × (PI×PI)

394. combine: PI × PI → PlSy∼→ PlS × PI



Definitions 731

Platoon Formation

389. Formation results in a new platoon system and a new platoon identifier.395. The identified vehicles argument must be those of the vehicles component of the platoon

system.396. The fresh platoon identifier must not be one of the argument platoons.397. The resulting vehicles component must be less exactly the identified vehicles of the vehicles

argument.398. The resulting platoon component must be augmented with exactly one new platoon.

732

value

389. form: VI-set → PlSy∼→ PlSy × PI

389. form(vis)((vm,pm)) as ((vm′,pm′),pi)395. pre: vis ⊆ vehicle identifiers(vm)396. post: pi 6∈ unique platoon identifiers(pm)397. ∧ vm′ = vm \ vi|v:V•uid (v) ∈ vis398. ∧ pm′ = pm ∪ [ pi7→〈v|v:V•uid (v) ∈ vis〉 ]387. proof obligation: TH((vm,pm)(vm′,pm′))

733

Platoon Dissolvement

390. To dissolve a platoon399. requires that the identified platoon does exist400. and results in a platoon system where the platoon has been removed from the base platoon

components401. and its vehicles “added” to he bae vehicles component.

value

390. dissolve: PI → PlSy∼→ PlSy

390. dissolve(pi)(vm,pm) as (vm′,pm′)399. pre: pi ∈ dom pm400. post: pm′ = pm \ pi401. ∧ vm′ = vm ∪ re form VEs(pm(pi))387. proof obligation TH((vm,pm)(vm′,pm′))

734

Platoon Join

391. For a vehicle, from the base vehicles component of a platoon system to join an identifiedplatoon of the base platoons component

402. requires that the vehicle403. and platoons are know as such and404. results in the vehicle being removed from the base vehicles component405. and appended to the [tail of the] identified platoon.

391. join: V I× PI → PlSy∼→ PlSy

391. join(vi.pi)(vm.pm) as (vm′,pm′)402. pre: vi ∈ dom vm403. ∧ pi ∈ dom pn404. post: vm′ = vm \ vi405. ∧ pm′ = pm + [ pi7→append(vm(vi),pm(pi)) ]387. proof obligation: TH((vm,pm)(vm′,pm′))

735



Platoon Leave

392. For an identified vehicle to lave an identified platoon406. requirese that the vehicle and platoon identifications are proper407. and that the identified vehicle does indeed “belong” to the identified platoon, and

results in respectively updated components:408. the leaving vehicle becoming an element of the resulting vehicles component and409. the resulting identified platoon being “less” that vehicle.

392. leave: VI× PI → PlSy∼→ PlSy

392. leave(vi.pi)(vm.pm) as (vm′,pm′)406. pre: vi ∈ dom vm ∧ pi ∈ dom pm407. ∧ vi ∈ vehicle identifiers(pm(p))408. post: vm′ = vm ∪ [ vi7→identified vehicle(vi,pm(pi)) ]409. ∧ pm′ = pm † [ pi7→reject vehicle(vi,pm(pi)) ]387. proof obligation: TH((vm,pm)(vm′,pm′))

736

Platoon Split

393. To split4a platoon, at an indexed position,410. into two platoons identified by pi′ and pi′′,411. requires that the identified platoon, pi, is indeed a proper platoon412. of length beyond the splitting point i.

The result is a changed platoon system413. where pi′ and pi′′ are “fresh”,414. where the two new plattoons are the [simpler] split of the identified platoon,415. where the platoon component has the identified platoon removed and the two new platoons

inserted with proper identification.416. and where the vehicles component has not changed.

737

393. split: PI × Nat → PlSy∼→ PlSy × (PI×PI)

410. split(pi,i)(vm,pm) as ((vm′,pm′),(pi′,p′′))411. pre: pi ∈ dom pm412. ∧ i ∈ inds(pm(pi)) ∧ i<len pm(pi)413. post: pi′,pi′′ ∩ dom pm = 414. let (p′′′,p′′′′) = split(i,pm(p)) in

415. pm′ = pm\pi ∪ [ pi′7→p′′′,pi′′7→p′′′′ ]416. vm′=vm end

387. proof obligation: TH((vm,pm)(vm′,pm′))

738

Platoon Combine

394. To combine two identified platoons417. requires that they are proper platoons and then

results418. in the combined platoon receiving a “fresh” platoon identifier,419. in a new platoons component where the two identified platoons have been removed and the

combined one with a proper new identifier inserted, and420. where the vehicles component is unchanged.

4 Note that we “overload” define the split function: Item 393 on Page 154 versus Item393. below !


B.3 A Model of Railway Nets 157

394. combine: PI × PI → PlSy∼→ PlSy × PI

394. combine(pi,pi′)(vm,pm) as ((vm′,pm′),pi′′)417. pre: pi,pi′⊆dom pm418. post: pi′′6∈ dom pm419. ∧ vm′=vm420. ∧ pm′=pm\pi,pi′∪[ pi′′ 7→append(pm(pi),pm(pi′)) ]387. proof obligation: TH((vm,pm)(vm′,pm′))

B.2.5 A Model of Platoon Movement 739


Rail Units and Connectors 741

type U, Cvalue

obs U Cs : U → C-set

is Linear U : U → Bool,is Junction U : U → Bool,is Crossover U : U → Bool

axiom

forall u : U •

is Linear U(u) ⇒ card obs U Cs(u) = 2,is Junction U(u) ⇒ card obs U Cs(u) = 3,is Crossover U(u) ⇒ card obs U Cs(u) = 4

Rail unit States and State Spaces 742

type

P = C × C,Σ = P-set,Ω = Σ-set

value

obs U Σ : U → Σ,obs U Ω : U → Ω,

/∗ All possible paths through a unit ∗/U Ps : U → P-set

U Ps(u) ≡ p |

p : P •

∃ σ : Σ •

σ ∈ obs U Ω(u) ∧ p ∈ σ,

/∗ All connectors of a set of units ∗/Us Cs : U-set → C-set

Us Cs(us) ≡ c | c : C • ∃ u : U • u ∈ us ∧ c ∈ obs U Cs(u)



Rail Unit and Rail State Properties 743

axiom

/∗ The state is in the set of all states ∗/∀ u : U • obs U Σ(u) ∈ obs U Ω(u),

/∗ All connectors of paths in the state are connectors of the unit ∗/∀ u : U, σ : Σ, (c, c′) : P •

σ ∈ obs U Ω(u) ∧ (c, c′) ∈ σ ⇒c, c′ ⊆ obs U Cs(u)

axiom

forall u : U •

is Linear U(u) ⇒ U Ps(u) 6= ,

is Junction U(u) ⇒(

∃ c1, c2, c3 : C •

card c1, c2, c3 = 3 ∧(c1, c2), (c2, c1) ∩ U Ps(u) 6= ∧(c1, c3), (c3, c1) ∩ U Ps(u) 6= ∧(c2, c3), (c3, c2) ∩ U Ps(u) =

),

is Crossover U(u) ⇒(

∃ c1, c2, c3, c4 : C •

card c1, c2, c3, c4 = 4 ∧(c1, c4), (c4, c1) ∩ U Ps(u) 6= ∧(c2, c3), (c3, c2) ∩ U Ps(u) 6= ∧(c1, c3), (c3, c1) ∩ U Ps(u) = ∧(c2, c4), (c4, c2) ∩ U Ps(u) =

)

Rail Net and Unit Properties 744

type Nvalue

obs N Us : N → U-set

axiom

/∗ In a network, a connector connects no more than two units ∗/∀ n : N, c : C •

card u | u : U • u ∈ obs N Us(n) ∧ c ∈ obs U Cs(u) ≤2,

/∗ In a network, two units do not contain the same path ∗/∀ n : N, u, u′ : U •

u, u′ ⊆ obs N Us(n) ∧ u 6= u′ ⇒ U Ps(u) ∩ U Ps(u′) =

Rail Routes 745

type



Rt′ = C∗, Rt = | rt : Rt′ • wf Rt(rt) |value

/∗ Wellformed routes have lenght at least 2 ∗/wf Rt : Rt′ → Bool

wf Rt(rt) ≡ len rt ≥ 2,

/∗ A route is feasible wrt a network if the route designatespossible paths in the network and the route does notdesignate two succesive paths through the same unit

∗/feasible Rt : Rt × N → Bool

feasible Rt(rt, n) ≡Rt possible paths(rt, n) ∧let ul = Rt Ul(rt, n) in

∼ (∃ i : Nat • i, i + 1 ⊆ inds ul ∧ ul(i) = ul(i + 1))end,

/∗ Route describes possible paths of units in a network ∗/Rt possible paths : Rt × N → Bool

Rt possible paths(rt, n) ≡(

∀ i : Nat •

i, i + 1 ⊆ inds rt ⇒(

∃ u : U •

u ∈ obs N Us(n) ∧ (rt(i), rt(i + 1)) ∈ U Ps(u))

),

Rail Route Concepts 746

/∗ The list of units designated by a route ∗/Rt Ul : Rt × N → U∗

Rt Ul(rt, n) as ulpost

len ul = (len rt) − 1 ∧elems ul ⊆ obs N Us(n) ∧(

∀ i : Nat •

i, i + 1 ⊆ inds rt ⇒ (rt(i), rt(i + 1)) ∈ U Ps(ul(i)))

pre Rt possible paths(rt, n),

/∗ The list of paths designated by a route ∗/Rt Pl : Rt → P∗

Rt Pl(rt) ≡ 〈 (rt(i), rt(i + 1)) | i in 〈 1 .. (len rt) − 1 〉〉,

/∗ All units of a route ∗/Rt Us : Rt × N → U-set

Rt Us(rt, n) ≡ elems Rt Ul(rt, n) pre feasible Rt(rt, n),

/∗ Examine if a route is open ∗/is OpenRt : Rt × N → Bool



is OpenRt(rt, n) ≡(

∀ i : Nat •

i, i + 1 ⊆ inds rt ⇒(rt(i), rt(i + 1)) ∈ obs U Σ(Rt Ul(rt, n)(i))

)pre feasible Rt(rt, n),

747

/∗ The first connector of a route ∗/Rt firstC : Rt → CRt firstC(rt) ≡ hd rt,

/∗ The last connector of a route ∗/Rt lastC : Rt → CRt lastC(rt) ≡ rt(len rt),

/∗ The first unit of a route ∗/Rt firstU : Rt × N → URt firstU(rt, n) ≡ hd Rt Ul(rt, n) pre feasible Rt(rt, n),

/∗ The last unit of a route ∗/Rt lastU : Rt × N → URt lastU(rt, n) ≡

let ul = Rt Ul(rt, n) in ul(len ul) end

pre feasible Rt(rt, n),

/∗ All feasible routes of a network ∗/N Rts : N → Rt-setN Rts(n) ≡ rt | rt : Rt • feasible Rt(rt, n) ,

/∗ Two routes are disjoint ∗/Rt Disj : Rt × Rt × N → Bool

Rt Disj(rt, rt′, n) ≡Rt Us(rt, n) ∩ Rt Us(rt′, n) = pre feasible Rt(rt, n) ∧ feasible Rt(rt′, n),

748

/∗ All possible routes through a set of units ∗/Us Rts : U-set → Rt-setUs Rts(us) ≡

rt |rt : Rt • ∃ n : N • rt ∈ N Rts(n) ∧ Rt Us(rt, n) = us

,

/∗ There is a route through a set of units ∗/is RoutableUs : U-set → Bool

is RoutableUs(us) ≡ Us Rts(us) 6= ,

/∗ Route is cyclic ∗/is Cyclic Rt : Rt × N → Bool

is Cyclic Rt(rt, n) ≡(

∃ i, j : Nat •

i, i + 1, j, j + 1 ⊆ inds rt ∧



i 6= j ∧(Rt Ul(rt, n)(i), rt(i + 1)) = (Rt Ul(rt, n)(j), rt(j + 1))

)pre feasible Rt(rt, n)

type L, S, Trk

Rail Tracks and Train Stations 749

value

obs N Ls : N → L-set,obs N Ss : N → S-set,obs L Us : L → U-set,obs S Us : S → U-set,obs S Trks : S → Trk-set,obs Trk Us : Trk → U-set,

/∗ Examine if a route of a line connects to a station ∗/LS connection : L × S → Bool

LS connection(l, s) ≡(

∃ rt : Rt •

rt ∈ Us Rts(obs L Us(l)) ∧Rt lastC(rt) ∈ Us Cs(obs S Us(s))

),

/∗ Examine if a station connects to a route of a line ∗/SL connection : S × L → Bool

SL connection(s, l) ≡(

∃ rt : Rt •

rt ∈ Us Rts(obs L Us(l)) ∧Rt firstC(rt) ∈ Us Cs(obs S Us(s))

),

Trains Stations 750

/∗ Examine if two stations are connected via a line ∗/SLSConnection : S × L × S → Bool

SLSConnection(s, l, s′) ≡SL connection(s, l) ∧ LS connection(l, s′),

/∗ All lines that can be reached from a trackin a given station

∗/

TrkLs : N × S × Trk∼→ L-set

TrkLs(n, s, t) ≡ l |

l : L •

l ∈ obs N Ls(n) ∧(

∃ rt : Rt •



rt ∈ Us Rts(obs S Us(s)) ∧Rt firstC(rt) ∈ Us Cs(obs Trk Us(t)) ∧Rt lastC(rt) ∈ Us Cs(obs L Us(l))

)pre t ∈ obs S Trks(s) ∧ s ∈ obs N Ss(n),

Further Rail Net Properties 751

/∗ All tracks in a station that can be reachedfrom a given line

∗/

LTrks : N × L × S∼→ Trk-set

LTrks(n, l, s) ≡ t |

t : Trk •

t ∈ obs S Trks(s) ∧(

∃ rt : Rt •

rt ∈ Us Rts(obs S Us(s)) ∧Rt firstC(rt) ∈ Us Cs(obs L Us(l)) ∧Rt lastC(rt) ∈ Us Cs(obs Trk Us(t))

)pre l ∈ obs N Ls(n) ∧ s ∈ obs N Ss(n),

752

/∗ All units of the lines in a network ∗/N L Us : N → U-set

N L Us(n) ≡ u |

u : U • ∃ l : L • l ∈ obs N Ls(n) ∧ u ∈ obs L Us(l),

/∗ All units of the stations in a network ∗/N S Us : N → U-set

N S Us(n) ≡ u |

u : U • ∃ s : S • s ∈ obs N Ss(n) ∧ u ∈ obs S Us(s)

753

axiom

forall n : N, l, l′ : L, s, s′ : S, t, t′ : Trk, c : C, u : U •

/∗ Lines are routable and consist of linear units ∗/is RoutableUs(obs L Us(l)),

u ∈ obs L Us(l) ⇒ is Linear U(u),

/∗ Tracks are routable and consist of lineal units ∗/is RoutableUs(obs Trk Us(t)),

u ∈ obs Trk Us(t) ⇒ is Linear U(u),



/∗ Lines in a network do not intersect ∗/l, l′ ⊆ obs N Ls(n) ⇒obs L Us(l) ⊆ obs N Us(n) ∧ l 6= l′ ⇒obs L Us(l) ∩ obs L Us(l′) = ,

/∗ Stations in a network do not intersect ∗/s, s′ ⊆ obs N Ss(n) ⇒obs S Us(s) ⊆ obs N Us(n) ∧ s 6= s′ ⇒obs S Us(s) ∩ obs S Us(s′) = ,

/∗ Lines and stations do not intersect ∗/l ∈ obs N Ls(n) ∧ s ∈ obs N Ss(n) ⇒obs L Us(l) ∩ obs S Us(s) = ,

/∗ Lines connect stations ∗/l ∈ obs N Ls(n) ⇒(

∃ s, s′ : S •

s 6= s′ ∧ s, s′ ⊆ obs N Ss(n) ∧ SLSConnection(s, l, s′)),

754

/∗ Tracks of a station do not intersect ∗/t, t′ ⊆ obs S Trks(s) ⇒obs Trk Us(t) ⊆ obs S Us(s) ∧ t 6= t′ ⇒obs Trk Us(t) ∩ obs Trk Us(t′) = ,

/∗ Stations do not have common connectors ∗/s, s′ ⊆ obs N Ss(n) ∧ s 6= s′ ⇒Us Cs(obs S Us(s)) ∩ Us Cs(obs S Us(s′)) =

type Sn

value

obs S Sn : S → Sn

axiom

∀ n : N, s, s′ : S •

s, s′ ⊆ obs N Ss(n) ∧ s 6= s′ ⇒ obs S Sn(s) 6= obs S Sn(s′)

755

value

Open N Rts : N → Rt-setOpen N Rts(n) ≡

rt | rt : Rt • rt ∈ N Rts(n) ∧ is OpenRt(rt, n)

type TR = Rt

value

AddTR : TR × C → TRAddTR(tr, c) ≡ tr 〈c〉,

RemTR : TR∼→ TR

RemTR(tr) ≡ tl tr pre len tr ≥ 3



value

TR at S : TR × S → Bool

TR at S(tr, s) ≡ tr ∈ Us Rts(obs S Us(s)),

TR at Trk : TR × Trk → Bool

TR at Trk(tr, trk) ≡ tr ∈ Us Rts(obs Trk Us(trk)),

TR at StaTrk : TR × S → Bool

TR at StaTrk(tr, s) ≡(∃ trk : Trk • trk ∈ obs S Trks(s) ∧ TR at Trk(tr, trk))

756

type T, MR′ = T → N, MR = | mr : MR′• wf MR(mr) |

value

wf MR : MR′ → Bool

wf MR(mr) ≡(

∀ t : T •

∃ t′ : T •

t′ > t ∧(

∀ t′′ : T •

t ≤ t′′ ∧t′′ ≤ t′ ⇒MoN(mr(t), mr(t′′))

)),

MoN : N × N → Bool,

757

/∗ Removed or inserted stations contain only closed units ∗/rem ins S closed : N × N → Bool

rem ins S closed(n, n′) ≡(

∀ s : S •

s ∈(obs N Ss(n) \ obs N Ss(n′)) ∪(obs N Ss(n′) \ obs N Ss(n)) ⇒closed Us(obs S Us(s))

),

/∗ Removed or inserted lines contain only closed units ∗/rem ins L closed : N × N → Bool

rem ins L closed(n, n′) ≡(

∀ l : L •

l ∈(obs N Ls(n) \ obs N Ls(n′)) ∪(obs N Ls(n′) \ obs N Ls(n)) ⇒closed Us(obs L Us(l))

),

closed Us : U-set → Bool


B.4 A Model of TSE Stock Exchanges 165

closed Us(us) ≡ (∀ u : U • u ∈ us ⇒ obs U Σ(u) = )

axiom

∀ n, n′ : N •

MoN(n, n′) ⇒ rem ins S closed(n, n′) ∧ rem ins L closed(n, n′)


This chapter was begun on January 24, 2010. It is being released, first time, January 28, 2010.5

B.4.1 Introduction 759

This chapter shall try describe: narrate and formalise some facets of the (now “old”6) stock tradingsystem of the TSE: Tokyo Stock Exchange (especially the ‘matching’ aspects).

B.4.2 The Problem 760

The reason that I try tackle a description (albeit of the “old” system) is that Prof. Tetsuo Tamaipublished a delightful paper [99, IEEE Computer Journal, June 2009 (vol. 42 no. 6) pp. 58-65)],Social Impact of Information Systems, in which a rather sad story is unfolded: a human error keyinput: an offer for selling stocks, although “ridiculous” in its input data (“sell 610 thousand stocks,each at one (1) Japanese Yen”, whereas one stock at 610,000 JPY was meant), and although severalimmediate — within seconds — attempts to cancel this “order”, could not be cancelled ! This leadto a loss for the selling broker at around 42 Billion Yen, at today’s exchange rate, 26 Jan. 2010,469 million US $s !7Prof. Tetsuo Tamai’s paper gives a, to me, chilling account of what I judge asan extremely sloppy and irresponsible design process by TSE and Fujitsu. It also leaves, I think,a strong impression of arrogance on the part of TSE. This arrogance, I claim, is still there in thedocuments listed in Footnote 6.

So the problem is a threefold one of

• Proper Requirements: How does one (in this case a stock exchange) prescribe (to thesoftware developer) what is required by an appropriate hardware/software system for, as inthis case, stock handling: acceptance of buy bids and sell offers, the possible withdrawal (orcancellation) of such submitted offers, and their matching (i.e., the actual trade whereby buybids are marched in an appropriate, clear and transparent manner).

• Correctness of Implementation: How does one make sure that the software/hardwaresystem meets customers’ expectations.

• Proper Explanation to Lay Users: How does one explain, to the individual and institutionalcustomers of the stock exchange, those offering stocks for sale of bids for buying stocks – how

5 No work has been done on this model since then.6 We write “old” since, as of January 4, 2010, that ‘old’ stock trading system has been replaced by the

so-called arrowhead system. We refer to the following documents:

• http://www.tse.or.jp/english/rules/equities/arrowhead/pamphlet.html

• http://www.tse.or.jp/english/rules/equities/arrowhead/pamphlet-e.pdf

• http://www.tse.or.jp/english/rules/equities/arrowhead/pamphlet1e.pdf

• http://www.tse.or.jp/english/rules/equities/arrowhead/pamphlet2e.html

7 So far three years of law court case hearing etc., has, on Dec. 4, 2009, resulted in complainant beingawarded 10.7 billion Yen in damages. See http://www.ft.com/cms/s/0/e9d89050-e0d7-11de-9f58-

-00144feab49a.html.



does one explain – in a clear and transparent manner the applicable rules governing stockhandling.8

I shall only try contribute, in this document, to a solution to the first of these sub-problems.

B.4.3 A Domain Description 761

Market and Limit Offers and Bids 762

421. A market sell offer or buy bid specifies(a) the unique identification of the stock,(b) the number of stocks to be sold or bought, and(c) the unique name of the seller.

422. A limit sell offer or buy bid specifies the same information as a market sell offer or buy bid(i.e., Items 421a–421c), and(d) the price at which the identified stock is to be sold or bought.

423. A trade order is either a (mkMkt marked) market order or (mkLim marked) a limit order.424. A trading command is either a sell order or a buy bid.425. The sell orders are made unique by the mkSell “make” function.426. The buy orders are made unique by the mkBuy “make” function.

type

421 Market = Stock id × Number of Stocks × Name of Customer421a Stock id

421b Number of Stocks = |n•n:Nat∧n≥1|421c Name of Customer422 Limit = Market × Price

422d Price = |n•n:Nat∧n≥1|423 Trade == mkMkt(m:Market) | mkLim(l:Limit)424 Trading Command = Sell Order | Buy Bid425 Sell Order == mkSell(t:Trade)426 Buy Bid == mkBuy(t:Trade)

Order Books 763

427. We introduce a concept of linear, discrete time.428. For each stock the stock exchange keeps an order book.429. An order book for stock sid : SI keeps track of limit buy bids and limit sell offers (for the

identified stock, sid), as well as the market buy bids and sell offers; that is, for each price(d) the number of stocks, designated by unique order number, offered for sale at that price,

that is, limit sell orders, and(e) the number of stocks, by unique order number, bid for buying at that price, that is, limit

buy bid orders;(f) if an offer is a market sell offer, then the number of stocks to be sold is recorded, and if

an offer is a market buy bid (also an offer), then the number of stocks to be bought isrecorded,

430. Over time the stock exchange displays a series of full order books.431. A trade unit is a pair of a unique order number and an amount (a number larger than 0) of

stocks.432. An amount designates a number of one or more stocks.

8 The rules as explained in the Footnote 6 on the preceding page listed documents are far from clear andtransparent: they are full of references to fast computers, overlapping processing, etc., etc.: matters withwhich these buying and selling customers should not be concerned — so, at least, thinks this author !



type

427 T, On [ Time, Order number ]428 All Stocks Order Book = Stock Id →m Stock Order Book429 Stock Order Book = (Price →m Orders) × Market Offers429 Orders:: so:Sell Orders × bo:Buy Bids429d Sell Orders = On →m Amount429e Buy Bids = On →m Amount429f Market Offers :: mkSell(n:Nat) × mkBuy(n:Nat)430 TSE = T →m All Stocks Order Book431 TU = On × Amount432 Amount = |n•Nat∧n≥1|

Aggregate Offers 764

433. We introduce the concepts of aggregate sell and buy orders for a given stock at a given price(and at a given time).

434. The aggregate sell orders for a given stock at a given price is(g) the stocks being market sell offered and(h) the number of stocks being limit offered for sale at that price or lower

435. The aggregate buy bids for a given stock at a given price is(i) including the stocks being market bid offered and(j) the number of stocks being limit bid for buying at that price or higher

value

434 aggr sell: All Stocks Order Book × Stock Id × Price → Nat

434 aggr sell(asob,sid,p) ≡434 let ((sos, ),(mkSell(ns), )) = asob(sid) in

434g ns +434h all sell summation(sos,p) end

435 aggr buy: All Stocks Order Book × Stock Id × Price → Nat

435 aggr buy(asob,sid,p) ≡435 let (( ,bbs),( ,mkBuy(nb))) = asob(sid) in

435i nb +435j nb + all buy summation(bbs,p) end

all sell summation: Sell Orders × Price → Nat

all sell summation(sos,p) ≡let ps = p′|p′:Prices • p′ ∈ dom sos ∧ p′ ≥ p in accumulate(sos,ps)(0) end

all buy summation: Buy Bids × Price → Nat

all buy summation(bbs,p) ≡let ps = p′|p′:Prices • p′ ∈ dom bos ∧ p′ ≤ p in accumulate(bbs,ps)(0) end

The auxiliary accumulate function is shared between the all sell summation and the all buy -summation functions. It sums the amounts of limit stocks in the price range of the accumulatefunction argument ps. The auxiliary sum function sums the amounts of limit stocks — “pealingoff” the their unique order numbers.

value

accumulate: (Price →m Orders) × Price-set → Nat → Nat

accumulate(pos,ps)(n) ≡case ps of → n, p∪ ps′ → accumulate(pos,ps′)(n+sum(pos(p))dom pos(p)) end



sum: (Sell Orders|Buy Bids) → On-set → Nat

sum(ords)(ns) ≡case ns of → 0, n∪ ns′ → ords(n)+sum(ords)(ns′) end

To handle the sub limit sells and sub limit buys indicated by Item 437c of the Itayose “algorithm”we need the corresponding sub sell summation and sub buy summation functions:

value

sub sell summation: Stock Order Book × Price → Nat

sub sell summation(((sos, ),(ns, )),p) ≡ ns +let ps = p′|p′:Prices • p′ ∈ dom sos ∧ p′ > p in accumulate(sos,ps)(0) end

sub buy summation: Stock Order Book × Price → Nat

sub buy summation((( ,bbs),( ,nb)),p) ≡ nb +let ps = p′|p′:Prices • p′ ∈ dom bos ∧ p′ < p in accumulate(bbs,ps)(0) end

The TSE Itayose “Algorithm” 765

436. The TSE practices the so-called Itayose “algorithm” to decide on opening and closing prices9.That is, the Itayose “algorithm” determines a single so-called ‘execution’ price, one thatmatches sell and buy orders10:

437. The “matching sell and buy orders” rules:(a) All market orders must be ‘executed’11.(b) All limit orders to sell/buy at prices higher/lower12than the ‘execution price’13must be exe-

cuted.(c) The following amount of limit orders to sell or buy at the execution prices must be executed:

the entire amount of either all sell or all buy orders, and at least one ‘trading unit’14from‘the opposite side of the order book’15.

• The 28 January 2010 version had lines⋄⋄ 437c′

∃name some priced buys, should have been, as now, some priced sells and

⋄⋄ 437c′′∀

name all priced buys, should have been, as now, all priced sells.• My current understanding of and assumptions about the TSE is

⋄⋄ that each buy bid or sell order concerns a number, n, of one or more of the same kind ofstocks (i.e. sid).

⋄⋄ that each buy bid or sell order when being accepted by the TSE is assigned a unique ordernumber on, and

⋄⋄ that this is reflected in some Sell Orders or Market Bids entry being augmented.16

• For current (Monday 22 Feb., 2010) lack of a better abstraction17, I have structured the Itayose“Algorithm” as follows:⋄⋄ (437′) either a match can be made based on

all buys and some sells,

9 [99, pp 59, col. 1, lines 4-3 from bottom]10 [99, pp 59, col. 2, lines 1–3 and Items 1.–3. after yellow, four line ‘insert’] These items 1.–3. are repro-

duced as “our” Items 437a–437c.11 To execute an order: ?????12 Yes, it should be: “higher/lower”13 Execution price: ?????14 Trading unit: ?????15 The opposite side of the order book: ?????16 The present, 22.2.2010, model “lumps” all market orders. This simplification must be corrected, as for

the Sell Orders and Market Bids, the Market Offers must be modelled as are Orders.17 One that I am presently contemplating is based on another set of pre/post conditions.



⋄⋄ (437′∨) or⋄⋄ (437′′) a match can be made based on

aome buys and all sells.

value

437 match: All Stocks Order Book × Stock Id → Price-set437 match(asob,sid) as ps437 pre: sid ∈ dom asob437 post: ∀ p′:Price • p′ ∈ ps ⇒437′ all buys some sells(p′,ason,sid,ps) ∨437′∨ ∨437′′ some buys all sells(p′,ason,sid,ps)

• (437′) The all buys some sells part of the above disjunction “calculates” as follows:⋄⋄ The all buys... part includes

all the market buys all the buys properly below the stated price, and all the buys at that price.

⋄⋄ The ...some sells part includes all the market sells all the sells properly below the stated price, and some of the buys at that price.

437′ all buys some sells(p′,ason,sid,ps) ≡437′ ∃ os:On-set •

437a′ all market buys(asob(sid))437b′ + all sub limit buys(asob(sid))(p′)437c′ + all priced buys(asob(sid))(p′)437a′ = all market sells(asob(sid))437b′ + all sub limit sells(asob(sid))(p′)437c′

∃+ some priced sells(asob(sid))(p′)(os)

• (437′′) As for the above, only “versed”.

437′′ some buys all sells(p′,ason,sid,ps) ≡437′′ ∃ os:On-set •

437a′′ all market buys(asob(sid))437b′′ + all sub limit buys(asob(sid))(p′)437c′′ + some priced buys(asob(sid))(p′)(os)437a′′ = all market sells(asob(sid))437b′′ + all sub limit sells(asob(sid))(p′)437c′′

∀+ all priced sells(asob(sid))(p′) ∨

The match function calculates a set of prices for each of which a match can be made. The setmay be empty: there is no price which satisfies the match rules (cf. Items 437a–437c below). Theset may be a singleton set: there is a unique price which satisfies match rules Items 437a–437c.The set may contain more than one price: there is not a unique price which satisfies match rulesItems 437a–437c. The single (′) and the double (′′) quoted (437a–437c) group of lines, in thematch formulas above, correspond to the Itayose “algorithm”s Item 437c ‘opposite sides of theorder book’ description. The existential quantification of a set of order numbers of lines 437′ and437′′ correspond to that “algorithms” (still Item 437c) point of at least one ‘trading unit’. It maybe that the post condition predicate is only full-filled for all trading units – so be it.



value

all market buys: Stock Order Book → Amountall market buys(( ,( ,mkBuys(nb))),p) ≡ nb

all market sells: Stock Order Book → Amountall market sells(( ,(mkSells(ns), )),p) ≡ ns

all sub limit buys: Stock Order Book → Price → Amountall sub limit buys(((,bbs), ))(p) ≡ sub buy summation(bbs,p)

all sub limit sells: Stock Order Book → Price → Amountall sub limit sells((sos, ))(p) ≡ sub sell summation(sos,p)

all priced buys: Stock Order Book → Price → Amountall priced buys(( ,bbs), )(p) ≡ sum(bbs(p))

all priced sells: Stock Order Book → Price → Amountall priced sells((sos, ), )(p) ≡ sum(sos(p))

some priced buys: Stock Order Book → Price → On-set → Amountsome priced buys(( ,bbs), )(p)(os) ≡

let tbs = bbs(p) in if 6=os∧os⊆dom tbs then sum(tbs)(os) else 0 end end

some priced sells: Stock Order Book → Price → On-set → Amountsome priced sells((sos, ), )(p)(os) ≡

let tss = sos(p) in if 6=os∧os⊆dom tss then sum(tss)(os) else 0 end end

The formalisation of the Itayise “algorithm”, as well as that “algorithm” [itself], does not guaranteea match where a match “ought” be possible. The “stumbling block” seems to be the Itayose“algorithm”s Item 437c. There it says: ‘at least one trading unit’. We suggest that a match couldbe made in which some of the stocks of a candidate trading unit be matched with the remainingstocks also being traded, but now with the stock exchange being the buyer and with the stockexchange immediately “turning around” and posting those remaining stocks as a TSE markedtrading unit for sale.

438. It seems to me that the Tetsuo Tamai paper does not really handle(a) the issue of order numbers,(b) therefore also not the issue of the number of stocks to be sold or bought per order number.

439. Therefore the Tetsuo Tamai paper does not really handle(a) the situation where a match “only matches” part of a buy or a sell order.

Much more to come: essentially I have only modelled column 2, rightmost column, Page 59 of [99,Tetsuo Tamai, “TSE”]. Next to be modelled is column 1, leftmost column, Page 60 of [99]. Seethese same page numbers of the present document !

Match Executions 766

to come

Order Handling 767

to come


C

Indexes 768

C.1 Index of RSL Symbols

Arithmetics

...,-2,-1,0,1,2,..., 130ai*aj , 132ai+aj , 132ai/aj , 132ai=aj , 132ai≥aj , 132ai>aj , 132ai≤aj , 132ai<aj , 132ai 6=aj , 132ai−aj , 132

Cartesians

(e1,e2,...,en) , 133Chaos

chaos, 136, 137Clauses

... elsif ... , 142case be of pa1 → c1, ... pan → cn end ,

142if be then cc else ca end , 142

Combinators

let a:A • P(a) in c end , 141let pa = e in c end , 141

Functions

post P(args,result), 140, 141pre P(args), 140, 141f(args) as result, 140, 141f(a), 139f(args) ≡ expr, 140

Imperative

case be of pa1 → c1, ... pan → cn end ,143

do stmt until be end , 143for e in listexpr • P(b) do stm(e) end , 143if be then cc else ca end , 143

skip , 143variable v:Type := expression , 143while be do stm end , 143f(), 142stm1;stm2;...;stmn; , 143v := expression , 143

Lists

<Q(l(i))|i in<1..lenl> •P(a)> , 134hAB, 133ℓ(i) , 136〈ei ..ej 〉, 133〈e1, e2, ..., enB , 133elems ℓ , 136hd ℓ , 136inds ℓ , 136len ℓ , 136tl ℓ , 136

Logics

bi ∨ bj , 132∀ a:A • P(a) , 132∃! a:A • P(a) , 132∃ a:A • P(a) , 132∼ b , 132false, 130, 132true, 130, 132ai=aj , 132ai≥aj , 132ai>aj , 132ai≤aj , 132ai<aj , 132ai 6=aj , 132bi ⇒ bj , 132bi ∧ bj , 132

Maps

[F(e)7→G(m(e))|e:E•e∈dom m∧P(e)] , 134[ ] , 134

172 C Indexes

[u1 7→v1,u2 7→v2,...,un 7→vn] , 134mi \ mj , 138mi mj , 138mi / mj , 138domm , 138rng m , 138mi = mj , 138mi ∪mj , 138mi † mj , 138mi 6= mj , 138m(e) , 138

Processes

channel c:T , 143channel k[i]:T•i:KIdx , 143c ! e , 144c ? , 144k[i] ! e , 144k[i] ? , 144P⌈⌉Q, 143P–‖ Q, 143P:Unit→ in cout k[i] Unit , 144P[]Q, 143P‖ Q, 143Q: i:KIdx →out c ink[i] Unit, 144

Sets

Q(a)|a:A•a∈s∧P(a) , 133 , 133e1, e2, ..., en , 133∩s1,s2,...,sn , 134∪s1,s2,...,sn , 134card s , 135e∈s , 134

e 6∈s , 134si=sj , 135si∩sj , 134si∪sj , 134si⊂sj , 134si⊆sj , 135si 6=sj , 135si\sj , 134

Types

Bool, 129Char, 129Int, 129Nat, 129Real, 129Text, 129Unit, 142, 144(T1×T2×... ×Tn), 130T∗, 129Tω, 129T1 × T2 × ... × Tn, 129mk id(s1:T1,s2:T2,...,sn:Tn), 130s1:T1 s2:T2 ... sn:Tn, 130T = Type Expr, 131T1 | T2 | ... | T1 | Tn , 130T=| v:T′• P(v)| , 131T==TE1 | TE2 | ... | TEn , 131T-infset, 129T-set, 129Ti →m Tj, 130Ti

∼→Tj, 130

Ti→Tj, 130

C.2 Index of Endurant Analysis Prompts



C.3 Index of Attribute Analysis Prompts

A. is discrete attribute, 39

B. is continuous attribute, 39

C. is static attribute, 39

D. is dynamic attribute, 39

E. is inert attribute, 39

F. is reactive attribute, 39


C.4 Index of Domain Description Prompts 173

G. is active attribute, 39

H. is autonomous attribute, 39

I. is biddable attribute, 39

J. is programmable attribute, 39

C.4 Index of Domain Description Prompts



C.5 Index of Some Domain Description Operators

a. obs P, 30b. is P, 30c. obs T, 31d. uid P, 35e. attr A, 37

f. obs attribs, 37g. upd attr, 42h. mereo P, 43i. upd mereology, 45j. obs M, 46

C.6 Index of Definitions

A ‘Development Phase’ Concept, 95A ‘Development Stage’ Concept, 95A ‘Development Step’ Concept, 95abstract

type, 29active

attribute, 39Actor, 58actor, 58Atomic

part, 28Atomic Part, 28autonomous

attribute, 39

biddableattribute, 39

Checking, 4checking, 4Composite

part, 28Composite Part, 28concrete

type, 29confusion, 49continuous

attribute, 39

behaviour, 60endurant, 27

derived, 32description

treepath, 76

trees, 76Determination, 106discrete

action, 58attribute, 39behaviour, 59endurant, 27

Discrete Action, 58Discrete Behaviour, 59Discrete Endurant, 28Domain, 3domain, 3

analysis, 4prompt, 26–29, 31, 37, 43, 46, 52, 57

description, 4prompt, 31, 35, 37, 43, 46, 52, 57

determination, 106engineering, 3extension, 107facet, 81information


174 C Indexes

analysis, 4gathering, 4

instantiation, 104intrinsics, 82projection, 103requirements

prescription, 103stake-holder, 4, 81

Domain [Requirements] Stake-holder, 4Domain Analysis, 4Domain Engineering, 3Domain Information Gathering, 4Domain Management, 86Domain Organisation, 86Domain Projection, 103Domain Regulation, 88Domain Rules, 88Domain Script, 90duplicate

node, 74dynamic

attribute, 39

Endurant, 27endurant, 3, 27endurants, 25entities, 3Entity, 26entity, 26Event, 58event, 58event, 16extent, 26external

endurantquality, 34

Facet, 81formal

concept, 26context, 25

functionsignature, 61type

expression, 61Function Signature, 61Function Type Expression, 61

Human Behaviour, 92

inertattribute, 39

Instantiation, 104intent, 26

internalendurant

quality, 34Intrinsics, 82

junk, 49

Machine, 101Material, 27material, 27, 28, 45mereology, 7, 42

type, 43

ontological engineering, 52

part, 27, 28qualities, 34

Parts, 27Perdurant, 27perdurant, 3, 27perdurants, 25phase, 95phenomenon, 26prerequisite

prompthas concrete type, 31has mereology, 44has unique identifier, 35is composite, 30is discrete, 28is entity, 26, 27observe part type, 31

programmableattribute, 39

pumphead, 60

reactiveattribute, 39

Requirements, 5requirements, 5, 99, 101

engineering, 5stake-holder, 4

Requirements (I), 99Requirements (II), 101Requirements (III), 101Requirements Engineering, 5Requirements Prescription, 103

semanticqualities, 34

share, 40shared

attribute, 40societal


C.7 Index of Concepts 175

infrastructure, 3software

design, 5Software Design, 5sort, 29stage, 95stake-holder, 81State, 57state, 57State-holder, 81static

attribute, 39step, 95

sub-part, 28Support technology, 84syntactic

qualities, 34

Testing, 4testing, 4type, 29

Validation, 4validation, 4Verification, 4verification, 4

C.7 Index of Concepts

abstractvalue, 35

abstraction, 26action, 57algorithmic

engineering, 53analysis

domain, 26, 53–55problem

world, 54product line, 53world

problem, 54architecture

software, 54

basesknowledge, 52

behaviour, 57

classdiagram, 55

componentreusable

software, 54software, 54, 55

reusable, 54composite, 5conceive, 26concept

formal, 26confusion, 49context, 26continuous

endurant, 27time, 60

criminal human behaviour, 92

defined, 77delinquent human behaviour, 92description

developmentdomain, 54

domain, 53–55development, 54

descriptionsdomain, 55

designsoftware, 54, 55

development, 95description

domain, 54domain

description, 54model-oriented

software, 54phase, 95requirements, 55software

model-oriented, 54stage, 95

diagramclass, 55

diligent human behaviour, 92discrete

endurant, 27, 28domain, 55

[endurant]analysis prompts, 67description prompts, 67

analysis, 26, 53–55description, 53–55


176 C Indexes

development, 54descriptions, 55development

description, 54engineer, 54engineering, 54facet, 81language

specific, 53, 54modelling, 48, 53, 54software

specific, 55specific

language, 53, 54software, 55

stake-holders, 3duplicate, 75

endurantdiscrete, 28

engineerdomain, 54requirements, 54software, 54

engineeringalgorithmic, 53domain, 54knowledge, 52ontological, 53product line

software, 54requirements, 54software

product line, 54event, 16, 57

formalconcept, 26

formal concept analysis, 26frame

problem, 54frames

problem, 54function

name, 61type

constructor, 61expression, 61

golden rule of requirements, 100

hardware, 54head, 60human behaviour

criminal, 92delinquent, 92diligent, 92sloppy, 92

ideal rule of requirements, 100imperative

languageprogramming, 53

programminglanguage, 53

intervaltime, 16, 58

joinlattice, 34

junk, 49

knowledgebases, 52engineering, 52, 53representation, 53

languagedomain

specific, 53, 54imperative

programming, 53programming

imperative, 53specific

domain, 53, 54lattice

join, 34

machine, 54=hardware+software, 101

machine=hardware+software, 101mereology

observer, 43type, 43

model-orienteddevelopment

software, 54software

development, 54modelling

domain, 48, 53, 54requirements, 48

observe, 26ontological

engineering, 53ontology

upper, 52, 53


C.7 Index of Concepts 177

part, 28sort, 29

phase, 95prescription

requirements, 54, 55problem

analysisworld, 54

frame, 54frames, 54world, 54

analysis, 54process

schema, 56product line

analysis, 53engineering

software, 54software, 54

engineering, 54programming

imperativelanguage, 53

languageimperative, 53

proofobligation, 49

redefined, 77representation

knowledge, 53requirements, 54, 55

development, 55engineer, 54engineering, 54modelling, 48prescription, 54, 55stake-holders, 5

requirements, golden rule, 100requirements, ideal rule, 100reusable

componentsoftware, 54

softwarecomponent, 54

reuse, 54

sharing, 35sloppy human behaviour, 92software, 54

architecture, 54component, 54, 55

reusable, 54design, 54, 55development

model-oriented, 54domain

specific, 55engineer, 54engineering

product line, 54model-oriented

development, 54product line, 54

engineering, 54reusable

component, 54specific

domain, 55sort, 26

well-formednessaxiom, 49

specificdomain

language, 53, 54software, 55

languagedomain, 53, 54

softwaredomain, 55

stake-holder, 81state, 57

change, 60sub-part, 28

time, 16, 57, 58interval, 16, 58

TripTych, 26, 52–55type, 26

expression, 61

Unified Modelling LanguageUML, 55

uniqueidentifier, 35

upperontology, 52, 53

worldanalysis

problem, 54problem, 54

analysis, 54
