Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
1.2 An Example: Road Transport 23
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 7
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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, ...
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 9
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,
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 11
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 13
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 15
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
1.2 An Example: Road Transport 19
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 27
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 .
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 29
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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. .
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 31
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 33
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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′.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 35
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 ?
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 37
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 39
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 41
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′
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 43
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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),
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 45
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 47
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 49
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.3 Endurant Entities 51
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.4 Comparison to Other Work 53
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
2.4 Comparison to Other Work 55
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
3.8 Perdurant Signatures and Definitions 61
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
3.8 Perdurant Signatures and Definitions 63
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.2 A Model of The Analysis & Description Process 69
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 δ.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
70 4 Models of Domain Anaysis
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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.2 A Model of The Analysis & Description Process 71
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
72 4 Models of Domain Anaysis
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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.2 A Model of The Analysis & Description Process 73
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
74 4 Models of Domain Anaysis
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.3 A Model of The Analysis & Description Prompts 75
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
76 4 Models of Domain Anaysis
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.3 A Model of The Analysis & Description Prompts 77
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
78 4 Models of Domain Anaysis
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 ...
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
4.3 A Model of The Analysis & Description Prompts 79
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
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
Description Prompts 393
1. observe part sorts, 292. observe part type, 313. observe unique identifier, 35
4. observe attributes, 375. observe mereology, 436. observe material sorts, 46
• • •
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
80 4 Models of Domain Anaysis
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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...
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 83
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 85
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 87
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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:
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 89
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 91
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
5.2 Domain Facets 93
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
102 7 From Domains to Requirements
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
7.5 Domain Requirements Prescription 551
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
104 7 From Domains to Requirements
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 .
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
7.5 Domain Requirements Prescription 105
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),
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
106 7 From Domains to Requirements
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
7.5 Domain Requirements Prescription 107
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 .
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
108 7 From Domains to Requirements
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
7.5 Domain Requirements Prescription 109
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
110 7 From Domains to Requirements
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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
7.5 Domain Requirements Prescription 111
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
112 7 From Domains to Requirements
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]
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
7.5 Domain Requirements Prescription 113
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
114 7 From Domains to Requirements
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
116 7 From Domains to Requirements
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 131
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
132 A Abstraction & Modelling – using RAISE
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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 133
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
134 A Abstraction & Modelling – using RAISE
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 135
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′′
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
136 A Abstraction & Modelling – using RAISE
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 137
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′′)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
138 A Abstraction & Modelling – using RAISE
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 139
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;
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
140 A Abstraction & Modelling – using RAISE
• 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)
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 141
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
142 A Abstraction & Modelling – using RAISE
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
A.1 RSL: The Raise Specification Language 143
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
144 A Abstraction & Modelling – using RAISE
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]
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.1 A Model of Pipeline Endurants 147
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 = 〈〉 ∪
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
148 B Domain Examples
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.1 A Model of Pipeline Endurants 149
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
150 B Domain Examples
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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 A Model of Platoons & Platooning 718
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
152 B Domain Examples
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.2 A Model of Platoons & Platooning 153
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,
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
154 B Domain Examples
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.2 A Model of Platoons & Platooning 155
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
156 B Domain Examples
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 !
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
B.3 A Model of Railway Nets 740
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)
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
158 B Domain Examples
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.3 A Model of Railway Nets 159
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
160 B Domain Examples
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 ∧
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.3 A Model of Railway Nets 161
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 •
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
162 B Domain Examples
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),
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.3 A Model of Railway Nets 163
/∗ 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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
164 B Domain Examples
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
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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′)
B.4 A Model of TSE Stock Exchanges 758
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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
166 B Domain Examples
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 !
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.4 A Model of TSE Stock Exchanges 167
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
168 B Domain Examples
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.
c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
B.4 A Model of TSE Stock Exchanges 169
⋄⋄ (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.
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
170 B Domain Examples
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© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
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
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© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
1. observe part sorts, 292. observe part type, 313. observe unique identifier, 35
4. observe attributes, 375. observe mereology, 436. observe material sorts, 46
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark
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© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark From Domains to Requirements August 12, 2013, 08:17
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
August 12, 2013, 08:17, A Gentle Introduction to Domain Engineering c© Dines Bjørner 2010, Fredsvej 11, DK–2840 Holte, Denmark