invisible

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek0/dek0-1The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 1. Slide: 1 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 1. Slide: 2 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1Lecture 1: The Triptych Paradigms: DevelopmentPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.1 Lecture: 1. Slide: 3 of 894/home/db/de/dek0/dek0-1The Triptych Paradigms• We put forward the triptych dogma.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• Overview the (three) triptych phases of software development,• and their stages and steps of development.• Then we overview the kind of documents⋆ being the target of⋆ and emanating fromthe three phases.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1 Lecture: 1. Slide: 4 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• These are/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]⋆ the domain engineering,⋆ the requirements engineering and⋆ the software designphases, namely respectively⋆ informative,⋆ descriptive / prescriptive / specificational and⋆ analyticdocuments.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 1, Subsect. 1 Lecture: 1. Slide: 5 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]The Domain ParadigmWhat is a Domain? – An Attempt at a DefinitionCharacterisation 1 (Domain) By a domain we shall understand.• a universe of discourse, small or large,• a structure⋆ of entities, that is, of “things”, individuals, particulars⋄ some of which are designated as state components;⋆ of functions, say over entities,⋄ which when applied become possibly state-changing actions of the domain;⋆ of events,⋄ possibly involving entities,⋄ occurring in time and⋄ expressible as predicates over single or pairs of (before/after) states; and⋆ of behaviours,⋄ sets of possibly interrelated sequences of actions and eventsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 1, Subsect. 2 Lecture: 1. Slide: 6 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Domain Paradigm ]Examples of Domains• We give some examples of domains.⋆ (i) A country’s railways form a domain⋄ of the rail net with its rails, switches, signals, etc.;⋄ of the trains travelling on the net, forming the train traffic;⋄ of the potential and actual passengers, inquiring about traintravels, booking tickets, actually travelling, etc.;⋄ of the railway staff: management, schedulers, train drivers,cabin tower staff, etc.;⋄ and so forth.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 1, Subsect. 2 Lecture: 1. Slide: 7 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Domain Paradigm, Examples of Domains ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1⋆ (ii) Banks, insurance companies, stock brokers, traders and stockexchanges, the credit card companies, etc., form the financialservices industry domain.⋆ (iii) consumers, retailers, wholesalers, producers and the supplychain form “the market” domain.⋆ There are many domains⋄ and the above have only exemplified “human made” domains,⋄ not, for example, those of the natural sciences⋆ We shall have more to say about this later.• Essentially it is for domains like the ‘human made’ domains thatthese lectures will show you how to professionally develop the rightsoftware and where that software is right !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2 Lecture: 1. Slide: 8 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]The Development Paradigm• Before software can be designed• one must understand its requirements.• Before requirements can be expressed• one must understand the application domain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 1 Lecture: 1. Slide: 9 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Triptych Development Paradigm ]The Triptych Phases of Software DevelopmentThe Three Phases• As a consequence of the “dogma”• we view software development as ideally progressing in threephases:⋆ In the first phase, ‘Domain Engineering’, a model is built of theapplication domain.⋆ In the second phase, ‘Requirements Engineering’, a model is builtof what the software should do (but not how it should that).⋆ In the third phase, ‘Software Design’, the code that is subject toexecutions on computers is designed.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 2 Lecture: 1. Slide: 10 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Triptych Development Paradigm, The Triptych Phases of Software Development ]Attempts at DefinitionsCharacterisation 2 (Domain Engineering) By domain engineering weshall understand.• the processes of constructing a domain model,• that is, a model, a description, of the chosen domain,• as it is, “out there”, in some reality,• with no reference to requirements, let alone softwareCharacterisation 3 (Requirements Engineering) By requirementsengineering we shall understand.• the processes of constructing a requirements model,• that is, a model, a prescription, of the chosen requirements,• as we would like them to bePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 2 Lecture: 1. Slide: 11 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Development Paradigm, The Triptych Phases of Software Development, Attempts at Definitions ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 4 (Software Design) By software design we shallunderstand.invisible/home/db/de/dek0/dek0-1• the processes of constructing software,• from high level, abstract (architectural) designs,• via intermediate abstraction level component and module designs,• to concrete level, “executable” codeCharacterisation 5 (Model) By a model we shall understand.• a mathematical structure whose properties• are those described, prescribed or design specified by⋆ a domain description,⋆ a requirements prescription, respectively⋆ a software design specificationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 3 Lecture: 1. Slide: 12 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Development Paradigm, The Triptych Phases of Software Development ]Comments on The Three Phases• The three phases are linked:⋆ the requirements prescription is “derived” from the domaindescription, and⋆ the software design is derived from the requirements prescription• in such a way that we obtain a maximum trust in the software:⋆ that it meets customer expectations: that is, it is the rightsoftware, and⋆ that it is correct with respect to requirements: that is, thesoftware is right.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 3 Lecture: 1. Slide: 13 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Development Paradigm, The Triptych Phases of Software Development, Comments on The Three Phases ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 6 (Phase of Software Development) •By a phase of development we shall understand⋆ a set of development stages⋆ which together accomplish⋆ one of the three major development objectives:⋄ a(n analysed, validated, verified) domain model,⋄ a(n analysed, validated, verified) requirements model, or⋄ a (verified) software design.These three “tasks”: a domain model, a requirements model, and asoftware design will be defined below.invisible/home/db/de/dek0/dek0-1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 1, Subsubsect. 3 Lecture: 1. Slide: 14 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Development Paradigm, The Triptych Phases of Software Development, Comments on The Three Phases ]Characterisation 7 (Software Development) • Collectivelythe three phases are included• when we say ‘software development’.invisible• We make distinctions between/home/db/de/dek0/dek0-1⋆ phases of development (i.e., the domain engineering, therequirements engineering and the software design phases),⋆ stages of development — within a phase, and⋆ steps of development — within a stage.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 2 Lecture: 1. Slide: 15 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Development Paradigm ]The Triptych Stages of DevelopmentCharacterisation 8 (Stage of Software Development) • Bya stage of development we mean.⋆ a major set of logically strongly related development steps⋆ which together solves a clearly defined development task• We shall later define the stages of the major phases,• and we shall then be rather loose as to what constitutes adevelopment step.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 2, Subsect. 3 Lecture: 1. Slide: 16 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Development Paradigm ]The Triptych Steps of DevelopmentCharacterisation 9 (Step of Software Development) • Bya step of development we mean.⋆ iterations of development within a stage⋆ such that the purpose of the iteration is⋄ to improve the precision or⋄ make the document resulting from the step reflect a moreconcrete description, prescription or specificationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3 Lecture: 1. Slide: 17 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]The Document Paradigm• All we do, really, as software developers, can be seen as a longsequence of⋆ documenting, i.e., producing, writing, documents⋆ alternating with⋆ thinking and reasoning about and presenting and discussingthese documents to and with other people:⋄ customers, clients and⋄ colleagues.⋆ Among the last documents to be developed in this series arethose of the executable code.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3 Lecture: 1. Slide: 18 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm ]• In this section we shall take a look at the kind of documents⋆ that should result from the various phases, stages and steps ofdevelopment,⋆ and for whose writing, i.e., as “input”, aside from otherdocuments, we do all the thinking, reasoning, and discussing.• For any of the three phases of development, one can distinguishthree classes of documents:⋆ Informative Documents (Slide 19)⋆ Modelling Documents (Slide 21)⋆ Analysis Documents (Slide 26)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 1 Lecture: 1. Slide: 19 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm ]Informative Documents• An informative document ‘informs’.• An informative document is expressed in some national language.• Informative documents serve as a link between developers. clientsand possible external funding agencies:⋆ “What is the project name ?” Item 1⋆ “When is the project carried out ?” Item 1⋆ “Who are the project partners ?” Item 2⋆ “Where is the project being done ?” Item 2⋆ “Why is the project being pursued ?”⋆ “What is the project all about ?”Items 3(a)–3(b)Items 3(b)–3(g)⋆ “How is the project being pursued ?” Items 4–6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 1 Lecture: 1. Slide: 20 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Informative Documents ]• And many other such practicalities.• Legal contracts can be seen as part of the informative documents.• We shall list the various kinds of informative documents that aretypical for domain and for requirements engineering.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 2 Lecture: 1. Slide: 21 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm ]Modelling Documents• Documents which describe, prescribe or specify something,• such document are intended to model those things.• They, the document, are not those things,• just conceptualisations, i.e., models of them.• In this book we shall only seriously cover• the modelling of domains and of requirements.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 2, Subsubsect. 1 Lecture: 1. Slide: 22 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Modelling Documents ]Domain Modelling Documents• Domain descriptions are documents.• They are usually rather substantial.• They usually include the following kinds of documents:1. stakeholder identification and liaison records,2. domain acquisition sketches,3. domain business process rough sketches,4. domain terminologies,5. and domain models properPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 2, Subsubsect. 1 Lecture: 1. Slide: 23 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Modelling Documents, Domain Modelling Documents ]• We shall cover the domain engineering phase with its⋆ (i) stakeholder identification,⋆ (ii) domain acquisition,⋆ (iii) domain analysis and concept formation,⋆ (iv) business process rough sketching,⋆ (v) terminology,⋆ (vi) domain modelling,⋆ (vii) domain model verification,⋆ (viii) domain model validation,⋆ and (ix) domain theory formationstages.• Documents emerge from each of these stages.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 2, Subsubsect. 2 Lecture: 1. Slide: 24 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Modelling Documents ]Requirements Modelling Documents• Requirements prescriptions are documents.• They are usually rather substantial.• They usually include the following kinds of documents:1. stakeholder identification and liaison records,2. acquisition sketches,3. business process re-engineering rough sketches,4. terminologies, and5. requirements models proper.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 2, Subsubsect. 2 Lecture: 1. Slide: 25 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Modelling Documents, Requirements Modelling Documents ]• We shall later covers the requirements engineering phase with its⋆ (i) stakeholder identification,⋆ (ii) requirements acquisition,⋆ (iii) requirements analysis and concept formation,⋆ (iv) business process re-engineering rough sketching,⋆ (v) terminology,⋆ (vi) requirements modelling,⋆ (vii) requirements model verification,⋆ (viii) requirements model validation,⋆ (ix) requirements feasibility and satisfiability analysis,⋆ and (x) requirements theory formation.stages.• Documents emerge from each of these stages.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 3, Subsubsect. 1 Lecture: 1. Slide: 26 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm ]Analysis DocumentsVerification, Model Checks and TestsCharacterisation 10 (Analysis) By analysis.• we mean a process which results in a document• and which analyses another document:⋆ a domain description,⋆ a requirements prescription, or⋆ a software design,and where the analysis is either⋆ a verification, or⋆ a model check, or⋆ a formal (or even informal) testPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 3, Subsubsect. 2 Lecture: 1. Slide: 27 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Analysis Documents ]Concept Formation• Yet there is also another form of analysis.• One that results in the analysing engineer forming a concept.Characterisation 11 (Concept Formation) By conceptformation.• we mean an analysis process• in which the analysing engineer• from analysed phenomena or analysed concrete concepts• form a concept, respectively a “more” abstract, i.e., less concreteconceptPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 3, Subsubsect. 3 Lecture: 1. Slide: 28 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Analysis Documents ]Domain Analysis Documents• Stages (iii, vii, viii, ix) listed on Slide 23 are analytic.• They result in the following kinds of documents:1. domain analysis (and concept formation)2. domain model verification,3. domain model validation,4. and domain theory formation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 3, Subsect. 3, Subsubsect. 4 Lecture: 1. Slide: 29 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Document Paradigm, Analysis Documents ]Requirements Analysis Documents• Stages (iii, vii, viii, ix, x) listed on Slide 25 are analytic.• They result in the following kinds of documents:1. requirements analysis (and concept formation),2. requirements model verification,3. requirements model validation,4. requirements feasibility and satisfiability,5. and requirements theory formation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 1 Lecture: 1. Slide: 30 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]The Description, Prescription, Specification ParadigmCharacterisations• We have, so far, used the terms descriptions, prescriptions andspecifications — and we shall continue to use these terms — withthe following meanings.⋆ (A) Descriptions are of “what there is”, that is, descriptions are,in this book, of domains, “as they are”;⋆ (B) Prescriptions are of “what we would like there to be”, thatis, prescriptions are, in this book, of requirements to software;and⋆ (C) Specifications are of “how it is going to be”, that is,specifications are, in this book, of software.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 2 Lecture: 1. Slide: 31 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm ]Reiteration of Differences• Descriptions are intended to state objective facts, i.e., areindicative.• Prescriptions are intended to state commonly supposed andassumed to exist facts, i.e., are putative which we here take to bethe same as optative: expressive of wish or desire.• Specifications are intended to be expressive of a command, not tobe avoided or evaded, i.e., are imperative.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 2 Lecture: 1. Slide: 32 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Reiteration of Differences ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Descriptions are intended to state objective facts, i.e., areindicative.• Prescriptions are intended to state commonly supposed andassumed to exist facts, i.e., are putative which we here take to bethe same as optative: expressive of wish or desire.• Specifications are intended to be expressive of a command, not tobe avoided or evaded, i.e., are imperative./home/db/de/dek0/dek0-1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 2 Lecture: 1. Slide: 33 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Reiteration of Differences ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1• (i) Software shall satisfy requirements.• (ii) Requirements defines properties of software.• (iii) Requirements must be commensurate with “their domain”;⋆ that is, requirements must satisfy all the properties of the domain⋆ insofar as these have not been re-engineered.• (iv) Requirements prescriptions denote requirements models.• (v) Requirements models are not the software, only abstractions of software.• (vi) Requirements models are computable adaptations of subsets of domainmodels.• (vii) Domains satisfy a number of laws.• (viii) Domain laws should be expressed by or derivable from domain descriptions.• (ix) Domain descriptions denote domain models.• (x) Domain models are not the domain, only abstractions of domains.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3 Lecture: 1. Slide: 34 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm ]Rôle of Domain Descriptions• Domain descriptions for common computing system (colloquially:IT) applications⋆ relate to requirements prescriptions and software specifications(incl. code)⋆ as physics relate to classical engineering artifacts:⋄ (a) electricity, plasma physics, etc., relate to electronics;⋄ (b) mechanics, aerodynamics, etc., relate to aeronauticalengineering;⋄ (c) nuclear physics, thermodynamics, etc., relate to nuclearengineering;⋄ etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3 Lecture: 1. Slide: 35 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Rôle of Domain Descriptions ]⋆ Domain engineering relate to IT applications as follows:⋄ (d) transport domains to software (engineering) for road, rail,shipping and air traffic applications;⋄ (e) financial service industry domains to software (engineering)for banking, stock trading; portfolio management, insurance,credit card, etc., applications;⋄ (f) market trading (“the market”) domains to software(engineering) for consumer, retailer, wholesaler, supply chain,etc., applications (aka “e-business”);⋄ etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3, Subsubsect. 1, § 1 Lecture: 1. Slide: 36 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Rôle of Domain Descriptions ]The Sciences of Human and Natural Domains• The ‘Human Domains’ •• The domains for which most software systems are at play are —what we shall call — the human domains of⋆ financial service industries⋄ banks,⋄ insurance companies,⋄ stock (etc.) trading◦ brokers,◦ traders,◦ exchanges,◦ etcetera;⋆ transportation industries⋄ roads,⋄ rails,⋄ shipping and⋄ air traffic;⋆ “the market” of⋄ consumers,⋄ retailers,⋄ wholesalers,⋄ product originators, and⋄ their distribution chains;⋆ etcetera,Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3, Subsubsect. 1, § 2 Lecture: 1. Slide: 37 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ Rôle of Domain Descriptions, The Sciences of Human and Natural Domains ]• The Natural Sciences •In contrast the natural sciences includes• physics:⋆ classical mechanics:⋄ statics, kinematics, dynamics,⋄ continuum mechanics: solidmechanics and fluid mechanics,⋄ mechanics of liquids and gases:hydrostatics, hydrodynamics,pneumatics, aerodynamics, andother fields;⋄ electromagnetism,⋄ relativity,⋄ thermodynamics and statisticalmechanics,⋄ quantum mechanics,⋄ etceteraPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3, Subsubsect. 1, § 2 Lecture: 1. Slide: 38 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, Descriptions, Prescriptions, Specifications, Rôle of Domain Descriptions, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Sciences of Human and Natural Domains, The Natural Sciences ]• The above listing is of disciplines within the natural sciences.• It is not to be confused with a listing of research areas such as:⋆ condensed matter physics,⋆ atomic, molecular, and opticalphysics,⋆ high energy/particle physics,⋆ astrophysics and physical cosmology,etc.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3, Subsubsect. 1, § 3 Lecture: 1. Slide: 39 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ Rôle of Domain Descriptions, The Sciences of Human and Natural Domains ]• Research Areas of the Human Domains •• To establish a domain description⋆ for an area within the human domain —⋆ for which there was no prior domain description —⋆ is a research undertaking• — just as it is for establishing a domain description⋆ for an area within the domain of natural sciences.• There are thus as many⋆ human domain research areas⋆ as there are reasonably clearly separable⋆ such areas within the human domain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 3, Subsubsect. 1, § 4 Lecture: 1. Slide: 40 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ Rôle of Domain Descriptions, The Sciences of Human and Natural Domains ]• Rôle of Domain Descriptions — Summarised •• That then is the rôle of domain descriptions⋆ to gain understanding, through research,⋆ and, independently,⋆ to obtain the right software:⋄ software that meet client expectations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 4, Subsubsect. 2 Lecture: 1. Slide: 41 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm ]Rôle of Requirements Prescriptions• A main rôle of a requirements prescription• is to prescribe “the machine” !The MachineCharacterisation 12 (Machine) By ‘the machine’ we shall mean• a combination of hardware and software.Machine Properties• The purpose of developing a requirements prescription• is to prescribe properties of a machine.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 5 Lecture: 1. Slide: 42 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm ]Rough SketchesCharacterisation 13 (Rough Sketch) By a rough sketch wemean.• an informal text• which does not claim to be consistent or complete,• and which attempts, perhaps in an unstructured manner,• to outline a phenomenon or a concept• Rough sketches are useful “starters” towards narratives,• and are used in acquired domain or requirements knowledge, and• in outlining business processes and re-engineered such.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 6 Lecture: 1. Slide: 43 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, Descriptions, Prescriptions, Specifications ]NarrativesCharacterisation 14 (Narrative) • By a narrative we mean.⋆ an informal text⋆ which is structured,⋆ which is claimed consistent and relative complete,⋆ and which informally defines a phenomenon or a conceptPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 6 Lecture: 1. Slide: 44 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Narratives ]• Narratives will be our main “work horse”, our chief means,• at communicating⋆ domain descriptions and⋆ requirements prescriptionsto all stakeholders.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 7 Lecture: 1. Slide: 45 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, Descriptions, Prescriptions, Specifications ]AnnotationsCharacterisation 15 (Annotation) By an annotation we mean• an informal text• which is structured• so as to follow, usually line-by-line• a formal (mathematical) text• which it aims at explaining to a lay reader• not familiar with the mathematical formulas.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 4, Subsect. 7 Lecture: 1. Slide: 46 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Description, Prescription, Specification Paradigm, Annotations ]• We usually mandate that⋆ all formulas⋆ be annotated.• But we do not mandate⋆ a specific “formal” way⋆ of structuring the annotations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 1 Lecture: 1. Slide: 47 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]The Software ParadigmWhat is Software ?Characterisation 16 (Software) By software we understand:.• a set of documents:⋆ the domain development (incl. verification and validation)documents,⋆ the requirements development (incl. verification and validation)documents, and⋆ the software design development (incl. verification) documentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 2, Subsubsect. 1 Lecture: 1. Slide: 48 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Software Paradigm ]Software is Documents !Domain Documents• The domain development documents include⋆ the informative documents and⋆ the documents which record⋄ stakeholder identification and relations,⋄ domain acquisition,⋄ domain analysis and concept formation,⋄ rough sketches of the business (i.e., domain) processes,⋄ terminologies,⋄ domain description,⋄ domain verification (incl. model check and test),⋄ domain validation and⋄ domain theory formation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 2, Subsubsect. 2 Lecture: 1. Slide: 49 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Software Paradigm, Software is Documents ! ]Requirements Documents• The requirements development documents include⋆ the informative documents and⋆ the documents which record⋄ stakeholder identification and relations,⋄ requirements acquisition,⋄ requirements analysis and concept formation,⋄ rough sketches of the re-engineered business (i.e., new, revised domain)processes,⋄ terminologies,⋄ requirements description,⋄ requirements verification (incl. model check and test),⋄ requirements validation and⋄ requirements theory formation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 2, Subsubsect. 3 Lecture: 1. Slide: 50 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Software Paradigm, Software is Documents ! ]Software Design Documents• And the software design development documents include⋆ the informative documents,⋆ the documents which record⋄ architectural designs (“how derived from requirements”) and verifications(incl. model checks and tests),⋄ component designs and verifications (incl. model checks and tests),⋄ module designs and verifications (incl. model checks and tests),⋄ code designs and verifications (incl. model checks and tests), and⋆ the actual executable code documents.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 2, Subsubsect. 4 Lecture: 1. Slide: 51 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Software Paradigm, Software is Documents ! ]Software System DocumentsCharacterisation 17 (Software System) By a software[-based]system we shall understand.• a set of software system documents (see below)• as well as the hardware, the IT equipment for which the software isoriented:⋆ computers,⋆ their peripherals,⋆ data communication equipments,⋆ etceteraPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 5, Subsect. 2, Subsubsect. 4 Lecture: 1. Slide: 52 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, The Software Paradigm, Software is Documents !, Software System Documents ]• The software system documents include:⋆ the actual executable code documents, as well as⋆ ancillary documents:⋄ demonstration (i.e., demo) manuals,⋄ training manuals,⋄ installation manuals,⋄ user manuals,⋄ maintenance manuals, and⋄ development and maintenance logbooks.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 1 Lecture: 1. Slide: 53 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms ]Informal and Formal Software DevelopmentCharacterisationsInformal DevelopmentCharacterisation 18 (Informal Development) By informaldevelopment we understand, in this book, a software developmentwhich.• does not use formal techniques, see below;• instead it may use⋆ UML and⋆ an executable programming languagePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 2 Lecture: 1. Slide: 54 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, Informal and Formal Software Development, Characterisations ]Formal DevelopmentCharacterisation 19 (Formal Development) By formaldevelopment we mean, in this book, a software development which.• uses one or more formal techniques, see below,• and it may then use these in a spectrum from⋆ systematically via⋆ rigorously to⋆ formallyPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 3, § 1 Lecture: 1. Slide: 55 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1[ The Triptych Paradigms, Informal and Formal Software Development, Characterisations ]A Spectrum of Developments• Formal Software Development •Characterisation 20 (Formal Software Development Technique) By a formaldevelopment technique we mean, in this book, a software development in which.• specifications are expressed in a formal language,• that is, a language with⋆ a formal syntax so that all specifications can be judged well-formed or not;⋆ a formal semantics so that all well-formed specifications have a precise meaning;⋆ and a (relatively complete) proof system such that one may be able to reason over propertiesof specifications or steps of formally specified developments from a more abstract to a moreconcrete step.• Additionally a formal technique may be a calculus which allows developers to calculate, to refine“next”, formally specified development steps from a preceding, formally specified stepPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 3, § 2 Lecture: 1. Slide: 56 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, Informal and Formal Software Development, Characterisations, A Spectrum of Developments ]• Systematic (Formal) Development ! •Characterisation 21 (Systematic (Formal) Development)By a systematic use of a formal technique we mean, in this book, asoftware development which.• which formally specifies whenever something is specified,• but which does not• (at least only at most in a minor of cases)• reason formally over steps of development/home/db/de/dek0/dek0-1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 3, § 3 Lecture: 1. Slide: 57 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, Informal and Formal Software Development, Characterisations, A Spectrum of Developments ]/home/db/de/dek0/dek0-1• Rigorous (Formal) Development ! •Characterisation 22 (Rigorous (Formal) Development) By a rigoroususe of formal techniques we mean, in this book, a software development which.• which formally specifies whenever something is specified, and• which formally express (some, if not all) properties that ought be expressed,• but which does not• (at least only at most in a minor number of cases)• reason formally over steps of development,• that is, verify these to hold,• either by theorem proving, or by model checking, or by formally based testsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 1, Subsubsect. 3, § 4 Lecture: 1. Slide: 58 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, Informal and Formal Software Development, Characterisations, A Spectrum of Developments ]• Formal (Formal) Development ! •Characterisation 23 (Formal (Formal) Development) Byformal use of a formal techniques we mean, in this book, a softwaredevelopment which.• which formally specifies whenever something is specified,• which formally expresses (most, if not all) properties that ought beexpressed,• and which formally verifies these to hold,• either by theorem proving, or by model checking, or by formallybased tests/home/db/de/dek0/dek0-1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 2 Lecture: 1. Slide: 59 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• This book advocates/home/db/de/dek0/dek0-1[ The Triptych Paradigms, Informal and Formal Development ]Recommendations⋆ that software development be pursued according to the triptychparadigm, and⋆ that the phases, stages and steps,⋄ be pursued in a combination⋄ of both informal and formal⋄ descriptions, prescriptions and specifications,⋄ in a systematic to rigorous fashion.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 6, Subsect. 2 Lecture: 1. Slide: 60 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-1End of Lecture 1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek0/dek0-2The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 2. Slide: 61 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 2. Slide: 62 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2Lecture 2: The Specification Paradigm: Simple EntitiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7 Lecture: 2. Slide: 63 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms ]The Entity, Operation, Event and Behaviour Paradigm• So what is it that we⋆ describe, ⋆ prescribe and ⋆ specify,• informally or formally ?• The answer is:⋆ simple entities,⋆ operations,⋆ events and⋆ behaviours• We shall, in this section, survey these concepts of⋆ domains, ⋆ requirements and ⋆ software designs.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7 Lecture: 2. Slide: 64 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In the domain we observe phenomena./home/db/de/dek0/dek0-2⋆ From usually repeated such observations we form (immediate, abstract) concepts.⋆ We may then “lift” such immediate abstract concepts to more general abstract concepts.• Phenomena are manifest.• They can be observed⋆ by human senses (seen, heard, felt, smelled or tasted)⋆ or by physical measuring instruments⋄ (mass,⋄ length,⋄ time,⋄ electric current,• Concepts are defined.⋄ thermodynamic temperature,⋄ amount of substance,⋄ luminous intensity).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7 Lecture: 2. Slide: 65 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• We shall analyse phenomena and concepts according to thefollowing simple, but workable classification:/home/db/de/dek0/dek0-2⋆ simple entities,⋆ functions (over entities),⋆ events (involving changes in entities, possibly as caused byfunction invocations, i.e., actions, and/or possibly causing such),and⋆ behaviours as (possibly sets of) sequences of actions (i.e.,function invocations) and events.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1 Lecture: 2. Slide: 66 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Discrete and Continuous Entities• The concepts of discrete and continuous are closely interwoven andare mainly, or best, understood in a physical context. FromWikipedia we bring:⋆ Discreteness constituting a separate thing; consisting ofnon-overlapping, but possibly adjacent, but distinct parts.⋆ Discreteness are fundamentally discrete in the sense of notsupporting or requiring the notion of continuity.⋆ Continuity is seen as consistency, over time, of thecharacteristics of persons, plot, objects, places and events asobserved.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 1 Lecture: 2. Slide: 67 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities ]/home/db/de/dek0/dek0-2An Analysis• For our purposes we shall limit our consideration of entity⋆ discreteness and⋆ continuity• to the physically, more specifically tactile manifested forms:⋆ if a physical, simple entity is fixed, that is does not changephysical, spatial form, then we shall consider it a discrete, simpleentity;⋆ if, instead, a physical, simple entity is liquid or gaseous, that iscan, say through the force of gravity, change physical, spatialform, then we shall consider it a continuous, simple entity.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 2 Lecture: 2. Slide: 68 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2StructuresCharacterisation 24 (Entity Structure) By the structure of an entity weunderstand how that entity is “made up”,.• whether a⋆ simple entity,⋆ operation,• whether⋆ event or⋆ behaviour;⋆ atomic, ⋆ composite or ⋆ continuous;• whether⋆ static:⋄ fixed number of possible subentities⋄ and/or possible attributes, or⋆ dynamic:⋄ variable number of possible subentities⋄ and/or possible attributesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 2, § 1 Lecture: 2. Slide: 69 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, Structures ]• Observations •invisible• Note that/home/db/de/dek0/dek0-2⋆ the values of attributes and⋆ the number of alike sub-entities of composite entities⋆ may change⋆ while the structure remains the same.• Thus the structure concept implies⋆ that if two or more simple entities, or one simple entity over time,⋆ has the same, fixed, invariant structure⋆ but with possibly changing values of attributes⋆ or changing number of sub-entities,⋆ then they are discrete, simple entities. Slide[s]: 627Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 2, § 2 Lecture: 2. Slide: 70 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, Structures ]invisible/home/db/de/dek0/dek0-2• Finite Structures •• A simple entity structure is finite if it is⋆ either atomic⋆ or, if composite, then consists of a finite number of finitesubentities,⋆ or, if continuous, its measure of “size”,⋄ i.e., its amount of substance,⋄ or, if time,⋆ is finite.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 3 Lecture: 2. Slide: 71 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities ]/home/db/de/dek0/dek0-2CharacterisationsCharacterisation 25 (Discrete) Being discrete is a property associated with entities..• An entity is discrete⋆ if it is timewise fixed,⋄ i.e., does not change spatial extent with time⋄ but could change value of possible sub-entities or of attributesCharacterisation 26 (Continuous) Being continuous is a property associated with entities..• An entity is continuous⋆ if it is timewise variable, i.e., can change spatial extent with time,⋆ or if any subpart of it is also an entity of the same structurePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 4 Lecture: 2. Slide: 72 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities ]Examples• Our examples will be taken from the physical world as observed by physicists.• They are:/home/db/de/dek0/dek0-2⋆ length (meter, m),⋆ mass (Kilogram, kg),⋆ Time (or just T) (Second, sec),⋆ electric current (Ampere, A),⋆ thermodynamic temperature (Kelvin, K),⋆ luminous intensity (Candela, cd) and⋆ amount of (chemical) substance (Mol)).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 4, § 1 Lecture: 2. Slide: 73 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, Examples ]• Analysis of Time •invisible• There is a slight problem with the time example./home/db/de/dek0/dek0-2⋆ There is absolute time and there is relative time.⋄ By absolute time we understand time since some “point intime”.⋄ By relative time we understand a time interval between twotimes, i.e., two ‘points in time’.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 4, § 1 Lecture: 2. Slide: 74 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Examples, Analysis of Time ]⋆ The difference between these concepts can, perhaps, best beunderstood in terms of the operations that one can perform onthem:⋄ One can compare two absolute times in order to find outwhich absolute time is the later (earlier);⋄ and one can compare two relative times in order to find outwhich time interval is larger of the two.⋄ One cannot add two absolute times, but one can add timeintervals.⋄ One can subtract two absolute times, one, a smaller, from theother, the larger, to obtain the elapsed time interval.⋄ And so forth.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 4, § 1 Lecture: 2. Slide: 75 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In practice/home/db/de/dek0/dek0-2[ Examples, Analysis of Time ]⋆ absolute times are abstracted as time and⋆ relative time are abstracted as time intervals;⋆ and both are abstracted in terms of continuous quantities (reals,Real).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 1, Subsubsect. 4, § 1 Lecture: 2. Slide: 76 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Discrete and Continuous Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In practice/home/db/de/dek0/dek0-2[ Examples, Analysis of Time ]⋆ absolute time is concretised in terms of date (year (AD), month(Jan., Feb., . . . , Dec.), day of month (1, 2, . . . , 28, 29, 30 or 31))and hour (0, 1, . . . , 23), minute (0, 1, 2, . . . , 59) and second (0,1, 2, . . . , 59));⋆ and relative time is concretised in terms of number of elapsedyears, months, days, hours, minutes and seconds;⋆ and these are expressed in terms of discretised quantities (saynatural numbers).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 2 Lecture: 2. Slide: 77 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Entity Classification• We shall now present a classification of simple entities.⋆ This classification shall serve and serves our purposes.⋆ The classification is not claimed to constitute a scientific theoryor fact.⋆ But it is claimed to reflect our engineering approach to modelling.• The classification of simple entities partition their universe intothree parts.⋆ continuous simple entities,⋆ atomic simple entities and⋆ composite simple entities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 2 Lecture: 2. Slide: 78 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Entity Classification ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The classification allows composite simple entities to be composed fromsubentities that are/home/db/de/dek0/dek0-2⋆ either continuous⋆ or atomic⋆ or themselves composite.• So it is not a matter of a simple entity which is not continuous instead beingdiscrete.• A discrete simple entity is an entity⋆ which is not continuous,⋆ and, if composite,⋆ then all of its subentities are discrete simple entities.• Since all simple entities are of finite structure the above recursivecharacteristation stops.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3 Lecture: 2. Slide: 79 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Simple EntitiesCharacterisation 27 (Simple Entity) By a simple entity wemean.• something we can point to, i.e., something manifest,• or a concept abstracted from, such a phenomenon or conceptthereof• Simple entities are either continuous, atomic or composite.• The decision as to which simple entities are considered continuous,atomic or composite• is a decision sôlely taken by the describer.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 1 Lecture: 2. Slide: 80 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]Atomic Simple EntitiesCharacterisation 28 (Atomic Simple Entity) By an atomicsimple entity we intuitively understand.• a simple entity which “cannot be taken apart”• (into other, the sub-entities)• and which possess one or more attributesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 2 Lecture: 2. Slide: 81 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]Attributes — Types and ValuesWith any entity we can associate one or more attributes.Characterisation 29 (Attribute) By an attribute weunderstand.• a pair of a type• and a valuePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 2 Lecture: 2. Slide: 82 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, Attributes — Types and Values ]Dines Bjorner: 1st DRAFT: January 2, 2009.invisible/home/db/de/dek0/dek0-2Example 1 (Atomic Entities)Entity: Person Entity: Bank AccountType Value Type ValueName Dines Bjørner number 212 023 361 918Weight 118 pounds balance 1,678,123 YenHeight 179 cm interest rate 1.5 %Gender male credit limit 400,000 Yen“Removing” an attribute from an entity destroys its “entity-hood”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 3 Lecture: 2. Slide: 83 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]Composite EntitiesCharacterisation 30 (Composite Entity) • By a compositeentity we intuitively understand an entity.• (i) which “can be taken apart” into sub-entities,• (ii) where the composition of these is described by its mereology,and• (iii) which, apart from the attributes of the sub-entities, furtherpossess one or more attributesSub-entities are entities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 4 Lecture: 2. Slide: 84 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]MereologyCharacterisation 31 (Mereology) By mereology we understand• a theory of part-hood relations.• That is, of the relations of part to whole• and the relations of part to part within a whole.• The term mereology seems to have been first used• in the sense we are using it by• the Polish mathematical logician Stanis̷law Leshniewski.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 5 Lecture: 2. Slide: 85 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009.invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]Composite Entities — ContinuedExample 2 (Transport Net, A Narrative)Entity: Transport NetSubentities: SegmentsJunctionsMereology: “set” of one or more s(egment)s and“set” of two or more j(unction)ssuch that each s(egment) is delimited by two j(unctions)and such that each j(unction) connects one or more s(egments)AttributesTypes: Values:Multimodal Rail, RoadsTransport Net of DenmarkYear Surveyed 2006Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 5 Lecture: 2. Slide: 86 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, Composite Entities — Continued ]invisible• To put the above example of a composite entity in context• we give an example of both/home/db/de/dek0/dek0-2⋆ an informal narrative⋆ and a corresponding formal specification:Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 5 Lecture: 2. Slide: 87 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, Composite Entities — Continued ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 3 (Transport Net, A Formalisation) • A transportnet consists of one or more segments and two or more junctions.invisible• With segments [junctions] we can associate the following attributes:/home/db/de/dek0/dek0-2⋆ segment [junction] identifiers,⋆ the identifiers of the two junctions to which segments areconnected [the identifiers of the one or more segments connectedto the junction],⋆ the mode of a segment [the modes of the segments connected tothe junction]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 5 Lecture: 2. Slide: 88 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, Composite Entities — Continued ]Dines Bjorner: 1st DRAFT: January 2, 2009typeN, S, J, Si, Ji, Mvalueobs Ss: N → S-set, obs Js: N → J-setobs Si: S → Si, obs Ji: J → Jiobs Jis: S → Ji-set, obs Sis: J → Si-setobs M: S → M, obs Ms: J → M-setaxiom∀ n:N card obs Ss(n) ≥ 1 ∧ card obs Js(n) ≥ 2•∀ n:N card obs Ss(n) ≡ card {obs Si(s)|s:S s ∈ obs Ss(n)}• •∀ n:N card obs Js(n) ≡ card {obs Ji(c)|j:J j ∈ obs Js(n)} ...• •typeNm, Co, Yevalueobs Nm: N → Nm, obs Co: N → Co, obs Ye: N → Yeinvisible./home/db/de/dek0/dek0-2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 6 Lecture: 2. Slide: 89 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]StatesCharacterisation 32 (State) By a domain state• we shall understand• a collection of domain entities chosen by the domain engineer.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 7, § 1 Lecture: 2. Slide: 90 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]• How do we model entities ?• The answer is:Formal Modelling of Simple Entities• The Basics •⋆ by selecting a name for the desired “set”, that is, type of entities;⋆ by defining that type to be⋄ either an abstract type, i.e., a sort,typeA⋄ or a concrete type, i.e., with defined, concrete values.typeA = Type ExpressionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 7, § 1 Lecture: 2. Slide: 91 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Formal Modelling of Simple Entities, The Basics ]• Values of the type are then expressed as:valuea:A• As our main support example unfolds in Appendices A–N we shall illustrate⋆ sorts with their observer, generator and classifier functions⋆ and concrete types over⋄ either basic types (Booleans, Integers, Natural numbers, Reals, etc.,⋄ or over composite types (sets, Cartesians, records, lists, maps, functions).• Appendix section “RSL Types” (Slides 905–914) gives a terse introduction to thetype system of our main formal specification language RSL.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 7, § 2 Lecture: 2. Slide: 92 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Simple Entities, Formal Modelling of Simple Entities ]• Some Caveats •• This part of the lecture has dealt with⋆ discrete and continuous, andsimple entities.• where composite simple entities possessed⋆ subentities,⋆ a mereology ofthese, and⋆ atomic and composite⋆ attributes.• We can (and must) express these distinctions (i.e., properties) of domains clearlyin narratives,• but cannot do so in our chosen, or for that matter in any formal specificationlanguage !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 7, § 2 Lecture: 2. Slide: 93 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Formal Modelling of Simple Entities, Some Caveats ]• Thus we shall, without discrimination, use the RSL type system toexpress⋆ both the possible subentity types of composite types⋆ and the attributes of these composite types.⋆ Whether a type is⋆ continuous, ⋆ discrete or ⋆ composite⋆ will only transpire rather indirectly from the formulas:⋄ in the form, for example, of observer functions,⋄ but these will not discriminate between observing◦ attributes or◦ subentities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 7, § 2 Lecture: 2. Slide: 94 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Formal Modelling of Simple Entities, Some Caveats ]• One could, of course, extend the (or any) formal specification language with the following literals(allowing plural forms):⋆ attribute,⋆ subentity,⋆ discrete,⋆ continuous,• These could be used, for example, in the following type expressions:typeatomic: A, B, ...composite: C, D, ...subentities: A, D, ...attributes: B, E, ...continuous: D, F, ...• Etcetera.• We shall consider all such use of the literals as pragmas,or:⋆ atomic and⋆ composite.typeatomic A, ... andcomposite D, ... assubentities of C, ...⋆ that is, as pragmatic comments. Their presence (or absence) has no semantic importance.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 8, § 1 Lecture: 2. Slide: 95 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities ]Discussion• Simple Entities, Operations, Events and Behaviours as Entities •• We have focused in this lecture on a concept of simple entities.⋆ We have used the prefix ‘simple’ since we consider the totality of⋄ simple entities,⋄ operations,⋄ events and⋄ behavioursto all be entities.⋆ As entities they are potentially arguments of⋄ operations, ⋄ events and ⋄ behaviours.⋆ We shall not here pursue this possibility further.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 8, § 2 Lecture: 2. Slide: 96 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, Discussion ]• A Possible Critique of Our ‘Simple Entity’ Ontology •• We advice the student that the concepts of⋆ discrete and⋆ continuous, and⋆ attribute and⋆ subentities, and⋆ atomic and⋆ composite• are “non-standard”, i.e., not commonly accepted or in widespreadusage.⋆ The student might have guessed that from the “Some Caveats”paragraphs.⋆ Nevertheless we bring them here in textbook form⋄ since we think that they are indeed useful.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 8, § 2 Lecture: 2. Slide: 97 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Discussion, A Possible Critique of Our ‘Simple Entity’ Ontology ]• We also remind the student that the concepts of, for example, physical types:⋆ meter,⋆ kilogram,and their derivatives⋆ second,⋆ Ampere,• as part of a specification language is not new,⋆ Kelvin,⋆ candela and⋆ mol⋆ it was the subject of a number of (different) chapter exercises in Vol.2 of mybook:⋆ and of a MSc. Thesis project in the late 1990s.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 8, § 2 Lecture: 2. Slide: 98 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Simple Entities, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2[ Discussion, A Possible Critique of Our ‘Simple Entity’ Ontology ]• Add to this “applied science” typology one of⋆ “business” typology⋄ Danish Kroner,⋄ Euro,⋄ revenue,⋄ expense,⋄ budget,⋄ debit,⋄ credit,⋄ spent,and you have exciting new projects in⋆ the design and⋆ implementation⋆ of domain specific programming languages• that allow the separate definition of⋆ application specific type systems,⋄ committed,⋄ asset,⋄ liability,⋄ account,⋆ of corresponding scale and conversion systems(millimeter, centimeter, meter, kilometer, inch, foot, yard, mile), etc.,⋄ balance sheet,⋄ general ledger,⋄ balance,⋄ sales,⋆ and of axioms that govern laws of physics, or laws of accounting, etc.⋄ accountsreceivable,⋄ inventory,⋄ etc., etc.,Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 3, Subsubsect. 8, § 2 Lecture: 2. Slide: 99 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-2End of Lecture 2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek0/dek0-3The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 3. Slide: 100 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 3. Slide: 101 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009Lecture 3: The Triptych Specification Paradigm: Operationsinvisible/home/db/de/dek0/dek0-3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4 Lecture: 3. Slide: 102 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible•••••/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]OperationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 1 Lecture: 3. Slide: 103 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]CharacterisationsCharacterisation 33 (Operation) By an operation we shallunderstand.• something (i.e., a function) which when applied to what we shallcall arguments (i.e., entities)• yield some entities called the result of the function (application)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 1 Lecture: 3. Slide: 104 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Characterisations ]• The observer functions of the formal example above are not thekind of functions we are (later) seeking to identify in domains.• These observer functions are mere technicalities:⋆ needed, due to the way in which we formalise —⋆ and are deployed in order to express⋄ sub-entities, ⋄ mereologies and ⋄ attributes.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 2 Lecture: 3. Slide: 105 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]Describing Operations• One can describe functions in a variety of ways.• We shall briefly mention four:⋆ “direct” definitions,⋆ pre/post condition definitions,⋆ “mixtures” of the former two, and⋆ axiomatically.• Each of these can be formulated⋆ either informally⋆ or formally.• But first we introduce the concepts of operation (or function) signatures and ofactions and their signatures.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 3 Lecture: 3. Slide: 106 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]Operation SignaturesCharacterisation 34 (Operation Signature) By a operation signature.• we mean the name and type of a operation.typeA, B, ..., C, X, Y, .., Zvaluef: A × B × ... × C → X × Y × ... × Z• The last line above expresses a schematic operation signature.• Narratively, it expresses that the function f⋆ takes ordered arguments of the types A, B,...,C and⋆ yields results of the (Cartesian) type X×Y ×...×ZPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 5 Lecture: 3. Slide: 107 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]ActionsCharacterisation 35 (Action) By an action.• we shall understand• the same thing as applying a state-changing operation (function)• to its arguments (including the state)Action Signatures• One can speak of three kinds of actions,• and hence of action signatures.• Let Σ denote the type of states.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 5 Lecture: 3. Slide: 108 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Action Signatures ]Dines Bjorner: 1st DRAFT: January 2, 2009typeA, B, ΣvalueVal: A → Σ → BInt: A → Σ → ΣElab: A → Σ → Σ × Binvisible• Valuation functions inspect the state, do not change it, and yield avalue.• Interpretation functions inspect the state, change it, but do notyield a (further) value.• Elaboration functions inspect the state, change it, and yield a value./home/db/de/dek0/dek0-3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6 Lecture: 3. Slide: 109 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]Operation DefinitionsCharacterisation 36 (Operation Definiton) By an operationdefinition we mean.• an operation signature• and something which describes the relationship between operationarguments (the a:A’s, b:B’s, . . . , c:C’s and the x:X’s, y:Y’s, . . . ,z:Z’s)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6 Lecture: 3. Slide: 110 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Operation Definitions ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 4 (Well Formed Routes) Presupposing materialpresented in Example 3 on page 87:typeP = Ji × Si × Ji /∗ path: triple of identifiers ∗/R ′ = P ∗ /∗ route: sequence of connected paths ∗/R = {| r:R ′ •wf R(r) |} /∗ subtype of R ′ : those r ′ s satisfying wf R(r) ∗/valuewf R: R ′→ Boolwf R(r) ≡∀ i:Nat•{i,i+1}⊆inds r⇒let (,,ji ′ )=r(i),(ji ′′ ,,)=r(i+1) in ji ′ =ji ′′end.invisible/home/db/de/dek0/dek0-3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 1 Lecture: 3. Slide: 111 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Operation Definitions ]• Direct Operation Definitions •• In a narrative direct operation definition⋆ the signature is described⋆ followed by an abstracted description of the operation, forexample:⋄ “Operation f applies to arguments, a, of type A, and yieldsresults, b or type B.”⋄ “Operation f, when applied to argument a, i.e., f(a), yields aresult, b, which arises as follows ...”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 1 Lecture: 3. Slide: 112 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ Operation Definitions, Direct Operation Definitions ]Example 5 (The Factorial Function Definition: Direct) Informally and direct formally:1. The factorial function applies to natural numbers and yields natural numbers.The factorial function is otherwise defined as follows:2. Applied to the natural number 0 it yields the natural number 1.Applied to the natural number n (larger than 0) it yields3. Applied to the natural number n (larger than 0) it yields(a) the result of multiplying the number n(b) with the result of applying the factorial function to n − 1.value1 fact: Nat → Nat2–3 fact(n) ≡ if n=0 then 1 else n∗fact(n−1) end.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 1 Lecture: 3. Slide: 113 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ Operation Definitions, Direct Operation Definitions ]• A formal, direct function definition, including the functionsignature thus looks like this ‘schematic’:valuef: A → Bf(a) ≡ C(a)⋆ Here A and B are some type clauses;⋆ C is some clause: some (process) expression, some (process) statement usuallywith a free identifier, say x,⋆ and C(a) designates the evaluation of that clause with the argument a boundto all occurrences of the free identifier x.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 2 Lecture: 3. Slide: 114 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations ]/home/db/de/dek0/dek0-3• Pre/Post Operation Definitions •• In a narrative pre/post operation definition⋆ the signature is described⋆ followed by an abstracted description of pre/post conditions of theoperation, for example:⋄ “Operation f applies to arguments, a, of type A, and yields results, b or typeB.”⋄ “Operation f, when applied to argument a, i.e., f(a), yields a result, let uscall it b;◦ “A pre condition of a is that it satisfies the following predicate: ... , etc.”◦ “The relation between proper input arguments a and results, b is expressedby the post condition: ..., etc.”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 2 Lecture: 3. Slide: 115 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31he Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations, Pre/Post Operation DefinitionsDines Bjorner: 1st DRAFT: January 2, 2009Example 6 (Factorial Function Definition: pre/post) Informally and formally:invisible./home/db/de/dek0/dek0-3• Narrative:⋆ The factorial function applies to natural numbers and yields natural numbers.⋆ The factorial function is otherwise characterised as follows:⋄ Let the factorial of n be called n ′ ;⋄ n must be larger than or equal to 0;⋄ n = 0 implies that the factorial of n is 1;⋄ n>0 implies that the factorial of n is◦ the result of multiplying the number n◦ with the result of applying the factorial function to n − 1.• Formalisation:valuefact: N → Nfact(n) as n ′pre: n≥0post: n=0 ⇒ n ′ =1 ∧ n>0 ⇒ n ′ =n∗fact(n−1)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 2 Lecture: 3. Slide: 116 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31he Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations, Pre/Post Operation DefinitionsDines Bjorner: 1st DRAFT: January 2, 2009invisible• A pre/post operation definition, including the function signature looks like this‘schematic’:/home/db/de/dek0/dek0-3valuef: A → Bf(a) as bpre: P(a)post: Q(a,b)⋆ Here A and B are some type clauses;⋆ P is some predicate expression with free identifier, say x;⋆ Q is some predicate expression with free identifiers, say y, z;⋆ P(a) designates the evaluation of the predicate with the argument a bound to all occurrencesof the free identifier x; and⋆ Q(a, b) designates the evaluation of the predicate with the arguments a, b bound to alloccurrences of respecxtive free identifiers y and z.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 3 Lecture: 3. Slide: 117 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations ]• “Mixed” Operation Definitions •• In a narrative, mixed operation definition⋆ the signature is described —⋄ usually involving arguments (and possibly also results)⋄ types that denote “larger” sets of values⋄ than actually accepted (respectively yielded).⋆ followed by an abstracted description of the operation, for example:⋄ “Operation f applies to arguments, a, of type A, and yields results, b or typeB.”⋄ “Operation f, when applied to argument a, i.e., f(a), yields a result, b,which arises as follows ...”;⋆ followed, finally, by a pre condition (on the operation input arguments).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 3 Lecture: 3. Slide: 118 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations, “Mixed” Operation DefinitionsDines Bjorner: 1st DRAFT: January 2, 2009Example 7 (Factorial Function Definition: “Mixed”) Informally andformally:invisible.• Narrative:/home/db/de/dek0/dek0-3⋆ The factorial function applies to integers and yields natural numbers.⋆ The factorial function is otherwise characterised as follows:⋄ 5 on page 112⋄• Formalisation:valuefact: Int → Natfact(n) ≡ if n=0 then 1 else n∗fact(n−1) endpre: n≥0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 3 Lecture: 3. Slide: 119 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations, “Mixed” Operation DefinitionsDines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3• A formal, “mixed” operation definition, including the function signature thuslooks like this ‘schematic’:valuef: A → Bf(a) ≡ C(a)pre: P(a)⋆ Here A and B are some type clauses;⋆ C is some clause: some (process) expression, some (process) statement usually with a freeidentifier, say x;⋆ C(a) designates the evaluation of that clause with the argument a bound to all occurrences ofthe free identifier x;⋆ P is some predicate expression with free identifier, say x; and⋆ P(a) designates the evaluation of the predicate with the argument a bound to all occurrencesof the free identifier x.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 4 Lecture: 3. Slide: 120 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations ]• Axiomatic Operation Definitions •Example 8 (Factorial Function Definition: axiomatic) Informally and formally:.• Narrative:/home/db/de/dek0/dek0-3⋆ The factorial function, together with natural numbers satisfy the following two axioms:⋄ factorial of 0 is 1, and⋄ factorial of n, for n larger than 0, is n multiplied by the factorial of n − 1.• Formalisation:valuefact: N → Naxiom∀ n:Nat •n=0 ⇒ fact(0) = 1 ∧n>0 ⇒ fact(n) = n∗fact(n−1)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 6, § 4 Lecture: 3. Slide: 121 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31he Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Describing Operations, Axiomatic Operation DefinitionsDines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3• Formal axiomatic operation definitions thus looks like this ‘schematic’:typeA, Bvaluef: A → BaxiomP i (a,b),P j (a,b),...,P k (a,b),⋆ P i , P j , . . . , P k are some predicate expression with free identifiers, say x, y; and⋆ P(a, b) designates the evaluation of the predicate with the argument a, b bound to alloccurrences of the free identifiers x, y.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 7 Lecture: 3. Slide: 122 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 7 Lecture: 3. Slide: 123 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Discussion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 7 Lecture: 3. Slide: 124 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Discussion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 4, Subsubsect. 7 Lecture: 3. Slide: 125 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-3End of Lecture 3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek0/dek0-4The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 4. Slide: 126 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 4. Slide: 127 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009Lecture 4: The Triptych Specification Paradigm: Events and Behavinvisible/home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 5 Lecture: 4. Slide: 128 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Characterisation 37 (Event).Events• An event can be characterised by⋆ a predicate, p and⋆ a pair of (“before”) and (“after”) of pairs of⋄ states and⋄ times:⋄ p((t b ,σ b ), (t a ,σ a )).⋆ Usually the time interval t a − t b⋆ is of the order t a ≃ next(t b )Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 5 Lecture: 4. Slide: 129 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Events ]• Sometimes the event times coincide,• t b = t a ,• in which case we say that the event is instantaneous.• The states may then be equal σ b = σ a or distinct !• We call such predicates as p for event predicates.• Events may or may not lead to the initiation of explicitly issuedoperations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 5 Lecture: 4. Slide: 130 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Events ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 9 (Events) A ‘withdraw’ from a positive balance bankaccount action may leave a negative balance bank account. A bankbranch office may have to temporarily stop actions, i.e., close, due to abank robbery.invisible• Internal events: The first example above illustrates an internalevent. It was caused by an action in the domain, but was notexplicitly the main intention of the “withdraw” function.• External events: The second example above illustrates anexternal event. We assume that we have not explicitly modelledbank robberies!/home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 1 Lecture: 4. Slide: 131 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]BehavioursSimple BehavioursCharacterisation 38 (Simple Behaviour) By a simple behaviour.• we understand a sequence, q, of zero, one or more⋆ actions⋆ and/or events• such that the state⋆ resulting from one such action, q i ,⋆ or in which some event, q i , occurs,⋆ q 1 , q 2 , . . . , q i , q i+1 , . . . , q n• becomes the state in which the next action or event, q i+1 ,⋆ if it is an action, is effected,⋆ or, if it is an event, is the event statePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 1 Lecture: 4. Slide: 132 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, Simple Behaviours ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 10 (Simple Behaviours) • The opening of a bank account,followed by zero, one or more.invisible• deposits into that bank account, and/or• withdrawals from the bank account in question,• ending with a closing of the bank account.• Any prefix of such a sequence is also a simple behaviour.• Any sequence in which one or more events are interspersed is also a simplebehaviour/home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2 Lecture: 4. Slide: 133 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• A behaviour/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours ]General Behaviours⋆ is either a simple behaviour,⋆ or is a concurrent behaviour,⋆ and, if the latter, can be⋄ either a communicating behaviour⋄ or not (i.e., just a concurrent behaviour).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2, § 1 Lecture: 4. Slide: 134 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, General Behaviours ]• Concurrent Behaviours •Characterisation 39 (Concurrent Behaviour) By aconcurrent behaviour.• we shall understand a set of behaviours• (simple or otherwise)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2, § 1 Lecture: 4. Slide: 135 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, General Behaviours, Concurrent Behaviours ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 11 (Concurrent Behaviours) A set of simplebehaviours,.invisible• that may result• from two or more distinct bank clients, each operating of their own,distinct, that is, non-shared accounts,• forms a concurrent behaviour/home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2, § 2 Lecture: 4. Slide: 136 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, General Behaviours ]• Communicating Behaviours •Characterisation 40 (Communicating Behaviour) By acommunicating behaviour.• we shall understand a set of two or more• behaviours where otherwise distinct elements (i.e., behaviours)share eventsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2, § 2 Lecture: 4. Slide: 137 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, General Behaviours, Communicating Behaviours ]invisible• Sometimes we do not model the behaviour from which externalevents are incident (i.e., “arrive”) or to which events emanate (i.e.,“depart”).• But such an environment is nevertheless a behaviour./home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 2, § 2 Lecture: 4. Slide: 138 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours, General Behaviours, Communicating Behaviours ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 12 (Communicating Behaviours) Consider a bank.invisible.• To model that two or more clients can share the same bank account one couldmodel the bank account as one behaviour and each client as a distinct behaviour.• Let us assume that only one client can open an account and that only one clientcan close an account.• Let us further assume that sharing is brought about by one client, say the onewho opened the account, identifying the sharing clients.• Now, in order to make sure that at most one client accesses the shared accountat one one time (in any one “smallest” transaction interval) one may model“client access to account” as a pair of events such that during the intervalbetween the first (begin transaction) and the second (end transaction) event noother client can share events with the bank account behaviour.• Now the set of behaviours of the bank account and one or more of the clientbehaviours is an example of a communicating behavior/home/db/de/dek0/dek0-4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 6, Subsubsect. 3 Lecture: 4. Slide: 139 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Behaviours ]Formal Modelling of Behaviours• Communicating behaviours,• the only really interesting behaviours,• can be modelled in a great variety of ways:⋆ from set-oriented models in B, RSL, VDM, or Z ,⋆ to models using for example CSP,(as for example “embedded” inRSL,),⋆ or, to diagram models using, for example, Petri nets, message orlive sequence charts, or state-charts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 7 Lecture: 4. Slide: 140 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Discussion• The main aim of Sect. is to ensure that we have a clearunderstanding of the modelling concepts of entities, functions,events and behaviours.• To “reduce” the modelling of phenomena and concepts to thesefour kinds of phenomena and concepts is, of course, debatable.• Our point is that it works,⋆ that further classification, as is done in for example John F.Sowa’s book,⋆ is not necessary, or rather,⋆ is replaced by⋄ how we model attributes of, for example, entities, and⋄ how we model facets .Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 1 Lecture: 4. Slide: 141 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm ]Operations, Events and Behaviours as EntitiesReview of Entities• In the main example of these lectures we identify the following asbeing entities:⋆ (i)⋆ (ii)⋆ (iii)⋆ (iv)⋆ (v)⋆ (vi)⋆ (vii)⋆ (viii)⋆ (ix)⋆ (x)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 1 Lecture: 4. Slide: 142 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities, Review of Entities ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• It may surprise some that we designate the insert and removecommands as entities./home/db/de/dek0/dek0-4⋆ They are certainly of conceptual nature,⋆ but can be given manifest representations⋄ in the form of documents⋄ (that, for example order the building of a link⋄ and its eventual inclusion in the net).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 1 Lecture: 4. Slide: 143 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities, Review of Entities ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• It may surprise some that we designate time and time intervals asentities./home/db/de/dek0/dek0-4⋆ They are certainly of conceptual and very abstract nature,⋆ but so is our choice.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 1 Lecture: 4. Slide: 144 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities, Review of Entities ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• It may surprise some that we designate positions as entities./home/db/de/dek0/dek0-4⋆ They are certainly manifest:⋄ one can point to a position.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 1 Lecture: 4. Slide: 145 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities, Review of Entities ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• And it may finally surprise some that we designate traffics asentities./home/db/de/dek0/dek0-4⋆ It is certainly manifest, and can be recorded,⋄ say by video-recording the traffic.⋆ So that is also our choice.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 2 Lecture: 4. Slide: 146 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities ]invisible/home/db/de/dek0/dek0-4Operations as Entitiesto be written•Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 3 Lecture: 4. Slide: 147 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities ]invisible/home/db/de/dek0/dek0-4Events as Entitiesto be written•Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 7, Subsect. 8, Subsubsect. 4 Lecture: 4. Slide: 148 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ The Triptych Paradigms, The Entity, Operation, Event and Behaviour Paradigm, Operations, Events and Behaviours as Entities ]invisible/home/db/de/dek0/dek0-4Behaviours as Entitiesto be written•Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 8, Subsect. 1 Lecture: 4. Slide: 149 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms ]Domain vs. Operational Research ModelsOperational Research (OR)• OR models (OR for Operational Research), have won a significant position alsowithin the transportation infrastructure.• But domain models are not OR models.• OR models usually⋆ use classical applied mathematics:⋄ calculus ([partial] differentialequations),⋄ statistics,⋄ probability theory,⋄ graph theory,⋄ combinatorics,⋄ signal analysis,⋄ theory of flows in networks,⋄ etcetera⋆ where domain engineering use formal specification languages⋄ emphasising applied mathematical logic⋄ and modern algebra.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 8, Subsect. 2 Lecture: 4. Slide: 150 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, Domain vs. Operational Research Models ]Reasons for Operational Research Analysis• Operational research (OR) models are established,• that is, OR analysis is performed, for the following reasons:⋆ to solve a particular problem,⋆ usually a resource allocation and/or scheduling problem,⋆ but also, less often, the problem is one of taking advice:⋄ should an investment be made,⋄ should one form of resource be “converted” into another form, etc.• Once solved the solver and the client knows⋆ how to best allocate and/or schedule the investigated resource⋆ or whether to perform a certain kind of investment, etc.• OR models typically⋆ do not themselves lead to software derived from the OR model,⋆ but sometimes results of OR analysis⋆ become constants in or parameters for otherwise independently developed software.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 8, Subsect. 3 Lecture: 4. Slide: 151 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, Domain vs. Operational Research Models ]Domain Models• Domain models are usually established⋆ (i) to understand an area of a domain much wider than thatanalysable by current OR techniques, and sometimes⋆ (ii) for purposes of “deriving” appropriate requirements, and⋆ (iii) for implementing the right software.• It has then turned out that in order to achieve items (i–iii) aboveone has to use the kind of mathematics shown in this book.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 8, Subsect. 4 Lecture: 4. Slide: 152 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, Domain vs. Operational Research Models ]Domain and OR Models• But domain and OR modelling are not really that separated — asit may appear from the above.⋆ Oftentimes software (as well as hardware) design decisions must(or ought to) be based on OR analysis.⋆ The two kinds of modelling must still be pursued.⋆ But it is desirable that their scientists and engineers, i.e., thattheir practitioners, collaborate.⋆ Today they do not collaborate.⋆ Today only the domain engineers are aware of the existence ofOR engineers.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 8, Subsect. 5 Lecture: 4. Slide: 153 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, Domain vs. Operational Research Models ]Domain versus Mathematical Modelling• We could widen our examination of⋆ domain modelling versus OR modelling to⋆ domain modelling versus mathematical modelling,• where the latter⋆ extends well beyond OR modelling to⋆ the modelling of physical and human made domains in its widestsense —⋆ such as also practiced by physicists, biologists, etc.• For OR modelling as well as mathematical modelling we can say⋆ that domain modelling currently lacks the formal techniques⋆ offered by the former.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 9 Lecture: 4. Slide: 154 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms ]Summary• The exercises brought in Chap. 1 of the lecture notes reveal theessence of this chapter:⋆ (i) the ‘triptych paradigm’;⋆ (ii) the ‘triptych phases of software engineering’;⋆ (iii) the ‘stages’ and ‘steps’ of software development;⋆ (iv) the three classes of development documents;⋆ (v) the detailed nature of 16 kinds of ‘informative documents’;⋆ (vi) the concepts of ‘modelling documents’;Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 9 Lecture: 4. Slide: 155 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4[ The Triptych Paradigms, Summary ]⋆ (vii) the concepts of ‘analysis documents’;⋆ (viii) the concepts of ‘descriptions, prescriptions’ and‘specifications’;⋆ (ix) the concept of ‘software’;⋆ (x) the concepts of ‘informal development’, ‘formal development’,‘informal and formal development’, ‘formal software developmenttechnique’, ‘systematic development’, ‘rigorous development’ and‘formal development’;⋆ (xi) the concepts of ‘entities’, ‘functions’, ‘events’ and‘behaviours’; and⋆ (xii) the concepts of ‘operational research’ versus those of‘domain models’.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.1, Sect. 9 Lecture: 4. Slide: 156 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek0/dek0-4End of Lecture 4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dep2/dep2The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 5. Slide: 157 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 5. Slide: 158 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2Lecture 5: Domain EngineeringPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.2 Lecture: 5. Slide: 159 of 894/home/db/de/dep2/dep2Domain Engineering: An Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• Domain engineering is a new element of software engineering.• Domain engineering is to be performed prior to requirementsengineering⋆ for the case where there is no relevant domain description⋆ on which to base the requirements engineering.• For the case that such a description exists⋆ that description has to first be checked:⋆ its scope must cover at least that of the desired requirements.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2 Lecture: 5. Slide: 160 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering ]• The next three–four lectures shall outline⋆ the stages and steps of development actions to be taken⋆ in order to arrive, in a proper way,⋆ at a proper domain description.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 1, Subsect. 1 Lecture: 5. Slide: 161 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering ]Discussions of The Domain ConceptThe Novelty• The idea of domain engineering preceding requirements engineeringis new.• Well, in some presentations of requirements engineering there areelements of domain analysis.• But basically those requirements engineering-based forms ofanalysis⋆ do not expect the requirements engineer to write down,⋆ that is, to seriously describe the domain,⋆ and certainly not in a form which is independent of,⋆ that is, separated from the requirements prescriptions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 1, Subsect. 1 Lecture: 5. Slide: 162 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Engineering, Discussions of The Domain Concept, The Novelty ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• As also outlined in earlier lectures (Lectures # 1 and # 4),/home/db/de/dep2/dep2⋆ domain models⋆ are as necessary for requirements development and —⋆ thus also —⋆ for software design,⋆ as physics is for the classical branches of⋄ electrical and electronics,⋄ mechanics,engineering.⋄ civil, and⋄ chemicalPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 1, Subsect. 2 Lecture: 5. Slide: 163 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Discussions of The Domain Concept ]Implications• This new aspect of software engineering implies⋆ that software engineers, as a group, engaged in a softwaredevelopment project,⋄ from (and including) domain engineering⋄ via requirements engineering⋄ to (and including) software design,⋆ must possess the necessary formal and practical bases:⋄ the science skills of domain engineering,⋄ the R&D skills of requirements engineering, and⋄ the (by now) engineering skills of software design.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 1, Subsect. 3 Lecture: 5. Slide: 164 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Discussions of The Domain Concept ]The Domain Dogma• Before software can be designed⋆ one must understand its requirements.• Before requirements can be expressed⋆ one must understand the application domain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2 Lecture: 5. Slide: 165 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering ]Stages of Domain EngineeringAn Overview of “What to Do ?”• How do we then construct a domain description ?• That is, which are the stages of domain engineering ?• The answer is:⋆ there are a number of stages,⋆ which, when followed in some order, some possibly concurrently,⋆ will lead you reasonably disciplined way from scratch to goal !• Before enumerating the stages⋆ let us argue their presence⋆ and basic purpose.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 1 Lecture: 5. Slide: 166 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][1] Domain Information• We are here referring to the construction of informative documents.• We have earlier, as mentioned earlier, (Slide 19) introduced thegeneral issues of informative documents.Slides 184–275 covers the present topic in some detail.• Suffice it here to emphasize that⋆ each and every of the items listed on Slide 187⋆ must be kept up-to-date during the full development cycle.• This means that this activity is of “continuing concern”⋆ all during development.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 1 Lecture: 5. Slide: 167 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering, [1] Domain Information ]• The purpose of this stage of development, to repeat, is to record allrelevant⋆ administrative,⋆ socio-economic,⋆ budgetary,⋆ project management (planning)⋆ and all such non-formalisable informationwhich has a bearing on the domain description project.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 2 Lecture: 5. Slide: 168 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The domain is populated with/home/db/de/dep2/dep2⋆ staff,⋆ customers,⋆ providers,⋆ the public at large,[ Domain Engineering, Stages of Domain Engineering ][2] Domain Stakeholder Identification⋆ regulatory agencies,⋆ politicians,⋆ etcetera.• There are many kinds of staff, many kinds of customers, manykinds of providers, etc.• All these need be identified so that⋆ as complete a coverage of sources of domain knowledge can be established andused⋆ when actively acquiring, that is, soliciting and eliciting knowledge about thedomain.Slides 279–286 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 3 Lecture: 5. Slide: 169 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][3] Domain Acquisition• The software engineers need a domain description.• Software engineers, today, are basically the only ones who have thetools, techniques and experience in creating large scalespecifications.• But the software engineers do not possess the domain knowledge.• They must acquire this knowledge from the domain stakeholders.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 3 Lecture: 5. Slide: 170 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Engineering, Stages of Domain Engineering, [3] Domain Acquisition ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 41 (Domain Acquisition (I)) By domain acquisition weunderstand.invisible• a process in which• documents, interviews, etc.,• informing — “in any shape or form” —• about the domain• entities, functions, events and behaviours• are collected• from the domain stakeholdersCompare the above characterisation to that of Characterisation 53 on page 290.Slides 290–300 covers the present topic in some detail./home/db/de/dep2/dep2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 4 Lecture: 5. Slide: 171 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][4] Domain Analysis and Concept Formation• The acquired domain knowledge is then analysed,• that is, studied with a view towards discovering⋆ inconsistencies and incompleteness of what has been acquired⋆ as well as concepts that capture properties of knowledge⋆ about the phenomena and concepts being analysed.Slides 304–311 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 5 Lecture: 5. Slide: 172 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][5] Domain Business Processes• On the basis of acquired knowledge,⋆ sometimes as part of its acquisition⋆ one is either presented with or constructs rough sketches⋆ of the business processes of the domain.• An aim of describing these business processes⋆ is to check the acquired knowledge⋆ for inconsistencies and completeness⋆ and whether proposed concepts help improve the informalunderstanding.Slides 315–327 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 6 Lecture: 5. Slide: 173 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2• Out of the[ Domain Engineering, Stages of Domain Engineering ][6] Domain Terminology⋆ domain acquisition,⋆ analysis and⋆ business process rough-sketchingprocesses emerges a domain terminology.• That is, a set of terms that cover⋆ entities,⋆ functions,of the domain.⋆ events and⋆ behavioursPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 6 Lecture: 5. Slide: 174 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering, [6] Domain Terminology ]• It is an important aspect of software development⋆ to establish,⋆ use and• And first comes the domain terminology.⋆ maintain⋆ a variety of terminologies.Slides 331–341 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 7 Lecture: 5. Slide: 175 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][7] Domain Modelling• Based on properly analysed domain acquisitions⋆ these are “domain description units”• we can now model the domain.• The major stage of the domain engineering phase⋆ is that of domain modelling, that is,⋆ of precisely describe⋄ in narrative and possibly also in formal terms⋆ the domain as it is.⋆ Several principles, many techniques and many tools⋄ can be given for describing domains.Slides 355–459 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 8 Lecture: 5. Slide: 176 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][8] Domain Verification• While describing a domain one may wish to verify properties of what is being described.• The use here of the term ‘verification’ covers⋆ (i) formal testing,⋄ that is, testing⋄ (symbolic executions of descriptions)⋄ based on formally derived test cases and test answers,⋆ (ii) model checking,⋄ that is, executions of simplified,⋄ but crucial models of what is being described,and⋆ (iii) formal verification⋄ that is, formal, possibly mechanisable proof of theorems⋄ (propositions etc.) about what is being described.Slides 463–469 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 9 Lecture: 5. Slide: 177 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][9] Domain ValidationCharacterisation 42 (Validation) By validation we shall mean.• a systematic process —• involving representatives of all stakeholders• and the domain engineers —• going carefully through all the narrative descriptions• and confirming or rejecting these descriptionsSlides 473–475 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 10 Lecture: 5. Slide: 178 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Verification/home/db/de/dep2/dep2[ Domain Engineering, Stages of Domain Engineering ][10] Domain Verification versus Domain Validation⋆ serves to ensure that⋆ the domain model is right.• Validation⋆ serves to ensure that⋆ one obtains the right model.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 2, Subsect. 11 Lecture: 5. Slide: 179 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2• Describing a domain,[ Domain Engineering, Stages of Domain Engineering ][11] Domain Theory Formation⋆ precisely, and even⋆ formally,⋆ verifying propositions and theorems,is tantamount to establishing a basis for a domain theory.• Just as in physics, we need theories also of the man-made universes.Slides 479–481 covers the present topic in some detail.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 3 Lecture: 5. Slide: 180 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2[ Domain Engineering ]A Summary Enumeration• We can now summarise the relevant stages of domain engineering:1. Domain Information2. Domain Stakeholder Identification,3. Domain Acquisition,4. Domain Analysis and Concept Formation,5. Domain [i.e., Business] Processes,6. Domain Terminology,7. Domain Modelling,(a) Intrinsics (Slides 355–363)(b) Support Technologies (Slides 367–374)(c) Mgt. & Org. (Slides 378–408)8. Domain Verification,9. Domain Validation and10. Domain Theory Formation(d) Rules & Regulations (Slides 412–430)(e) Scripts and Contracts (Slides 434–447)(f) Human Behaviour (Slides 451–459)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.2, Sect. 3 Lecture: 5. Slide: 181 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dep2/dep2End of Lecture 5Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek1/dek1The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 6. Slide: 182 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 6. Slide: 183 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1Lecture 6: Informative DocumentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3 Lecture: 6. Slide: 184 of 894Informative Documentsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• An informative document ‘informs’.• An informative document is expressed in some national language.• Informative documents serve as a link between developers. clientsand possible external funding agencies:/home/db/de/dek1/dek1⋆ “What is the project name ?” Item 1⋆ “When is the project carried out ?” Item 1⋆ “Who are the project partners ?” Item 2⋆ “Where is the project being done ?” Item 2⋆ “Why is the project being pursued ?”⋆ “What is the project all about ?”Items 3(a)–3(b)Items 3(b)–3(g)⋆ “How is the project being pursued ?” Items 4–6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Subsect. -1 Lecture: 6. Slide: 185 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]• And many other such practicalities.• Legal contracts can be seen as part of the informative documents.• We shall list the various kinds of informative documents that aretypical for domain and for requirements engineering.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 1 Lecture: 6. Slide: 186 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]An Enumeration of Informative Documents• Instead of broadly informing about the aims and objectives• of a development project• we suggest a far more refined repertoire of information “tid-bits”.• A listing of the sixteen names of these “tid-bits” hints at these:Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 1 Lecture: 6. Slide: 187 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, An Enumeration of Informative Documents ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek11. Project Name and Date from Slide 1882. Project Partners (‘whom’) and Place(s) (‘where’) from Slide 1893. [Project: Background and Outlook](a) Current Situation from Slide 193(b) Needs and Ideas from Slide 196(c) Concepts and Facilities from Slide 201(d) Scope and Span from Slide 204(e) Assumptions and Dependencies from Slide 208(f) Implicit/Derivative Goals from Slide 211(g) Synopsis from Slide 2154. [Project Plan](a) Software Development Graph from Slide 218(b) Resource Allocation from Slide 228(c) Budget Estimate from Slide 233(d) Standards Compliance from Slide 2345. Contracts and Design Briefs from Slide 2446. Logbook from Slide 267Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 2 Lecture: 6. Slide: 188 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Informative Documents ]Project Names and DatesThe first information are those ofinvisible• Project Name: the name of the endeavour;• Project Dates: the dates of the project./home/db/de/dek1/dek1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 3 Lecture: 6. Slide: 189 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Informative Documents ]Project Partners and PlacesThe second information is that ofinvisible/home/db/de/dek1/dek1• Project Partners: who carries out the project.Full partner (collaborator) details are (eventually) to be given:⋆ Client(s): full names, addresses, and possibly names of contactpersons, etc., of the people and/or companies and/or institutionswho and which have ‘ordered’ the project and who and whichshall receive its resulting documents.⋆ Developer(s): full names, addresses, and possibly names ofcontact persons, etc., of the people and/or companies and/orinstitutions who and which are primarily developing thedeliverables of the project and who and which shall receive itsmain funding.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 3 Lecture: 6. Slide: 190 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Development Documents, Informative Documents, Project Partners and Places ]⋆ Project Consultant(s): full names, addresses, and possibly namesof possible consultants, i.e., companies and/or individuals outside“the circle” of clients and developers.⋆ Project Funding Agencies: full names, addresses, possibly namesof contact persons, etc., of the people and/or agencies who andwhich are possibly [co-]funding the project.⋆ Project Audience: full names, addresses, and possibly names ofcontact persons, etc., of the people and/or agencies who andwhich are possibly (also) interested in the project.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 3 Lecture: 6. Slide: 191 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Project Partners and Places ]• Project Places: where is the project carried out ?⋆ Full addresses:⋄ visiting and postal mailing addresses and⋄ electronic addresses.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 3 Lecture: 6. Slide: 192 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Project Partners and Places ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 4 Lecture: 6. Slide: 193 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Current Situation• Usually a domain engineering project is started for some reason.⋆ Either the developer or the client, or both, have only scantknowledge of the domain,⋆ or, when they have it is not written down but is “inside” theheads of some or most of their (i.e., developer or client) staff.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 4 Lecture: 6. Slide: 194 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Current Situation ]• Similarly a requirements engineering project is started for somereason.⋆ A common reason is that of the current situation on the clientside.⋄ Either no IT is used but there is a need for some IT,⋄ or current IT is outdated,⋄ or new demands are made by owners, management oremployees in general at the client, demands that “translate”into altered or new IT;⋆ or customers of the client may have similar expectations — ofbetter e-service etc., from the client, i.e., their provider.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 4 Lecture: 6. Slide: 195 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• For a software design project⋆ ....⋆ ....⋆ ....[ Informative Documents, Current Situation ]• The ‘Current Situation’ document⋆ must outline this in succinct terms:⋆ say half to a full page.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 5, Subsect. 1 Lecture: 6. Slide: 196 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Needs and IdeasNeeds• Usually the current situation is paraphrased,⋆ i.e., accentuated, by expressions of specific ‘needs’ for a domaindescription,⋆ or for a requirements prescription,⋆ or for a completed software design, i.e., for software.• The need for a domain description could⋆ either be that it should form the basis for an orderly process ofrequirements development,⋆ or the basis for teaching and learning courses, say for new staff ofthe enterprise (of the domain),⋆ or both.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 5, Subsect. 1 Lecture: 6. Slide: 197 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Needs and Ideas, Needs ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• The need for a requirements prescription could⋆ either be that it should form the basis for an orderly process ofrequirements development,⋆ or the basis for a tender, i.e., an offer to develop some software,⋆ or both.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 5, Subsect. 1 Lecture: 6. Slide: 198 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Needs and Ideas, Needs ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Usually can express needs while at the same time indicate how onemight foresee an expressed need being possibly fulfilled, i.e.,achieved.• A need for a software design may be that it must be based on anexisting requirements prescription.• A need for a requirements prescription may be that it must bebased on an existing domain description.• A need for a domain description may be that it must be justinformal, another need may be that it be both informal and formal./home/db/de/dek1/dek1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 5, Subsect. 2 Lecture: 6. Slide: 199 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• One thing are the ‘needs’.• Another thing are the ‘ideas’.[ Informative Documents, Needs and Ideas ]Ideas• If there are needs but no ideas, or if there is no need but ideas, then“forget it”: no reason to embark on a development !• By ideas we mean that there are some substantial concepts that,when properly deployed, can lead to a believable development,⋆ whether of a domain description,⋆ of a requirements prescription, or⋆ of a software design.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 5, Subsect. 2 Lecture: 6. Slide: 200 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Needs and Ideas, Ideas ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• By domain ideas• we mean such concepts “upon” or “around” which one can build,one can model, a domain description.• By requirements ideas• we mean such concepts “upon” or “around” which one can build,one can model, a requirements prescription.• By software design ideas• we mean such concepts “upon” or “around” which one can build,one can model, a software design./home/db/de/dek1/dek1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 6 Lecture: 6. Slide: 201 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Facilities and Concepts• The pragmatics of the ‘concepts and facilities’ section• is to — ever so briefly — inform all parties to the contract of• which are the most important ideas of the subject domain of thecontract.• A facility is a physical phenomenon (here embodied, for example, inthe form of software tools)• while a concept is a mental construction (covering, usually somephysical phenomena or concepts of these).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 6 Lecture: 6. Slide: 202 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Facilities and Concepts ]• In the context of informing only about a domain descriptiondevelopment project⋆ the concepts and facilities are intended,⋆ in the document section of that name,⋆ to be the most pertinent concepts and facilities⋆ on which the domain description should focus.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 6 Lecture: 6. Slide: 203 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Facilities and Concepts ]• In the context of informing only about a requirements prescriptiondevelopment project⋆ the concepts and facilities are intended,⋆ in the document section of that name,⋆ to be the most pertinent concepts and facilities of therequirements prescription:⋄ which are the novel ideas which the requirements should bebased.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 7 Lecture: 6. Slide: 204 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Scope and SpanCharacterisation 43 (Scope) By scopescope — in the context ofinformative software development documentation — we shallunderstand• an outline of the broader setting of the problem, i.e., the universe ofdiscourse at hand..Characterisation 44 (Span) By a spanspan — in the context ofinformative software development documentation — we shallunderstand• an outline of the more specific area• and the nature• of the problem that need be tackled..Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 7 Lecture: 6. Slide: 205 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Scope and Span ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• Let us examine a few generic cases of scope/span determination.⋆ (i) “Pure” domain engineering scope and span:⋄ By ‘ “pure” domain engineering’ we mean a project aimed atjust producing a domain model.⋄ In such a case the scope should typically be chosen as wide aspossible,⋄ while the span is a proper, but not too “small” subset of thescope.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 7 Lecture: 6. Slide: 206 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Scope and Span ]⋆ (ii) Domain and requirements engineering scope and span:⋄ By ‘domain and requirements engineering’ we mean a project⋄ first aimed at producing a domain model⋄ and then, from it, “derive” a requirements model.⋄ In such a case the scope should typically be chosen to becomfortably wider⋄ than the scope of the requirements part of the project.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 7 Lecture: 6. Slide: 207 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Scope and Span ]⋆ (iii) Requirements engineering and software design scope and span:⋄ By ‘requirements engineering and software design’ we mean aproject⋄ first aimed at producing a requirements model⋄ and then, from it, “derive” a software design.⋄ In such a case the scope and span part of⋄ the requirements part of the project should be equal.⋄ Software design projects have their scope and span being setby the requirements part of the project.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 8 Lecture: 6. Slide: 208 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Assumptions and Dependencies• There are two kinds of assumptions and dependencies.⋆ One kind has to do with sources of knowledge.⋄ For domain development there needs to be the sources fromwhich the domain engineer can learn about and develop thedomain description. We assume and depend on that.⋄ For requirements development there needs to be a domaindescription as well as people from whom the requirementsengineer can elicit the requirements and thus develop therequirements prescription. We assume and depend on that.⋄ And for software design there needs to be a requirementsprescription. We assume and depend on that.⋆ The other kind has to do with delineation of the domain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 8 Lecture: 6. Slide: 209 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Assumptions and Dependencies ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• Usually a domain description• (one upon which we base our (domain) requirements)• leaves out• what we might call the “fringes” of the domain,• i.e., the environment of that domain.• To also describe those parts might simply “be too much”!• That environment is simply judged too large, too unwieldy, todescribe.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 8 Lecture: 6. Slide: 210 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Assumptions and Dependencies ]• Yet, sooner or later, that environment will show up in therequirements prescription, if it is not already in the domaindescription.• The requirements prescription eventually, thus, comes to depend —maybe not exactly crucially, but anyway — on events originating inthe environment, or the ability of the computing system to disposeof some output to that environment.• In the ‘assumptions and dependencies’ project document⋆ the project responsible must clearly express⋆ these assumptions and dependencies.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 9 Lecture: 6. Slide: 211 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Implicit & Derivative Goals• Usually computing systems provide, or offer, a large number ofentities, functionalities, events and behaviours,• and it is those requirements we prescribe.• But those entities, functionalities, events and behaviours really donot themselves reveal why they are or were prescribed.• Usually their prescription serves “ulterior” goals which cannot bequantified in a way that indicates what the prescribed computingsystem should offer.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 9 Lecture: 6. Slide: 212 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Typical meta-goals are such as:/home/db/de/dek1/dek1[ Informative Documents, Implicit/Derivative Goals ]⋆ “Deployment of the computing system should result ingreater profits for the company.”⋆ “Deployment of the computing system should result in thecompany attaining a larger market share for its products.”⋆ “Deployment of the computing system should result in fewerworker accidents.”⋆ “Deployment of the computing system should result in moresatisfied customers (and staff).”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 9 Lecture: 6. Slide: 213 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Implicit/Derivative Goals ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• Other kinds of meta-goals are:⋆ “The existence of a domain description will have led or shouldlead to better understanding of the domain, hence to improvedperformance of domain staff trained in the domain based on suchdomain descriptions.”⋆ “The existence of a requirements prescription will have led orshould lead to more appropriately targeted software.”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 9 Lecture: 6. Slide: 214 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Implicit/Derivative Goals ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In the ‘implicit/derivative goals’ project document/home/db/de/dek1/dek1⋆ the project responsible must clearly express⋆ these implicit/derivative goals.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 10 Lecture: 6. Slide: 215 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Synopsis• The four sub-groups of informative document parts:⋆ current situation,⋆ needs and ideas,⋆ scope and span, and⋆ concepts and facilities,• form an introductory “whole”• that now need be “solidified”.• They need to be brought together in a more coherent fashion — inwhat we shall call the⋆ synopsis documentPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 10 Lecture: 6. Slide: 216 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Synopsis ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 45 (Synopsis) By a synopsissynopsis 1 — inthe context of informative software development documentation — weshall understand the same as a resumé, a summary, that is,invisible• a comprehensive view, that is,• an extract of a combination of current situation, needs and ideas,concepts, and scope and span documentation• informing about a universe of discourse for which somedevelopment work is desired, for example:/home/db/de/dek1/dek11 Synopsis: Greek, comprehensive view, from synopsis: to be going to see together.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 10 Lecture: 6. Slide: 217 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Synopsis ]Dines Bjorner: 1st DRAFT: January 2, 2009.invisible/home/db/de/dek1/dek1⋆ the construction of a domain description,⋆ or the construction of a requirements prescription based on anexisting domain description, or both;⋆ or the construction of a software design based on existingrequirements prescription;⋆ or both (requirements and software design),⋆ or all (domain, requirements and software design);⋆ or the first two (domain and requirements)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11 Lecture: 6. Slide: 218 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Software Development Graphs• Development projects need be managed.• This is true also for single person projects.• Management of domain engineering projects must take into account⋆ that these are normally research projects:⋄ little is objectively known about the domain before it isproperly described;⋄ hence one must be prepared for “unforeseen” resource usage.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11 Lecture: 6. Slide: 219 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs ]• Software development graphs are a means of capturing,⋆ either beforehand,⋆ during,⋆ or after the projecthow that project⋆ is to be done,⋆ is being done,⋆ or was done,respectively !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 1 Lecture: 6. Slide: 220 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs ]GraphsCharacterisation 46 (Software Development Graph) • Bya software development graph we shall syntactically understanda labelled graph⋆ whose distinctly labelled nodes (vertexes) designatedevelopment activities (phases, stages or steps),⋆ and whose distinctly labelled, directed edges (arcs) designateprecedence relations between (node designated) activities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 1 Lecture: 6. Slide: 221 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009.invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs, Graphs ]• Semantically a software development graph designate a set ofproject behaviour designators.⋆ A project behaviour designator is⋄ a sequence of phase, stage or step state designators andstate transition designators.⋄ A phase, stage or step state designator is a node label suchthat the node is that of a phase part, or a stage part, or a steppart of a software development graph.⋄ A state transition designator is an edge label such that theedge is that of an edge of a development graphPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 2 Lecture: 6. Slide: 222 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1Aab[ Informative Documents, Software Development Graphs ]A Conceptual Software Development GraphBCcdefDEFGghjkmHJKnL... etcetera ... etceteraFigure 3.1: A software development graph (left)and two (incomplete) project behaviour designators (center and right)• The above graph portrays the following incompletely listed projectbehaviour designator:Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 2 Lecture: 6. Slide: 223 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs, A Conceptual Software Development Graph ]• The “abstracted” software development graph of Fig. 3.1• denotes a very large number of project behaviours,• that is, a very large number of project behaviour designators,• and, for each of these,⋆ depending on the states of phase, stage or step,⋆ as represented, for example, by the states of the documentsrelated to each of the nodes,• a very large number of (dynamic) behaviours.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 3 Lecture: 6. Slide: 224 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs ]Who Sets Up the Graphs ?• Management is responsible for setting up an appropriate softwaredevelopment graph (for each project).⋆ A software development graph shows how management intendsto pursue the project:⋄ which phases, stages and steps to conduct,⋄ that is, to which depth of adherence⋄ to the triptych principles⋄ management wishes to achieve its aims.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 4 Lecture: 6. Slide: 225 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs ]How Do Software Development Graphs Come About ?• For a given, specific project, its software development graph comes about in anynumber of ways.• (i) Either the project is a “repeat” project, that is, is developing a kind ofsoftware which has been developed before.⋆ In that case one simply uses the software development graph used in thoseearlier projects.⋆ But since there probably⋄ are some small, or perhaps not even that small,⋄ difference between the current project and the previous ones,⋄ the currently chosen software development graph may be modified.⋆ Thus every software development graph will be recorded for possible re-use infuture.⋆ It becomes part of the “corporate assets” of the software house.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 4 Lecture: 6. Slide: 226 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Software Development Graphs, How Do Software Development Graphs Come About ? ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (ii) Or the project is a “research” project, that is, is developing anew kind of software which has not been developed before./home/db/de/dek1/dek1⋆ In that case one starts with the process diagram mostappropriate for the project.⋄ If it is a domain engineering project◦ then one starts with the domain engineering process graph of Fig. 21.3 (Chap. ,Sect. 21.3 on page 525) as the software development graph;◦ modifies this graph to suit the specific domain at hand,◦ all the while recalling that development of domain descriptions are really research ratherthan engineering tasks,◦ hence accepting that the software development graph need be modified along the way:◦ clear resource estimates of time and effort cannot be assured.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 11, Subsect. 4 Lecture: 6. Slide: 227 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Software Development Graphs, How Do Software Development Graphs Come About ? ]⋄ If it is a requirements engineering project◦ then one starts with the domain engineering process graph ofFig. 20.2 (Chap. , Sect. on page 519) as the softwaredevelopment graph;◦ and modifies this graph to suit the specific requirements athand.◦ One must always be prepared to modify the softwaredevelopment graph along the way.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 12 Lecture: 6. Slide: 228 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Resource AllocationCharacterisation 47 (Software Development Graph Attribute) •An attributed software development graph.• is a software development graph whose nodes and edges have beenassigned development attributesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 12 Lecture: 6. Slide: 229 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Resource Allocation ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1• Usually node development attributes include⋆ whether the node is a domain, a requirements or a softwaredesign development node;⋆ whether the node is a phase, stage, or step node;⋆ of what specific kind the node — when not just a phase node —is:⋄ any one of the stages of the three triptych phases;⋄ any one of the 16 kinds of information document developmentsteps enumerated on Page 187;⋄ or any one of the many stages or steps of the domain modellingand analysis otherwise “revealed” in Chapters 1–21.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 12 Lecture: 6. Slide: 230 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Resource Allocation ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Given an attributed software development graph/home/db/de/dek1/dek1⋆ and given experience from projects “similar”⋆ to the one described by the graph⋆ one can now estimate resources to be allocated to each task,⋆ that is, to the carrying out the actions⋆ implied by each of its nodes.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 12 Lecture: 6. Slide: 231 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Resource Allocation ]• These resource estimates are of the following kinds:⋆ number and qualifications of project staff;⋆ when, i.e., during which periods each individual, but not yetnamed staff, is to be available for the action denoted by the boxbeing attributed;⋆ tools (office space, equipment (incl. IT equipment), software —by allocated staff members — to be available for that action;⋆ ‘begin’ and ‘end time’;⋆ etcetera.• These estimates can be affixed to the nodes (boxes);• thus augmenting its set of attributes.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 13, Subsect. 1 Lecture: 6. Slide: 232 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents ]Budget (and Other) EstimatesBudgetPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 13, Subsect. 2 Lecture: 6. Slide: 233 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1[ Informative Documents, Budget (and Other) Estimates ]Other Estimates• From the augmented (i.e., extended attributed) softwaredevelopment graph one can now derive a number of estimates:⋆ (i) a budget estimate, per phase and stage, and thus for the entire (softwaredevelopment graph [SDG] designated) project;⋆ (ii) a time estimate, per phase and stage, and thus for the entire (SDGdesignated) project;⋆ (iii) a staff estimate, per phase and stage, and thus for the entire (SDGdesignated) project (here it must be analysed which activities can occur inparallel) and usually in the form of a histogram;⋆ (iv) an equipment estimate, per phase and stage, and thus for the entire (SDGdesignated) project;⋆ etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 1 Lecture: 6. Slide: 234 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents ]Standards Compliance• A distinction is made between development standards anddocumentation standards.Development Standards• Usually development occurs in the context of following somedevelopment standards (one or more).• The Institute of Electrical and Electronics Engineers (IEEE) hasestablished a number of standards for the development of a variouskinds of software.• Other national and international organisations, including theInternational Organization for Standardization (ISO) and theInternational Telecommunication Union (ITU), have establishedsimilar standards.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 2 Lecture: 6. Slide: 235 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance ]Documentation Standards• Usually documentation occurs in the context of following somedocumentation standards (one or more).• The Institute of Electrical and Electronics Engineers (IEEE) hasestablished a number of standards also for the documentation of avarious kinds of software.• Other national and international organisations, including theInternational Organization for Standardization (ISO) and theInternational Telecommunications Union (ITU), have alsoestablished similar standards.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 3 Lecture: 6. Slide: 236 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance ]Standards Versus Recommendations• Some standards are binding, some are recommendations.• Reference to specific standards and recommendations can bewritten into project contracts with the meaning that the projectmust comply with these standards and recommendations.• Some standards mandate or recommend the use — and hence thedocumentation style — of certain development practices.• Other standards mandate or recommend the use of specific spellingforms, mnemonics, abbreviations, etc.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 237 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance ]Specific Standards• There are very many standards for software development and for itsdocumentation.• Some standards come and go. Others are quite stable.• A study of more specialised standards reveals the followingacronyms: MIL-STD-498, DOD-STD-2167A, RTCA/DO-178B,JSP188 and DEF STAN 05-91.• The student is invited to search for these on the Internet.• It therefore makes little sense for us to list other than a few clustersof seemingly more stable and trustworthy standards.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 238 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Standards Compliance, Specific Standards ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex⋆ International Organization for Standardization (ISO):http://www.iso.ch/⋄ ISO 9001: Quality Systems Model for quality assurance indesign, development, production, installation and servicing⋄ ISO 9000-3: Guidelines for the application of ISO 9001 to thedevelopment, supply and maintenance of software⋄ ISO 12207: Software Life Cycle Processeshttp://www.12207.com/Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 239 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance, Specific Standards ]⋆ IEEE Standards: http://standards.ieee.org/⋄ IEEE Std 610.12-1990,Standard Glossary of Software Engineering TerminologyThis standard contains definitions for more than 1000 terms,establishing the basic vocabulary of software engineering.⋄ IEEE Std 1233-1996,Guide for Developing System Requirements SpecificationsThis standard provides guidance for the development of a setof requirements that, when realized, will satisfy an expressedneed.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 240 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance, Specific Standards ]⋄ IEEE Std 1058.101987,Standard for Software Project Management PlansThis standard specifies the format and contents of softwareproject management plans.⋄ IEEE Std 1074.1-1995,Guide for Developing Software Life Cycle ProcessesThis guide provides approaches to the implementation of IEEEStd 1074.⋄ IEEE Std 730.1-1995,Guide for Software Quality Assurance PlansThe purpose of this guide is to identify approaches to goodSoftware Quality Assurance practices in support of IEEE Std730.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 241 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance, Specific Standards ]⋄ IEEE Std 1008-1987 (reaffirmed 1993),Standard for Software Unit TestingThe standard describes a testing process composed of ahierarchy of phases, activities, and tasks. Further, it defines aminimum set of tasks for each activity.⋄ IEEE Std 1063-1987 (reaffirmed 1993),Standard for Software User DocumentationThis standard provides minimum requirements for thestructure and information content of user documentation.⋄ IEEE Std 1219-1992,Standard for Software MaintenanceThis standard defines a software maintenance process.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 14, Subsect. 4 Lecture: 6. Slide: 242 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Standards Compliance, Specific Standards ]⋆ Software Engineering Institute (SEI): http://www.sei.cmu.edu⋄ Software Process Improvement Models and Standards, includingSEI’s various Capability Maturity Models⋆ UK Ministry of Defence Standards http://www.dstan.mod.uk/⋄ 00-55: Requirements for Safety Related Software in DefenceEquipmenthttp://www.dstan.mod.uk/data/00/055/02000200.pdf⋄ 00-56: Safety Management Requirements for Defence Systemshttp://www.dstan.mod.uk/data/00/056/01000300.pdf• So, please, use the Internet for latest on standards relevant to yourproject.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15 Lecture: 6. Slide: 243 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents ]Contracts and Design BriefsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 1 Lecture: 6. Slide: 244 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The/home/db/de/dek1/dek1.tex⋆ current situation,⋆ needs and ideas,⋆ concepts and facilities,document parts[ Informative Documents, Contracts and Design Briefs ]Contracts⋆ scope and span and⋆ synopsis⋆ set the stage for, and are a necessary background for contractualdocuments.Characterisation 48 (Contract) By a contractcontract — in thecontext of informative software development documentation — weshall understand a separate, clearly identifiable documentPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 1 Lecture: 6. Slide: 245 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contracts ]Dines Bjorner: 1st DRAFT: January 2, 2009.invisible• which is legally binding in a court of law,• which identifies parties to the contract,• which describes what is being contracted for, possibly mutualdeliveries, by dates, by contents, by quality, etc.,• which details the specific development principles, techniques, toolsand standards to be used and followed,• which defines price and payment conditions for the deliverables,• and which outlines what is going to happen if delivery of any onedeliverable is not made on time, or does not have the desiredcontents, or does not have the desired quality, etc/home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 1 Lecture: 6. Slide: 246 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contracts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• For national and for international contracts predefined forms whichmake more precise what the contracts must contain are usuallyavailable.• We will not bring in an example.• Such an example would have to reflect the almost ‘formal’ status of‘legal binding’, and would thus have to be extensive and verycarefully worded, hence rather long.• Instead we refer to national and international contract forms.• The software development field is undergoing dramaticimprovements.• Clients are entitled to have legally guaranteed quality standards(incl. correctness verification)./home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 1 Lecture: 6. Slide: 247 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contracts ]• Hence contracts will have to refer to⋆ the broader domain and give specific references to named domainstakeholders, if the development of a domain description is (tobe) contracted; or⋆ existing domain descriptions and give specific references tonamed stakeholders, if the development of a requirementsprescription is (to be) contracted; or⋆ existing requirements prescriptions and give specific references tonamed stakeholders, if the development of software is (to be)contracted.• Therefore contracts should name “the methods” by means of whichthe deliveries will be developed — as we have indicated in bulletfour of the characterisation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 248 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20091. Overview:invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs ]Contract Details• Contracts between an organization and a software vendor shouldclearly describe the rights and responsibilities of the parties tothe contract.⋆ The contracts should be in writing with sufficient detail toprovide assurances for performance, source code accessibility,software and data security, and other important issues.⋆ Before management signs the contracts, it should submit themfor legal counsel review.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 249 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contract Details, Overview ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex• Organizations may encounter situations where software vendorscannot or will not agree to the terms an organization requests.⋆ Under these circumstances, organizations should determine ifthey are willing to accept or able to mitigate the risks ofacquiring the software without the requested terms.⋆ If not, consideration of alternative vendors and software maybe appropriate.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 250 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]2. General Issues of Licensing:• Software⋆ is usually licensed, not purchased; and⋆ under licensing agreements, organizations obtain no ownershiprights, even if the organization paid to have the softwaredeveloped.• In general, for domain descriptions and requirementsprescriptions,⋆ a license should clearly define permitted users and sites.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 251 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20093. Copyright:invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]• Proprietary as well as open-source software⋆ are protected by copyright laws.• If need be then clients and vendors⋆ must make sure that also their⋆ domain descriptions and requirements prescriptions⋆ are protected by being proprietary.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 252 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]4. Domain, Reqs. and Softw. Devt. Specs.:• Contracts for the development of custom⋆ domain descriptions,⋆ requirements prescriptions, and⋆ software designmust be very specific aboutPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 253 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details, Domain, Reqs. and Softw. Devt. Specs. ]⋆ the scope and span of domain descriptions and requirementsprescriptions,⋆ that requirements prescriptions build on accepted domaindescriptions,⋆ that requirements prescriptions are feasible and satisfiable,⋆ and that software designs build on accepted requirementsprescriptions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 254 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]5. Performance Standards:• This issue relates to requirements and software.⋆ When the requirements prescriptions are claimed feasible andsatisfiable,⋄ then there must be software that satisfies the requirements.⋄ These requirements also include performance requirements,⋄ part of the machine requirements to be (very lightly) coveredlater.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 255 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]6. Documentation, Modification, Updates andConversion:• A licensing or development agreement⋆ should require vendors to deliver appropriate documentation.⋆ This should include all kinds of documentation —⋆ such as defined later.• A license or separate maintenance agreement⋆ should address the availability⋆ and cost of document updates and modifications.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 256 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contract Details ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible7. Bankruptcy:/home/db/de/dek1/dek1.tex• In addition to escrow agreements,• organizations should consider the⋆ need for other clauses in licensing agreements⋆ to protect against the risk of a vendor bankruptcy.• For mission-critical software,⋆ organizations should consult with their legal counsel⋆ on how best to deal with the Bankruptcy laws,⋆ which typically gives a bankrupt vendor discretion⋆ to determine which of its executory contracts it will continue to perform⋆ and which it will reject.• Proper structuring of the contract⋆ can help an organization protect its interests if a vendor becomes insolvent.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 257 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]8. Regulatory Requirements:• Domain descriptions, requirements prescriptions and softwaredesigns⋆ must individually often have to comply with⋄ national (state and federal),⋄ regional (NAFTA, EU, etc.),⋄ and/or international (ICAO, IMO, etc.)regulatory agency requirements.• These compliance requirements must be clearly stated in thecontract.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 258 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contract Details ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible9. Payments:/home/db/de/dek1/dek1.tex• Software development contracts normally call for partial payments at specifiedmilestones, with final payment due after completion of acceptance tests.• Organizations should structure payment schedules so developers haveincentives to complete the project quickly and properly.• Properly defined milestones can break development projects into deliverablesegments so an organization can monitor the developer’s progress and identifypotential problems.• Contracts should detail all features and functions the delivered software willprovide.• If a vendor fails to meet any of its express requirements, organizations shouldretain the right to reject the tendered product and to withhold payment untilthe vendor meets all requirements.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 259 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]10. Representations and Warranties:• Organizations should seek an express representation andwarranty —⋆ this is a statement by which one party gives certain assurances⋆ to the other,⋆ and on which the other party may rely —in the document deliverables,⋆ that the licensed documentation⋆ whether a domain description⋆ a requirements prescriptions,⋆ or a software design (incl. code)does not infringe upon the intellectual property rights of anythird parties.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 260 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200911. Dispute Resolution:invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]• Organizations should consider including dispute resolutionprovisions in contracts and licensing agreements.⋆ Such provisions enhance an organization’s ability to resolveproblems expeditiously⋆ and may provide for continued software development⋆ during a dispute resolution period.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 261 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]12. Agreement Modifications:• Organizations should ensure software licenses clearly state⋆ that vendors cannot modify agreements⋆ without written signatures from both parties.⋆ This clause helps ensure there are no inadvertent modifications⋆ through less formal mechanisms some states may permit.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 262 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Contracts and Design Briefs, Contract Details ]Dines Bjorner: 1st DRAFT: January 2, 200913. Vendor Liability Limitations:invisible/home/db/de/dek1/dek1.tex• Some vendors may propose contracts that contain clauseslimiting their liability.⋆ They may add provisions that disclaim all express or implied warranties orthat limit monetary damages to the value of the product itself, specificliquidated damages, etc..⋆ Generally, courts uphold these contractual limitations on liability incommercial settings unless they are unconscionable.⋆ Therefore, if organizations are considering contracts, they should considerwhether the proposed damage limitation bears an adequate relationship tothe amount of loss the financial organization might reasonably experience asa result of the vendor’s failure to perform its obligations.⋆ Broad exculpatory clauses that limit a vendor’s liability are a dangerouspractice that could adversely affect the soundness of an organizationbecause organizations could be injured and have no recourse.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 263 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200914. IT Security:invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]• We interpret this contract aspect only in the light of software.There is an ISO recommendation of IT Security:⋆ INTERNATIONAL ISO/IEC STANDARD 17799⋆ Reference number ISO/IEC 17799:2005(E),⋆ ISO/IEC 2005, ISO/IEC 17799:2005(E),⋆ Information technology, Security techniques: Code of practice forinformation security management,⋆ ISO copyright office, Case postale 56, CH-1211 Geneva 20, Switzerland.E-mail copyright@iso.org, Web www.iso.org. Published in Switzerland.Second edition, 2005-06-15.We advice clients and developers to carefully adhere to that ISOrecommendation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 264 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]15. Subcontracting and Multiple Vendor Relationships:• Some software vendors may contract third parties to developsoftware for their clients.⋆ To provide accountability, it may be beneficial fororganizations to designate a primary contracting vendor.⋆ Organizations should include a provision specifying that theprimary contracting vendor is responsible for the softwareregardless of which entity designed or developed the software.⋆ Organizations should also consider imposing notification andapproval requirements regarding changes in vendor’s significantsubcontractors.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 2 Lecture: 6. Slide: 265 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs, Contract Details ]16. Restrictions and Adverse Comments:• Some software licenses include a provision prohibiting licenseesfrom disclosing adverse information about the performance of thesoftware to any third party.⋆ Such provisions could inhibit an organization’s participation inuser groups, which provide useful shared experience regardingsoftware packages.⋆ Accordingly, organizations should resist these types ofprovisions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 15, Subsect. 3 Lecture: 6. Slide: 266 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Contracts and Design Briefs ]Design BriefsCharacterisation 49 (Design Brief) By a designbrief design!brief we understand.• a clearly delineated subset text of the contract.⋆ This text (bullet three) describes what is being contracted forpossibly mutual deliveries, by dates, by contents, by quality, etc.,and⋆ (bullet four) it details the specific development principles,techniques and tools;• that is, the design brief directs the developers, the providers ofwhat the contract primarily designates,• as to what, how and when to develop what is being contractedPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 16 Lecture: 6. Slide: 267 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents ]Development LogbookCharacterisation 50 (Logbook) By a logbooklogbook weunderstand.• a record, a set of notes,• which as correctly as is humanly feasible,• lists the⋆ development, release, installation, use, maintenance,etc., history of a projectA logbook serves as a necessary reference in innumerable, usuallyunforeseeable instances of development.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 16 Lecture: 6. Slide: 268 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Logbook ]Dines Bjorner: 1st DRAFT: January 2, 2009Example 13 (Logbook) An “abstracted” . . . (dot, dot, dot) example is:2 Jan. 1991: Initial meeting between partners &c....31 May 1993: Acceptance of domain model &c....24 October 1994: Acceptance of requirements model &c....3 June 1996: Acceptance of software delivery &c....The &c. signify reports, and the . . . signify other logbook entries. .invisible/home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 1 Lecture: 6. Slide: 269 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents ]Discussion of Informative DocumentationGeneral• We have identified some useful components of informative document parts.• There may be other such informative parts. It all may depend on the universe ofdiscourse, i.e., the problem at hand.• We thus encourage the software developer to carefully reflect on which are thenecessary and sufficient informative document parts.• There is usually a separate set of informative documents to be worked out foreach phase of development:⋆ the domain phase,⋆ the requirements phase, and⋆ the software design phase.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 1 Lecture: 6. Slide: 270 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Discussion of Informative Documentation, General ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The current situation, needs, ideas, concepts, scope, span, synopsis and contractdocument parts differ in content between these phases.• Usually the informative document parts, although crucially important, need notrequire excessive resources to develop, but their development must still be verycareful!• In general, the informative document parts are concerned with thesocioeconomic, even geopolitical, and hence pragmatic context of the projectsabout which they inform.• As such they are “fluid”, i.e., less precise, in what they aim at and what theirobjectives are.• The next two documentation kinds are, in that respect, much more precise, andmuch more focused./home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 271 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.tex[ Informative Documents, Discussion of Informative Documentation ]Methodological Consequences: Principle, Techniques and ToolsPrinciple 1 (Information Document Construction) Whenfirst contemplating a new software development project,.• make sure — as the very first thing —• to establish a proper complement of (all) informative documents.• Throughout the entire development and after —• during the entire lifetime of the result,⋆ whether a domain model,⋆ or a requirements model,⋆ or a software system —• maintain this set of informative documentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 272 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Discussion of Informative Documentation, Methodological Consequences: Principle, Techniques and Tools ]Dines Bjorner: 1st DRAFT: January 2, 2009Principle 2 (Information Documents) The informativedocuments must be authoritative,.invisible• definitive and• interesting to read/home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 273 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Discussion of Informative Documentation, Methodological Consequences: Principle, Techniques and Tools ]Dines Bjorner: 1st DRAFT: January 2, 2009Technique 1 (Information Document Construction) Firstestablish a document embodying the fullest possible table of contents,whether forinvisible• just a/home/db/de/dek1/dek1.tex⋆ domain development, or a⋆ requirements development, or a⋆ software design project,• or for a combination of these.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 274 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Informative Documents, Discussion of Informative Documentation, Methodological Consequences: Principle, Techniques and Tools ]Then fill in respective document parts,invisible• “little by little”, just a few sentences,• using terse, precise, i.e., concise language,• while avoiding descriptions (prescriptions and specifications) andanalyses.Throughout maintain clear monitoring and control of all versions ofthese documents./home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 275 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Discussion of Informative Documentation, Methodological Consequences: Principle, Techniques and Tools ]Dines Bjorner: 1st DRAFT: January 2, 2009Tool 1 (Information Document Construction) A textprocessing system, preferably LATEX, but MS Word will do,.invisible• with good cross-referencing facilities, even between separately‘compilable’ documents,• provides a ‘minimum’ tool of documentation.• Add to this a reasonably capable version monitoring and controlsystem (such as CVS) and you have a workable system/home/db/de/dek1/dek1.texPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.3, Sect. 17, Subsect. 2 Lecture: 6. Slide: 276 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek1/dek1.texEnd of Lecture 6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek2/dek2The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 7. Slide: 277 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 7. Slide: 278 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2Lecture 7: Stakeholder Identification and LiaisonPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.4, Sect. 1 Lecture: 7. Slide: 279 of 894/home/db/de/dek2/dek2Stakeholder Identification and LiaisonCharacterisationsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Characterisation 51 (Stakeholder) By a domain stakeholderwe shall understand.• a person, or a group of persons, “united” somehow in their commoninterest 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, ordependency on the domainPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 1 Lecture: 7. Slide: 280 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Stakeholder Identification and Liaison, Characterisations ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 52 (General Application Domain Stakeholder)By general application domain stakeholders we understandstakeholders whose primary interestinvisible/home/db/de/dek2/dek2⋆ is neither the projects which develop software (from domains, viarequirements to software design),⋆ nor the products evolving from such projects.• Instead we mean stakeholders from• typically non-IT business areas.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 2 Lecture: 7. Slide: 281 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2[ Domain Stakeholder Identification and Liaison ]Why Be Concerned About Stakeholders ?• The domain stakeholders are the main sources of domainknowledge.• So the domain engineers must acquire as much and more than theknowledge relevant to describe the domain.• And the domain stakeholders must eventually validate the domainengineers’ domain description.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 3 Lecture: 7. Slide: 282 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2[ Domain Stakeholder Identification and Liaison ]How to Establish List of Stakeholders ?• Awareness, by the domain engineers,⋆ of who and which are the main and the subordinate domain“players”,⋆ is obtained by the same initial processes that first acquiredomain knowledge,⋆ namely⋄ by reading about the domain,⋄ from books, journals, the Internet,• The process is an iterative one.⋄ by talking to stakeholders, and⋄ by interviewing these systematically.• One cannot know till “deep” into domain modelling whether onehas obtained a reasonably complete list.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 4 Lecture: 7. Slide: 283 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2• Later lectures outline[ Domain Stakeholder Identification and Liaison ]Form of Contact With Stakeholders⋆ the regular interactions between domain stakeholders and domain engineers⋆ from the early stages of domain acquisition⋆ to the late stage of domain validation.• This form of domain stakeholder and engineers interactionalternates between⋆ one-on-one meetings,⋆ e-mails,⋆ the joint filling out of larger questionnaires, and⋆ joint multi-stakeholder group and domain engineer presentations.• The domain engineers shall carefully keep record of all that iscommunicated.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 4 Lecture: 7. Slide: 284 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Stakeholder Identification and Liaison, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 5 Lecture: 7. Slide: 285 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2[ Domain Stakeholder Identification and Liaison ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 6 Lecture: 7. Slide: 286 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2[ Domain Stakeholder Identification and Liaison ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.4, Sect. 6 Lecture: 7. Slide: 287 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek2/dek2End of Lecture 7Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek3The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 8. Slide: 288 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 8. Slide: 289 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3Lecture 8: Domain AcquisitionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.5, Sect. 1 Lecture: 8. Slide: 290 of 894/home/db/de/dek3Domain AcquisitionAnother Characterisationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Characterisation 53 (Domain Acquisition (II)) By domainacquisition we shall here understand.• the systematic solicitation and elicitation of knowledge about thechosen domain and• the systematic vetting, recording and classification of thisknowledgeCompare the above characterisation to that of Characterisation 41 onpage 170.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 2 Lecture: 8. Slide: 291 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition ]Sources of Domain Knowledge• To return to the issue of stakeholders,⋆ from where does the domain engineer acquire the domainknowledge ?• The answer is:⋆ from many (stakeholder) sources.• We suggest some sources:⋆ from the Internet,⋆ from books, papers, etc.,⋆ from owners and staff of the client,⋆ from customers of the client,⋆ possibly from domain regulators,⋆ from consultancy, equipment andservice providers for and to the clientand⋆ possibly others.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 3, Subsect. 1 Lecture: 8. Slide: 292 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition ]Forms of Solicitation and ElicitationSolicitation• How can the domain engineer solicit the desired domainknowledge ?⋆ By searching the Internet, looking up books, papers and reports;and⋆ by contacting and by asking to be referred to domainknowledgeable client and customer staff.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 3, Subsect. 2 Lecture: 8. Slide: 293 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition, Forms of Solicitation and Elicitation ]Elicitation• How does the domain engineer elicit the desired domainknowledge ?⋆ By studying hopefully relevant⋄ Internet Web pages, books, papers and reports and⋄ by forming “impressions of” the domain;and⋆ by interviewing (“questionnairing”) contacted domainstakeholders,⋄ with interviews being based on the prior ‘impressions’.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 3, Subsect. 3 Lecture: 8. Slide: 294 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition, Forms of Solicitation and Elicitation ]Solicitation and Elicitation• Solicitation and elicitation is an iterative process:⋆ Impressions obtained early in the process may turn out to bewrong.⋆ Hence they must be scrapped and lead to reevaluation of theacquisition process,⋆ and to it being repeated.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 4 Lecture: 8. Slide: 295 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3• The aims of elicitation[ Domain Acquisition ]Aims and Objectives of Elicitation⋆ is to cover the span of the domain⋆ as accurately and fully as possible.• The objectives of elicitation⋆ is to obtain “bits and pieces” — and hopefully much more –⋆ of relevant domain knowledge within the scope of the domainbeing studied.• We shall refer to the ‘bits and pieces’ of domain knowledge asdomain description units.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 5, Subsect. 1 Lecture: 8. Slide: 296 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition ]Domain Description UnitsCharacterisationCharacterisation 54 (Domain Description Unit) By a domain descriptionunit.• we shall mean an as far as possible well-formed sentence,• something which names and describes some⋆ entity,⋆ function,of the domain,⋆ event or⋆ behaviour• that is, something expressible which “makes sense”,• that is, which can contribute to the modelling of⋆ an entity,⋆ a function,⋆ an event or⋆ a behaviourPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 5, Subsect. 2 Lecture: 8. Slide: 297 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition, Domain Description Units ]Handling• Thus domain acquisition amounts to⋆ the laborious,⋆ painstaking⋆ process of• In preparation⋆ collecting (storing)⋆ “zillions”⋆ of domain description units.⋆ for the ongoing, say concurrent⋆ domain analysis and concept formation process⋆ domain description units are provided with attributes such as⋄ name(s),⋄ kinds,⋄ source, and⋄ date(s).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 5, Subsect. 2 Lecture: 8. Slide: 298 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 6 Lecture: 8. Slide: 299 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 7 Lecture: 8. Slide: 300 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3[ Domain Acquisition ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.5, Sect. 7 Lecture: 8. Slide: 301 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek3End of Lecture 8Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek4/dek4The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 9. Slide: 302 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 9. Slide: 303 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4Lecture 9: Business ProcessesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.6, Sect. 1 Lecture: 9. Slide: 304 of 894/home/db/de/dek4/dek4Business ProcessesCharacterisationCharacterisation 55 (Business Process) By a businessprocess business processprocess!businesswe understand.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• the procedurally describable aspects, of one of the (possibly many)ways in which a business, an enterprise, a factory, etc.,• conducts its yearly, quarterly, monthly, weekly and daily processes,that is, regularly occurring chores.⋆ The process may involve strategic, tactical or operational management andwork-flow planning and decision activities; or⋆ the administrative, and, where applicable, the marketing, the research anddevelopment, the production planning and execution, the sales and the service(work-flow) activities — to name somePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 2 Lecture: 9. Slide: 305 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain. i.e., Business Processes ]Business Process Description• A business process description is usually in the form of⋆ a behaviour description which covers⋆ core entities, functions and events.• Usually one describes several (more or less related) businessprocessesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 3, Subsect. 1 Lecture: 9. Slide: 306 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain, i.e., Business Processes ]Aims & Objectives of Business Process DescriptionAims• The aims of describing a set of domain business processes⋆ is to cover all the “standard”, i.e., all the most common⋆ as well as a reasonable number of the more special⋆ business processes of the chosen span and scope⋆ while covering most of the entities, functions and events⋆ that were identified is the full set of domain description units.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 3, Subsect. 2 Lecture: 9. Slide: 307 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain, i.e., Business Processes, Aims and Objectives of Business Process Description ]Objectives• The objectives of describing a set of domain business processes⋆ is to discover domain entities, functions and events⋆ that were omitted from, i.e., are not found in the⋆ the full set of domain description units;⋆ that is, to somehow “test” and validate⋆ the domain acquisition stage.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 4 Lecture: 9. Slide: 308 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain, i.e., Business Processes ]Disposition• So what do we do if and when we find that the⋆ full set of domain description units⋆ and the rough-sketched domain business processes⋆ are at odds ?• We obviously have to inquire with the relevant domain stakeholders.⋆ Based on their “feedback” we have to modify⋆ the full set of domain description units⋆ as well as the rough-sketched domain business processes.• This is an iterative process⋆ and may involve modifying⋆ the domain analysis and concept formation findings.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 4 Lecture: 9. Slide: 309 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain, i.e., Business Processes, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 5 Lecture: 9. Slide: 310 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain, i.e., Business Processes ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 6 Lecture: 9. Slide: 311 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4[ Domain, i.e., Business Processes ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.6, Sect. 6 Lecture: 9. Slide: 312 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek4/dek4End of Lecture 9Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek5/dek5The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 10. Slide: 313 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 10. Slide: 314 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5Lecture 10: Domain Analysis and Concept FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.7 Lecture: 10. Slide: 315 of 894/home/db/de/dek5/dek5Domain Analysis and Concept Formation• Given a suitable set,⋆ not necessarily what may be believed to be a reasonablycomplete set,• of reasonably related domain description units,c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31⋆ where, by ‘related’, we mean domain description units that⋆ contain overlapping (names of) entities, functions, events andbehaviours,• one can start analysing these domain description units.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 1, Subsect. 1 Lecture: 10. Slide: 316 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• First some preliminaries./home/db/de/dek5/dek5[ Domain Analysis and Concept Formation ]CharacterisationsConsistencyCharacterisation 56 (Consistency) By consistency of a set oftwo or more domain description units.• we mean that no combination of any subset of these• contradicts another combination of a subset of thesePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 1, Subsect. 2 Lecture: 10. Slide: 317 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Characterisations ]ContradictionCharacterisation 57 (Contradiction) By two different sets ofdomain description units being in contradiction of one another.• we mean that one can claim a property• and its negation• to hold in the model of the domain description unitsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 1, Subsect. 3 Lecture: 10. Slide: 318 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Characterisations ]CompletenessCharacterisation 58 (Relative Completeness) By relativecompleteness of a set of domain description units.• we mean a consistent set of domain description units• which allows a meaningful modelling of what is being described• such that the model does not leave something accidentallyundefined• That is, we can perfectly well imagine that we leave• some domain aspects purposely undefined.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 1, Subsect. 4 Lecture: 10. Slide: 319 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Characterisations ]ConflictCharacterisation 59 (Conflict) By a conflict of a set of domaindescription units.• we mean an inconsistency• that cannot be resolved by the domain engineer• only discussing the conflicting domain description units• with the stakeholders from whom the units are elicitedPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 1, Subsect. 4 Lecture: 10. Slide: 320 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Characterisations, Conflict ]• There are three cases of conflict resolution.⋆ (i) A single stakeholder is assumed not to generate conflicts.⋆ (ii) Two or more stakeholders from the same stakeholder groupshould be able, together with the domain engineers, to resolvethe conflict.⋆ (iii) Two or more stakeholders from different stakeholder groupsmay, together with the domain engineers, have to refer to theirmanagement for resolution.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 2, Subsect. 1 Lecture: 10. Slide: 321 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation ]Aims and Objectives of Domain AnalysisAims of Domain AnalysisCharacterisation 60 (Domain Analysis, Aims) By domainanalysis we mean.• a systematic study of all domain description units,• that is a “close reading and review” of these• whose aim is to cover them allPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 2, Subsect. 2 Lecture: 10. Slide: 322 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Aims and Objectives of Domain Analysis ]Objectives of Domain AnalysisCharacterisation 61 (Domain Analysis, Objectives) Bydomain analysis objectives we mean.• a domain analysis• whose objective it is⋆ to find [all] inconsistencies and [all] incompletenesses,⋆ to remove these, and⋆ to ensure a relatively scope-complete set of consistent domaindescription unitsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 3 Lecture: 10. Slide: 323 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation ]Concept Formation• In addition to detecting inconsistencies, conflicts andincompleteness• of a set of domain description units,• domain analysis also has as objective to possibly form concepts.Characterisation 62 (Domain Concept) By a domain concept.• we mean a concept, an abstraction, a mental construction,• which captures all essential properties• and “suppresses” expression of properties deemed not essentialPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 3, Subsect. 1 Lecture: 10. Slide: 324 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ Domain Analysis and Concept Formation, Concept Formation ]Aims and Objectives of Domain Concept Formation• The aim of domain concept formation⋆ is to focus on similarities of⋆ domain phenomena or already defined domain concepts⋆ and, from these possibly form new, usually more genericconcepts.• The objective of domain concept formation is to arrive⋆ at simpler domain models,⋆ at generic domain models, that is, models which cover severalmore concrete, i.e., instantiated domains.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 3, Subsect. 1 Lecture: 10. Slide: 325 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ , The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 4 Lecture: 10. Slide: 326 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 5 Lecture: 10. Slide: 327 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5[ ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.7, Sect. 5 Lecture: 10. Slide: 328 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek5/dek5End of Lecture 10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek6/dek6The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 11. Slide: 329 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 11. Slide: 330 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6Lecture 11: TerminologyPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.8, Sect. 1 Lecture: 11. Slide: 331 of 894/home/db/de/dek6/dek6TerminologyThe ‘Terminology’ Dogma• It is an important aspect of domain engineering⋆ to establish,⋆ use and⋆ maintain⋆ a domain terminology.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 2 Lecture: 11. Slide: 332 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]CharacterisationsCharacterisation 63 (Term) By a term is here meant:.• a word or phrase used in a definite or precise sense• in some particular subject, as a science or art;• a technical expression;• by word or group of words expressing a notion or conception,• or denoting an object of thoughtPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 2 Lecture: 11. Slide: 333 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Terminology, Characterisations ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 64 (Terminology) By terminology is meant:• the doctrine or scientific study of terms;• the system of terms belonging to a science or subject;• technical terms collectively;• nomenclature.invisible/home/db/de/dek6/dek6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 3 Lecture: 11. Slide: 334 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]Term Definitions• Thus a terminology is a set of definitions⋆ consisting of a “left-hand side” definiendum, usually a name,“the term”, of that which is to be defined,⋆ and a “right-hand side” definiens, the expression which defines.• The definiens expression⋆ may either contain ground terms,⋄ that is, terms that are taken for understood,⋄ and the definiens expression is then called an atomic expression;⋆ or it contains other terms⋄ being defined in the terminology⋄ and the definiens expression is then called a composite expression.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 3 Lecture: 11. Slide: 335 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Terminology, Term Definitions ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6• A set of term definitions form a well-formed terminology⋆ if all professional, i.e., domain-specific terms are defined,⋆ and, although some terms may be (mutually) recursively defined,⋆ these recursions do terminate by means of alternative definitionchoices.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 4 Lecture: 11. Slide: 336 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]Aims and Objectives of a Terminology• The aims of a domain terminology (i.e., of domainterminologisation)⋆ is to cover all the terms that are specific to the domain.• The objectives of a domain terminology (i.e., of domainterminologisation)⋆ is to ensure that all stakeholders,⋆ the developers and⋆ the domain description readers⋆ obtain as near, if not, the same understanding of the recordedterms.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 5 Lecture: 11. Slide: 337 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]How to Establish a Terminology• First a set of terms to be defined is selected.• Then each term is defined,⋆ either atomically,⋆ or in composite manner, possibly recursively.• The definition ends⋆ when all selected terms have been defined⋆ and all uses of domain-specific terms⋆ not already in the list of selected terms have been defined.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 5 Lecture: 11. Slide: 338 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Terminology, How to Establish a Terminology ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• As can be seen from the above procedure/home/db/de/dek6/dek6⋆ it requires careful administration⋆ and usually ends up in a prolonged, iterated process.• When defined informally,⋆ the domain engineer may wish to use pictures, diagrams.• When defined formally⋆ one may have to prove that the definitions are sound.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 5 Lecture: 11. Slide: 339 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Terminology, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 6 Lecture: 11. Slide: 340 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 7 Lecture: 11. Slide: 341 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6[ Domain Terminology ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.8, Sect. 7 Lecture: 11. Slide: 342 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek6/dek6End of Lecture 11Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek7/dek7aThe Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 12. Slide: 343 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 12. Slide: 344 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7aLecture 12: Domain Modelling: An OverviewPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.9, Sect. 1 Lecture: 12. Slide: 345 of 894/home/db/de/dek7/dek7aDomain Modelling: An OverviewAims & Objectivesc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• The aims of the domain modelling stage of domain engineering are⋆ to research the chosen domain,⋆ to find suitable delineations within⋆ and structures of that domain.• The objectives of the domain modelling stage of domainengineering are⋆ to develop narrative and formal descriptions of the domain,⋆ to analyse those descriptions,⋆ and hence to establish a and contribute to a theory of thatdomain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 2 Lecture: 12. Slide: 346 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7a[ Domain Modelling: An Overview ]Domain Facets• In this, a major methodology part of the current presentation, weshall start unravelling a number of principles, techniques of and atool (RSL) for domain modelling.• Domain modelling, as we shall see, entails modelling a number ofdomain facets.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 2 Lecture: 12. Slide: 347 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: An Overview, Domain Facets ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 65 (Domain Facet) By a domain facet wemean.invisible• one amongst a finite set of generic ways• of analysing a domain:• a view of the domain,• such that the different facets cover conceptually different views,• and such that these views together cover the domain/home/db/de/dek7/dek7aPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 3 Lecture: 12. Slide: 348 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7a[ Domain Modelling: An Overview ]Describing Facets• These are the facets that we find “span” a domain in apragmatically sound way:⋆ intrinsics,⋆ support technology,⋆ management & organisation,• There may be other ways in which to view,⋆ that is, to understand the domain.⋆ rules & regulations,⋆ scripts and⋆ human behaviour:• That is, there may be other compositions of other “facets”,⋆ which together also “span” the domain.• The ones listed above, (i–vi), are the ones we shall pursue.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 3 Lecture: 12. Slide: 349 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: An Overview, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7aPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 4 Lecture: 12. Slide: 350 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7a[ Domain Modelling: An Overview ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 5 Lecture: 12. Slide: 351 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7a[ Domain Modelling: An Overview ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.9, Sect. 5 Lecture: 12. Slide: 352 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7aEnd of Lecture 12Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek7/dek7The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 13. Slide: 353 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 13. Slide: 354 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7Lecture 13: Domain Modelling: IntrinsicsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.10 Lecture: 13. Slide: 355 of 894/home/db/de/dek7/dek7Domain Modelling: IntrinsicsCharacterisation 66 (Domain Intrinsics) By domainintrinsics we mean.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• those phenomena and concepts of a domain which are basic to anyof the other facets (listed earlier and treated, in some detail, below),• with such domain intrinsics initially covering at least one specific,hence named, stakeholder view• By studying just the domain intrinsics⋆ we get to understand a, or rather, the essence of the domain.• If we remove any one aspect of the domain intrinsics⋆ then we jeopardise our understanding of the domain.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.1 Lecture: 13. Slide: 356 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics ]Construction of Model of Domain Intrinsics• So the domain engineer,⋆ on the basis of analysed and possibly abstracted⋆ domain description units⋆ must construct a domain intrinsics model.• The model consists, we advocate, of two complimentary parts:⋆ a narrative description and⋆ a formal description.• The usual description principles and techniques apply:⋆ these are shown applied in the support example that complements this volume;⋆ we advice the student to study that example carefully: learn by reading.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.2 Lecture: 13. Slide: 357 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics ]Overview of Support ExamplePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.2, Subsect. 1 Lecture: 13. Slide: 358 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics, Overview of Support Example ]EntitiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.2, Subsect. 2 Lecture: 13. Slide: 359 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics, Overview of Support Example ]OperationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.2, Subsect. 3 Lecture: 13. Slide: 360 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics, Overview of Support Example ]EventsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.2, Subsect. 4 Lecture: 13. Slide: 361 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics, Overview of Support Example ]BehavioursPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.3 Lecture: 13. Slide: 362 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.4 Lecture: 13. Slide: 363 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7[ Domain Modelling: Intrinsics ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.10, Sect.4 Lecture: 13. Slide: 364 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek7/dek7End of Lecture 13Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek8/dek8The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 14. Slide: 365 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 14. Slide: 366 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8Lecture 14: Domain Modelling: Support TechnologiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11 Lecture: 14. Slide: 367 of 894Domain Modelling: Support Technologiesc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 67 (Support Technologies) By domainsupport technologies we meaninvisible/home/db/de/dek8/dek8• ways and means of concretesing• certain observed (abstract or concrete) phenomena or• certain conceived concepts• in terms of (possibly combinations of)⋆ human work,⋆ mechanical,⋆ hydro mechanical,⋆ thermo-mechanical,⋆ pneumatic,⋆ aero-mechanical,⋆ electro-mechanical,⋆ electrical,⋆ electronic,⋆ telecommunication,(possibly computerised) sensor, actuator tools⋆ photo/optoelectric,⋆ chemical, etc.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11 Lecture: 14. Slide: 368 of 894.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.1, Subsect. 1 Lecture: 14. Slide: 369 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8[ Domain Modelling: Support Technologies ]Technology as an Embodiment of Laws of Physics• By technology, we here mean “gadgets” (instruments, machines, artifacts) which⋆ somehow or other embody, exploit, rely on, etc.,⋆ laws of physics (including chemistry).• UsuallyFrom Abstract Domain States to Concrete Technology States⋆ an intrinsic domain phenomenon or concept⋆ embody an abstract notion of state.• The essence of a support technology⋆ is then to render⋆ such an abstract notion of state⋆ more concrete.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.2 Lecture: 14. Slide: 370 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8[ Domain Modelling: Support Technologies ]Intrinsics versus Other Facets• Take as “other facets” those of supporting technologies.• The nature of intrinsics in the light of a supporting technology is⋆ to force the domain engineer to think abstractly⋆ in order to capture an essence of a phenomenon or concept of the domain,⋆ not by its “implementing” support technologies, i.e., the how,⋆ but by what that domain phenomenon or concept really means, semantically.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.3 Lecture: 14. Slide: 371 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8[ Domain Modelling: Supporting Technologies ]The Support Example[s]• The points made on the previous slide are illustrated in the⋆ examples of an intrinsic concepts of states versus the⋆ examples of a corresponding support technology concepts of states⋆ (intrinsics)⋆ (intrinsics)⋆ (intrinsics)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.3 Lecture: 14. Slide: 372 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Supporting Technologies, The Support Example[s] ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.4 Lecture: 14. Slide: 373 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8[ Domain Modelling: Intrinsics ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.5 Lecture: 14. Slide: 374 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8[ Domain Modelling: Intrinsics ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.11, Sect.5 Lecture: 14. Slide: 375 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek8/dek8End of Lecture 14Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek9/dek9The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 15. Slide: 376 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 15. Slide: 377 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009Lecture 15: Domain Modelling: Management and Organisationinvisible/home/db/de/dek9/dek9Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.12, Sect.1 Lecture: 15. Slide: 378 of 894/home/db/de/dek9/dek9Domain Modelling: Management and OrganisationManagement• Management is an elusive term.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• Business schools and private consultancy firms excel in offering degrees and 2–3day courses in ‘management’.• In the mind of your author most of what is being taught — and even researched— is a lot of “hot air”.• Well, the problem here, is, of course, that your author was educated at a science& technology university.• In the following we shall repeat some of this ‘hot air ’.• And after that we shall speculate on how to properly describe the outlined (“coldair”) management concepts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1 Lecture: 15. Slide: 379 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management ]Dines Bjorner: 1st DRAFT: January 2, 2009Characterisation 68 (Domain Management) By domain managementwe mean people.invisible/home/db/de/dek9/dek9• (i) who determine, formulate and thus set standards (cf. rules and regulations, alater lecture topic) concerning⋆ strategic, tactical and operational decisions;• (ii) who ensure that these decisions are passed on to (lower) levels ofmanagement, and to “floor” staff;• (iii) who make sure that such orders, as they were, are indeed carried out;• (iv) who handle undesirable deviations in the carrying out of these orders cumdecisions;• and (v) who “backstop” complaints from lower management levels and from floorstaffPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 1 Lecture: 15. Slide: 380 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Management Issues• Management in simple terms means the act of getting people together toaccomplish desired goals.• Management comprises⋆ (vi) planning,⋆ (vii) organizing,⋆ (viii) resourcing,⋆ (ix) leading or directing, andor effort• for the purpose of accomplishing a goal.• Resourcing encompasses the⋆ (xi) deployment and manipulation ofhuman resources,⋆ (xii) financial resources,⋆ (x) controlling an organization⋆ (a group of one or more people orentities)⋆ (xiii) technological resources, and⋆ (xiv) natural resourcesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 2 Lecture: 15. Slide: 381 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Management and Organisation, Management ]Basic Functions of ManagementThese are normally seen as management issues:invisible/home/db/de/dek9/dek9• Planning:⋆ (xv) deciding what needs to happen in the future⋆ (today, next week, next month, next year, over the next 5 years, etc.)⋆ (xvi) and generating plans for action.• Organizing:⋆ (xvii) making optimum use of the resources⋆ (xix) required to enable the successful carrying out of plans.• Leading/Motivating:⋆ (xx) exhibiting skills in these areas⋆ (xxi) for getting others to play an effective part in achieving plans.• Controlling:⋆ (xxii) monitoring –⋆ (xxiii) checking progress against plans,⋆ (xxiv) which may need modification based on feedback.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 3 Lecture: 15. Slide: 382 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Formation of Business Policy• (xxvi) The mission of a business seems to be its most obviouspurpose – which may be, for example, to make soap.• (xxvii) The vision of a business is seen as reflecting its aspirationsand specifies its intended direction or future destination.• (xxviii) The objectives of a business refers to the ends or activityat which a certain task is aimed.• The business policy is a guide that stipulates⋆ (xix) rules, regulations and objectives,⋆ (xxx) and may be used in the managers’ decision-making.⋆ (xxxi) It must be flexible and easily interpreted and understoodby all employees.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 3 Lecture: 15. Slide: 383 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Formation of Business Policy• The business strategy refers to⋆ (xxxii) the coordinated plan of action that it is going to take,⋄ (xxxiii) as well as the resources that it will use, to realize itsvision and long-term objectives.⋄ (xxxiv) It is a guideline to managers, stipulating how theyought to allocate and utilize the factors of production to thebusiness’s advantage.⋄ (xxxv) Initially, it could help the managers decide on whattype of business they want to form.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 4 Lecture: 15. Slide: 384 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Implementation of Policies and Strategies• (xxxvi) All policies and strategies are normally discussed withmanagerial personnel and staff.• (xxxvii) Managers usually understand where and how they canimplement their policies and strategies.• (xxxviii) A plan of action is normally devised for the entirecompany as well as for each department.• (xxxix) Policies and strategies are normally reviewed regularly.• (xxxvii) Contingency plans are normally devised in case theenvironment changes.• (xl) Assessments of progress are normally and regularly carried outby top-level managers.• (xli) A good environment is seen as required within the business.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 5 Lecture: 15. Slide: 385 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Development of Policies and Strategies• (xlii) The missions, objectives, strengths and weaknesses of eachdepartment or normally analysed to determine their rôles inachieving the business mission.• (xliii) Forecasting develops a picture of the business’s futureenvironment.• (xliv) Planning unit are often created to ensure that all plans areconsistent and that policies and strategies are aimed at achievingthe same mission and objectives.• (xlv) Contingency plans are developed — just in case !• (xlvi) Policies are normally discussed with all managerial personneland staff that is required in the execution of any departmentalpolicy.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 6 Lecture: 15. Slide: 386 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Management Levels• A careful analysis has to be made by the domain engineer of how management isstructured in the domain being described.• One view, but not necessarily the most adequate view for a given domain is thatmanagement can be seen as composed from⋆ the board of directors (representing owners, private or public, or both),⋆ the senior level or strategic (or top, upper or executive) management,⋆ the mid level or tactical management,⋆ the low level or operational management, and⋆ supervisors and team leaders.• Other views, other “management theories” may apply.• We shall briefly pursue the above view.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 7 Lecture: 15. Slide: 387 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Resources• Management is about resources.• A resource is any physical or virtual entity of limited availabilitysuch as, for example,⋆ time and (office, factory, etc.) space,⋆ people (staff, consultants, etc.),⋆ equipment (tools, machines, computers, etc.),⋆ capital (cash, goodwill, stocks, etc.), etcetera.• Resources have to be managed⋆ allocated (to [factory, sales, etc.] processes, projects, etc.), and⋆ scheduled (to time slots).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 8 Lecture: 15. Slide: 388 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Resource Conversion• Resources can be traded for other resources:⋆ capital funds can be spent on acquiring space, staff andequipment,⋆ services and products can be traded for other such or for monies,⋆ etc.• The decisions as to who schedules, allocates and converts resources• are made by strategic and tactical management.• Operational management transforms abstract, general schedulesand allocations into concrete, specific such.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 9 Lecture: 15. Slide: 389 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Strategic Management• A strategy is a long term plan of action designed to achieve a particular goal.• Strategy is differentiated from⋆ tactics or⋆ immediate actions with resourcesat hand• by its nature of being⋆ extensively premeditated,⋆ and often practically rehearsed.• Strategies are used to make business problems easier to understand and solve.• Strategic management deals⋆ with conversion of long term resources involving financial issues⋆ and with long term scheduling issues.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 9 Lecture: 15. Slide: 390 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Strategic Management ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Among examples of strategic management issues (in supply chain management)we find:/home/db/de/dek9/dek9⋆ (xlvii) strategic network optimization, including the number, location, and sizeof warehouses, distribution centers and facilities;⋆ (xlviii) strategic partnership with suppliers, distributors, and customers,creating communication channels for critical information and operationalimprovements such as cross docking, direct shipping, and third-party logistics;⋆ (xlix) product design coordination, so that new and existing products can beoptimally integrated into the supply chain, load management;⋆ (l) information technology infrastructure, to support supply chain operations;⋆ (li) where-to-make and what-to-make-or-buy decisions; and⋆ (lii) aligning overall organizational strategy with supply strategy.• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 9 Lecture: 15. Slide: 391 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Strategic Management ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9• Strategic management⋆ requires knowledge of management rôles and skills;⋆ have to be aware of external factors such as markets;⋆ decisions are generally of a long-term nature;⋆ decision are made using analytic, directive, conceptual and/orbehavioral/participative processes;⋆ are responsible for strategic decisions;⋆ have to chalk out the plan and see that plan may be effective inthe future; and⋆ is executive in nature.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 10 Lecture: 15. Slide: 392 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]• Tactical management deals withTactical Management⋆ shorter term issues than strategic management, but⋆ longer term issues than operational management.• Tactical management deals with⋆ allocation and⋆ short term scheduling.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 10 Lecture: 15. Slide: 393 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Tactical Management ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9• Among examples of tactical management issues (in supply chain management)we find:⋆ (lx) sourcing contracts and other purchasing decisions;⋆ (lxi) production decisions, including contracting, locations, scheduling, andplanning process definition;⋆ (lxii) inventory decisions, including quantity, location, and quality ofinventory;⋆ (lxiii) transportation strategy, including frequency, routes, and contracting;⋆ (lxiv) benchmarking of all operations against competitors and implementationof best practices throughout the enterprise;⋆ (lxv) milestone payments; and⋆ (lxvi) focus on customer demand.• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 11 Lecture: 15. Slide: 394 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Operational management/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Operational Management⋆ deals with day-to-day and week-to-week issues⋆ where tactical management deals with month-to-month andquarter-to-quarter issues and⋆ strategic management deals with year-to-year and longer termissues.• (Operational management is⋆ not to be confused with the concept of operational research⋆ and operational analysis⋆ which deals with optimising resource usage⋆ (allocation and scheduling).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 11 Lecture: 15. Slide: 395 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Operational Management ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9• Among examples of operational management issues (in supply chainmanagement) we find:⋆ (lxviii) daily production and distribution planning, including all nodes in thesupply chain;⋆ (lxix) production scheduling for each manufacturing facility in the supplychain (minute by minute);⋆ (lxx) demand planning and forecasting, coordinating the demand forecast ofall customers and sharing the forecast with all suppliers;⋆ (lxxi) sourcing planning, including current inventory and forecast demand, incollaboration with all suppliers;⋆ (lxxii) inbound operations, including transportation from suppliers andreceiving inventory;Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 11 Lecture: 15. Slide: 396 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling, Management and Organisation, Management, Operational Management ]⋆ (lxxiii) production operations, including the consumption ofmaterials and flow of finished goods;⋆ (lxxiv) outbound operations, including all fulfillment activitiesand transportation to customers;⋆ (lxxv) order promising, accounting for all constraints in thesupply chain, including all suppliers, manufacturing facilities,distribution centers, and other customers.• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 12 Lecture: 15. Slide: 397 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9• We make here a distinction[ Domain Modelling: Management and Organisation, Management ]Supervisors and Team Leaders⋆ between managers, “on one side”, and⋆ supervisors and team leaders, “on the other side”.• The distinction is based on⋆ managers being able to make own decisions without necessarily having toconfer or discuss these beforehand or to report these afterwards, while⋆ supervisors and team leaders normally are not expected to make owndecisions:⋄ if they have to make decisions then such are considered to be of “urgency”,⋄ must normally be approved of beforehand, or,⋄ at the very least, reported on afterwards.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 12 Lecture: 15. Slide: 398 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management, Supervisors and Team Leaders ]• Supervisors basically⋆ monitor that work processes are carried out as planned⋆ and report other than minor discrepancies.• Team leaders⋆ coordinate work in a group (“the team”)⋆ while participating in that work themselves;⋆ additionally they are also supervisors.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 13 Lecture: 15. Slide: 399 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Management ]Description of ‘Management’• On the last several slides (379–398) we have outlined conventionalissues of management.• The problems confronting us now are:⋆ Which aspects of domain management are we to describe ?⋆ How are we describe, especially formally, the chosen issues ?• The reason why these two “leading questions” questions are posedis that the management issues mentioned on slides 379–398⋆ are generally “too lofty”, “too woolly”,⋆ that is, are more about “feelings”⋆ than about “hard, observable facts”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 13 Lecture: 15. Slide: 400 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Description of ‘Management’ ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• We, for example, consider the following issues for “too lofty”, “too woolly”:⋆ Item (xix) Slide 381;⋆ Item (xxxv) Slide 383;⋆ Item (xx) Slide 381;⋆ Item (xxxvi) Slide 384;⋆ Item (xxi) Slide 381;⋆ Item (xxxvii) Slide 384;⋆ Item (xxvii) Slide 382;⋆ Item (xxxix) Slide 384;⋆ Item (xxviii) Slide 382;⋆ Item (xli) Slide 384;⋆ Item (xxxi) Slide 382;⋆ Item (xlii) Slide 385;⋆ Item (xxxiii) Slide 383;⋆ Item (xliii) Slide 385;⋆ Item (xxxiv) Slide 383;⋆ etcetera./home/db/de/dek9/dek9Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 13 Lecture: 15. Slide: 401 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Description of ‘Management’ ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9• As we see from the above “quick” analysis⋆ the problems hinge on our [in]ability to⋄ formally,⋄ let alone informallydescribe many management issues.⋆ In a sense that is acceptable⋄ in as much as ‘management’ is clearly accepted as anon-mechanisable process,⋄ one that requires subjective evaluations: “feelings”, “hunches”,⋄ and one that requires informal contacts with other managerialpersonnel and staff.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.1, Subsect. 13 Lecture: 15. Slide: 402 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Management and Organisation, Management, Description of ‘Management’ ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• But still we are left with the problems:/home/db/de/dek9/dek9⋆ Which aspects of domain management are we to describe ?⋆ How are we describe, especially formally, the chosen issues ?• Our simplifying and hence simple answer is:⋆ the domain engineer shall describe⋄ what is objectively observable⋄ or concepts that are precisely defined◦ in terms of objectively observable phenomena◦ and concepts defined from these and such defined concepts.• This makes the domain description task a reasonable one,⋆ one that can be objectively validated⋆ and one where domain description evaluators can objectively judge⋄ whether (projected) requirements involving these descriptions⋄ may be feasible and satisfactory.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.2 Lecture: 15. Slide: 403 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation ]OrganisationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.2, Subsect. 1 Lecture: 15. Slide: 404 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Organisation ].1.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.2, Subsect. 2 Lecture: 15. Slide: 405 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Organisation ].2.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.2, Subsect. 3 Lecture: 15. Slide: 406 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation, Organisation ].3.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.3 Lecture: 15. Slide: 407 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation ]The Support Example[s]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.4 Lecture: 15. Slide: 408 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9[ Domain Modelling: Management and Organisation ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.12, Sect.4 Lecture: 15. Slide: 409 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek9/dek9End of Lecture 15Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek10/dek10The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 16. Slide: 410 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 16. Slide: 411 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10Lecture 16: Domain Modelling: Rules and RegulationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.13 Lecture: 16. Slide: 412 of 894/home/db/de/dek10/dek10Domain Modelling: Rules and Regulations• Human stakeholders act in the domain, whether⋆ clients,⋆ workers,⋆ managers,⋆ suppliers,⋆ regulatory authorities,⋆ or other.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• Their actions are guided and constrained by rules and regulations.• These are sometimes implicit, that is, not “written down”.• But we can talk about rules and regulations as if they wereexplicitly formulated.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13 Lecture: 16. Slide: 413 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations ]• The main difference between rules and regulations is that⋆ rules express properties that must hold and⋆ regulations express state changes that must be effected if rules are observedbroken.• Rules and regulations are directed⋆ not only at human behaviour⋆ but also at expected behaviours of support technologies.• Rules and regulations are formulated⋆ by enterprise staff, management or workers,⋆ and/or by business and industry associations,⋄ for example in the form of binding or guiding⋄ national, regional or international standards,⋆ and/or by public regulatory agencies.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.1 Lecture: 16. Slide: 414 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations ]Domain RulesCharacterisation 69 (Domain Rule) By a domain rule wemean.• some text• which prescribes how people or equipment• are expected to behave when dispatching their duty,• respectively when performing their functionsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.1 Lecture: 16. Slide: 415 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Domain Rules ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Usually the rule text, when written down, appears in some, notnecessarily public documents./home/db/de/dek10/dek10⋆ It is not our intention to formalise these rule texts,⋆ but to formally define the crucial predicates⋆ and, if not already formalised, then also the domain entities overwhich the predicate ranges.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.2 Lecture: 16. Slide: 416 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations ]Domain RegulationsCharacterisation 70 (Domain Regulation) By a domainregulation we mean.• some text• which prescribes what remedial actions are to be taken• when it is decided that a rule has not been followed according to itsintentionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 417 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Domain Regulations ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Usually the regulation text, when written down, appears in some,not necessarily public documents./home/db/de/dek10/dek10⋆ It is not our intention to formalise these rule texts,⋆ but to formally define the crucial functions⋆ and, if not already formalised, then also the domain entities overwhich these functions range.Formalisation of the Rules and Regulations Concepts• Rules, as already mentioned, express predicates, and regulationsexpress state changes.• In the following we shall review a semantics of rules and regulations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 418 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rules and Regulations Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• There are, abstractly speaking, usually three kinds of languagesinvolved wrt. (i.e., when expressing) rules and regulations(respectively when invoking actions that are subject to rules andregulations)./home/db/de/dek10/dek10⋆ Two languages, Rules and Reg, exist for describing rules,respectively regulations; and⋆ one, Stimulus, exists for describing the form of the [alwayscurrent] domain action stimuli.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 419 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• A syntactic stimulus, sy sti, denotes a function, se sti:STI: Θ → Θ,from any configuration to a next configuration• A syntactic rule, sy rul:Rule, has as its semantics, its meaning,rul:RUL,/home/db/de/dek10/dek10⋆ a predicate over current and next configurations, (Θ × Θ) →Bool,⋆ where these next configurations have been caused, by thestimuli. These stimuli express:⋆ If the predicate holds then the stimulus will result in a valid nextconfiguration.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 420 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009typeStimulus, Rule, ΘSTI = Θ → ΘRUL = (Θ × Θ) → Boolvaluemeaning: Stimulus → STImeaning: Rule → RULinvisiblevalid: 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))(θ))/home/db/de/dek10/dek10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 421 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]• A syntactic regulation, sy reg:Reg (related to a specific rule), standsfor, i.e., has as its semantics, its meaning,⋆ 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.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 422 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]⋆ The two kinds 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.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 423 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009typeRegRul and Reg = Rule × RegREG = Pre REG × Act REGPre REG = Θ × Θ → BoolAct REG = Θ → Θvalueinterpret: Reg → REGinvisible/home/db/de/dek10/dek10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 424 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]• The idea is now the following:⋆ Any action of the system, i.e., the application of any stimulus,⋄ may be an action in accordance with the rules,⋄ or it may not.⋆ Rules therefore express whether stimuli are valid or not in thecurrent configuration.⋆ And regulations therefore express whether they should beapplied, and, if so, with what effort.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 425 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• More specifically,/home/db/de/dek10/dek10⋆ there is usually, in any current system configuration, given a set of pairs ofrules and regulations.⋆ Let (sy rul,sy reg) be any such pair.⋆ Let sy sti be any possible stimulus.⋆ And let θ be the current configuration.⋆ Let the stimulus, sy sti, applied in that configuration result in a nextconfiguration, θ ′ , where θ ′ = (meaning(sy sti))(θ).⋆ Let θ ′ violate the rule, ∼valid(sy sti,sy rul)(θ),⋆ then if predicate part, pre reg, of the meaning of the regulation, sy reg, holdsin that violating next configuration, pre reg(θ,(meaning(sy sti))(θ)),⋆ then the action part, act reg, of the meaning of the regulation, sy reg, must beapplied, act reg(θ), to remedy the situation.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.3 Lecture: 16. Slide: 426 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009axiom•∀ (sy rul,sy reg):Rul and Regslet 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θ)endinvisible/home/db/de/dek10/dek10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.4 Lecture: 16. Slide: 427 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]• It may be that the regulation predicate fails to detect applicabilityof regulations actions.• That is, the interpretation of a rule differs, in that respect, from theinterpretation of a regulation.• Such is life in the domain, i.e., in actual realityOn Modelling Rules and Regulations• Usually rules (as well as regulations) are expressed in terms ofdomain⋆ entities, including those grouped into “the state”,⋆ functions,⋆ events, and⋆ behaviours.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.4 Lecture: 16. Slide: 428 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Rules and Regulations, On Modelling Rules and Regulations ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Thus the full spectrum of modelling techniques and notations may be needed.• Since rules usually express properties one often uses some combination of/home/db/de/dek10/dek10⋆ axioms and⋆ well-formedness predicates.• Properties sometimes include temporality and hence⋆ temporal notations (like Duration Calculus or Temporal Logic of Actions )are used.• And since regulations usually express state (restoration) changes one often uses⋆ state changing notations (such as found in B, RSL, VDM-SL, and Z).• In some cases it may be relevant to model using some constraint satisfactionnotation or some Fuzzy Logic notations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.5 Lecture: 16. Slide: 429 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations ]The Support Example[s]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.6 Lecture: 16. Slide: 430 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10[ Domain Modelling: Rules and Regulations ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.13, Sect.6 Lecture: 16. Slide: 431 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek10/dek10End of Lecture 16Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek11/dek11The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 17. Slide: 432 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 17. Slide: 433 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009Lecture 17: Domain Modelling: Scripts, Licenses and Contractsinvisible/home/db/de/dek11/dek11Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14 Lecture: 17. Slide: 434 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Domain Modelling: Scripts, Licenses and ContractsDines Bjorner: 1st DRAFT: January 2, 2009Characterisation 71 (Domain Script) By a domain script wemean.invisible• the structured wording of a set of rules and regulationCharacterisation 72 (Domain License) By a domain licensewe mean.• a script• that prescribes a desirable set of behavioursCharacterisation 73 (Domain Contract) By a domaincontract we mean• a license/home/db/de/dek11/dek11Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.14 Lecture: 17. Slide: 435 of 894.• that additionally has legally binding power,• that is, which may be contested in a court of law/home/db/de/dek11/dek11c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.1 Lecture: 17. Slide: 436 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009We refer to Appendix .invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts ]Analysis of ExamplesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.1, Subsect. 1 Lecture: 17. Slide: 437 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, Analysis of Examples ]TimetablesWe refer to Appendix Sect. Slide 690–720invisible• The bus/train timetable is informally sketched.• A later part of this lecture will elaborate, and formalise, thistimetable example.• In addition that part will relate timetables to the underlying net ofto the resulting and possible traffics.• A timetable script thus can be given several pragmatics:/home/db/de/dek11/dek11⋆ (i-ii) a, perhaps not exactly legally binding, contract between thebus/train operator and the passengers, as well as a contractbetween the bus/train operator and the public authorities;⋆ (iii) a particular timetable (considered as syntax) semanticallydenotes a possibly infinite set of bus/train traffics, each of whichruns to schedule; andPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.14, Sect.1, Subsect. 1 Lecture: 17. Slide: 438 of 894/home/db/de/dek11/dek11c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31⋆ (iv) a script, to be followed by the drivers/train engine men,guiding these in the bus/train journey (to speed up or slowdown, etc.).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.1, Subsect. 2 Lecture: 17. Slide: 439 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts, Analysis of Examples ]Aircraft Flight Simulator ScriptWe refer to Appendix Sect. Slide 721–726• The example script is from a specific aircraft simulator demo. Ithas been abstracted a bit from the real case script.• You may think of the example script being partly “programmed”into the flight simulator which is a reactive system awaiting pilottrainee actions and reactions.• As you note, it is quite detailed. It mentions many phenomena andconcepts of aircraft flights:⋆ entities (simple as well as behavioural),⋆ operations,⋆ events,⋆ and itself prescribes a behaviour.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.14, Sect.1, Subsect. 2 Lecture: 17. Slide: 440 of 894/home/db/de/dek11/dek11c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• You may additionally think of the example script as also (inaddition to the flight simulator hardware and software) “scripting”the pilot trainee.• Thus a specific script, for example, denotes an infinity of actualbehaviours of pilot trainees working in conjunction with flightsimulators.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.1, Subsect. 3 Lecture: 17. Slide: 441 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts, Analysis of Examples ]Bill of LadingWe refer to Appendix Sect. Slide 727–731• The bill of lading is also a script, but it is quite different from theprevious two examples.• It only very, very loosely hints at transport behaviours.• Whereas it certainly puts some constraints on freight transport.• The bill of lading script is a legal instrument which⋆ entitles the consignee to receive the freight at the destinationharbour;⋆ stipulates, in the closing “conditions” item, legal protection ofthe two parties to the contract;⋆ etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.2 Lecture: 17. Slide: 442 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts ]LicensesLicense:a right or permissiongranted in accordance with lawby a competent authority- to engage in some business or occupation,- to do some act, or- to engage in some transactionwhich but for such license would be unlawfulMerriam Webster On-linePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.2 Lecture: 17. Slide: 443 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts, Licenses ]• The concepts of licenses and licensing express relations between⋆ actors (licensors (the authority) and licensees),⋆ simple entities (artistic works, hospital patients, publicadministration and citizen documents) and⋆ operations (on simple entities), and as performed by actors.• By issuing a license to a licensee, a licensor wishes to express andenforce certain permissions and obligations:⋆ which operations⋆ on which entities⋆ the licensee is allowed (is licensed, is permitted) to perform.• As such a license denotes a possibly infinite set of allowablebehaviours.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.2 Lecture: 17. Slide: 444 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts, Licenses ]• We shall consider three kinds of entities:⋆ (i) digital recordings of artistic and intellectual nature:⋄ music, movies, readings (“audio books”), and the like,⋆ (ii) patients in a hospital⋄ as represented also by their patient medical records, and⋆ (iii) documents related to public government.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.2 Lecture: 17. Slide: 445 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Licenses ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The permissions and obligations issues are,/home/db/de/dek11/dek11⋆ (i) for the owner (agent) of some intellectual property to be paid(i.e., an obligation) by users when they perform permittedoperations (rendering, copying, editing, sub-licensing) on theirworks;⋆ (ii) for the patient to be professionally treated — by medical staffwho are basically obliged to try to cure the patient; and⋆ (iii) for public administrators and citizens to enjoy goodgovernance: transparency in law making (national parliamentsand local prefectures and city councils), in law enforcement (i.e.,the daily administration of laws), and law interpretation (thejudiciary) — by agents who are basically obliged to producecertain documents while being permitted to consult (i.e., read,perhaps copy) other documents.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.3 Lecture: 17. Slide: 446 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts ]The Support Example(s)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.4 Lecture: 17. Slide: 447 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11[ Domain Modelling: Scripts, Licenses and Contracts ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.14, Sect.4 Lecture: 17. Slide: 448 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek11/dek11End of Lecture 17Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek12/dek12The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 18. Slide: 449 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 18. Slide: 450 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12Lecture 18: Domain Modelling: Human BehaviourPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesChap.15 Lecture: 18. Slide: 451 of 894/home/db/de/dek12/dek12Domain Modelling: Human BehaviourCharacterisation 74 (Human Behaviour) By humanbehaviour we mean.• any of a quality spectrum of carrying out assigned work:⋆ from careful, diligent and accurate,via⋆ sloppy dispatch, and⋆ delinquent work,to⋆ outright criminal pursuitc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.1 Lecture: 18. Slide: 452 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviours ]A Meta-characterisation of Human Behaviour• Commensurate with the above, humans interpret rules and regulations differently,• and not always consistently — in the sense of repeatedly applying the sameinterpretations.• Our final specification pattern is therefore:typeAction = Θ → ∼ Θ-infsetvaluehum int: Rule → Θ → RUL-infsetaction: Stimulus → Θ → Θhum beha: Stimulus × Rules → Action → Θ → ∼ Θ-infsethum beha(sy sti,sy rul)(α)(θ) as θsetpostθset = α(θ) ∧ action(sy sti)(θ) ∈ θset∧ ∀ θ ′ :Θ θ ′ ∈ θset ⇒•∃ se rul:RUL se rul ∈ hum int(sy rul)(θ)⇒se rul(θ,θ ′ )•Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.1 Lecture: 18. Slide: 453 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviours, A Meta-characterisation of Human Behaviour ]• The above is, necessarily, sketchy:⋆ There is a possibly infinite variety of ways of interpreting somerules.⋆ A human, in carrying out an action, interprets applicable rulesand chooses one which that person believes suits 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 intended by the ones who issued the rules andregulations or not.⋆ We do not cover the case of whether an appropriate regulation isapplied or not.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.1 Lecture: 18. Slide: 454 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Human Behaviours, A Meta-characterisation of Human Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009• The above-stated axioms express how it is in the domain,• not how we would like it to be.• For that we have to establish requirements.invisible/home/db/de/dek12/dek12Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.2 Lecture: 18. Slide: 455 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible••/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviours ]Review of Support Examples• to be writtenPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.2 Lecture: 18. Slide: 456 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Human Behaviours, Review of Support Examples ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible••/home/db/de/dek12/dek12• to be writtenPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.3 Lecture: 18. Slide: 457 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviours ]On Modelling Human Behaviour• To model human behaviour is, “initially”, much like modellingmanagement and organisation.• But only ‘initially’.• The most significant human behaviour modelling aspect is thenthat of modelling non-determinism and looseness, even ambiguity.• So a specification language which allows specifying non-determinismand looseness (like CafeOBJ and RSL) is to be preferred.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.4 Lecture: 18. Slide: 458 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviour ]The Support Example[s]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.5 Lecture: 18. Slide: 459 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12[ Domain Modelling: Human Behaviour ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.15, Sect.5 Lecture: 18. Slide: 460 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek12/dek12End of Lecture 18Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek13/dek13The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 19. Slide: 461 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 19. Slide: 462 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13Lecture 19: VerificationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16 Lecture: 19. Slide: 463 of 894Verificationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.1 Lecture: 19. Slide: 464 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]Theorem ProvingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.2 Lecture: 19. Slide: 465 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]Model CheckingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.3 Lecture: 19. Slide: 466 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]Formal TestingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.4 Lecture: 19. Slide: 467 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]Combining Proofs, Checks and TestsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.5 Lecture: 19. Slide: 468 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.6 Lecture: 19. Slide: 469 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13[ Verification ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.16, Sect.6 Lecture: 19. Slide: 470 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek13/dek13End of Lecture 19Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek14/dek14The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 20. Slide: 471 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 20. Slide: 472 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek14/dek14Lecture 20: ValidationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.17 Lecture: 20. Slide: 473 of 894Validationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek14/dek14Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.17, Sect.1 Lecture: 20. Slide: 474 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek14/dek14[ Validation ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.17, Sect.2 Lecture: 20. Slide: 475 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek14/dek14[ Validation ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.17, Sect.2 Lecture: 20. Slide: 476 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek14/dek14End of Lecture 20Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek15/dek15The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 21. Slide: 477 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 21. Slide: 478 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15Lecture 21: Theory FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.18 Lecture: 21. Slide: 479 of 894Theory Formationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.18, Sect.1 Lecture: 21. Slide: 480 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15[ Theory Formation ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.18, Sect.2 Lecture: 21. Slide: 481 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15[ Theory Formation ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.18, Sect.2 Lecture: 21. Slide: 482 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15End of Lecture 21Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek15/dek15aThe Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 22. Slide: 483 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 22. Slide: 484 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aLecture 22: Domain Engineering: A PostludiumPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek15/dek15aThe Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 23. Slide: 485 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 23. Slide: 486 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aLecture 23: Domain Engineering: A PostludiumPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19 Lecture: 23. Slide: 487 of 894Domain Engineering: A Postludiumc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.1 Lecture: 23. Slide: 488 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium ]Consolidation of Domain Modelling Facets• The many domain facet stages⋆ may have yielded descriptions which,⋆ typically at the formal level,⋆ does not reveal how it all “hangs together”.• In such cases, and in general,⋆ consolidation of these domain facet documentaton stages⋆ could take the following forms.⋄ With each potential management unit we associate a process or an indexed set of two ormore processes, usually an indeterminate number.◦ Such management units will usually involve entities and behaviours —◦ whether staff of entity behaviours.◦ Usually type definitions and axioms (about sorts) and value definitions of auxiliary andwell-formedness functions about values can be kept separate from the process definitions.◦ The entity processes usually take, as arguments, the entity whose time-wise behaviourand interaction with oother entity processes is being domain modelled.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.1 Lecture: 23. Slide: 489 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium, Consolidation of Domain Modelling Facets ]⋄ With each structural component of the organisation weassociate one or more channels, or vector or array or tensor (or. . . ) indexed sets of channels.More to comePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.1 Lecture: 23. Slide: 490 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Engineering: A Postludium, Consolidation of Domain Modelling Facets ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.2 Lecture: 23. Slide: 491 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium ]Domain Engineering DocumentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.3 Lecture: 23. Slide: 492 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium ]Generic Domain Engineering Development GraphPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.4 Lecture: 23. Slide: 493 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium ]Principles, Techniques and ToolsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.5 Lecture: 23. Slide: 494 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15a[ Domain Engineering: A Postludium ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.5 Lecture: 23. Slide: 495 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aEnd of Lecture 23Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.19, Sect.5 Lecture: 23. Slide: 496 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek15/dek15aEnd of Lecture 23Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek16/dek16The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 24. Slide: 497 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 24. Slide: 498 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16Lecture 24: From Domains to RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20 Lecture: 24. Slide: 499 of 894From Domains to Requirementsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.1 Lecture: 24. Slide: 500 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Principles and Concepts of RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2 Lecture: 24. Slide: 501 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Stages of Requirements EngineeringPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 1 Lecture: 24. Slide: 502 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Informative DocumentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 2 Lecture: 24. Slide: 503 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Stakeholder IdentificationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 3 Lecture: 24. Slide: 504 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements AcquisitionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 4 Lecture: 24. Slide: 505 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Business Process Re-engineeringPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 5 Lecture: 24. Slide: 506 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements Analysis and Concept FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 6 Lecture: 24. Slide: 507 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements TerminologyPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 7 Lecture: 24. Slide: 508 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements ModellingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 8 Lecture: 24. Slide: 509 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements Model VerificationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 9 Lecture: 24. Slide: 510 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements Model ValidationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 10 Lecture: 24. Slide: 511 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements Feasibility and SatisfiabilityPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.2, Subsect. 11 Lecture: 24. Slide: 512 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Stages of Requirements Engineering ]Requirements Theory FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.3 Lecture: 24. Slide: 513 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Shared Phenomena and ConceptsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.4 Lecture: 24. Slide: 514 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Domain RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.5 Lecture: 24. Slide: 515 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Interface RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.6 Lecture: 24. Slide: 516 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Machine RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.7 Lecture: 24. Slide: 517 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.8 Lecture: 24. Slide: 518 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements ]Requirements Engineering ManagementPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.8, Subsect. 1 Lecture: 24. Slide: 519 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16Stake HolderLiaison[ From Domains to Requirements, Requirements Engineering Management ]Requirements Engineering Development GraphRequirementsAcquisitionRequirements Analysis& Concept FormationRequirements ModelingValidation& VerificationSatisfiability& FeasibilityDomain RequirementsShared PhenomenaIdentificationBPRProjectionDeterminationInstantiationExtensionFittingInterface RequirementsShared Data InitialisationShared Data RefreshmentMan−machine DialoguePhysiological DialogueMachine−.Machine DialogueRequirements ModelingFigure 20.2: Requirements engineering process graphMachine RequirementsPerformanceDependabilityAccessabilityAvailabilityReliabilitySafetySecurityMaintainabilityPortabilityPerfectiveAdaptiveCorrectivePreventiveDevelopment PlatformExecution PlatformMaintenance PlatformDemo PlatformDocumentationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.8, Subsect. 2 Lecture: 24. Slide: 520 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16[ From Domains to Requirements, Requirements Engineering Management ]Requirements Engineering Development DocumentsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.20, Sect.8, Subsect. 2 Lecture: 24. Slide: 521 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek16/dek16End of Lecture 24Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible/home/db/de/dek17/dek17The Triptych and Specification Ontology Paradigm1. The Triptych Paradigm 3The Ontology Paradigm2. Simple Entities 633. Operations 1024. Events and Behaviours 128Domain Engineering5. Domain Engineering: An Overview 159Domain Engineering: Administrative Activities6. Informative Documents 1847. Stakeholder Identification and Liaison 279Domain Engineering: Prelude Modelling & Analysis8. Domain Acquisition 2909. Business Processes 30410. Domain Analysis and Concept Formation 31511. Terminology 331Domain Engineering: Modelling2009 LecturesLecture: 25. Slide: 522 of 894Lecture Overviewc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:3112. Domain Modelling: An Overview 15913. Intrinsics 35514. Support Technologies 36715. Management and Organisation 37816. Rules and Regulations 41217. Licenses and Contracts 43418. Human Behaviour 451Domain Engineering: Analysis19. Verification 46320. Validation 47321. Theory Formation 479Domain Engineering: Postlude Summary22. Domain Engineering: A Postludium 488A Little Bit on Requirements23. From Domains to Requirements 499Closing24. Summary and Conclusion 524Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesLecture: 25. Slide: 523 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17Lecture 25: Summary and ConclusionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21 Lecture: 25. Slide: 524 of 894Summary and Conclusionc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.1 Lecture: 25. Slide: 525 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17[ Summary and Conclusion ]A Domain Engineering Development GraphStakeholder IdentificationElicitation StudiesStakeholderIdentification and LiaisonElicitation InterviewsQuestionnairePreparation, PresentationFill−out, and ReturnChapter 13Chapters 10−11Chapter 14DOMAINACQUISITIONChapter 12Description Unit IndexingChapter 15Chapter 9DomainAnalysis andConcept FormationDomain ModellingDomainValidation andVerificationDomain Theory R&DDOMAINDEVELOPMENTChapter 11DOMAIN MODELLINGBusiness ProcessesIntrinsicsSupport TechnologiesManagement andOrganisationRules and RegulationsScriptsHuman BehaviourFigure 21.3: Domain engineering process graphPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.2 Lecture: 25. Slide: 526 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17[ Summary and Conclusion ]Domain Engineering Development Documents• There are basically three kinds of domain development documents:⋆ information documents,⋆ description documents and⋆ analytic documents.• We have earlier covered the concept of informative documents.• In the next two sections we shall cover the motivation for andprinciples and techniques of description and analysis documents.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.2, Subsect. 1 Lecture: 25. Slide: 527 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20091. Stakeholders2. The Acquisition Processinvisible/home/db/de/dek17/dek17(a) Studies(b) Interviews(c) Questionnaires(d) Indexed Description Units3. Terminology4. Business Processes[ Summary and Conclusion, Domain Engineering Documents ]Description Documents5. Facets:(a) Intrinsics(b) Support Technologies(c) Management andOrganisation(d) Rules and Regulations(e) Scripts(f) Human Behaviour6. Consolidated DescriptionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.2, Subsect. 2 Lecture: 25. Slide: 528 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Summary and Conclusion, Domain Engineering Documents ]Dines Bjorner: 1st DRAFT: January 2, 20091. Domain Analysis andConcept Formationinvisible(a) Inconsistencies(b) Conflicts(c) Incompletenesses(d) Resolutions2. Domain Validation/home/db/de/dek17/dek17Analytic Documents(a) Stakeholder Walkthroughs(b) Resolutions3. Domain Verification(a) Model Checkings(b) Theorems and Proofs(c) Test Cases and Tests4. (Towards a) Domain TheoryPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.3 Lecture: 25. Slide: 529 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Summary and Conclusion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.4 Lecture: 25. Slide: 530 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Summary and Conclusion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.5 Lecture: 25. Slide: 531 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Summary and Conclusion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesChap.21, Sect.5 Lecture: 25. Slide: 532 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/dek17/dek17End of Lecture 25Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 26. Slide: 533 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Support: Informative DocumentationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A Support: 26. Slide: 534 of 894Informative Documentationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.1 Support: 26. Slide: 535 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Project Names and DatesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.1 Support: 26. Slide: 536 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Project Names and Dates ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.2 Support: 26. Slide: 537 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Project Partners and PlacesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.2 Support: 26. Slide: 538 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Project Partners and Places ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.3 Support: 26. Slide: 539 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Current SituationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.3 Support: 26. Slide: 540 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Current Situation ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4 Support: 26. Slide: 541 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Needs and IdeasPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4, Subsect.1 Support: 26. Slide: 542 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Needs and Ideas ]NeedsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4, Subsect. 1 Support: 26. Slide: 543 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Needs and Ideas, Needs ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4, Subsect.2 Support: 26. Slide: 544 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Needs and Ideas ]IdeasPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4, Subsect. 2 Support: 26. Slide: 545 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Needs and Ideas, Ideas ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.4, Subsect.3 Support: 26. Slide: 546 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Needs and Ideas ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.5 Support: 26. Slide: 547 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Facilities and ConceptsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.5 Support: 26. Slide: 548 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Facilities and Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.5 Support: 26. Slide: 549 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Facilities and Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.6 Support: 26. Slide: 550 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Scope and SpanPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.6, Subsect. 1 Support: 26. Slide: 551 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Scope and Span ]ScopePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.6, Subsect.2 Support: 26. Slide: 552 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Scope and Span ]SpanPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.7 Support: 26. Slide: 553 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Assumptions and DependenciesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.7, Subsect.1 Support: 26. Slide: 554 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Assumptions and Dependencies ]AssumptionsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.7, Subsect. 2 Support: 26. Slide: 555 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Assumptions and Dependencies ]DependenciesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.8 Support: 26. Slide: 556 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Implicit & Derivative GoalsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.8 Support: 26. Slide: 557 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Implicit & Derivative Goals ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.9 Support: 26. Slide: 558 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]SynopsisPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.9 Support: 26. Slide: 559 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Synopsis ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.10 Support: 26. Slide: 560 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Domain Development GraphPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.10 Support: 26. Slide: 561 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Domain Development Graph ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.11 Support: 26. Slide: 562 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Resource AllocationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.11 Support: 26. Slide: 563 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Resource Allocation ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.12 Support: 26. Slide: 564 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Budget (and Other) EstimatesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.12, Subsect. 1 Support: 26. Slide: 565 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Budget (and Other) Estimates ]BudgetPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.12, Subsect. 2 Support: 26. Slide: 566 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Budget (and Other) Estimates ]Other EstimatesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.13 Support: 26. Slide: 567 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Standards CompliancePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.13, Subsect. 1 Support: 26. Slide: 568 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Standards Compliance ]Development StandardsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.13, Subsect. 2 Support: 26. Slide: 569 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Standards Compliance ]Documentation StandardsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.13, Subsect. 3 Support: 26. Slide: 570 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Standards Compliance ]Standards versus RecommendationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.13, Subsect. 4 Support: 26. Slide: 571 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Standards Compliance ]Specific StandardsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.14 Support: 26. Slide: 572 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Contracts and Design BriefsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.14, Subsect. 1 Support: 26. Slide: 573 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Contracts and Design Briefs ]ContractsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.14, Subsect. 2 Support: 26. Slide: 574 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents, Contracts and Design Briefs ]Design BriefsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.15 Support: 26. Slide: 575 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]Development LogbookPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.15 Support: 26. Slide: 576 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Development Logbook ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.16 Support: 26. Slide: 577 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0[ Informative Documents ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.16 Support: 26. Slide: 578 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Informative Documents, Discussion ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak0/ak0Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix A, Sect.16 Support: 26. Slide: 579 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Informative DocumentationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 27. Slide: 580 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak1/ak1Support: StakeholdersPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix B Support: 27. Slide: 581 of 894Stakeholdersc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak1/ak1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix B Support: 27. Slide: 582 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: StakeholdersPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 28. Slide: 583 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Support: Domain AcquisitionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C Support: 28. Slide: 584 of 894Domain Acquisitionc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1 Support: 28. Slide: 585 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition ]System Composition• We can rough sketch an oil & natural gas industry by diagrammingit, as shown in Fig. C.4.RS1Oil/GasFieldsPSPipelinesField Pipe DepotTTTankerTransportSwitchesTanker Sea LanesTankerRefineryRefineries &End CustomersRS2Harbours...LocalTransportLTRefractoryFigure C.4: A Schematic of an Oil & Natural Gas Industry...EndCustomersPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, §2 Support: 28. Slide: 586 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition ]• Narrative •2. The oil/natural gas domain, Ω, is here throught of as consisting ofthree sub-domains:(a) oil and natural gas field, refinery and end-consumer resourcemanagement, Ω RS ,(b) pipeline systems, Ω PS , and(c) tanker transport systems, Ω TT .type2. Ω, Ω RS , Ω PS , Ω TT ,value2(a. obs Ω RS : Ω → Ω RS2(b. obs Ω PS : Ω → Ω PS2(c. obs Ω TT : Ω → Ω TT• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 1 Support: 28. Slide: 587 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible••••/home/db/de/ak2/ak2[ Domain Acquisition, System Composition ]Pipeline SystemsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.1, §1 Support: 28. Slide: 588 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Pipeline Systems ]• Narrative •3. A pipeline system consists of one or more pipes and two or more nodes.4. Pipes and nodes have unique identifiers.5. A pipeline node is either a field drain pump, a fill pump, a valve or a flow pump.6. From a pipe one can observe the (directed) pair of identifiers of the two nodesconnected to the pipe, or, put differently, the two nodes that the pipe connects.7. A field drain pump is connected to a pipe and one can thus observe the identifierof that pipe.8. A fill pump is connected to a pipe and one can thus observe the identifier of thatpipe.9. A valve connects one or more pipes (called input pipes) to one or more (output)pipes, and one can thus observe the set of one or more identifiers of the inputpipes and the set of one or more identifiers of the output pipes.10. A flow pump connects one input pipe to one output pipe, and one can thusobserve the pair of identifiers of the input and output pipes.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 1, § 1 Support: 28. Slide: 589 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, System Composition, Pipeline Systems ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2iniinjinkinlp1p4p2p3fpa fpc p10onpfpbvxp5p6p7vyvzvup12Figure C.5: A Pipeline System: in: input node (drain pump, valve or flow pump),on: output node (valve or flow pump), fp: flow pump, v: valvep8p9p11fpdp13vwp14p15onqonronsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.1, §2 Support: 28. Slide: 590 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Pipeline Systems ]• Formalisation •type3. P, Nvalue3. obs Ps: PS → P-set3. obs Ns: PS → N-setaxiom3. ∀ ps:PS • card obs Ps(ps) ≥ 1 ∧ card obs Ns(ps) ≥ 2type4. PI, NIvalue4. obs PI: P → PI4. obs NI: N → NItype5. DrainP, FillP, V, FlowP5. N == mkDP(fdp:DrainP)| mkFiP(fp:FillP) | mkV(v:V) | mkFloP(fp:FlowP)value6. obs NIp: P → (NI × NI)7. obs PI: (DrainP|mkDP(fdp:DrainP)) → PI8. obs PI: (FillP|mkFiP(fdp:FillP)) → PI9. obs PIsp: (V|mkV(v:V)) → (PI-set × PI-set)10. obs PIp: (FlowP|mkFloP(fp:FlowP)) → (PI × PI)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 1, § 2 Support: 28. Slide: 591 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, PS: Pipeline System ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2p1,pi1[12] adjacent node identifiersp4,pi4,(nia,nib)p2,pi2na,nia,({pi1,pi2,pi3},{pi4}) nb,nib[14] node na input/output pipe identifiersp3,pi3node na identifiernode na(possibly zig−zagged) designate "ownershipFigure C.6: Nodes and pipes, node and pipe identifiers and adjacent node and pipe identifiersPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.2 Support: 28. Slide: 592 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition ]Tanker Transport SystemsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 2, § 1 Support: 28. Slide: 593 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Tanker Transport Systems ]• Narrative •11. A tanker transport system consists of two or more harbours, one ormore tanker ships (tanker), and one or more sea lanes.12. Harbours, tankers and sea lanes have unique identifiers."Rest" ofOil Transport Systemfieldspipesvalvespumpsrefineries&c.Harbour iHarbour j...Harbour kSea Lane...ShipHarbour p...Harbour qHarbour rFigure C.7: Tanker Transport System with Harbours, Sea Lanes and Ships"Rest" ofOil Transport Systempipesvalvespumpsrefineriessinks&c.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.2, §2 Support: 28. Slide: 594 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009type11. H, T, Lvalue11. obs Hs: Ω TT → H-set11. obs Ts: Ω TT → T-set11. obs Ls: Ω TT → L-setaxiom•11. ∀ ω TT :Ω TTcard obs Hs(ω TT )≥2 ∧card obs Ts(ω TT )≥1 ∧card obs Ls(ω TT )≥1type12. HI, TI, LIvalue12. obs HI: H → HI12. obs TI: T → TI12. obs LI: L → LIinvisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Tanker Transport Systems ]• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 2, § 3 Support: 28. Slide: 595 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Depots[ Domain Acquisition, System Composition, Tanker Transport Systems ]• Narrative •...............Ship2 [un]Loading Arms, in Use1 [un]Loading Arm, not in UseSwitchBerthFigure C.8: Harbour with Depots, Switch, Berths and ShipPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.2, §3 Support: 28. Slide: 596 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, System Composition, Tanker Transport Systems, Narrative ]Dines Bjorner: 1st DRAFT: January 2, 200913. From a harbour one can observeinvisible(a) a set of one or more depots,(b) a switch,(c) a set of one or more berths,(d) the identification of the one or more sea lanes emanating fromthat harbour,(e) and the identifications of the one or more sea lanes incident uponthat harbour,(f) and, from a berth, one or more loading arms/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 2, § 3 Support: 28. Slide: 597 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Tanker Transport Systems, Narrative ]14. From a sea lane one can observe(a) the pair of distinct identifiers of the harbours from, respectivelyto which the lane is directed, and(b) its length.15. From a tanker one can observe(a) a set of one or more tanks(b) whether the tanker is at sea,(c) and, if so, along which sea lane it sails,(d) and, if not, at which berth and in which harbour it is moored.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.2, §4 Support: 28. Slide: 598 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Tanker Transport Systems ]• Formalisation •type13(a. Depot, Switch, Berth, LdArm, Tank, Lengthvalue13(a. obs Depots: H → Depot-set13(b. obs Switch: H → Switch13(c. obs Berths: H → Berth-set13(d. obs eLIs: H → LI-set13(e. obs iLIs: H → LI-set13(f. obs LdArms: Berth → LdArm-set14(a. obs HIp: L → HI×HI14(b. obs Len: L → Length15(a. obs Tanks: T → Tank-set15(b. is at Sea: T → Bool15(c. obs LI: T ∼ → LI15(d. obs HIBI: T ∼ → (HI×BI)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 2, § 4 Support: 28. Slide: 599 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, System Composition, Tanker Transport Systems, Formalisation ]Dines Bjorner: 1st DRAFT: January 2, 2009axiom13(a. ∀ h:H • card obs Depots(h)≥1,13(c. ∀ h:H • card obs Berths(h)≥1,13(d. ∀ h:H • card obs eLIs(h)≥1,13(e. ∀ h:H • card obs eLIs(h)≥1,13(f. ∀ b:Berth • card obs LdArms(b)≥1,14(a. ∀ l:L • let (hi.hi ′ )=obs HIp(l) in hi≠hi ′ end,15(a. ∀ tnkr:T • card obs Tanks(t)≥1axiom15(d. ∀ ω TT :Ω TT•∀ t:T • h ∈ obs Ts(ω TT ) •∼is at Sea(t) ⇒let (hi.bi)=obs HIBI(t) in∃ h:H • h ∈ obs Hs(ω TT ) ∧ hi=obs HI(h) ⇒∃ b:Berth • b ∈ obs Berths(h) • bi=obs BI(b) endinvisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.3 Support: 28. Slide: 600 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible••••/home/db/de/ak2/ak2[ Domain Acquisition, System Composition ]Oil Field and Refinery SystemsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 3, § 1 Support: 28. Slide: 601 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Oil Field and Refinery Systems ]• Narrative •16. The oil/gas resource management domain consists of one or moreoil/gas fields, one or more depots, one or more oil refineries, one ormore local (oil and/or natural gas) distribution nets, and one ormore end-customers (referred to as sinks).17. Oil/gas fields, depots, oil refineries, distribution nets andend-customers all have unique identifiers.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.3, §1 Support: 28. Slide: 602 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, System Composition, Oil Field and Refinery Systems, Formalisation ]Dines Bjorner: 1st DRAFT: January 2, 2009type16. Field, Depot, Refinery, DistrNet, EndCust17. FI, DI, RI, NI, EIvalue16. obs Fields: Ω RS → Field-set16. obs Depots: Ω RS → Depot-set16. obs Refineries: Ω RS → Refinery-set16. obs EndCust: Ω RS → EndCust-set16. obs DistrNets: Ω RS → DistrNet-set17. obs FI: Field → FI17. obs DI: Depot → DIinvisible/home/db/de/ak2/ak217. obs RI: Refinery → RI17. obs NI: DistrNet → DNI17. obs SI: EndCust → EIaxiom16. ∀ ω RS :Ω RScard obs Fields(ω RS )≥1 ∧card obs Depots(ω RS )≥1 ∧card obs Refineries(ω RS )≥1 ∧card obs EndCusts(ω RS )≥1 ∧card obs DistrNetss(ω RS )≥1Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 3, § 3 Support: 28. Slide: 603 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Oil Field and Refinery Systems ]• Narrative •18. An oil/gas field contains a reservoir of oil and/or gas, one or more oil/gas drainpumps and zerop, one or more fill pumps.19. Reservoirs and oil/gas (drain or fill) pumps have unique identifiers.type18. Reservoir, DrainPump, FillPumpvalue18. obs Reservoir: Field → Reservoir18. obs DrainPumps: Field → DrainPump-set18. obs FilPumps: Field → FillPump-setaxiom18. ∀ f:Field card obs DrainPumps(f)≥1•type19. RI, DPI, FPIvalue19. obs RI: Reservoir → RI19. obs DPI: DrainPump → DPI19. obs FPI: FillPump → FPI• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.3, §5 Support: 28. Slide: 604 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Oil Field and Refinery Systems ]• Narrative •20. A reservoirs and a depot is either an oil (or some liquid derivate) ora gas (or some gaseous derivate) depot.• Formalisation •type20. DepTyp == oil | gasvalue20. obs DepTyp: (Reservoir|Depot) → DepTypPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect. 3, § 7 Support: 28. Slide: 605 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition, System Composition, Oil Field and Refinery Systems ]• Narrative •21. An oil refinery consists of one or more input depots, one or morerefractory towers, a switch system of pipes “running” from inputdepots to refractory towers, one or more output depots, and aswitch system of pipes “running” from refractory towers to outputdepots.22. Depots and Refractory towers have unique identifiers.• Formalisation •type21. Refractory, Switch22. RTIvalue21. obs InDepots: Refinery → Depot-set21. obs Refractories: Refinery → Refractory-set21. obs InSwitch: Refinery → Switch21. obs OutDepots: Refinery → Depot-setPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.1, Subsect.3, §7 Support: 28. Slide: 606 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible21. obs OutSwitch: Refinery → Switch22. obs RTI: Refractory → RTI/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.2 Support: 28. Slide: 607 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible••/home/db/de/ak2/ak2[ Domain Acquisition ]Preliminary AnalysisPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.3 Support: 28. Slide: 608 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition ]Simple EntitiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.3, Subsect. 1 Support: 28. Slide: 609 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition, System Composition ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.4 Support: 28. Slide: 610 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition ]OperationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.5 Support: 28. Slide: 611 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition ]EventsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.6 Support: 28. Slide: 612 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2[ Domain Acquisition ]BehavioursPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.6 Support: 28. Slide: 613 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.6 Support: 28. Slide: 614 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.6 Support: 28. Slide: 615 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Acquisition ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak2/ak2Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix C, Sect.6 Support: 28. Slide: 616 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Domain AcquisitionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 29. Slide: 617 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak3/ak3Support: Business ProcessesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix D Support: 29. Slide: 618 of 894Business Processesc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak3/ak3Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix D Support: 29. Slide: 619 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Business ProcessesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 30. Slide: 620 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4Support: Domain Analysis and Concept FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E Support: 30. Slide: 621 of 894Domain Analysis and Concept Formationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 1 Support: 30. Slide: 622 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation ]Simple EntitiesOil Industry Simple Entity Phenomena23. Reservoir, drain pump, flow pump, pipeline segment, valve, depot,switch, refractory tower, (harbour berth to tanker) load arm, andtanker tank structures (“casings”. “mechanisms”) — i.e., whenviewed void of oil — all have the following in common: they arediscrete, atomic and can be (correctly or erroneously) connected insimple ways to one another.We shall therefore suggest that we “lift” these phenomena intoconcepts of type (or sort) unit (U).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 1 Support: 30. Slide: 623 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Simple Entities, Oil Industry Simple Entity Phenomena ]24. Oil (and natural gas) is a liquid (a gas) which can be contained inunits.25. A reservoir, drain pump, flow pump, pipeline segment, valve, depot,switch, refractory tower, (harbour berth to tanker) load arm, and atanker tank when (partially) filled with (even no) oil (or gas) is acomposite simple entity.26. A unit, when not considering its possible oil (or natural gas)content, will be referred to as the unit casing.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 1 Support: 30. Slide: 624 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Simple Entities, Oil Industry Simple Entity Phenomena ]27. Some unit casings can, when disregarding for example ambienttemperature and humidity, be considered static and some aredynamic, that is their attribute values may be constants,respectively variables. Examples are:(a) A pipeline segment casing is a static simple entity with, forexample, these constant valued attributes: length, diameter,geographical location, etc.(b) A valve is a dynamic simple entity with, for example, theseconstant valued attributes: possible valve states, geographicallocation, etc. , and these variable valued attributes: current valvestate.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 1 Support: 30. Slide: 625 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Simple Entities, Oil Industry Simple Entity Phenomena ](c) A pump is a dynamic simple entity with, for example, theseconstant valued attributes: possible pumping states, geographicallocation, etc. , and with, for example, these variable valuedattributes: current pump state.(d) A depot is a dynamic simple entity with, for example, theseconstant valued attributes: maximum contained volume,maximum filling voule per second (max filling rate), maximumdraining volume per second (max draining rate), geographicallocation, etc.; and with, for example, these variable valuedattributes: current contained volume, whether being filled, ordrained, or both, and then at which respective rates.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 1 Support: 30. Slide: 626 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200928.29.invisible(e)(f)(g)(h)/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Simple Entities, Oil Industry Simple Entity Phenomena ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.1, Subsect. 2 Support: 30. Slide: 627 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200930. Oil industry units:invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Simple Entities ]Discrete and Continuous Simple EntitiesSlides: 66–76• an oil pump (without oil) is a discrete simple entity;• so are pipes (pipe segments), valves, depots, switches — when consideredwithout oil;• oil is a continuous simple entity:⋆ a barrel of oil can be divided into two fragments of the barrel⋆ in an infinity of ways, “down to the minutest level” of molecules.31. Time,• when viewed as a time axis, is a continuous simple entity,• but when viewed as a specific time, a time point, it is a discrete entity.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2 Support: 30. Slide: 628 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation ]Analysis of Domain Sketches• The English narrative items of Sect. can be said to represent some of the domainacquisition (i.e., some of the description units) gathered from domainstakeholders• and the formalisations can be said to represent initial parts of domain analysis.Of course many more such units should be gathered before completing the initialactions of the domain acquisition stage.• But it is useful, before settling on (choices of) formalisation, to alternate thedomain acquisition stage with steps of the domain analysis and conceptformation stage.• So, although these stages, methodology-wise, are usually presented as orderedstages (acquisition before analysis), but usually pursued in an in interleavedfashion, we shall, “table-of-contents”-wise, present them “sequentially” !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 1, § 1 Support: 30. Slide: 629 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Analysis of Domain Sketches ]Pipeline Systems• In order to prepare for a major subpart of this lecture• we discuss relations between pipes and the nodes (pumps and valves) thatconnect to pipes.• Narrative •32. For the subdomain of the pipeline system the following mutual pipeand node indentifier connections must be satisfied:(a) The pair of node identifiers of a pipe must identify distinct nodesof the pipeline system.(b) The pipe identifier of a field drain pump and a fill pump mustidentify pipes of the pipeline system.(c) The pair of sets of pipe identifiers of a valve must be disjoint andthe pipe identifiers must identify pipes of the pipeline system.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 1, §2 Support: 30. Slide: 630 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Analysis of Domain Sketches, Pipeline Systems ]• Formalisation •valuenodes: PS → NI-set, pipes: PS → PI-setnode ids(ps) ≡ {obs NI(n)|n:N n ∈ obs Ns(ps)}•pipe ids(ps) ≡ {obs PI(p)|p:P p ∈ obs Ps(ps)}•axiom32. ∀ ps:PS •32(a. ∀ p:P p ∈ obs Ps(ps) ⇒•let (ni,ni ′ )=obs NIp(p) in {ni,ni ′ } ⊆ node ids(ps) ∧∀ n:N n ∈ obs Ns(ps) ⇒•case n of32(a. mkDP(drp) → obs PI(drp) ∈ pipe ids(ps),32(a.32(b.32(c.mkFiP(fip) → obs PI(drp) ∈ pipe ids(ps)mkV(v) →let (ipis,opis)=obs PIsp(v) inipis ∩ opis = {} ∧ ipis ∪ opis ⊆ pipe ids(ps) endmkFloP(flp) →let (ipi,opi)=obs PIp(flp) inipi ≠ opi ∧ {ipi,opi} ⊆ pipe ids(ps) endend endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 2 Support: 30. Slide: 631 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Analysis and Concept Formation, Analysis of Domain Sketches ]Resource Management and Tanker TransportThe previous subsection treated pumps and valves of pipeline systems“on par”, i.e., as nodes. We shall extend the concept of nodes to alsocover the reservoirs, depots, refractories, end customers (i.e., sinks),switches, loading arms and tanks of “the rest” of the oil and naturalgas system as nodes.invisible/home/db/de/ak4/ak4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 3 Support: 30. Slide: 632 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Analysis of Domain Sketches ]Discussion of Emerging Concepts• And we shall generalise the notions of nodes and pipes into units of oil and natural gas systems.• These units are (to be) composed, i.e., connected to one another in orderly ways.• The “point” (or ‘spatial extent’) where two units are joined is now to be referred to as aconnection as well as a connector.• This spatial extent, i.e., a connector (a connection), is a concept.• We argue that it is not a phenomenon that has separate existence.• If one end of a pipe⋆ can be connected to a valve (at a certain place “on” that valve),⋆ that pipe end is said, by us, here in our modelling, to have connector potential,⋆ so we treat it as a connector,⋆ but it really only becomes a connector once it is actually joined to the corresponding valveconnector.• And so on for all joinable pairs of units.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 3 Support: 30. Slide: 633 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Analysis and Concept Formation, Analysis of Domain Sketches, Discussion of Emerging Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4• We shall make a kind of ‘Gedanken Experiment’.• Assume that two oil and natural gas system units are lying,separate from one another on the ground, say in the desert, nearsome oil fields, ready to be assembled, but not yet assembled.• (We thus assume that the two units of a kinds that can indeed beassembled.)• Can we refer to their connectors ?• To answer this question let us — temporarily — assume that theyhave been assembled.• Their assembly defines a connection and hence those twoconnectors of respective units that have been joined.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 3 Support: 30. Slide: 634 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4[ Domain Analysis and Concept Formation, Analysis of Domain Sketches, Discussion of Emerging Concepts ]• Those two connectors are now “the same”, that is identical !• And we refer to them as one.• Thus we shall take the position that before they were joined wecould, and can, indeed, refer to the two connectors by the same,identical reference.• The consequence of this “theory” is that there can at most be twounits (“lying around in the desert”, or being manufactured, shippedand made ready for assembly) sharing any give connector.• There may be zero such units, or there may be just one such unit !• In the former case the connector is “purely” hypothetical.• In the latter case the one-and-only-unit of a given connectorappears to be one that is (was) never meant to be assembled !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 3 Support: 30. Slide: 635 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Analysis and Concept Formation, Analysis of Domain Sketches, Discussion of Emerging Concepts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak4/ak4Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix E, Sect.2, Subsect. 3 Support: 30. Slide: 636 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Domain Analysis and Concept FormationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 31. Slide: 637 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak5/ak5Support: TerminologyPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix F Support: 31. Slide: 638 of 8941. Berth:2. Connector:3. Connection Point:/home/db/de/ak5/ak5Domain Terminologyc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 639 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20094. Crude Oil:5. Depot:6. End Customer:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 640 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20097. Field:8. Gas:9. Harbour:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 641 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200910. Oil:11. Natural Gas:12. Drain Pump:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 642 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200913. Fill Pump:14. Flow Pump:15. Flow:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 643 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200916. Flow Rate:17. Land Switch:18. Loading Arm:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 644 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200919. Pipe:20. Pump:21. Refinery:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 645 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200922. Refractory:23. Reservoir:24. Sea Lane:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 646 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200925. Sink:26. Switch:27. Tank:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 647 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200928. Tanker:29. Tanker Switch:30. Valve:invisible/home/db/de/ak5/ak5[ Domain Terminology ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix F Support: 31. Slide: 648 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: TerminologyPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 32. Slide: 649 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6Support: IntrinsicsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G Support: 32. Slide: 650 of 894Intrinsicsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, §1 Support: 32. Slide: 651 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Intrinsics ]Domain EntitiesThe Node, Unit and Connector Concept• Narrative •33. We now consider Reservoirs, Depots, End Customers, Drain Pumps, Valves,Flow Pumps, Fill Pumps, Refractories, Switches, Berth Loading Arms andtanker Tanks to be Nodes.34. We now consider Pipes and Nodes to be Units.35. Each Unit has Connectors 2 :(a) Reservoirs have a pair of disjoint sets of zero, one or more connectors 3 .(b) Depots have a pair of disjoint sets of connectors: a set of input connectors anda set of output connectors 4 .(c) Valves have a pair of disjoint sets of one or more connectors, respectively theinput and the output connectors 5 .2 — and, pragmatically, connectors are what “binds” units together3 Constraints: Reservoir output connectors are (to be) bound to drain pump inputs, one-by-one) and input connectors (for refilling the reservoir), are (to be) bound fillpump outputs, one-by-one.4 Constraints: Depot input connectors are (to be) bound to outputs of Fill Pumps and depot output connectors are (to be) bound to inputs of Switches.5 Constraints: Valve input connectors are (to be) bound to Pipe or Flow Pump output connectors, and Valve output connectors are (to be) bound to Pipe or Flow Pump/home/db/de/ak6/ak6 input connectors.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.1, §1 Support: 32. Slide: 652 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ • Narrative • ](d) Refractories have a pair of disjoint sets of input, respectively outputconnectors 6 .(e) Switches have a pair of disjoint sets of input, respectively output connectors 7 .(f) Drain Pumps have a pair of distinct connectors: one input and one outputconnector 8 .(g) Flow Pumps have a pair of distinct connectors: one input and one outputconnector 9 .(h) Fill Pumps have a pair of distinct connectors: one input and one outputconnector 10 .(i) Pipes have a pair of distinct connectors 11 .6 Constraints: Refractory input connectors are (to be) bound to Switch output connectors and Refractory output connectors are (to be) bound to Switch input connectors.7 Constraints: There are two kinds of Switches: on land and on tankers. (i) Either land Switch input connectors are (to be) bound to Depot output connectors andland Switch output connectors are (to be) bound to Refractory input connectors, or (ii) land Switch input connectors are (to be) bound to Refractory output connectors andland Switch output connectors are (to be) bound to Depot input connectors, or (iii) land Switch input connectors are (to be) bound to Depot output connectors and landSwitch output connectors are (to be) bound to Berth Loading Arm input connectors; and (iv) tanker Switch input connectors are (to be) bound to Berth Loading Arm outputconnectors and tanker Switch output connectors are (to be) bound to Tank input connectors.8 Constraints: Drain Pump input connector (to be) bound to a Reservoir output connector and Drain Pump output connector (to be) bound either to a Flow Pump inputconnector or to a Pipe input connector or to a Switch input connector.9 Constraints: Flow Pump input connectors are (to be) bound to Pipe or Valve output connectors and Flow Pump output connectors are (to be) bound to Pipe or Valveor Fill Pump input connectors.10 Constraints: Either (i) these are usually (to be) bound on the input side to a Pipe output and on the output side to an End Customer input, or (ii) on the input side toa Switch output and on the output side to a Depot input; or ldots, etc.11 Pragmatics & Constraints: The pair of distinct connectors thus designates a direction (that is, we assume pipes, like all other units, except [perhaps] swithches, to bedirectional). Pipe connectors (can) bind two Pipe units together or a Pipe unit (output/input) with a Depot (input/output), or a Pipe unit input Drain Pump output, or a/home/db/de/ak6/ak6 Pipe unit (output/input) with a Valve or Flow Pump (input/output).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, §1 Support: 32. Slide: 653 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ • Narrative • ](j) Berth Loading Arms have a pair of distinct connectors, an input and anoutput connector 12 .(k) Tanker Tanks have a pair of distinct connectors, one input (fill) and oneoutput (drain) connector 13 .(l) End Customers have just a single, the input connector 14 .12 Constraints: (i) When loading, i.e. filling, tanker Tanks, Berth Loading Arm input connectors are (to be) bound to a land Switch output connector, and Berth LoadingArm output connectors to a tanker Switch input connector. (ii) Or vice versa: when unloading the tanks.13 Constraints: Both tanker Tank connectors are (to be) bound to the tanker switch, respectively a tanker Switch output and a tanker Switch input connector./home/db/de/ak6/ak614 Constraints: This End Customer connector is (to be) bound to a Fill Pump output connector. Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.1, §2 Support: 32. Slide: 654 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]• Formalisation •type34. N = Reserv | Depot | EndCust | DraPump | Valve | FloPump |FilPump | Refract | Switch | LdArm | Tank33. U = N | Pipe35. Cvalue35. obs Cs: U → C | (C×C) | (C-set×C-set)35(a–35(e. obs Cs: (Reserv|Depot|Valve|Refract|Switch) → (C-set×C-set)35(f–35(k. obs Cs: (DraPump|FloPump|FilPump|Pipe|LdArm|Tank) → (C×C)35(l. obs Cs: EndCust → Caxiom∀ u:U •is Reserv(u)∨is Depot(u)∨is Valve(u)∨is Refract(u)∨is Switch(u)→ let (cs,cs ′ )=obs Cs(u) in cs ∩ cs ′ ={} end,is DraPump(u)∨is FloPump(u)∨is FilPump(u)∨is Pipe(u)∨is LdArm(u)∨is Tank(u)→ let (c,c ′ )=obs Cs(u) in c̸=c ′endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, §4 Support: 32. Slide: 655 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]• Narrative •36. For all oil/natural gas systems, ω, one can thus observe all itsReservoir, Depot, End Customer, Drain Pump, Valve, Flow Pump,Fill Pump, Pipe, Refractory, Switch, Load Arm, and Tank units.37. Let us, as technical aids, introduce the auxiliary functions ofextracting(a) all Units of an oil/natural gas system, ω,(b) all Connectors of a unit, and(c) all Connectors of an oil/natural gas system, ω.38. Every connector in any oil/natural gas system, ω, connects at mosttwo, and then distinct units.• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.1, §4 Support: 32. Slide: 656 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]Dines Bjorner: 1st DRAFT: January 2, 2009value36. obs Reservs: Ω → Reserv-set36. obs Depots: Ω → Depot-set36. obs EndCusts: Ω → EndCust-set36. obs DraPumps: Ω → DraPump-set36. obs Valves: Ω → Valve-set36. obs FloPumps: Ω → FloPump-set36. obs FilPumps: Ω → FilPump-set36. obs Pipes: Ω → Pipe-set36. obs Refracts: Ω → Refract-set36. obs Switchs: Ω → Switch-set36. obs LdArms: Ω → LdArms-set36. obs Tanks: Ω → Tank-set37(a. xtr Us: Ω → U-setxtr Us(ω) ≡obs Reservs(ω) ∪ obs Depots(ω) ∪ obs EndCusts(ω) ∪ obs DraPumps(ω) ∪obs Valves(ω) ∪ obs FloPumps(ω) ∪ obs FilPumps(ω) ∪ obs Pipes(ω) ∪obs Refracts(ω) ∪ obs Switchs(ω) ∪ obs LdArms(ω) ∪ obs Tanks(ω)37(b. xtr Cs: Ω → C-setxtr Cs(ω) ≡ let us = xtr Us(ω) in {c|c:C,u:U • u ∈ us ∧ c ∈ xtr Cs(u)} endinvisible/home/db/de/ak6/ak6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, §4 Support: 32. Slide: 657 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak637(c. xtr iCs: U → C-setxtr iCs(u) ≡let cs = obs Cs(u) incase cs of({},{}) → {},(cs ′ ,{}) → cs ′ ,({},cs ′′ ) → {},({c}∪ cs ′ ,{c ′ }∪ cs ′′ ) → {c}∪ cs ′ ,(c,c ′ ) → {c},c → {c} assert: is EndCust(u)end end[ • Formalisation • ]37(c. xtr Cs: U → C-setxtr Cs(u) ≡ xtr oCs(u) ∪ xtr oCs(u)axiom38. ∀ ω:Ω • ∀ c:C • c ∈ xtr Cs(ω) ⇒∃!u,u ′ :U • {u,u ′ }⊆xtr Us(ω) ∧ c ∈ xtr Cs(u) ∩ xtr Cs(u ′ ) ∨∃!u:U • u ∈ xtr Us(ω) ∧ c ∈ xtr Cs(u)37(c. xtr oCs: U → C-setxtr oCs(u) ≡let cs = obs Cs(u) incase cs of({},{}) → {},(cs ′ ,{}) → {},({},cs ′′ ) → cs ′′ ,({c}∪ cs ′ ,{c ′ }∪ cs ′′ ) → {c ′ }∪ cs ′′ ,(c,c ′ ) → {c ′ },c → {} assert: is EndCust(u)end endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.1, Subsubsect. 1 Support: 32. Slide: 658 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009∀ ω:Ω •let us = obs Us(ω) in∀ u:U • u ∈ us ⇒let (ics,ocs) = (obs iCs(u),obs oCs(u)) ininvisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept ]Wellformedness of Connections(35(a,fn:3)is Reserv(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is FilPump(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is DraPump(u ′′ ) ⇒ c ∈ obs iCs(u ′′ )(35(b,fn:4)is Depot(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is FilPump(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is Switch(u ′′ ) ⇒ c ∈ obs iCs(u ′′ )(35(c,fn:5)is Valve(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ (is Pipe(u ′ )∨is FloPump(u ′ )) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ (is Pipe(u ′′ )∨is FloPump(u ′′ )) ⇒ c ∈ obs oCs(u ′ )Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, Subsubsect. 1 Support: 32. Slide: 659 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Entities, The Node, Unit and Connector Concept, Wellformedness of Connections ]Dines Bjorner: 1st DRAFT: January 2, 2009(35(d,fn:6)is Refract(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is Switch(u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is Switch(u ′′ ) ⇒ c ∈ obs oCs(u ′′ )(35(e,fn:7)is Switch(u) ⇒ (is Land Switch(u) ⇒(i) (∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is Depot(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ocs ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is Refrac(u ′′ ) ⇒ c ∈ obs iCs(u ′′ )) ∨(ii) (∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is Refrac(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ocs ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is Depot(u ′′ ) ⇒ c ∈ obs iCs(u ′′ )) ∨(iii) (∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is Depot(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ocs ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is LdArm(u ′′ ) ⇒ c ∈ obs iCs(u ′′ )))(iv) ∨ (is Tanker Switch(u) ⇒∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is LdArm(u ′ ) ⇒ c ∈ obs oCs(u ′ ) ∧∀ c:C • c ∈ ocs ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is Tank(u ′′ ) ⇒ c ∈ obs iCs(u ′′ ))invisible/home/db/de/ak6/ak6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.1, Subsubsect. 1 Support: 32. Slide: 660 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Intrinsics, Domain Entities, The Node, Unit and Connector Concept, Wellformedness of Connections ]Dines Bjorner: 1st DRAFT: January 2, 2009(35(f,fn:8)is DraPump(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is (u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is (u ′′ ) ⇒ c ∈ obs oCs(u ′′ )(35(g,fn:9)is FloPump(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is (u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is FilPump(u ′ ) ⇒ c ∈ obs oCs(u ′ )(35(h,fn:10)is FilPump(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is DraPump(u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is FilPump(u ′′ ) ⇒ c ∈ obs oCs(u ′′ )(35(i,fn:11)is Pipe(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is DraPump(u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is FilPump(u ′ ) ⇒ c ∈ obs oCs(u ′ )invisible/home/db/de/ak6/ak6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 1, Subsubsect. 1 Support: 32. Slide: 661 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Entities, The Node, Unit and Connector Concept, Wellformedness of Connections ]Dines Bjorner: 1st DRAFT: January 2, 2009(35(j,fn:12)is LdArm(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is DraPump(u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is FilPump(u ′′ ) ⇒ c ∈ obs oCs(u ′′ )(35(k,fn:13)is Tank(u) ⇒∀ c:C • c ∈ ocs ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is DraPump(u ′ ) ⇒ c ∈ obs iCs(u ′ ) ∧∀ c:C • c ∈ ics ⇒∃ u ′′ :U • u ′′ ∈ us ∧ u≠u ′′ ∧ is FilPump(u ′′ ) ⇒ c ∈ obs oCs(u ′′ )(35(l,fn:14)is EndCust(u) ⇒∀ c:C • c ∈ ics ⇒∃ u ′ :U • u ′ ∈ us ∧ u≠u ′ ∧ is FilPump(u ′ ) ⇒ c ∈ obs oCs(u ′′ )end endinvisible/home/db/de/ak6/ak6Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.2, §1 Support: 32. Slide: 662 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities ]Paths and Routes• Narrative •39. A path is a concept. A path of the oil/natural gas system is a triple:(a) either, (c i , π j ,c k ), a pipe input connector, a pipe identifier, and a pipe outputconnector,[i] such that the node connectors, (c i , c k ), are the pair of distinct connectors ofthe pipe (of the oil/natural gas system, ω) identified by the pipe identifier,π j ,[ii] such that the pipe, p, identified by the pipe identifier, π j , is a pipe of theoil/natural gas system, ω.(b) or, (c i , n j ,c k ), a node input connector, a node identifier, and a node outputconnector,[i] such that node connectors are input, respectively output connectors[ii] of the node, n, identified by n j , of the oil/natural gas system, ω.40. A route is a concept. A route of the oil/natural gas system is a sequence of oneor more paths such that adjacent paths share connectors.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 2, §2 Support: 32. Slide: 663 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Paths and Routes ]• Formalisation •type39. Path = PP | NP39(a. PP == mkPP(ci:C,pi:PI,co:C)39(b. NP == mkNP(ci:C,ni:NI,co:C)axiom∀ ω:Ω •∀ mkPP(c,π,c ′ ):PP •39((a)i. ∃ p:Pipe p ∈ xtr Us(ω)∧π=obs PI(p) ∧•39((a)i. (c,c ′ )=obs Cs(π) ∧∀ mkNP(c,ni,c ′ ):NP •39((b)ii. ∃ n:N n ∈ xtr Us(ω)∧ni=obs NI(n)∧•39((b)i. c ∈ xtr iCs(n) ∧ c ′ ∈ xtr oCs(n)type40. Route = Path ωaxiom40. ∀ r:Route ∀ i:Nat {i,i+1}⊆inds r ⇒ let ( , ,c)=r(i),(c ′ , , )=r(i+1) in c=c ′ end• •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.2, §3 Support: 32. Slide: 664 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Paths and Routes ]• Narrative •41. An oil/natural gas system, ω, determines a set of routes as follows:(a) The empty list, 〈〉, is a route.(b) A singleton list, 〈p〉, of a path, p, of ω, is a route (so all suchsingleton lists of ω form routes).(c) If r and r ′ are routes of ω then r ̂ r ′ , their concatenation, is aroute of ω.(d) No other route is a route of ω unless it follows from a finitenumber of applications of prescriptions 41(a, 41(b and 41(c.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 2, §4 Support: 32. Slide: 665 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Paths and Routes ]• Formalisation •valuecalc Paths: Ω → Path-setcalc Paths(ω) ≡{mkPP(c,pi,c ′ )|mkPP(c,pi,c ′ ):Path {c,c ′ }⊆xtr Cs(ω)∧c≠c ′ ∧•∃ p:Pipe p ∈ xtr Us(ω)∧π=obs PI(p)∧(c,c ′ )=obs Cs(π)}•∪ {〈〉} ∪{mkNP(c,ni,c ′ )|mkNP(c,ni,c ′ ) {c,c ′ }⊆xtr Cs(ω) ⇒•∃ n:N n ∈ xtr Us(ω)∧ni=obs NI(n)∧•c ∈ xtr iCs(n) ∧ c ′ ∈ xtr oCs(n)}41. calc Routes: Ω → Route-infset41(a. calc Routes(ω) ≡41(b. let rs = {〈path〉|path:Path path ∈ calc Paths(ω)} ∪•41(c. {r ̂r ′ |r,r ′ :Route {r,r ′ }⊆rs∧r≠〈〉∧r ′ ≠〈〉∧last C(r)=first C(r ′ )} in•41(c. rs endfirst C, last C: (Route|Path) → ∼ Cfirst C(〈mkPP(c, , )〉 ̂r ′ ) ≡ c, first C(mkPP(c, , )) ≡ c,first C(〈mkNP(c, , )〉 ̂r ′ ) ≡ c, first C(mkNP(c, , )) ≡ c,last C(r ′ ̂ 〈mkPP( , ,c)〉) ≡ c, last C(mkPP( , ,c)) ≡ clast C(r ′ ̂ 〈mkNP( , ,c)〉) ≡ c, last C(mkNP( , ,c)) ≡ c, first C(〈〉)=chaos=last C(〈〉)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.2, §5 Support: 32. Slide: 666 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Paths and Routes ]• Observations •• The “statics” of connections “start” at reservoirs and end atloading arms, respectively at loading arms and end at reservoirs.• Routes cannot “start earlier” than reservoir or tank outputconnectors.• Routes cannot go further than reservoir or tank input connectors.• The “dynamics” of loading arms really means that routecalculation depends on the state of the system (i.e., ω).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 3, §2 Support: 32. Slide: 667 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities ]Acyclic Networks• Narrative •42. The routes of an oil/natural gas system are not cyclic,43. that is, no node or pipe identifier must occur more than at most once.• Formalisation •value42. acyclic: Route → Bool43. acyclic(r) ≡∀ i,j:Nat • {i,j}⊆ index r ∧ i≠j ⇒case (r(i),r(j)) of(mkPP( ,pi, ),mkPP( ,pj, )) → pi≠pj,(mkNP( ,ni, ),mkNP( ,nj, )) → ni≠nj,→ trueendPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.4 Support: 32. Slide: 668 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities ]Attributes• So far the only propertie we have ascribed to units are⋆ their identifications and⋆ their connectors.• They are not really of the kind which we think of as attributes.• Unique identifications and unique connectors are abstractions of⋆ unique spatial unit locations and unique, mereological relations between“adjacent” units,⋆ and can be thought off as pragmatic means of “formalising” such spatiallocations and mereological relations.• Attributes are not necessarily abstractions.• In the following we shall give examples of attributes.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 4, Subsubsect. 1, § 2 Support: 32. Slide: 669 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes ]Static Attributes• Narrative •44. Units are either made for handling fluieds: either liquids (i.e., oil)or for handling gaseous substance (i.e., natural gas). Within modeliquid there could be several “submodes”: raw oil, gasoline,acetone, etc. Similar for mode gaseous (but we refrain fromelaborating !).• Formalisation •type44. Mode == liquid | gaseous44. SubMode == raw oil | gasoline | acetone | ...value44. obs Mode: U → Mode44. obs SubMode: U → SubModePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.4, Subsubsect. 1, § 4 Support: 32. Slide: 670 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes, Static Attributes ]• Narrative •45. A valve is a device that regulates the flow of a fluid (gases, fluidizedsolids, slurries, or liquids) by opening, closing, or partiallyobstructing various passageways. Valves are technically pipefittings, but are usually discussed separately.• Formalisation •type45. Valve Setting = C → m Frac•Frac = {| f:Real 0≤f≤1 |}value45. obs Valve Setting: Valve → Valve Settingaxiom•45. ∀ u:Valve dom obs Valve Setting(u) ⊆ xtr oCs(u)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 4, Subsubsect. 1, § 5 Support: 32. Slide: 671 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes, Static Attributes ]• Narrative •46. A pump is a device used to move fluids, such as gases, liquids orslurries. A pump displaces a volume by physical or mechanicalaction. One common misconception about pumps is the thoughtthat they create pressure. Pumps alone do not create pressure theyonly displace fluid causing a flow. Adding resistance to flow causespressure.47. The volumetric flow rate in fluid dynamics and hydrometry (alsoknown as volume flow rate or rate of fluid flow) is the volume offluid which passes through a given surface per unit time (forexample cubic meters per second).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.4, Subsubsect. 1, § 6 Support: 32. Slide: 672 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009type46.47.invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes, Static Attributes ]• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 4, Subsubsect. 1, § 8 Support: 32. Slide: 673 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200948.49.invisible••type48.49./home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes, Static Attributes ]• Narrative •• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.4, Subsubsect. 2, § 1 Support: 32. Slide: 674 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200950.51.52.53.54.invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes ]Dynamic Attributes• Narrative •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect. 4, Subsubsect. 2, § 2 Support: 32. Slide: 675 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak6/ak6[ Intrinsics, Domain Entities, Attributes, Dynamic Attributes ]• Formalisation •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix G, Sect.1, Subsect.4, Subsubsect. 2, § 2 Support: 32. Slide: 676 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: IntrinsicsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 33. Slide: 677 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak7/ak7Support: Support TechnologiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix H Support: 33. Slide: 678 of 894Support Technologiesc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak7/ak7Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix H Support: 33. Slide: 679 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Support TechnologiesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 34. Slide: 680 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak8/ak8Support: Management and OrganisationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix I Support: 34. Slide: 681 of 894Management and Organisationc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak8/ak8Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix I Support: 34. Slide: 682 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Management and OrganisationPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 35. Slide: 683 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak9/ak9Support: Rules and RegulationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix J Support: 35. Slide: 684 of 894Rules and Regulationsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak9/ak9Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix J Support: 35. Slide: 685 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Rules and RegulationsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 36. Slide: 686 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10Support: Scripts, Licenses and ContractsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K Support: 36. Slide: 687 of 894Scripts, Licenses and Contractsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.1 Support: 36. Slide: 688 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts ]OverviewPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2 Support: 36. Slide: 689 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts ]ScriptsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1 Support: 36. Slide: 690 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts ]Time Tables• We shall view timetables as scripts.• In on the next slides (690–720) we shall⋆ first narrate and formalise the syntax, including thewell-formedness of timetable scripts,⋆ then we consider the pragmatics of timetable scripts,⋄ including the bus routes prescribed by these journeydescriptions and⋄ timetables marked with the status of its currently activeroutes, and⋆ finally we consider the semantics of timetable, that is, thetraffic they denote.• In a next lecture part on licenses for bus traffic, we shall assume thetimetable scripts of this part of the lecture on scripts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1 Support: 36. Slide: 691 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10Figure K.9: Some bus timetables: Italy, India and NorwayPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 1 Support: 36. Slide: 692 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Time Tables ]The Syntax of Timetable Scripts55. Time is a concept covered earlier. Bus lines and bus rides have unique names (across any set oftime tables). Hub and link identifiers, HI, LI, were treated from the very beginning.56. A TimeTable associates to Bus Line Identifiers a set of Journies.57. Journies are designated by a pair of a BusRoute and a set of BusRides.58. A BusRoute is a triple of the Bus Stop of origin, a list of zero, one or more intermediate Bus Stopsand a destination Bus Stop.59. A set of BusRides associates, to each of a number of Bus Identifiers a Bus Schedule.60. A Bus Schedule a triple of the initial departure Time, a list of zero, one or more intermediate busstop Times and a destination arrival Time.61. A Bus Stop (i.e., its position) is a Fraction of the distance along a link (identified by a LinkIdentifier) from an identified hub to an identified hub.62. A Fraction is a Real properly between 0 and 1.63. The Journies must be well formed in the context of some net.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 1 Support: 36. Slide: 693 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts ]Dines Bjorner: 1st DRAFT: January 2, 2009type55. T, BLId, BId56. TT = BLId → m Journies57. Journies ′ = BusRoute × BusRides58. BusRoute = BusStop × BusStop ∗ × BusStop59. BusRides = BId → m BusSched60. BusSched = T × T ∗ × T61. BusStop == mkBS(s fhi:HI,s ol:LI,s f:Frac,s thi:HI)62. Frac = {|r:Real • 0

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 1 Support: 36. Slide: 694 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2 Support: 36. Slide: 695 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 200964. A set of journies is well-formed65. if the bus stops are all different,invisible/home/db/de/ak10/ak10[ Timetables, The Syntax of Timetable Scripts ]Well-formedness of Journies66. if a defined notion of a bus line is embedded in some line of the net,and67. if all defined bus trips (see below) of a bus line are commensurable.value64. wf Journies: Journies → N → Bool64. wf Journies((bs1,bsl,bsn),js)(hs,ls) ≡65. diff bus stops(bs1,bsl,bsn) ∧66. is net embedded bus line(〈bs1〉 ̂ bsl ̂ 〈bsn〉)(hs,ls) ∧67. commensurable bus trips((bs1,bsl,bsn),js)(hs,ls)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 696 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts ]• Well-formedness of Journies •68. The bus stops of a journey are all different69. if the number of elements in the list of these equals the length ofthe list.value68. diff bus stops: BusStop × BusStop ∗ × BusStop → Bool68. diff bus stops(bs1,bsl,bsn) ≡69. card elems 〈bs1〉 ̂ bsl ̂ 〈bsn〉 = len 〈bs1〉 ̂ bsl ̂ 〈bsn〉• We shall refer to the (concatenated) list (〈bs1〉 ̂ bsl ̂ 〈bsn〉 = len〈bs1〉 ̂ bsl ̂ 〈bsn〉) of all bus stops as the bus line.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 697 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200970. To explain that a bus line is embedded in a line of the net71. let us introduce the notion of all lines of the net, lns,72. and the notion of projecting the bus line on link sector descriptors.73. For a bus line to be embedded in a net then means that there existsa line, ln, in the net, such that a compressed version of theprojected bus line is amongst the set of projections of that line onlink sector descriptors.value70. is net embedded bus line: BusStop ∗ → N → Bool70. is net embedded bus line(bsl)(hs,ls)71. let lns = lines(hs,ls),72. cbln = compress(proj on links(bsl)(elems bsl)) in73.•∃ ln:Line ln ∈ lns ∧ cbln ∈ projs on links(ln) endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 698 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200974. Projecting a list ( ∗ ) of BusStop descriptors (mkBS(hi,li,f,hi ′ )) onto a list of SectorDescriptors ((hi,li,hi ′ ))75. we recursively unravel the list from the front:76. if there is no front, that is, if the whole list is empty, then we get the empty listof sector descriptors,77. else we obtain a first sector descriptor followed by those of the remaining busstop descriptors.value74. proj on links: BusStop ∗ → SectDescr ∗74. proj on links(bsl) ≡75. case bsl of76. 〈〉 → 〈〉,77. 〈mkBS(hi,li,f,hi ′ )〉 ̂ bsl ′ → 〈(hi,li,hi ′ )〉 ̂ proj on links(bsl ′ )77. endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 699 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200978. By compression of an argument sector descriptor list we mean a result sectordescriptor list with no duplicates.79. The compress function, as a technicality, is expressed over a diminishingargument list and a diminishing argument set of sector descriptors.80. We express the function recursively.81. If the argument sector descriptor list an empty result sector descriptor list isyielded;82. else83. if the front argument sector descriptor has not yet been inserted in the resultsector descriptor list it is inserted else an empty list is “inserted”84. in front of the compression of the rest of the argument sector descriptor list.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 700 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200978. compress: SectDescr ∗ → SectDescr-set → SectDescr ∗79. compress(sdl)(sds) ≡80. case sdl of81. 〈〉 → 〈〉,82. 〈sd〉 ̂ sdl ′ →83. (if sd ∈ sds then 〈sd〉 else 〈〉 end)84. ̂ compress(sdl ′ )(sds\{sd}) endinvisible• In the last recursion iteration (line 84.)/home/db/de/ak10/ak10⋆ the continuation argument sds\{sd}⋆ can be shown to be empty: {}.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 701 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200985. We recapitulate the definition of lines as sequences of sector descriptions.86. Projections of a line generate a set of lists of sector descriptors.87. Each list in such a set is some arbitrary, but ordered selection of sectordescriptions.type85. Line ′ = (HI×LI×HI) ∗ ,85. Line = {| l:Line ′ •wf Line(l ′ ) |}value85. wf Line: Line ′ → Bool85. wf Line(l) ≡85. ∀ i:Nat • {i,i+1}⊆inds l⇒85. let (( , ,lij),(lik, , ))=(l(i),l(i+1)) in lij=lik end86. projs on links: Line → Line ′ -set86. projs on links(ln) ≡87. {〈isl(i)|i:〈1..len isl〉〉|isx:Nat-set • isx⊆inds ln∧isl=sort(isx)}invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 702 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200988. sorting a set of natural numbers into an ordered list, isl, of these is expressed by apost-condition relation between the argument, isx, and the result, isl.89. The result list of (arbitrary) indices must contain all the members of theargument set;90. and “earlier”elements of the list must precede, in value, those of “later” elementsof the list.value88. sort: Nat-set → Nat ∗88. sort(isx) as isl89. post card isx = lsn isl ∧ isx = elems isl ∧90. ∀ i:Nat • {i,i+1}⊆inds isl ⇒ isl(i)

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 703 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 200991. The bus trips of a bus schedule are commensurable with the list of bus stop descriptions if thefollowing holds:92. All the intermediate bus stop times must equal in number that of the bus stop list.93. We then express, by case distinction, the reality (i.e., existence) and timeliness of the bus stopdescriptors and their corresponding time descriptors – and as follows.94. If the list of intermediate bus stops is empty, then there is only the bus stops of origin anddestination, and they must be exist and must fit time-wise.95. If the list of intermediate bus stops is just a singleton list, then the bus stop of origin and thesingleton intermediate bus stop must exist and must fit time-wise. And likewise for the bus stopof destination and the the singleton intermediate bus stop.96. If the list is more than a singleton list, then the first bus stop of this list must exist and must fittime-wise with the bus stop of origin.97. As for Item 96 but now with respect to last, resp. destination bus stop.98. And, finally, for each pair of adjacent bus stops in the list of intermediate bus stopsinvisible99. they must exist and fit time-wise./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 704 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 2009value91. commensurable bus trips: Journies → N → Bool91. commensurable bus trips((bs1,bsl,bsn),js)(hs,ls)92. ∀ (t1,til,tn):BusSched (t1,til,tn)∈ rng js∧len til=len bsl∧•93. case len til of94. 0 → real and fit((t1,t2),(bs1,bs2))(hs,ls),95. 1 → real and fit((t1,til(1)),(bs1,bsl(1)))(hs,ls)∧fit((til(1),t2),(bsl(1),bsn))(hs,ls),96. → real and fit((t1,til(1)),(bs1,bsl(1)))(hs,ls)∧97. real and fit((til(len til),t2),(bsl(len bsl),bsn))(hs,ls)∧98. ∀ i:Nat {i,i+1}⊆inds til ⇒•99. real and fit((til(i),til(i+1)),(bsl(i),bsl(i+1)))(hs,ls) endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 705 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 2009100. A pair of (adjacent) bus stops exists and a pair of times, that is the time interval between them,fit with the bus stops if the following conditions hold:101. All the hub identifiers of bus stops must be those of net hubs (i.e., exists, are real).102. There exists links, l, l ′ , for the identified bus stop links, li, li ′ ,103. such that these links connect the identified bus stop hubs.104. Finally the time interval between the adjacent bus stops must approximate fit the distancebetween the bus stops105. The distance between two bus stops is a loose concept as there may be many routes, short orlong, between them.106. So we leave it as an exercise to the student to change/augment the description, in order to beable to ascertain a plausible measure of distance.107. The approximate fit between a time interval and a distance must build on some notion of averagebus velocity, etc., etc.108. So we leave also this as an exercise to the student to complete.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 36. Slide: 706 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Syntax of Timetable Scripts, Well-formedness of Journies ]Dines Bjorner: 1st DRAFT: January 2, 2009100. real and fit: (T×T)×(BusStop×BusStop) → N → Bool100. real and fit((t,t ′ ),(mkBS(hi,li,f,hi ′ ),mkBS(hi ′′ ,li ′ ,f ′ ,hi ′′′ )))(hs,ls) ≡101. {hi,hi ′ ,hi ′′ ,hi ′′′ }⊆his(hs)∧102. ∃ l,l ′ :L {l,l ′ }⊆ls∧(obs LI(l)=li∧obs(l ′ )=li ′ )∧•103. obs HIs(l)={hi,hi ′ }∧obs HIs(l ′ )={hi ′′ ,hi ′′′ }∧104. afit(t ′ −t)(distance(mkBS(hi,li,f,hi ′ ),mkBS(hi ′′ ,li ′ ,f ′ ,hi ′′′ ))(hs,ls))105. distance: BusStop × BusStop → N → Distance106. distance(bs1,bs2)(n) ≡ ... [ left as an exercise ! ] ...107. afit: TI → Distance → Bool108. [ time interval fits distance between bus stops ]invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3 Support: 36. Slide: 707 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Time Tables ]The Pragmatics of Timetable Scripts• A main purpose of a timetable is to bring an order into the traffic,• as seen from the side of⋆ net operators (signalling etc.),⋆ train operators and⋆ passengers.• With⋆ a net which is owned by one enterprise,⋆ many different train operators on that one net,⋆ and with cross-train passengers• a consolidated timetable offers a common, fixed interface.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 708 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts ]• Subset Timetables •• The pragmatics of a timetable may include its decomposition into a number ofsub-timetables.• When speaking of two timetables it is often convenient to make sure that bus lineidentifiers occuring in both designate identical bus routes.109. A bus line identifier occurring in two timetables is said to define compatible busrides in those two timetables provided the corresponding two bus routes areidentical.109 have compatible BLIds: TT × TT → Bool109 have compatible BLIds(tti,ttj) ≡109 ∀ blid:BLId • blid ∈ dom tti ∩ dom ttj109 ⇒ let (bri, )=tti(blid),(brj, )=ttj(blid) in bri=brj endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 709 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009110. Two journies are similar if they have identical bus line identified bus routes.111. A timetable, stt, is said to be a sub-timetable of a timetable, tt, if every bus lineidentified bus ride of similar journies is also an identical bus line identified busride of tt.value110 are similar Js: Journies × Journies → Bool110 are similar Js((bri, ),(brj, )) ≡ bri=brj111 is sub TT: TT × TT → Bool111 is sub TT(stt,tt) ≡111 ∀ sblid,blid:BLId • sblid=blid∧sblid ∈ dom stt∧blid ∈ dom tt111 ⇒ ∀ (sbr,sbrs),(br,brs):Journies • (sbr,sbrs)=stt(sblid)∧(br,brs)=tt(blid)111 ⇒ sbr=br ∧ ∀ bid:BId • bid ∈ dom sbrs ∩ dom br111 ⇒ sbrs(bid)=brs(bid)111 pre have compatible BLIds(stt,tt)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 710 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009112. We can thus generate all sub-timetables of a timetable.112 all sub TTs: TT → TT-set112 all sub TTs(tt) ≡ {stt|stt:TT • is sub TT(stt,tt)}113. Two timetables, stt i and stt j , are said to be disjoint if they share no same busline identifier bus rides.113 are disjoint TTs: TT × TT → Bool113 are disjoint TTs(tti,ttj) ≡113 ∀ blidi,blidj:BLId • blidj=blidj∧blidi ∈ dom tti∧blidj ∈ dom ttj113 ⇒ dom tti(blidi) ∩ dom ttj(blidj) = {}113 pre have compatible BLIds(tti,ttj)invisible• So disjointness is purely a matter of whether two bus rides (of the same bus routeand bus line identifier) have different bus ride identifiers.• The time schedule is not considered./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 711 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009114. Two timetables can be merged into one timetable provided they are disjoint.115. Merging two disjoint timetables result in a timetable which has exactly the busline identified journies of either of the timetables.114 can be merged TTs: TT × TT → Bool114 can be merged TTs(tti,ttj) ≡ are disjoint TTs(tti,ttj)115 merge TTs: TT × TT → TT115 merge TTs(tti,ttj) as tt115 pre are disjoint TTs(tti,ttj) [ i.e., have compatible BLIds(tti,ttj) ]115 post is sub TT(tti,tt ′ )∧is sub TT(ttj,tt ′ )115 ∧ dom tt = dom tti ∪ dom ttj115 ∧ ∀ blid:BLId • blid ∈ dom tt ∧ blid ∈ dom tti ∪ dom ttj115 ⇒ let ((br,brs),(bri,brsi),(brj,brsj)) = (tt(blid),tti(blid),ttj(blid)) in115 dom brsi ∩ dom brsj = {} ∧ dom brsi ∪ dom brsj = dom brs115 ∧ brs = brsi ∪ brsj endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 712 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• From a timetable one can construct any number of sub-timetables.116. Given a timetable, tt, and given a mapping of bus line identifiers, ex., blid, of ttinto the set, bids, of bus ride identifiers of the bus rides of tt(blid), construct,cons STT(tt,blid to bids map), the sub-timetable, stt, of tt where stt exactly liststhe so identified bus rides of tt.value116 cons STT: TT × (BLId → m BId-set) → TT116 cons STT(tt,id map) ≡116 [ blid ↦→ (tt(blid))(bid)116 | blid:BLId,bid:BId blid ∈ dom id map ∧ bid ∈ id map(blid) ]•116 pre dom id map ≠ {} ∧ dom id map ⊆ dom tt ∧116 ∧ ∀ blid:BLId blid ∈ dom(tt)•116 ⇒ id map(blid)≠{}∧id map(blid)⊆rng tt(blid)/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 713 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009117. Given a timetable, tt, and given a mapping of bus line identifiers, ex., blid, of ttinto the set, bids, of bus ride identifiers of the bus rides of tt(blid), construct,cons compl STT(tt,blid to bids map), the sub-timetable, stt, of tt where sttexactly lists the other identified bus rides of tt.117 cons compl STT: TT × (BLId → m BId-set) → TT117 cons compl STT(tt,id map)117 let idmap = [ blid ↦→ bids | blid:BLId,bids:BId-set117•(blid ∈ dom tt \ dom id map ∧ bids=dom tt(blid))117 ∨ blid ∈ dom tt ∩ dom id map ∧ bids=id map(blid) ]117 construct STT(tt,idmap) endinvisible/home/db/de/ak10/ak10• The following should be proven:theorem:∀ tt:TT, id map pre construct STT(tt,id map) ⇒•merge TTs(cons STT(tt,id map),cons compl STT(tt,id map))= tt =merge TTs(cons compl STT(tt,id map),cons STT(tt,id map))Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 714 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Some auxiliary functions might come in handy at a later stage.118. Given a bus line identifier to inquire whether it is the bus line identifier of aproper, non empty sets of bus rides in a given timetable.119. Given a bus line identifier and a bus ride identifier to inquire whether theytogether identify a proper bus ride of a given timetable.120. Given a bus ride identifier and a time table to to inquire whether there is a busline identifier of that timetable for which the bus ride identifier is defined.121. Given a bus line identifier and a bus ride identifier to find, if it exists, the busroute and ride schedule of that identification./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 3, § 1 Support: 36. Slide: 715 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Pragmatics of Timetable Scripts, Subset Timetables ]Dines Bjorner: 1st DRAFT: January 2, 2009value118. is def: BLId×TT→Bool,118. is def(blid,tt) ≡ blid ∈ dom tt ∧ tt(blid)≠[ ]119. is def: BLId×BId×TT→Bool,119. is def(blid,bid,tt) ≡ dom tt ∧ bid ∈ dom tt(blid)120. is def: BId×TT→Bool,120. is def(bid,tt) ≡ ∃ blid:BLId • is def(blid,bid,tt)121. inquire: BLId×BId×TT ∼ →(BusRoute×BusSched),121. inquire(blid,bid,tt) ≡121. let (br,brs)=tt(blid) in (br,brs(bid)) end121. pre is def(blid,bid,tt)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 4, § 1 Support: 36. Slide: 716 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Time Tables ]The Semantics of Timetable Scripts• One form of timetable denotations is the bus traffic implied by atimetable.122. We postulate a type of Buses.• Bus Traffic •123. From a bus one can observe the value of a number of attributes:current number of passengers, identity of driver, number ofpassengers who alighted and boarded at the most recent bus stop,etc. (We let X stand for any one of these attributes.)124. Bus traffic maps discrete times into the pair of a bus net and thepositions of buses.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 4, § 1 Support: 36. Slide: 717 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Timetables, The Semantics of Timetable Scripts, Bus Traffic ]125. A bus positions is either at a hub, on a link or at a bus stop.126. When a bus is at a hub we can also observe from which link it cameand to which link it proceeds.127. When a bus is on a link we can observe how far it has progresseddown the link from one of the two hubs it connects.128. When a bus is at a bus stop — which is like “on a link” — we canobserve that bus stop accordingly.129. Fractions have also be described earlier.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 4, § 1 Support: 36. Slide: 718 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Semantics of Timetable Scripts, Bus Traffic ]Dines Bjorner: 1st DRAFT: January 2, 2009type122. Busvalue123. obs X: Bus → Xtype124. BusTraffic = T → m (N × (BusNo → m (Bus × BPos)))125. BPos = atHub | onLnk | atBS126. atHub == mkAtHub(s fl:LIs hi:HI,s tl:LI)127. onLnk == mkOnLnk(s fhi:HI,s ol:LI,s f:Frac,s thi:HI)128. atBSt == mkAtBS(s fhi:HI,s ol:LI,s f:Frac,s thi:HI)129. Frac = {|r:Real•0

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.1, Subsubsect. 4, § 1 Support: 36. Slide: 719 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Scripts, Licenses and Contracts, Scripts, Time Tables, The Semantics of Timetable Scripts, Bus Traffic ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• From a bus timetable we can generate the set of all bus traffics thatsatisfy the bus timetable.• (We have covered this notion earlier.)valuegen BusTraffic: TT → BusTraffic-infsetgen BusTraffic(tt) as btrfs•post ∀ btrf:BusTraffic btrf ∈ btrfs ⇒ on time(btrf)(tt)• We leave it to the student to define the on time predicate.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.2 Support: 36. Slide: 720 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Timetable Scripts ]Discussion• We have built the foundations for a theory of timetables.• We have not yet formulated theorems let alone proven any such.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 721 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20091. Takeoff:invisible/home/db/de/ak10/ak10(a) Record time[ Scripts, Licenses and Contracts, Scripts ]Aircraft Flight Simulator Script(b) Release brakes and taxi onto runway 26L(c) Advance power to “FULL”(d) Maintain centerline of runway(e) At 50 knots airspeed lift nose wheel off runway(f) At 70 knots ease back on the yoke to establish a 10 degree pitchup attitude(g) Maintain a climb AIRSPEED of 80 knots(h) Maintain a climb AIRSPEED of 80 knots(i) Raise Gear when there is no more runway to land on(j) At “500” feet above the ground raise the FLAPS to “0”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 722 of 894/home/db/de/ak10/ak10c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31(k) Reduce power to about “2300” RPM at “1000” feet above theground (AGL)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 723 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20092. Climb out:invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Aircraft Flight Simulator Script ](a) Maintain runway heading and climb to “2400” feet(b) At “2400” feet start a climbing LEFT turn(c) Start to roll out when you see “140” in the DG window(d) Maintain a heading of “130”(e) Watch your NAV 1 CDI, when the needle is three dots LEFT ofcenter, start your RIGHT turn to a heading of “164”(f) Track outbound on the POMONA VOR 164 radialPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 724 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20093. Level off:invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Aircraft Flight Simulator Script ](a) Begin to level off when the altimeter reads “3900” feet(b) Maintain “4000” feet(c) Reduce power to about “2200” [2400] RPM4. Course change *1:(a) Watch your NAV 2 CDI, when the needle is one dot LEFT ofcenter, start your RIGHT turn to a heading of “276”(b) When your heading indicator reads “265” start to roll out(c) After you have rolled out, press “P” to pause the simulation(d) Record your: NAV, I, DME, DIST, ALTITUDE, AIRSPEEDVSI, GEAR, FLAPS, MAGS, STROBE, LIGHTS(e) Press “P” to continue the simulation(f) Track outbound on the PARADISE VOR 276 radial that yourNAV 2 OBI is displayingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 725 of 894/home/db/de/ak10/ak10c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31(g) Track outbound on the PARADISE VOR 276 radial that yourNAV 2 OBI is displaying(h) Switch ¿DME to “NAV 2”Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.3 Support: 36. Slide: 726 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 20095. Altitude change:invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Aircraft Flight Simulator Script ](a) When the DME on NAV 2 reads “29.0”, press “P” to pause thesimulation(b) Record your: ALTITUDE, AIRSPEED, VSI, HEADING(c) Press “P” to continue the simulation(d) Tune NAV 1 to “113.1” and set radial “276” in the upper window(e) Track inbound on the VAN NUYS VOR “096” radial (course276) that your NAV 1 OBI is displaying(f) Switch DME to “NAV 1”6. Etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.4 Support: 36. Slide: 727 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts ]Bill of LadingPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.4 Support: 36. Slide: 728 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Scripts, Licenses and Contracts, Scripts, Bill of Lading ]We show a template: the . . . are to be fillled in.invisible• B/L No.: . . .• Shipper: . . .• Reference No.: . . .• Consignee: . . .• Notify address: . . .• Vessel: . . .• Port of loading: . . .• Port of discharge: . . ./home/db/de/ak10/ak10• Shipper’s description of goods: . . .⋆ Gross weight: . . .⋄ of which ... is on deck at Shipper’s risk;the Carrier not being responsible forloss or damage howsoever arising.⋆ Measure: . . .⋆ Quality: . . .⋆ Quantity: . . .⋆ Condition: . . .⋆ Contents value unknown.• SHIPPED at the Port of Loading in apparent good order and condition on board the Vessel forcarriage to the Port of Discharge or so near thereto as she may safely get the goods specified above• Freight payable as per: . . . • Dated (by charter part: . . . ): . . .Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.4 Support: 36. Slide: 729 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10⋆ Freight Advance: . . .⋆ Time used for loading: . . .⋄ Days: . . .⋄ Hours: . . .• Conditions:[ Scripts, Licenses and Contracts, Scripts, Bill of Lading ]⋆ Freight payable at: . . .⋆ Place and date of issue: . . .⋆ Signature: . . .⋆ Number of original Bs: . . .⋆ (1) All terms and conditions, liberties and exceptions of the Charter Party, dated as overleaf, includingthe Law and Arbitration Clause, are herewith incorporated.⋆ (2) General Paramount Clause.⋄ (a) The Hague Rules contained in the International Convention for the Unification of certain rulesrelating to Bills of Lading, dated Brussels the 25th August 1924 as enacted in the country of shipment,shall apply to this Bill of Lading. When no such enactment is in force in the country of shipment, thecorresponding legislation of the country of destination shall apply, but in respect of shipments towhich no such enactments are compulsorily applicable, the terms of the said Convention shall apply.⋄ (b) Trades where Hague-Visby Rules apply. In trades where the International Brussels Convention1924 as amended by the Protocol signed at Brussels on February 23rd 1968 - the Hague- Visby Rules -apply compulsorily, the provisions of the respective legislation shall apply to this Bill of Lading.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.4 Support: 36. Slide: 730 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Bill of Lading ]⋄ (c) The Carrier shall in no case be responsible for loss of or damage to the cargo,howsoever arising prior to loading into and after discharge from the Vessel or while thecargo is in the charge of another Carrier, nor in respect of deck cargo or live animals.⋆ (3) General Average.General Average shall be adjusted, stated and settled according to York-Antwerp Rules 1994, or anysubsequent modification thereof, in London unless another place is agreed in the Charter Party. Cargo’scontribution to General Average shall be paid to the Carrier even when such average is the result of afault, neglect or error of the Master, Pilot or Crew. The Charterers, Shippers and Consignees expresslyrenounce the Belgian Commercial Code, Part II, Art. 148.⋆ (4) New Jason Clause.In the event of accident, danger, damage or disaster before or after the commencement of the voyage,resulting from any cause whatsoever, whether due to negligence or not, for which, or for the consequenceof which, the Carrier is not responsible, by statute, contract or otherwise, the cargo, shippers, consigneesor the owners of the cargo shall contribute with the Carrier in General Average to the payment of anysacrifices, losses or expenses of a General Average nature that may be made or incurred and shall paysalvage and special charges incurred in respect of the cargo. If a salving vessel is owned or operated bythe Carrier, salvage shall be paid for as fully as if the said salving vessel or vessels belonged to strangers.Such deposit as the Carrier, or his agents, may deem sufficient to cover the estimated contribution of thegoods and any salvage and special charges thereon shall, if required, be made by the cargo, shippers,consignees or owners of the goods to the Carrier before delivery.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.2, Subsect.4 Support: 36. Slide: 731 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Scripts, Licenses and Contracts, Scripts, Bill of Lading ]⋆ (5) Both-to-Blame Collision Clause.If the Vessel comes into collision with another vessel as a result of the negligence of the othervessel and any act, neglect or default of the Master, Mariner, Pilot or the servants of theCarrier in the navigation or in the management of the Vessel, the owners of the cargo carriedhereunder will indemnify the Carrier against all loss or liability to the other or non-carryingvessel or her owners in so far as such loss or liability represents loss of, or damage to, or anyclaim whatsoever of the owners of said cargo, paid or payable by the other or non-carryingvessel or her owners to the owners of said cargo and set-off, recouped or recovered by theother or non-carrying vessel or her owners as part of their claim against the carrying Vessel orthe Carrier.The foregoing provisions shall also apply where the owners, operators or those in charge ofany vessel or vessels or objects other than, or in addition to, the colliding vessels or objectsare at fault in respect of a collision or contact.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.3 Support: 36. Slide: 732 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts and Contracts ]License and Contract Languages• By a domain script language we mean⋆ the definition of a set of licenses and actions⋆ where these licenses when issued⋆ and actions when performed have morally obliging power.• By a domain contract language we mean⋆ a domain script language whose licenses and actions⋆ have legally binding power, that is,⋄ the issue of licenses and⋄ the invocation of actionsmay be contested in a court of law.⋆ We now refer to licenses as contracts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4 Support: 36. Slide: 733 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts ]The Performing Arts: Producers and Consumers• The intrinsic entities of the performing arts are the artistic works:⋆ drama or opera performances,⋆ music performances,⋆ readings of poems, short stories, novels, or jokes,⋆ movies,⋆ documentaries, newsreels, etc.• We shall limit our span to the scope of electronic renditions of theseartistic works:⋆ videos, CDs or other.• In this talk we shall not touch upon the technical issues of“downloading”(whether ”streaming” or copying, or other).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.1 Support: 36. Slide: 734 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers ]Operations on Digital Works• For a consumer to be able to enjoy these works that consumer must(normally first) usually “buy a ticket” to their performances.• The consumer, i.e., the theatre, opera, concert, etc., “goer”(usually)⋆ cannot copy the performance (e.g., “tape it”),⋆ let alone edit such copies of performances.• In the context of electronic, i.e., digital renditions of theseperformances the above “cannots” take on a new meaning.⋆ The consumer may copy digital recordings,⋆ may edit these,⋆ and may further pass on such copies or editions to others.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.1 Support: 36. Slide: 735 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, Operations on Digital Works ]invisible/home/db/de/ak10/ak10• To do so, while protecting the rights of the producers (owners,performers),⋆ the consumer requests permission to have the digital workstransferred (“downloaded”) from the owner/producer to theconsumer,⋆ so that the consumer⋄ can render (“play”) these works on own rendering devices (CD,DVD, etc., players),⋄ possibly can copy all or parts of them,⋄ then possibly can edit all or parts of the copies, and,⋄ finally, possibly can further license these “edited” versions toother consumers subject to payments to “original” licensor.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.2 Support: 36. Slide: 736 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers ]License Agreement and Obligation• To be able to obtain these permissions⋆ the user agrees with the wording of some license⋆ and pays for the rights to operate on the digital works.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.3 Support: 36. Slide: 737 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers ]Two Assumptions• Two, related assumptions underlie the pragmatics of the electronicsof the artistic works.⋆ The first assumption is that⋄ the format, the electronic representation of the artistic works isproprietary,⋄ that is, that the producer still owns that format.⋆ Either the format⋄ is publicly known⋄ or it is not, that is, it is somehow “secret”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.3 Support: 36. Slide: 738 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, Two Assumptions ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In either case we “derive” the second assumption (from the fulfilment of the first).⋆ The second assumption is that the consumer is not allowed to, or cannotoperate 15 on the works by own means (software, machines).• The second assumption implies that⋆ acceptance of a license⋆ results in the consumer receiving software⋆ that supports the consumer in performing all operations on⋆ licensed works, their copies and edited versions:⋄ rendering,⋄ copying,/home/db/de/ak10/ak1015 render, copy and edit⋄ editing and⋄ sub-licensing.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.4 Support: 36. Slide: 739 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers ]• The issue now is:Protection of the Artistic Electronic Works⋆ how to protect the intellectual property⋆ (i.e., artistic) and financial (exploitation) rights⋆ of the owners of the possibly rendered, copied and edited works,⋆ both when, and when not further distributed.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 740 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers ]A License Languagetype0. Ln, Nm, W, S, V1. L = Ln × Lic2. Lic == mkLic(licensor:Nm,licensee:Nm,work:W,cmds:Cmd-set)3. Cmd == Rndr | Copy | Edit | RdMe | SuLi4. Rndr = mkRndr(vw:(V| ′′ work ′′ ),sl:S ∗ )5. Copy = mkCopy(fvw:(V| ′′ work ′′ ),sl:S ∗ ,tv:V)6. Edit = mkEdit(fvw:(V| ′′ work ′′ ),sl:S ∗ ,tv:V)7. RdMe = ′′ readme ′′8. SuLi = mkSuLi(cs:Cmd-set,work:V)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 741 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (0.) Licenses⋆ are given names,⋄ ln:Ln,⋄ so are actors (owners, licensors, and users, licensees), nn:Nm.⋆ By w:W we mean a (net) reference to (a name of) thedownloaded possibly segmented artistic work being licensed,⋆ where segments are named (s:S), that is, s:S is a selector⋄ to either a segment of a downloaded work or⋄ to a segment of a copied and or and edited work.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 742 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (1.) Every license (lic:Lic) has a unique name (ln:Ln).• (2.) A license (lic:Lic) contains four parts:/home/db/de/ak10/ak10⋆ the name of the licensor,⋆ the name of the licensee,⋆ a reference to (the name of) the work,⋆ a set of commands (that may be permitted to be performed onthe work).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 743 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (3.) A command is⋆ either a render, a copy or an edit or a readme command,⋆ or a sub-licensing (sub-license)command.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 744 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]invisible• (4.–6.) The render, copy and edit commands are each “decorated”with an ordered list of selectors (i.e., selector names) and a (work)variable name./home/db/de/ak10/ak10⋆ The license commandcopy 〈s1,s2,s7〉 v⋆ means that the licensed work, ω, may have its sections s 1 , s 2 ands 7 copied, in that sequence, into a new variable named v,⋆ Other copy commands may specify other sequences.• Similarly for render and edit commands.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 745 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (7.) The ”readme” license command,⋆ in a license, ln, referring, by means of w, to work ω,⋆ somehow displays a graphical/textual “image” of, that is,information about ω.⋆ We do not here bother to detail what kind of information may beso displayed.⋆ But you may think of the following display information⋄ names of artistic work,artists, authors, etc.,⋄ names and details about licensed commands,⋄ a table of fees for performing respective licensed commands,⋄ etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 746 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (8.) The license command/home/db/de/ak10/ak10schema: license cmd1,cmd2,...,cmdn on work vformal: mkSuLi({cmd1,cmd2,...,cmdn},v)means⋆ that the licensee is allowed to act as a licensor,⋆ to name sub-licensees (that is, licensees) freely,⋆ to select only a (possibly full) subset of the sub-licensed commands (that are listed) for thesub-licensee to enjoy.• The license need thus not mention the name(s) of the possible sub-licensees.⋆ But one could design a license language, i.e., modify the present one to reflect such constraints.• The license also do not mention the payment fee component.⋆ As we shall see under licensor actions such a function will eventually be inserted.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 747 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• A license licenses the licensee to render, copy, edit and license (possibly theresults of editing) any selection of downloaded works.• In any order — but see below — and any number of times.• For every time any of these operations take place payment according to thepayment function occurs (that can be inspected by means of the read licensecommand).• The user can render the downloaded work and can render copies of the work aswell as edited versions of these. Edited versions are given own names.• Editing is always of copied versions.• Copying is either of downloaded or of copied or edited versions.• This does not transpire from the license syntax⋆ but is expressed by the licensee, see below,⋆ and can be checked and duly paid for according to the payment function.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 748 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• The payment function is considered a partial function of the selections of thework being licensed.• Please recall that licensed works are proprietary./home/db/de/ak10/ak10⋆ Either the work format is known, or it is not supposed to be known,⋆ In any case,⋄ the rendering, editing, copying and the license-“assembling” (more later)functions⋄ are part of the license and the licensed work⋄ and are also assumed to be proprietary.⋆ Thus the licensee is not allowed to and may not be able to use own softwarefor rendering, editing, copying and license assemblage.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 749 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• Licenses specify sets of permitted actions.• Licenses do not normally mandate specific sequences of actions.• Of course, the licensee, assumed to be an un-cloned human, can only perform oneaction at a time.• So licensed actions are carried out sequentially.• The order is not prescribed, but is decided upon by the licensee.• Of course, some actions must precede other actions.⋆ Licensees must copy before they can edit,⋆ and they usually must edit some copied work before they can sub-license it.⋆ But the latter is strictly speaking not necessary.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 750 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009type5. V6. Act = Ln × (Rndr|Copy|Edit|License)7. Rndr == mkR(sel:S ∗ ,wrk:(W|V))8. Copy == mkC(sel:S ∗ ,wrk:(W|V),into:V)9. Edit == mkE(wrks:V ∗ ,into:V)10. License == mkL(ln:Ln,licensee:Nm,wrk:V,cmds:Cmd-set,fees:PF)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 751 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (5.) By V we mean the name of a variable in the users own storage into whichdownloaded works can be copied (now becoming a local work.⋆ The variables are not declared.⋆ They become defined when the licensee names them in a copy command.⋆ They can be overwritten.⋆ No type system is suggested.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 752 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (6.) Every action of a licensee is tagged by the name of a relevant license./home/db/de/ak10/ak10⋆ If the action is not authorised by the named license then it is rejected.⋆ Render and copy actions mention a specific sequence of selectors.⋆ If this sequence is not an allowed (a licensed) one, then the action is rejected.⋆ (Notice that the license may authorise a specific action, a with different sets ofsequences of selectors — thus allowing for a variety of possibilities as well asconstraints.)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 753 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (7.) The licensee, having now received a license,⋆ can render selections⋄ of the licensed work,⋄ or of copied⋄ and/or edited versionsof the licensed work.⋆ No reference is made to the payment function.⋄ When rendering the semantics is that this function is invoked and dulyapplied.⋄ That is, render payments are automatically made: subtracted from thelicensees account and forwarded to the licensor.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 754 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (8.) The licensee/home/db/de/ak10/ak10⋆ can copy selections⋄ of the licensed work,⋄ or of previously copied⋄ and/or edited versionsof the licensed work.⋆ The licensee identifies a name for the local storage file where the copy will bekept.⋆ No reference is made to the payment function.⋄ When copying the semantics is that this function is invoked and dulyapplied.⋄ That is, copy payments are automatically made: subtracted from thelicensees account and forwarded to the licensor.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 755 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (9.) The licensee⋆ can edit selections⋄ of the licensed work,⋄ or of copied⋄ and/or previously edited versionsof the licensed work.⋆ The licensee identifies a name for the local storage file where thenew edited version will be kept.⋆ The result of editing is a new work.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 756 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]invisible/home/db/de/ak10/ak10⋆ No reference is made to the payment function.⋄ When copying the semantics is that this function is invokedand duly applied.⋄ That is, copy payments are automatically made: subtractedfrom the licensees account and forwarded to the licensor.⋆ Although no reference is made to any edit functions these aremade available to the licensee when invoking the edit command.⋄ You may think of these edit functions being downloaded at thetime of downloading the license.⋄ Other than this we need not further specify the editingfunctions.⋆ Same remarks apply to the above copying functions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 757 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (10.) The licensee can further sub-license copied and/or edited work.⋆ The licensee must give the license being assembled a unique name.⋆ And the licensee must choose to whom to license this work.⋆ A sub-license, like does a license, authorises which actions can be performed,and then with which one of a set of alternative selection sequences.⋆ No payment function is explicitly mentioned.⋄ It is to be semi-automatically derived⋄ (from the originally licensed payment fee function⋄ and the licensee’s payment demands)⋄ by means of functionalities provided as part of the licensed payment feefunction.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.4, Subsect.5 Support: 36. Slide: 758 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, The Performing Arts: Producers and Consumers, A License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10⋆ The sub-license command information is thus compiled (assembled) into alicense of the form given in (1.–3.).⋄ The licensee becomes the licensor and the recipient of the new, thesub-license, become the new licensee.⋄ The assemblage refers to the context of the action.⋄ That context knows who, the licensor, is issuing the sub-license.⋄ From the license label of the command it is known whether the sub-licenseactions are a subset of those for which sub-licensing has been permitted.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5 Support: 36. Slide: 759 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• Citizens[ Domain Modelling: Scripts, Licenses and Contracts ]A Hospital Health Care License Language⋆ go to hospitals⋆ in order to be treated for some calamity (disease or other),⋆ and by doing so these citizens become patients.• At hospitals patients, in a sense, issue a request to be treated withthe aim of full or partial restitution.• This request is directed at medical staff, that is,⋆ the patient authorises medical staff to perform a set of actionsupon the patient.⋆ One could claim, as we shall, that the patient issues a license.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.1 Support: 36. Slide: 760 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language ]Patients and Patient Medical Records• So patients and their attendant patient medical records (PMRs) are the mainentities, the “works” of this domain.• We shall treat them synonymously: PMRs as surrogates for patients.• Typical actions on patients — and hence on PMRs — involve⋆ admitting patients,⋆ interviewing patients,⋆ analysing patients,⋆ diagnosing patients,⋆ planning treatment for patients,⋆ actually treating patients, and,⋆ under normal circumstance, to finally release patients.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.3 Support: 36. Slide: 761 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language ]Medical Staff• Medical staff may request (‘refer’ to)⋆ other medical staff to perform some of these actions.⋆ One can conceive of describing action sequences (and ‘referrals’) in the form ofhospitalisation (not treatment) plans.⋆ We shall call such scripts for licenses.• The issue is now,Professional Health Care⋆ given that we record these licenses,⋆ their being issued and being honoured,⋆ whether the handling of patients at hospitals⋄ follow,⋄ or does not followproperly issued licenses.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.4 Support: 36. Slide: 762 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language ]A Notion of License Execution State• In the context of the Artistic License Language licensees could basically performlicensed actions in any sequence and as often as they so desired.⋆ There were, of course, some obvious constraints.⋄ Operations on local works could not be done before these had been created— say by copying.⋄ Editing could only be done on local works and hence required a prior actionof, for example, copying a licensed work.• In the context of hospital health care most of the actions can only be performedif the patient has reached a suitable state in the hospitalisation.• We refer to Fig. K.10 on the next page for an idealised hospitalisation plan.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.4 Support: 36. Slide: 763 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, A Notion of License Execution State ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10YESAdmitInterviewPlanAnalysisAnalyseMore Analysis ?1234Analysis finished ?YESYESMore analysis needed ?YES5DiagnoseTreatMore analysis needed ?Analysis follow−up ?7YESPlanTreatmentAnalyse6YES? More diagnosis8YESMore treatment ?YES? Is patient OKReleaseFigure K.10: An example hospitalisation plan. States: {1,2,3,4,5,6,7,8,9}9Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.4 Support: 36. Slide: 764 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, A Notion of License Execution State ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• We therefore suggest/home/db/de/ak10/ak10⋆ to join to the licensed commands⋆ an indicator which prescribe the (set of) state(s) of the hospitalisation plan inwhich the command action may be performed.• Two or more medical staff may now be licensed⋆ to perform different (or even same !) actions⋆ in same or different states.⋆ If licensed to perform same action(s) in same state(s) —⋆ well that may be “bad license programming” if and only if it is bad medicalpractice !• One cannot design a language and prevent it being misused!Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 765 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language ]The License Language• The syntax has two parts.⋆ One for licenses being issued by licensors.⋆ And one for the actions that licensees may wish to perform.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 766 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009type0. Ln, Mn, Pn1. License = Ln × Lic2. Lic == mkLic(staff1:Mn,mandate:ML,pat:Pn)3. ML == mkML(staff2:Mn,to perform acts:CoL-set)4 CoL = Cmd | ML | Alt5. Cmd == mkCmd(σs:Σ-set,stmt:Stmt)6 Alt == mkAlt(cmds:Cmd-set)7. Stmt = admit | interview | plan-analysis | do-analysis| diagnose | plan-treatment | treat | transfer | releaseinvisible• The above syntax is correct RSL.• But it is decorated!• The subtypes {|boldface keyword|} are inserted for readability./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 767 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (0.) Licenses, medical staff and patients have names.• (1.) Licenses further consist of license bodies (Lic).• (2.) A license body names the licensee (Mn), the patient (Pn), and,• (3.) through the “mandated” licence part (ML), it names thelicensor (Mn) and which set of commands (C) or (o) implicitlicenses (L, for CoL) the licensor is mandated to issue.• (4.) An explicit command or licensing (CoL) is either a command(Cmd), or a sub-license (ML) or an alternative.• (5.) A command (Cmd) is a state-labelled statement.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 768 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]• (3.) A sub-license just states the command set that the sub-licenselicenses./home/db/de/ak10/ak10⋆ As for the Artistic License Language the licensee⋆ chooses an appropriate subset of commands.⋆ The context “inherits” the name of the patient.⋆ But the sub-licensee is explicitly mandated in the license!• (6.) An alternative is also just a set of commands.⋆ The meaning is that⋄ either the licensee choose to perform the designated actions⋄ or, as for ML, but now freely choosing the sub-licensee,⋄ the licensee (now new licensor) chooses to confer actions toother staff.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 769 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (7.) A statement is either⋆ an admit,⋆ an interview,⋆ a plan analysis,⋆ an analysis,⋆ a diagnose,directive⋆ a plan treatment,⋆ a treatment,⋆ a transfer, or⋆ a release• Information given in the patient medical report⋆ for the designated state⋆ inform medical staff as to the details⋆ of analysis, what to base a diagnosis on, of treatment, etc.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 770 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]Dines Bjorner: 1st DRAFT: January 2, 20098. Action = Ln × Act9. Act = Stmt | SubLic10. SubLic = mkSubLic(sublicensee:Ln,license:ML)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 771 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (8.) Each action actually attempted by a medical staff refers to thelicense, and hence the patient name.• (9.) Actions are either of⋆ an admit,⋆ an interview,⋆ a plan analysis,⋆ an analysis,⋆ a diagnose,actions.⋆ a plan treatment,⋆ a treatment,⋆ a transfer, or⋆ a releasePhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.5, Subsect.5 Support: 36. Slide: 772 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Hospital Health Care License Language, The License Language ]• Each individual action is only allowed in a state σ/home/db/de/ak10/ak10⋆ if the action directive appears in the named license⋆ and the patient (medical record) designates state σ.• (10.) Or an action can be a sub-licensing action.⋆ Either the sub-licensing action that the licensee is attempting isexplicitly mandated by the license (4. ML),⋆ or is an alternative one thus implicitly mandated (6.).⋆ The full sub-license, as defined in (1.–3.) is compiled fromcontextual information.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.1 Support: 36. Slide: 773 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts ]Public Government and the CitizensThe Three Branches of Government• By public government we shall,⋆ following Charles de Secondat, baron de Montesquieu(1689–1755),⋆ understand a composition of three powers:⋄ the law-making (legislative),⋄ the law-enforcing and⋄ the law-interpretingparts of public government.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.1 Support: 36. Slide: 774 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling, Scripts, Public Government and the Citizens ]The Three Branches of Government• Typically⋆ national parliament and local (province and city) councils arepart of law-making government,⋆ law-enforcing government is called the executive (theadministration),⋆ and law-interpreting government is called the judiciary [system](including lawyers etc.).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.2 Support: 36. Slide: 775 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens ]Documents• A crucial means of expressing public administration is throughdocuments.• We shall therefore provide a brief domain analysis of a concept ofdocuments.• (This document domain description also applies⋆ to patient medical records and,⋆ by some “light” interpretation, also to artistic works —insofar as they also are documents.)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.2 Support: 36. Slide: 776 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, Documents ]• Documents are⋆ created,⋆ edited and⋆ read;• and documents can be⋆ copied,⋆ distributed,⋆ the subject of calculations (interpretations) and be⋆ shared and⋆ shredded.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.3 Support: 36. Slide: 777 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens ]Document Attributes• With documents one can associate, as attributes of documents, theactors who⋆ created,⋆ edited,⋆ read,⋆ copied,⋆ distributeddocuments.⋄ (to whom distributed),⋆ shared,⋆ performed calculations and⋆ shreddedPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.3 Support: 36. Slide: 778 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, Document Attributes ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• With these operations on documents,• and hence as attributes of documents one can, again conceptually,• associate the/home/db/de/ak10/ak10⋆ location and⋆ timeof these operations.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.4 Support: 36. Slide: 779 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens ]Actor Attributes and Licenses• With actors (whether agents of public government or citizens)⋆ one can associate the authority (i.e., the rights)⋆ these actors have with respect to performing actions ondocuments.• We now intend to express these authorisations as licenses.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.5 Support: 36. Slide: 780 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens ]Document Tracing• An issue of public government is⋆ whether citizens and agents of public government act inaccordance with the laws —⋆ with actions and laws reflected in documents⋆ such that the action documents enables a trace from the actionsto the laws “governing” these actions.• We shall therefore assume that every document can be traced⋆ back to its law-origin⋆ as well as to all the documents any one document-creation or-editing was based on.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 781 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens ]• The syntax has two parts.A Document License Language⋆ One for licenses being issued by licensors.⋆ And one for the actions that licensees may wish to perform.type0. Ln, An, Cfn1. L == Grant | Extend | Restrict | Withdraw2. Grant == mkG(license:Ln,licensor:An,granted ops:Op-set,licensee:An)3. Extend == mkE(licensor:An,licensee:An,license:Ln,with ops:Op-set)4. Restrict == mkR(licensor:An,licensee:An,license:Ln,to ops:Op-set)5. Withdraw == mkW(licensor:An,licensee:An,license:Ln)6. Op == Crea|Edit|Read|Copy|Licn|Shar|Rvok|Rlea|Rtur|Calc|ShrdPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 782 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009type7. Dn, DCn, UDI8. Crea == mkCr(dn:Dn,doc class:DCn,based on:UDI-set)9. Edit == mkEd(doc:UDI,based on:UDI-set)10. Read == mkRd(doc:UDI)11. Copy == mkCp(doc:UDI)12a. Licn == mkLi(kind:LiTy)12b. LiTy == grant | extend | restrict | withdraw13. Shar == mkSh(doc:UDI,with:An-set)14. Rvok == mkRv(doc:UDI,from:An-set)15. Rlea == mkRl(dn:Dn)16. Rtur == mkRt(dn:Dn)17. Calc == mkCa(fcts:CFn-set,docs:UDI-set)18. Shrd == mkSh(doc:UDI)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 783 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (0.) The are names of licenses (Ln), actors (An), documents (UDI),document classes (DCn) and calculation functions (Cfn).• (1.) There are four kinds of licenses: granting, extending,restricting and withdrawing.• (2.) Actors (licensors) grant licenses to other actors (licensees).⋆ An actor is constrained to always grant distinctly named licenses.⋆ No two actors grant identically named licenses.⋆ A set of operations on (named) documents are granted.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 784 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• (3.–5.) Actors who have issued named licenses may extend, restrictor withdraw the license rights (wrt. operations, or fully).• (6.) There are nine kinds of operation authorisations. Some of thenext explications also explain parts of some of the correspondingactions (see (16.–24.).• (7.) There are names of documents (Dn), names of classes ofdocuments (DCn), and there are unique document identifiers(UDI)./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 785 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• (8.) Creation results in an initially void document which is⋆ not necessarily uniquely named (dn:Dn) (but that name isuniquely associated with the unique document identifier createdwhen the document is created)⋆ typed by a document class name (dcn:DCn) and possibly⋆ based on one or more identified documents (over which thelicensee (at least) has reading rights).⋆ We can presently omit consideration of the document classconcept.⋆ “based on” means that the initially void document containsreferences to those (zero, one or more) documents.⋆ The “based on” documents are moved from licensor to licensee.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 786 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (9.) Editing a document/home/db/de/ak10/ak10⋆ may be based on “inspiration” from, that is, with reference to anumber of other documents (over which the licensee (at least)has reading rights).⋆ What this “be based on” means is simply that the editeddocument contains those references. (They can therefore betraced.)⋆ The “based on” documents are moved from licensor to licensee— if not already so moved as the result of the specification ofother authorised actions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 787 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• (10.) Reading a document⋆ only changes its “having been read” status.⋆ The read document, if not the result of a copy, is moved fromlicensor to licensee — if not already so moved as the result of thespecification of other authorised actions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 788 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (11.) Copying a document/home/db/de/ak10/ak10⋆ increases the document population by exactly one document.⋆ All previously existing documents remain unchanged except thatthe document which served as a master for the copy has been somarked.⋆ The copied document is like the master document except thatthe copied document is marked to be a copy.⋆ The master document, if not the result of a create or copy, ismoved from licensor to licensee⋆ — if not already so moved as the result of the specification ofother authorised actions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 789 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (12a.) A licensee can sub-license (sL) certain operations to beperformed by other actors.• (12b.) The granting, extending, restricting or withdrawingpermissions,⋆ cannot name a license (the user has to do that),⋆ do not need to refer to the licensor (the licensee issuing thesub-license),⋆ and leaves it open to the licensor to freely choose a licensee.⋆ The licensor (the licensee issuing the sub-license) must choose aunique license name.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 790 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (13.) A document can be shared/home/db/de/ak10/ak10⋆ between two or more actors.⋆ One of these is the licensee, the others are implicitly given readauthorisations.⋆ (One could think of extending, instead the licensing actions witha shared attribute.)⋆ The shared document, if not the result of a create and edit orcopy, is moved from licensor to licensee — if not already so movedas the result of the specification of other authorised actions.⋆ Sharing a document does not move nor copy it.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 791 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (14.) Sharing documents can be revoked. That is, the readingrights are removed.• (15.) The release operation:⋆ if a licensor has authorised a licensee to create a document⋆ (and that document, when created got the unique documentidentifier udi:UDI)⋆ then that licensee can release the created, and possibly editeddocument (by that identification)⋆ to the licensor, say, for comments.⋆ The licensor thus obtains the master copy.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 792 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (16.) The return operation:/home/db/de/ak10/ak10⋆ if a licensor has authorised a licensee to create a document⋆ (and that document, when created got the unique documentidentifier udi:UDI)⋆ then that licensee can return the created, and possibly editeddocument (by that identification)⋆ to the licensor — “for good”!⋆ The licensee relinquishes all control over that document.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 793 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (17.) Two or more documents can be subjected to any one of a setof permitted calculation functions.⋆ These documents, if not the result of a creates and edits orcopies, are moved from licensor to licensee —⋆ if not already so moved as the result of the specification of otherauthorised actions.⋆ Observe that there can be many calculation permissions, overoverlapping documents and functions.• (18.) A document can be shredded.⋆ It seems pointless to shred a document if that was the only rightgranted wrt. document.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 794 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 200917. Action = Ln × Clause18. Clause = Cre | Edt | Rea | Cop | Lic | Sha | Rvk | Rel | Ret | Cal | Shr19. Cre == mkCre(dcn:DCn,based on docs:UID-set)20. Edt == mkEdt(uid:UID,based on docs:UID-set)21. Rea == mkRea(uid:UID)22. Cop == mkCop(uid:UID)23. Lic == mkLic(license:L)24. Sha == mkSha(uid:UID,with:An-set)25. Rvk == mkRvk(uid:UID,from:An-set)25. Rev == mkRev(uid:UID,from:An-set)26. Rel == mkRel(dn:Dn,uid:UID)27. Ret == mkRet(dn:Dn,uid:UID)28. Cal == mkCal(fct:Cfn,over docs:UID-set)29. Shr == mkShr(uid:UID)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 795 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• A clause elaborates to a state change and usually some value.• The value yielded by elaboration of the above⋆ create, copy, and calculationclauses• are unique document identifiers.• These are chosen by the “system”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 796 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (17.) Actions are tagged by the name of the license/home/db/de/ak10/ak10⋆ with respect to which their authorisation and document nameshas to be checked.⋆ No action can be performed by a licensee⋆ unless it is so authorised by the named license,⋆ both as concerns the operation (create, edit, read, copy, license,share, revoke, calculate and shred)⋆ and the documents actually named in the action.⋆ They must have been mentioned in the license,⋆ or, created or copies of downloaded (and possibly edited)documents or copies of these — in which cases operations areinherited.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 797 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (19.) A licensee may create documents if so licensed —⋆ and obtains all operation authorisations to this document.• (20.) A licensee may edit “downloaded” (edited and/or copied) orcreated documents.• (21.) A licensee may read “downloaded” (edited and/or copied) orcreated and edited documents.• (22.) A licensee may (conditionally) copy “downloaded” (editedand/or copied) or created and edited documents.⋆ The licensee decides which name to give the new document, i.e.,the copy.⋆ All rights of the master are inherited to the copy.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 798 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• (23.) A licensee may issue licenses/home/db/de/ak10/ak10⋆ of the kind permitted.⋆ The licensee decides whether to do so or not.⋆ The licensee decides⋄ to whom,⋄ over which, if any, documents,⋄ and for which operations.⋆ The licensee looks after a proper ordering of licensing commands:⋄ first grant,⋄ then sequences of zero, one or more either extensions orrestrictions,⋄ and finally, perhaps, a withdrawal.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 799 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• (24.) A “downloaded” (possibly edited or copied) document may(conditionally) be shared with one or more other actors.⋆ Sharing, in a digital world, for example,⋆ means that any edits done after the opening of the sharingsession,⋆ can be read by all so-granted other actors.• (25.) Sharing may (conditionally) be revoked, partially or fully,that is, wrt. original “sharers”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 800 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• (26.) A document may be released./home/db/de/ak10/ak10⋆ It means that the licensor who originally requested⋆ a document (named dn:Dn) to be created⋆ now is being able to see the results —⋆ and is expected to comment on this document⋆ and eventually to re-license the licensee to further work.• (27.) A document may be returned.⋆ It means that the licensor who originally requested⋆ a document (named dn:Dn) to be created⋆ is now given back the full control over this document.⋆ The licensee will no longer operate on it.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.6, Subsect.6 Support: 36. Slide: 801 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, Public Government and the Citizens, A Document License Language ]• (28.) A license may (conditionally) apply any of a licensed set ofcalculation functions⋆ to “downloaded” (edited, copied, etc.) documents,⋆ or can (unconditionally) apply any of a licensed set of calculationfunctions⋆ to created (etc.) documents.⋆ The result of a calculation is a document.⋆ The licensee obtains all operation authorisations to thisdocument (— as for created documents).• (29.) A license may (conditionally) shred a “downloaded” (etc.)document.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.7 Support: 36. Slide: 802 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts and Contracts ]Discussion: License Language Comparisons• We have “designed”, or rather proposed three different kinds oflicense languages.⋆ In which ways are they “similar”,⋆ and in which ways are they “different”?• Proper answers to these questions can only be given after we haveformalised these languages.⋆ The comparisons can be properly founded on⋆ comparing the semantic values of these languages.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.7 Support: 36. Slide: 803 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts and Contracts, Discussion: License Language Comparisons ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• But before we embark on such formalisations⋆ we need some informal comparisons⋆ so as to guide our formalisations.• So we shall attempt such analysis now with the understanding thatit is only a temporary one.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.7, Subsect.1 Support: 36. Slide: 804 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts and Contracts, Discussion: License Language Comparisons ]Work Items• The work items of the artistic license language(s) are essentially“kept” by the licensor.• The work items of the hospital health care license language(s)are fixed and, for a large set of licenses there is one work item, thepatient which is shared between many licensors and licenses.• The work items of the public administration license language(s)— namely document — are distributed to or created and copied bylicenses and may possibly be shared.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.7, Subsect.2 Support: 36. Slide: 805 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts and Contracts, Discussion: License Language Comparisons ]Operations• The operations of the artistic license language(s) are areessentially “kept” by the licensor.• The operations of the hospital health care license language(s)are are essentially “kept” by the licensees (as reflected in theirprofessional training and conduct).• The operations of the public administration license language(s)are essentially “kept” by the licensees (as reflected in theirprofessional training and conduct).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.7, Subsect.3 Support: 36. Slide: 806 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts and Contracts, Discussion: License Language Comparisons ]• Generally we can say thatPermissions and Obligations⋆ the modalities of the artistic license language(s) are essentiallypermissions with payment (as well as use of licensorfunctions) being an obligation;⋆ that the modalities of the hospital health care licenselanguage(s) are are essentially obligations;⋆ and, as well, that the modalities of the public administrationlicense language(s) are essentially obligations• We shall have more to say about permissions and obligations later(much later).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1 Support: 36. Slide: 807 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• In a number of steps[ Domain Modelling: Scripts, Licenses and Contracts ]A Bus Transport Contract LanguageNarrativePreparations⋆ (‘A Synopsis’,⋆ ‘A Pragmatics and Semantics Analysis’, and⋆ ‘Contracted Operations, An Overview’)• we arrive at a sound basis from which to formulate the narrative.⋆ We shall, however, forego such a detailed narrative.⋆ Instead we leave that detailed narrative to the student.⋆ (The detailed narrative can be “derived” from the formalisation.)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1, § 1 Support: 36. Slide: 808 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Narrative, Preparations ]• A Synopsis •• Contracts obligate transport companies to deliver bus traffic according to a timetable.• The timetable is part of the contract.• A contractor may sub-contract (other) transport companies to deliver bus traffic according totimetables that are sub-parts of their own timetable.• Contractors are either public transport authorities or contracted transport companies.• Contracted transport companies may cancel a subset of bus rides provided the total amount ofcancellations per 24 hours for each bus line does not exceed a contracted upper limit.• The cancellation rights are spelled out in the contract.• A sub-contractor cannot increase a contracted upper limit for cancellations above what thesub-contractor was told (in its contract) by its contractor.• Etcetera.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1, § 2 Support: 36. Slide: 809 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Narrative, Preparations ]• A Pragmatics and Semantics Analysis •• The “works” of the bus transport contracts are two:⋆ the timetables and, implicitly,⋆ the designated (and obligated) bus traffic.• A bus timetable appears to define one or more bus lines,⋆ with each bus line giving rise to one or more bus rides.• Nothing is (otherwise) said about regularity of bus rides.• It appears that bus ride cancellations must be reported back to the contractor.⋆ And we assume that cancellations by a sub-contractor is further reported backalso to the sub-contractor’s contractor.⋆ Hence eventually that the public transport authority is notified.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1, § 2 Support: 36. Slide: 810 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31main Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Narrative, Preparations, A Pragmatics and Semantics AnalysDines Bjorner: 1st DRAFT: January 2, 2009invisible• Nothing is said, in the contracts, such as we shall model them,/home/db/de/ak10/ak10⋆ about passenger fees for bus rides⋆ nor of percentages of profits (i.e., royalties) to be paid back from asub-contractor to the contractor.• So we shall not bother, in this example, about transport costs nor transportsubsidies.• The opposite of cancellations appears to be ‘insertion’ of extra bus rides,⋆ that is, bus rides not listed in the time table,⋆ but, perhaps, mandated by special events⋆ We assume that such insertions must also be reported back to the contractor.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1, § 2 Support: 36. Slide: 811 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31main Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Narrative, Preparations, A Pragmatics and Semantics AnalysDines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• We assume concepts of acceptable and unacceptable bus ride delays.⋆ Details of delay acceptability may be given in contracts,⋄ but we ignore further descriptions of delay acceptability.⋄ but assume that unacceptable bus ride delays are also to be (iteratively)reported back to contractors.• We finally assume that sub-contractors cannot (otherwise) change timetables.⋆ (A timetable change can only occur after, or at, the expiration of a license.)• Thus we find that contracts have definite period of validity.⋆ (Expired contracts may be replaced by new contracts, possibly with newtimetables.)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.1, Subsubsect. 1, § 3 Support: 36. Slide: 812 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Narrative, Preparations ]• Contracted Operations, An Overview •• So these are the operations that are allowed by a contractoraccording to a contract:⋆ (i) start: to perform, i.e., to start, a bus ride (obligated);⋆ (ii) cancel: to cancel a bus ride (allowed, with restrictions);⋆ (iii) insert: to insert a bus ride; and⋆ (iv) subcontract: to sub-contract part or all of a contract.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3 Support: 36. Slide: 813 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language ]The Final Narrative• We leave, as an exercise, the expression of a complete narrative.• Instead we proceed directly to a formalisation.A Formal Syntax• We treat separately,⋆ the syntax of contracts (for a schematised example see Slide 814) and⋆ the syntax of the actions implied by contracts (for schematised examples see Slide 817).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 1 Support: 36. Slide: 814 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax ]Contracts• An example contract can be ‘schematised’:cid: contractor cor contracts sub-contractor ceeto perform operations{"start","cancel","insert","subcontract"}with respect to timetable tt.• We assume a context (a global state)⋆ in which all contract actions (including contracting) takes place⋆ and in which the implicit net is defined.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 1 Support: 36. Slide: 815 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax, Contracts ]Dines Bjorner: 1st DRAFT: January 2, 2009130. contracts, contractors and sub-contractors have unique identifiersCId, CNm, CNm.131. A contract has a unique identification, names the contractor and thesub-contractor (and we assume the contractor and sub-contractornames to be distinct). A contract also specifies a contract body.132. A contract body stipulates a timetable and the set of operationsthat are mandated or allowed by the contractor.133. An Operation is either a "start" (i.e., start a bus ride), a bus ride"cancel"lation, a bus ride "insert", or a "subcontrat"ingoperation.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 1 Support: 36. Slide: 816 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax, Contracts ]Dines Bjorner: 1st DRAFT: January 2, 2009type130. CId, CNm131. Contract = CId × CNm × CNm × Body132. Body = Op-set × TT133. Op == ′′ start ′′ | ′′ cancel ′′ | ′′ insert ′′ | ′′ subcontract ′′An abstract example contract:(cid,cnm i ,cnm j ,({ ′′ start ′′ , ′′ cancel ′′ , ′′ insert ′′ , ′′ sublicense ′′ },tt))invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 2 Support: 36. Slide: 817 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax ]Actions• Example actions can be schematised:(a)(b)(c)cid: conduct bus ride (blid,bid) to start at time tcid: cancel bus ride (blid,bid) at time tcid: insert bus ride like (blid,bid) at time t• The schematised license (Slide 814) shown earlier is almost like anaction; here is the action form:(d) cid: sub-contractor cnm ′ is granted a contract cid ′to perform operations {”conduct”,”cancel”,”insert”,sublicense”}with respect to timetable tt ′ .Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 2 Support: 36. Slide: 818 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ A Bus Transport Contract Language, A Formal Syntax, Actions ]• All actions are being performed by a sub-contractor in a contextwhich defines⋆ that sub-contractor cnm,⋆ the relevant net, say n,⋆ the base contract, referred here to by cid (from which this is asublicense), and⋆ a timetable tt of which tt ′ is a subset.• contract name cnm ′ is new and is to be unique.• The subcontracting action can (thus) be simply transformed into acontract as shown on Slide 814.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 2 Support: 36. Slide: 819 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax, Actions ]Dines Bjorner: 1st DRAFT: January 2, 2009typeAction = CNm × CId × (SubCon | SmpAct) × TimeSmpAct = Start | Cancel | InsertConduct == mkSta(s blid:BLId,s bid:BId)Cancel == mkCan(s blid:BLId,s bid:BId)Insert = mkIns(s blid:BLId,s bid:BId)SubCon == mkCon(s cid:CId,s cnm:CNm,s body:(s ops:Op-set,s tt:TT))examples:(a) (cnm,cid,mkSta(blid,id),t)(b) (cnm,cid,mkCan(blid,id),t)(c) (cnm,cid,mkIns(blid,id),t)(d) (cnm,cid,mkCon(cid ′ ,({ ′′ conduct ′′ , ′′ cancel ′′ , ′′ insert ′′ , ′′ sublicense ′′ },tt ′ ),t))where: cid ′ = generate CId(cid,cnm,t) See Item/Line 136 on page 822invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.3, Subsubsect. 2 Support: 36. Slide: 820 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formal Syntax ]Actionsinvisible• We observe that/home/db/de/ak10/ak10⋆ the essential information given in the start, cancel and insertaction prescriptions is the same;⋆ and that the RSL record-constructors (mkSta, mkCan, mkIns)make them distinct.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.4 Support: 36. Slide: 821 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language ]Uniqueness and Traceability of Contract Identifications134. There is a “root” contract name, rcid.135. There is a “root” contractor name, rcnm.value134 rcid:CId135 rcnm:CNm• All other contract names are derived from the root name.• Any contractor can at most generate one contract name per timeunit.• Any, but the root, sub-contractor obtains contracts from othersub-contractors, i.e., the contractor. Eventually all sub-contractors,hence contract identifications can be referred back to the rootcontractor.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.4 Support: 36. Slide: 822 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Uniqueness and Traceability of Contract Identifications ]Dines Bjorner: 1st DRAFT: January 2, 2009136. Such a contract name generator is a function which given acontract identifier, a sub-contractor name and the time at whichthe new contract identifier is generated, yields the unique newcontract identifier.137. From any but the root contract identifier one can observe thecontract identifier, the sub-contractor name and the time that“went into” its creation.value136 gen CId: CId × CNm × Time → CId137 obs CId: CId ∼ → CIdL [pre obs CId(cid):cid≠rcid ]137 obs CNm: CId ∼ → CNm [pre obs CNm(cid):cid≠rcid ]137 obs Time: CId ∼ → Time [pre obs Time(cid):cid≠rcid ]invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.4 Support: 36. Slide: 823 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Uniqueness and Traceability of Contract Identifications ]138. All contract names are unique.axiom138 ∀ cid,cid ′ :CId•cid≠cid ′ ⇒138 obs CId(cid)≠obs CId(cid ′ ) ∨ obs CNm(cid)≠obs CNm(cid ′ )138 ∨ obs LicNm(cid)=obs CId(cid ′ )∧obs CNm(cid)=obs CNm(cid ′ )138 ⇒ obs Time(cid)≠obs Time(cid ′ )invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.4 Support: 36. Slide: 824 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Uniqueness and Traceability of Contract Identifications ]Dines Bjorner: 1st DRAFT: January 2, 2009139. Thus a contract name defines a trace of license name, sub-contractor name and time triple, “allthe way back” to “creation”.typeCIdCNmTTrace = TraceTriple ∗TraceTriple == mkTrTr(CId,CNm,s t:Time)value139 contract trace: CId → LCIdCNmTTrace139 contract trace(cid) ≡139 case cid of139 rcid → 〈〉,139 → contract trace(obs LicNm(cid)) ̂ 〈obs TraceTriple(cid)〉139 end139 obs TraceTriple: CId → TraceTriple139 obs TraceTriple(cid) ≡139 mkTrTr(obs CId(cid),obs CNm(cid),obs Time(cid))invisible• The trace is generated in the chronological order: most recent contract name generation timeslast./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.4 Support: 36. Slide: 825 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Uniqueness and Traceability of Contract Identifications ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• Well, there is a theorem to be proven once we have outlined the fullformal model of this contract language:• namely that time entries in contract name traces increase withincreasing indices.theorem•∀ licn:LicNm•∀ trace:LicNmLeeNmTimeTrace trace ∈ license trace(licn) ⇒•∀ i:Nat {i,i+1}⊆inds trace ⇒ s t(trace(i))

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 1 Support: 36. Slide: 826 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language ]Execution StateLocal and Global States• Each sub-contractor has an own local state and has access to a global state.• All sub-contractors access the same global state.• The global state is the bus traffic on the net.• There is, in addition, a notion of running-state. It is a meta-state notion.⋆ The running state “is made up” from the fact that⋆ there are n sub-contractors, each communicating, as contractors,⋆ over channels with other sub-contractors.• The global state is distinct from sub-contractor to sub-contractor – no sharing oflocal states between sub-contractors.• We now examine, in some detail, what the states consist of.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 2 Support: 36. Slide: 827 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Global State• The net is part of the global state (and of bus traffics).• We consider just the bus traffic.type61. BusStop == mkBS(s fhi:HI,s ol:LI,s f:Frac,s thi:HI) 692124. BusTraffic = T → m (N × (BusNo → m (Bus × BPos))) 716125. BPos = atHub | onLnk | atBS126. atHub == mkAtHub(s fl:LIs hi:HI,s tl:LI)127. onLnk == mkOnLnk(s fhi:HI,s ol:LI,s f:Frac,s thi:HI)128. atBSt == mkAtBS(s fhi:HI,s ol:LI,s f:Frac,s thi:HI)• We shall consider BusTraffic (with its Net) to reflect the globalstate.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 3 Support: 36. Slide: 828 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Local Sub-contractor Contract States• A sub-contractor state contains, as a state component, the zero, one or morecontracts⋆ that the sub-contractor has received and⋆ that the sub-contractor has sublicensed.typeBody = Op-set × TTLicΣ = RcvLicΣ×SubLicΣ×LorBusΣRcvLicΣ = LorNm → m (LicNm → m (Body×TT))SubLicΣ = LeeNm → m (LicNm → m Body)LorBusΣ ... [ see ′′ Local sub-contractor Bus States: Semantic Types ′′ next ] ..• (Recall that LorNm and LeeNm are the same.)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 829 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Local Sub-contractor Bus States• The sub-contractor state further contains a bus status state component whichrecords⋆ which buses are free, FreeBusΣ, that is, available for dispatch, and where“garaged”,⋆ which are in active use, ActvBusΣ, and on which bus ride, and a bus historyfor that bus ride,⋆ and histories of all past bus rides, BusHistΣ.⋆ A trace of a bus ride is a list of zero, one or more pairs of times and bus stops.⋆ A bus history, BusHistory, associates a bus trace to a quadruple of bus lineidentifiers, bus ride identifiers, contract names and sub-contractor name.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 830 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Local Sub-contractor Bus States ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10typeBusNoBusΣ = FreeBusesΣ × ActvBusesΣ × BusHistsΣFreeBusesΣ = BusStop → m BusNo-setActvBusesΣ = BusNo → m BusInfoBusInfo = BLId×BId×LicNm×LeeNm×BusTraceBusHistsΣ = Bno → m BusInfo ∗BusTrace = (Time×BusStop) ∗LorBusΣ = LeeNm → m (LicNm → m ((BLId×BId) → m (BNo×BusTrace)))• A bus is identified by its unique number (i.e., registration) plate (BusNo).• The two components are modified whenever a bus is commissioned into action orreturned from duty, that is, twice per bus ride.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 831 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31in Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Local Sub-contractor Bus States: Update FunctDines Bjorner: 1st DRAFT: January 2, 2009valueupdate BusΣ: Bno×(T×BusStop) → ActBusΣ → ActBusΣupdate BusΣ(bno,(t,bs))(actσ) ≡let (blid,bid,licn,leen,trace) = actσ(bno) inactσ†[ bno↦→(licn,leen,blid,bid,trace ̂ 〈(t,bs)〉) ] endpre bno ∈ dom actσinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 832 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31in Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Local Sub-contractor Bus States: Update FunctDines Bjorner: 1st DRAFT: January 2, 2009valueupdate FreeΣ ActΣ:BNo×BusStop→BusΣ→BusΣupdate FreeΣ ActΣ(bno,bs)(freeσ,actvσ) ≡let ( , , , ,trace) = actσ(b) inlet freeσ ′ = freeσ†[ bs ↦→ (freeσ(bs))∪{b} ] in(freeσ ′ ,actσ\{b}) end endpre bno ∉ freeσ(bs) ∧ bno ∈ dom actσinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 833 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31in Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Local Sub-contractor Bus States: Update FunctDines Bjorner: 1st DRAFT: January 2, 2009valueupdate LorBusΣ:LorNm×LicNm×lee:LeeNm×(BLId×BId)×(BNo×Trace)→LorBusΣ→out {l to l[ leen,lorn ]|lorn:LorNm•lorn ∈ leenms\{leen}} Lupdate LorBusΣ(lorn,licn,leen,(blid,bid),(bno,tr))(lbσ) ≡l to l[ leenm,lornm ]!Licensor BusHistΣMsg(bno,blid,bid,libn,leen,tr) ;lbσ†[ leen↦→(lbσ(leen))†[ licn↦→((lbσ(leen))(licn))†[ (blid,bid)↦→(bno,trace) ]pre leen ∈ dom lbσ ∧ licn ∈ dom (lbσ(leen))invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 4 Support: 36. Slide: 834 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31cripts, Licenses and Contracts, A Bus Transport Contract Language, A Formalisation, Semantics, Execution State, Local Sub-contractor Bus States:Dines Bjorner: 1st DRAFT: January 2, 2009valueupdate ActΣ FreeΣ:LeeNm×LicNm×BusStop×(BLId×BId)→BusΣ→BusΣ×BNoupdate ActΣ FreeΣ(leen,licn,bs,(blid,bid))(freeσ,actvσ) ≡•let bno:Bno bno ∈ freeσ(bs) in((freeσ\{bno},actvσ ∪ [ bno↦→(blid,bid,licnm,leenm,〈〉) ]),bno) endpre bs ∈ dom freeσ ∧ bno ∈ freeσ(bs) ∧ bno ∉ dom actvσ ∧ [ bs existsinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 5 Support: 36. Slide: 835 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Constant State Values• There are a number of constant values, of various types, which characterise the “business ofcontract holders”. We define some of these now.140. For simplicity we assume a constant net — constant, that is, only with respect to the set ofidentifiers links and hubs. These links and hubs obviously change state over time.141. We also assume a constant set, leens, of sub-contractors. In reality sub-contractors, that is,transport companies, come and go, are established and go out of business. But assumingconstancy does not materially invalidate our model. Its emphasis is on contracts and theirimplied actions — and these are unchanged wrt. constancy or variability of contract holders.142. There is an initial bus traffic, tr.143. There is an initial time, t 0 , which is equal to or larger than the start of the bus traffic tr.144. To maintain the bus traffic “spelled out”, in total, by timetable tt one needs a number ofbuses.145. The various bus companies (that is, sub-contractors) each have a number of buses. Each bus,independent of ownership, has a unique (car number plate) bus number (BusNo).These buses have distinct bus (number [registration] plate) numbers.146. We leave it to the student to define a function which ascertain the minimum number of busesneeded to implement traffic tr.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 5 Support: 36. Slide: 836 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Constant State Values ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10value140. net : N,141. leens : LeeNm-set,142. tr : BusTraffic, axiom wf Traffic(tr)(net)143. t 0•: T t 0 ≥ mindom tr,•144. min no of buses : Nat necessary no of buses(itt),•145. busnos : BusNo-set card busnos ≥ min no of buses146. necessary no of buses: TT → NatPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 5 Support: 36. Slide: 837 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Constant State Values ]Dines Bjorner: 1st DRAFT: January 2, 2009147. To “bootstrap” the whole contract system we need adistinguished contractor, named init leen, whose only licenseoriginates with a “ghost” contractor, named root leen (o, foroutside [the system]).148. The initial, i.e., the distinguished, contract has a name, root licn.149. The initial contract can only perform the "sublicense"operation.150. The initial contract has a timetable, tt.151. The initial contract can thus be made up from the above.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 5 Support: 36. Slide: 838 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Constant State Values ]Dines Bjorner: 1st DRAFT: January 2, 2009value•147. root leen,init ln : LeeNm root leen ∉ leens ∧ initi leen ∈ leens,148. root licn : LicNm149. iops : Op-set = { ′′ sublicense ′′ },150. itt : TT,151. init lic:License = (root licn,root leen,(iops,itt),init leen)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 6 Support: 36. Slide: 839 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Initial Sub-contractor Contract StatestypeInitLicΣs = LeeNm → m LicΣvalueilσ:LicΣ=([ init leen ↦→ [ root leen ↦→ [ iln ↦→ init lic ] ] ]∪ [ leen ↦→ [ ] | leen:LeeNm • leen ∈ leenms\{init leen} ],[ ],[ ])Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 7 Support: 36. Slide: 840 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Initial Sub-contractor Bus States152. Initially each sub-contractor possesses a number of buses.153. No two sub-contractors share buses.154. We assume an initial assignment of buses to bus stops of the free buses statecomponent and for respective contracts.155. We do not prescribe a “satisfiable and practical” such initial assignment (ibσs).156. But we can constrain ibσs.157. The sub-contractor names of initial assignments must match those of initial busassignments, allbuses.158. Active bus states must be empty.159. No two free bus states must share buses.160. All bus histories are void.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 7 Support: 36. Slide: 841 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Initial Sub-contractor Bus States ]Dines Bjorner: 1st DRAFT: January 2, 2009type152. AllBuses ′ = LeeNm → m BusNo-set153. AllBuses = {|ab:AllBuses ′ •∀ {bs,bs ′ }⊆rng ab∧bns≠bns ′ ⇒bns ∩ bns ′ ={}|}154. InitBusΣs = LeeNm → m BusΣvalue153. allbuses:Allbuses • dom allbuses = leenms ∪ {root leen} ∧ ∪ rng allbuses = busnos154. ibσs:InitBusΣs155. wf InitBusΣs: InitBusΣs → Bool156. wf InitBusΣs(iσs) ≡157. dom iσs = leenms ∧158. ∀ ( ,abσ, ):BusΣ ( ,abσ, ) ∈ rng iσs ⇒ abσ=[ ] ∧•159. ∀ (fbiσ,abiσ),(fbjσ,abjσ):BusΣ •159. {(fbiσ,abiσ),(fbjσ,abjσ)}⊆rng iσs159. ⇒ (fbiσ,actiσ)≠(fbjσ,actjσ)159. ⇒ rng fbiσ ∩ rng fbjσ = {}160. ∧ actiσ=[ ]=actjσinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 842 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Communication Channels• The running state is a meta notion. It reflects the channels over which⋆ contracts are issued;⋆ messages about committed, cancelled and inserted bus rides are communicated, and⋆ fund transfers take place.• Sub-Contractor↔Sub-Contractor Channels⋆ Consider each sub-contractor (same as contractor) to be modelled as a behaviour.⋆ Each sub-contractor (licensor) behaviour has a unique name, the LeeNm.⋆ Each sub-contractor can potentially communicate with every other sub-contractor.⋆ We model each such communication potential by a channel.⋆ For n sub-contractors there are thus n × (n − 1) channels.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 843 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Communication Channels ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10channel { l to l[ fi,ti ] | fi:LeeNm,ti:LeeNm • {fi,ti}⊆leens ∧ fi≠ti } LLMSGtype LLMSG = ...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 844 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Communication Channels ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Sub-Contractor↔Bus Channels/home/db/de/ak10/ak10⋆ Each sub-contractor has a set of buses. That set may vary.⋆ So we allow for any sub-contractor to potentially communicate with any bus.⋆ In reality only the buses allocated and scheduled by a sub-contractor can be“reached” by that sub-contractor.channel { l to b[ l,b ] | l:LeeNm,b:BNo • l ∈ leens ∧ b ∈ busnos } LBMSGtype LBMSG = ...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 845 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Communication Channels ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• Sub-Contractor↔Time Channels⋆ Whenever a sub-contractor wishes to perform a contract operation⋆ that sub-contractor needs know the time.⋆ There is just one, the global time, modelled as one behaviour: time clock.channel { l to t[ l ] | l:LeeNm • l ∈ leens } LTMSGtype LTMSG = ...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 846 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Communication Channels ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Bus↔Traffic Channels/home/db/de/ak10/ak10⋆ Each bus is able, at any (known) time to ascertain where in the traffic it is.⋆ We model bus behaviours as processes, one for each bus.⋆ And we model global bus traffic as a single, separate behaviour.channel { b to tr[ b ] | b:BusNo • b ∈ busnos } LTrMSGtypeBTrMSG == reqBusAndPos(s bno:BNo,s t:Time) | (Bus×BusPos)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 8 Support: 36. Slide: 847 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Communication Channels ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10• Buses↔Time Channel⋆ Each bus needs to know what time it is.channel { b to t[ b ] | b:BNo • b ∈ busnos } BTMSGtypeBTMSG ...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 9 Support: 36. Slide: 848 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]Run-time Environment• So we shall be modelling the transport contract domain as follows:⋆ As for behaviours we have this to say.⋄ There will be n sub-contractors. One sub-contractor will beinitialised to one given license.⋄ Each sub-contractor is modelled, in RSL, as a CSP-like process.⋄ With each sub-contractor, l i , there will be a number, b i , ofbuses. That number may vary from sub-contractor tosub-contractor.⋄ There will be b i channels of communication between asub-contractor and that sub-contractor’s buses, for eachsub-contractor.⋄ There is one global process, the traffic. There is one channel ofcommunication between a sub-contractor and the traffic. Thusthere are n such channels.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 9 Support: 36. Slide: 849 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, Run-time Environment ]invisible/home/db/de/ak10/ak10⋆ As for operations, including behaviour interactions we assumethe following.⋄ All operations of all processes are to be thought of asinstantaneous, that is, taking nil time !⋄ Most such operations are the result of channel communications◦ either just one-way notifications,◦ or inquiry requests.⋄ Both the former (the one-way notifications) and the latter(inquiry requests) must not be indefinitely barred from receipt,otherwise holding up the notifier.⋄ The latter (inquiry requests) should lead to rather immediateresponses, thus must not lead to dead-locks.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 10 Support: 36. Slide: 850 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State ]The System Behaviour• The system behaviour starts by establishing a number of⋆ licenseholder ⋆ and ⋆ bus ridebehaviours and the single⋆ time clock ⋆ and ⋆ bus trafficbehavioursPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 10 Support: 36. Slide: 851 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Execution State, The System Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009valuesystem: Unit → Unitsystem() ≡licenseholder(init leen)(ilσ(init leen),ibσ(init leen))‖ (‖ {licenseholder(leen)(ilσ(leen),ibσ(leen))| leen:LeeNm•leen ∈ leens\{init leen}})‖ (‖ {bus ride(b,leen)(root lorn, ′′ nil ′′ )| leen:LeeNm,b:BusNo •leen ∈ dom allbuses ∧ b ∈ allbuses(leen)})‖ time clock(t 0 ) ‖ bus traffic(tr)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.5, Subsubsect. 10 Support: 36. Slide: 852 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, A Formalisation, Semantics, The System Behaviour ]invisible• The initial licenseholder behaviour states are individually initialised/home/db/de/ak10/ak10⋆ with basically empty license states and⋆ by means of the global state entity bus states.• The initial bus behaviours need no initial state.• Only a designated licenseholder behaviour is initialised⋆ to a single, received license.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 1 Support: 36. Slide: 853 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language ]Semantic Elaboration FunctionsThe Licenseholder Behaviour161. The licenseholder behaviour is a sequential, but internally non-deterministicbehaviour.162. It internally non-deterministically (⌈⌉) alternates between(a) performing the licensed operations (on the net and with buses),(b) receiving information about the whereabouts of these buses, and informingcontractors of its (and its subsub-contractors’) handling of the contracts (i.e.,the bus traffic), and(c) negotiating new, or renewing old contracts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 1 Support: 36. Slide: 854 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31omain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Licenseholder BehaviourDines Bjorner: 1st DRAFT: January 2, 2009161. licenseholder: LeeNm → (LicΣ×BusΣ) → Unit162. licenseholder(leen)(licσ,busσ) ≡162. licenseholder(leen)((lic ops⌈⌉bus mon⌈⌉neg licenses)(leen)(licσ,busσ))invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 855 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Bus Behaviour163. Buses ply the network following a timed bus route description.A timed bus route description is a list of timed bus stop visits.164. A timed bus stop visit is a pair: a time and a bus stop.165. Given a bus route and a bus schedule one can construct a timed bus routedescription./home/db/de/ak10/ak10(a) The first result element is the first bus stop and origin departure time.(b) Intermediate result elements are pairs of respective intermediate scheduleelements and intermediate bus route elements.(c) The last result element is the last bus stop and final destination arrival time.166. Bus behaviours start with a “nil” bus route description.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 856 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Bus Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009type163. TBR = TBSV ∗164. TBSV = Time × BusStopvalue165. conTBR: BusRoute × BusSched → TBR165. conTBR((dt,til,at),(bs1,bsl,bsn)) ≡165(a) 〈(dt,bs1)〉165(b) ̂ 〈(til[ i ],bsl[ i ])|i:Nat i:〈1..len til〉〉•165(c) ̂ 〈(at,bsn)〉pre: len til = len bsltype166. BRD == ′′ nil ′′ | TBRinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 857 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Bus Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009167. The bus behaviour is here abstracted to only communicate with some contractholder, time and traffic,168. The bus repeatedly observes the time, t, and its position, po, in the traffic.169. There are now four case distinctions to be made.170. If the bus is idle (and a a bus stop) then it waits for a next route, brd ′ on whichto engage.171. If the bus is at the destination of its journey then it so informs its owner (i.e., thesub-contractor) and resumes being idle.172. If the bus is ‘en route’, at a bus stop, then it so informs its owner and continuesthe journey.173. In all other cases the bus continues its journeyinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 858 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Bus Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009value167. bus ride: leen:LeeNm × bno:Bno → (LicNm × BRD) →167. in,out l to b[ leen,bno ], in,out b to tr[ bno ], in b to t[ bno ] Unit167. bus ride(leen,bno)(licn,brd) ≡168. let t = b to t[ bno ]? in168. let (bus,pos) = (b to tr[ bno ]!reqBusAndPos(bno,t) ; b to tr[ bno ]?) in169. case (brd,pos) of170. ( ′′ nil ′′ ,mkAtBS( , , , )) →170. let (licn,brd ′ ) = (l to b[ leen,bno ]!reqBusRid(pos);l to b[ leen,bno ]?) in170. bus ride(leen,bno)(licn,brd ′ ) end171. (〈(at,pos)〉,mkAtBS( , , , )) →171s l to b[ l,b ]!BusΣMsg(t,pos);171 l to b[ l,b ]!BusHistΣMsg(licn,bno);171 l to b[ l,b ]!FreeΣ ActΣMsg(licn,bno) ;171 bus ride(leen,bno)(ilicn, ′′ nil ′′ ),172. (〈(t,pos),(t ′ ,bs ′ )〉 ̂ brd ′ ,mkAtBS( , , , )) →172s l to b[ l,b ]!BusΣMsg(t,pos) ;172 bus ride(licn,bno)(〈(t ′ ,bs ′ )〉 ̂ brd ′ ),invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 859 of 894173. → bus ride(leen,bno)(licn,brd) end end endc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 2 Support: 36. Slide: 860 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Bus Behaviour ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• In formula line 168 of bus ride we obtained the bus.• But we did not use “that” bus !• We we may wish to record, somehow, number of passengers alighting and boarding at bus stops,bus fees paid, one way or another, etc.• The bus, which is a time-dependent entity, gives us that information.• Thus we can revise formula lines 171s and 172s:Simple: 171s l to b[ l,b ]!BusΣMsg(pos);Revised: 171r l to b[ l,b ]!BusΣMsg(pos,bus info(bus));Simple: 172s l to b[ l,b ]!BusΣMsg(pos);Revised: 172r l to b[ l,b ]!BusΣMsg(pos,bus info(bus));typeBus Info = Passengers × Passengers × Cash × ...valuebus info: Bus → Bus Infobus info(bus) ≡ (obs alighted(bus),obs boarded(bus),obs till(bus),...)/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 3 Support: 36. Slide: 861 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Global Time Behaviour174. The time clock is a never ending behaviour — started at some time t 0 .175. The time can be inquired at any moment by any of the licenseholder behaviours and by any ofthe bus behaviours.176. At any moment the time clock behaviour may not be inquired.177. After a skip of the clock or an inquiry the time clock behaviour continues, non-deterministicallyeither maintaining the time or advancing the clock!value174. time clock: T →174. in,out {l to t[ leen ] | leen:LeeNm leen ∈ leenms}•174. in,out {b to t[ bno ] | bno:BusNo bno ∈ busnos} Unit•174. time clock:(t) ≡176. (skip ⌈⌉175. (⌈⌉ ⌊⌋{l to t[ leen ]? ; l to t[ leen ]!t | leen:LeeNm leen ∈ leens})•175. ⌈⌉ (⌈⌉ ⌊⌋{b to t[ bno ]? ; b to t[ bno ]!t | bno:BusNo bno ∈ busnos})) ;•177. (time clock:(t) ⌈⌉ time clock(t+δ t ))/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 4 Support: 36. Slide: 862 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Bus Traffic Behaviour178. There is a single bus traffic behaviour. It is, “mysteriously”, given a constant argument, “the”traffic, tr.179. At any moment it is ready to inform of the position, bps(b), of a bus, b, assumed to be in thetraffic at time t.180. The request for a bus position comes from some bus.181. The bus positions are part of the traffic at time t.182. The bus traffic behaviour, after informing of a bus position reverts to “itself”.value178. bus traffic: TR → in,out {b to tr[ bno ]|bno:BusNo bno ∈ busnos} Unit•178. bus traffic(tr) ≡180. ⌊⌋ ⌈⌉ { let reqBusAndPos(bno,time) = b to tr[ b ]? in assert b=bno179. if time ∉ dom tr then chaos else181. let ( ,bps) = tr(t) in179. if bno ∉ dom tr(t) then chaos else179. b to tr[ bno ]!bps(bno) end end end end | b:BusNo b ∈ busnos} ;•182. bus traffic(tr)/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 5 Support: 36. Slide: 863 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]License Operations183. The lic ops function models the contract holder choosing between and performinglicensed operations.184. To perform any licensed operation the sub-contractor needs to know the time and185. must choose amongst the four kinds of operations that are licensed./home/db/de/ak10/ak10• The choice function, which we do not define, makes a basicallynon-deterministic choice among licensed alternatives.• The choice yields the contract number of a received contract and,• based on its set of licensed operations,• it yields either a simple action or a sub-contracting action.186. Thus there is a case distinction amongst four alternatives.187. This case distinction is expressed in the four lines identified by: 187.188. All the auxiliary functions, besides the action arguments, require the same statearguments.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 5 Support: 36. Slide: 864 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, License Operations ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10typeAction = LicNm × LeeNm × T × (SimplAct | SubLic)SmpAct = Condct | Cancel | InsertCondct == mkCon(s bli:BusLnId,s bi:BusId)Cancel == mkCan(s bli:BusLnId,s bi:BusId)Insert = mkIns(s bli:BusLnId,s bi:BusId)SubLic == mkLic(s l:LeeNm,s bo:(s tt:TT,s ops:Op-set))value183. lic ops: LeeNm → (LicΣ×BusΣ) → (LicΣ×BusΣ)183. lic ops(leen)(licσ,busσ) ≡184. let t = (time channel(leen)!req Time;time channel(leen)?) in185. let (licn,act) = choice(licσ)(busσ)(t) in186. (case act of187. mkCon(blid,bid) → cndct(licn,leenm,t,act),187. mkCan(blid,bid) → cancl(licn,leenm,t,act),187. mkIns(blid,bid) → insrt(licn,leenm,t,act),187. mkLic(leenm ′ ,bo) → sublic(licn,leenm,t,act) end)(licσ,busσ) end endcndct,cancl,insert: SmpAct→(LicΣ×BusΣ)→(LicΣ×BusΣ)sublic: SubLic→(LicΣ×BusΣ)→(LicΣ×BusΣ)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 6 Support: 36. Slide: 865 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]Bus Monitoring/home/db/de/ak10/ak10• Like for the bus ride behaviour we decompose the bus monitoring behaviourinto two behaviours.⋆ The local bus monitoring behaviour monitors the buses that arecommissioned by the sub-contractor.⋆ The licensor bus monitoring behaviour monitors the buses that arecommissioned by sub-contractors sub-contractd by the contractor.valuebus mon: l:LeeNm → (LicΣ×BusΣ)→ in {l to b[ l,b ]|b:BNo • b ∈ allbuses(l)} (LicΣ×BusΣ)bus mon(l)(licσ,busσ) ≡local bus mon(l)(licσ,busσ) ⌈⌉ licensor bus mon(l)(licσ,busσ)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 6 Support: 36. Slide: 866 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, Bus Monitoring ]Dines Bjorner: 1st DRAFT: January 2, 2009189. The local bus monitoring function models all the interaction between a contract holder and itsdespatched buses.190. We show only the communications from buses to contract holders.191.192.193.194.195.196.197.198.199.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 6 Support: 36. Slide: 867 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, Bus Monitoring ]Dines Bjorner: 1st DRAFT: January 2, 2009189. local bus mon: leen:LeeNm → (LicΣ×BusΣ)190. → in {l to b[ leen,b ]|b:BNo b ∈ allbuses(l)} (LicΣ×BusΣ)•189. local bus mon(leen)(licσ:(rlσ,slσ,lbσ),busσ:(fbσ,abσ)) ≡191. let (bno,msg) = ⌊⌋{(b,l ⌈⌉ to b[ l,b ]?)|b:BNo b ∈ allbuses(leen)} in•195. let (blid,bid,licn,lorn,trace) = abσ(bno) in192. case msg of193. BusΣMsg(t,bs) →197. let abσ ′ = update BusΣ(bno)(licn,leen,blid,bid)(t,bs)(abσ) in197. (licσ,(fbσ,abσ ′ ,histσ)) end,199. BusHistΣMsg(licn,bno) →199. let lbσ ′ =199. update LorBusΣ(obs LorNm(licn),licn,leen,(blid,bid),(b,trace))(lbσ) in199. l to l[ leen,obs LorNm(licn) ]!Licensor BusHistΣMsg(licn,leen,bno,blid,bid,tr);199. ((rlσ,slσ,lbσ ′ ),busσ) end198. FreeΣ ActΣMsg(licn,bno) →199. let (fbσ ′ ,abσ ′ ) = update FreeΣ ActΣ(bno,bs)(fbσ,abσ) in199. (licσ,(fbσ ′ ,abσ ′ )) end199. end end endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 6 Support: 36. Slide: 868 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ A Bus Transport Contract Language, A Formalisation, Semantics, Semantic Elaboration Functions, Bus Monitoring ]Dines Bjorner: 1st DRAFT: January 2, 2009200.201.202.203.204.invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 6 Support: 36. Slide: 869 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, Bus Monitoring ]Dines Bjorner: 1st DRAFT: January 2, 2009200. licensor bus mon: lorn:LorNm → (LicΣ×BusΣ)200. → in {l to l[ lorn,leen ]|leen:LeeNm leen ∈ leenms\{lorn}} (LicΣ×BusΣ)•200. licensor bus mon(lorn)(licσ,busσ) ≡200. let (rlσ,slσ,lbhσ) = licσ in200. let (leen,Licensor BusHistΣMsg(licn,leen ′′ ,bno,blid,bid,tr))= ⌊⌋{(leen ⌈⌉,l to l[ lorn,leen ′ ]?)|leen ′ :LeeNm leen ′ ∈ leenms\{lorn}} in•200. let lbhσ ′ =200. update BusHistΣ(obs LorNm(licn),licn,leen ′′ ,(blid,bid),(bno,trace))(lbhσ) in200. l to l[ leenm,obs LorNm(licnm) ]!Licensor BusHistΣMsg(b,blid,bid,lin,lee,tr);200. ((rlσ,slσ,lbhσ ′ ),busσ)200. end end endinvisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 7 Support: 36. Slide: 870 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009205.206.207.208.209.210.211.212.213.214.215.216.invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]License Negotiation/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 8 Support: 36. Slide: 871 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]License Negotiation205.206.207.208.209.210.211.212.213.214.215./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 9 Support: 36. Slide: 872 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Conduct Bus Ride Action217. The conduct bus ride action prescribed by (ln,mkCon(bli,bi,t ′ ) takes place in a context and shallhave the following effect:/home/db/de/ak10/ak10(a) The action is performed by contractor li and at time t. This is known from the context.(b) First it is checked that the timetable in the contract named ln does indeed provide a journey,j, indexed by bli and (then) bi, and that that journey starts (approximately) at time t ′ whichis the same as or later than t.(c) Being so the action results in the contractor, whose name is “embedded” in ln, receivingnotification of the bus ride commitment.(d) Then a bus, selected from a pool of available buses at the bust stop of origin of journey j, isgiven j as its journey script, whereupon that bus, as a behaviour separate from that ofsub-contractor li, commences its ride.(e) The bus is to report back to sub-contractor li the times at which it stops at en route bus stopsas well as the number (and kind) of passengers alighting and boarding the bus at these stops.(f) Finally the bus reaches its destination, as prescribed in j, and this is reported back tosub-contractor li.(g) Finally sub-contractor li, upon receiving this ‘end-of-journey’ notification, records the bus asno longer in actions but available at the destination bus stop.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 9 Support: 36. Slide: 873 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31omain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Conduct Bus Ride ActioDines Bjorner: 1st DRAFT: January 2, 2009217.217(a)217(b)217(c)217(d)217(e)217(f)217(g)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 10 Support: 36. Slide: 874 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Cancel Bus Ride Action218. The cancel bus ride action prescribed by (ln,mkCan(bli,bi,t ′ ) takes place in acontext and shall have the following effect:(a) The action is performed by contractor li and at time t. This is known from thecontext.(b) First a check like that prescribed in Item 217(b) is performed.(c) If the check is OK, then the action results in the contractor, whose name is“embedded” in ln, receiving notification of the bus ride cancellation.That’s all !/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 10 Support: 36. Slide: 875 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31omain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Cancel Bus Ride ActionDines Bjorner: 1st DRAFT: January 2, 2009218.218(a)218(b)218(c)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 11 Support: 36. Slide: 876 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Insert Bus Ride Action219. The insert bus ride action prescribed by (ln,mkIns(bli,bi,t ′ ) takes place in acontext and shall have the following effect:(a) The action is performed by contractor li and at time t. This is known from thecontext.(b) First a check like that prescribed in Item 217(b) is performed.(c) If the check is OK, then the action results in the contractor, whose name is“embedded” in ln, receiving notification of the new bus ride commitment.(d) The rest of the effect is like that prescribed in Items 217(d)–217(g)./home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 11 Support: 36. Slide: 877 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31omain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Insert Bus Ride ActionDines Bjorner: 1st DRAFT: January 2, 2009219.219(a)219(b)219(c)219(d)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 12 Support: 36. Slide: 878 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions ]The Contracting Action220. The subcontracting action prescribed by (ln,mkLic(li ′ ,(pe ′ ,ops ′ ,tt ′ ))) takes place in a context andshall have the following effect:/home/db/de/ak10/ak10(a) The action is performed by contractor li and at time t. This is known from the context.(b) First it is checked that timetable tt is a subset of the timetable contained in, and that theoperations ops are a subset of those granted by, the contract named ln.(c) Being so the action gives rise to a contract of the form (ln ′ ,li,(pe ′ ,ops ′ ,tt ′ ),li ′ ). ln ′ is a uniquenew contract name computed on the basis of ln, li, and t. li ′ is a sub-contractor name chosenby contractor li. tt ′ is a timetable chosen by contractor li. ops ′ is a set of operations likewisechosen by contractor li.(d) This contract is communicated by contractor li to sub-contractor li ′ .(e) The receipt of that contract is recorded in the license state.(f) The fact that the contractor has sublicensed part (or all) of its obligation to conduct bus ridesis recorded in the modified component of its received contracts.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.6, Subsubsect. 12 Support: 36. Slide: 879 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language, Semantic Elaboration Functions, The Contracting Action ]Dines Bjorner: 1st DRAFT: January 2, 2009220.220(a)220(b)220(c)220(d)220(e)220(f)invisible/home/db/de/ak10/ak10Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.7 Support: 36. Slide: 880 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak10/ak10[ Domain Modelling: Scripts, Licenses and Contracts, A Bus Transport Contract Language ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix K, Sect.8, Subsect.7 Support: 36. Slide: 881 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Scripts and ContractsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 37. Slide: 882 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak11/ak11Support: Human BehaviourPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix L Support: 37. Slide: 883 of 894Human Behaviourc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak11/ak11Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix L Support: 37. Slide: 884 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Human BehaviourPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 38. Slide: 885 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12Support: From Domains to RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M Support: 38. Slide: 886 of 894From Domains to Requirementsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 1 Support: 38. Slide: 887 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12[ From Domains to Requirements ]Shared Phenomena and ConceptsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 2 Support: 38. Slide: 888 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12[ From Domains to Requirements ]Domain RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 3 Support: 38. Slide: 889 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12[ From Domains to Requirements ]Interface RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 4 Support: 38. Slide: 890 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12[ From Domains to Requirements ]Machine RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 5 Support: 38. Slide: 891 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak12/ak12[ From Domains to Requirements ]DiscussionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix M, Sect. 5 Support: 38. Slide: 892 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: From Domains to RequirementsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 39. Slide: 893 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak13/ak13Support: Wrapping it All Up !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix N Support: 39. Slide: 894 of 894Wrapping it All Up !c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/ak13/ak13Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix N Support: 39. Slide: 895 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: Wrapping it All Up !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesSupport: 40. Slide: 896 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslSupport: An RSL PrimerPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O Support: 40. Slide: 897 of 894An RSL Primerc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1 Support: 40. Slide: 898 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Simplifying we consider/home/db/de/rsl/rsl[ An RSL Primer ]Types and Values⋆ a type to be a class (a possibly infinite set) of values,⋆ i.e., a set characterised by some unifying properties.⋆ Values are then instances of “things” that satisfy such properties.• Examples of values are⋆ the numbers denoted by the numerals: 0, 1, 2, . . . , etc.;⋆ the numbers denoted by the numerals: . . . , -2, -1, 0, 1, 2, . . . , etc.; and⋆ the numbers denoted by the numerals: . . . , -5.43, -1.0, 0.0, 1.23· · ·,2,71828183· · ·, 3,14159265· · ·, 4.56 . . . , etc.• We shall refer to the types of these three example sets by the type names Nat,Int, Real.• As we shall soon see, there are an infinity of types.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect.1 Support: 40. Slide: 899 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl• We distinguish[ An RSL Primer, Types and Values ]Some Distinctions⋆ between discrete and continuous types⋆ and hence between discrete and continuous values.• By a discrete value we mean a value which is either atomic discreteor composite discrete:⋆ an atomic discrete value is a value which we are not interested indecomposing into components as it makes no sense for us to doso;⋆ a composite discrete value is a value which can be decomposedinto (one or more) components which are all discrete values.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect. 1 Support: 40. Slide: 900 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ An RSL Primer, Types and Values, Some Distinctions ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible• By a continuous value we mean a value which is either atomiccontinuous or composite continuous:/home/db/de/rsl/rsl⋆ an atomic continuous value is a value which we are not interestedin decomposing into components as it makes no sense for us to doso and where the values of the type lie in some dense point space;⋆ a composite continuous value is a value which can bedecomposed into meaningful (one or more) components some ofwhich (one or more) are continuous values.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect.1 Support: 40. Slide: 901 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ An RSL Primer, Types and Values, Some Distinctions ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslOil Industry Example 1: Atomic and Composite Types and Values• A pipe is a composite continuous value which consists of⋆ a pipe structure and⋆ some oil;• the former being of discrete atomic value• while the latter is a continuous atomic value:⋆ “from no oil,⋆ via a tiny drop of oil, and more,⋆ say a gallon and a third of oil,⋆ to several million barrels of oil”.• Similarly for pumps, valves, depots, etc.:⋆ all are composite continuous values consisting of⋆ corresponding discrete atomic structures and continuous atomic valued (amounts of) oil.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect. 2 Support: 40. Slide: 902 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ An RSL Primer, Types and Values ]An Aside• You might mistakenly think that continuous atomic values are composed from“subsegments” or “subspcaces” or “subvolumes”, etc., of continuous atomicvalues.• Consider the following examples:⋆ Crude oil:⋄ one can decompose crude oil into a very large number of molecules (ofdifferent hydrocarbons);⋄ the most commonly found molecules are alkanes (linear or branched),cycloalkanes, aromatic hydrocarbons, or more complicated chemicals likeasphaltenes;⋄ but it is not a decomposition of a litre of crude oil to divide it up into tendecilitres.⋄ But if our choice of abstraction ignores the molecular structure of oil, thenoil has an atomic, continuous value.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect.2 Support: 40. Slide: 903 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ An RSL Primer, Types and Values, An Aside ]⋆ Time:⋄ one can decompose time into years, months, weeks, days,hourse, minutes and seconds;⋄ but if our choice of abstraction ignores these units, and justconsiders the time axis to be a linearly ordered dense set ofpoints, then time has an atomic, continuous value.• Thus we must consider the operations to be (i.e., that we wish)performed on what may appear as continuous values in order todetermine our abstraction:⋆ either as atomic continuous values⋆ or as composite continuous values.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.1, Subsect. 2 Support: 40. Slide: 904 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Operations on oil/home/db/de/rsl/rsl[ An RSL Primer, Types and Values, An Aside ]⋆ divide a volume of oil into a set of two or more volumes of oil,⋆ displaces a volume of oil from one location into a (usuallyneighbouring) locations,⋆ etc.• Operations on time⋆ calculates the time interval between two time points,⋆ adds an interval of time to time to obtain another time,⋆ etc.• But in all these examples oil, respectively time remain atomic,continuous values.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect.1, Subsubsect. 1 Support: 40. Slide: 905 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ An RSL Primer ]TypesType 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”.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect. 1, Subsubsect. 1 Support: 40. Slide: 906 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ An RSL Primer, Types, Type Expressions, Atomic Types ]Dines Bjorner: 1st DRAFT: January 2, 2009type[ 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”invisible/home/db/de/rsl/rslPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect.1, Subsubsect. 1 Support: 40. Slide: 907 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ An RSL Primer, Types, Type Expressions, Atomic Types ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslOil Industry Example 2: Atomic Discrete TypestypeDrainPumpStruct, PipeStruct, ValveStruct, FlowPumpStruct,FillPumpStruct, DepotStruct, SwitchStruct, ...Oil Industry Example 3: Atomic Continuous TypestypeTimeOil, Gasoline, Gas, Ethanol, ...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect. 1, Subsubsect. 2 Support: 40. Slide: 908 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ An RSL Primer, Types, Type Expressions ]Composite Types• Composite types have composite values.⋆ That is, values which we consider to have proper constituent(sub-)values,⋆ i.e., can be meaningfully “taken apart”.• There are two ways of expressing composite types:⋆ either explicitly, using concrete type expressions,⋆ or implicitly, using sorts (i.e., abstract types) and observerfunctions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect.1, Subsubsect. 2, § 1 Support: 40. Slide: 909 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ 7 ] A-set[ 8 ] A-infset[ 9 ] A × B × ... × C[ 10 ] A ∗[ 11 ] A ω[ 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[ An RSL Primer, Types, Type Expressions, Composite Types ]• Concrete Composite Types •Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect. 1, Subsubsect. 2, § 2 Support: 40. Slide: 910 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ An RSL Primer, Types, Type Expressions, Composite Types ]• Sorts and Observer Functions •typeA, B, C, ..., Dvalueobs 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 these are of type B, C, . . . , and D.• A concrete type definition corresponding to the above⋆ presupposing material of the next sectiontypeB, C, ..., DA = B × C × ... × DPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect.2, Subsubsect. 1 Support: 40. Slide: 911 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl• Types can be concrete[ An RSL Primer, Types ]Type DefinitionsConcrete Types• in which case the structure of the type is specified by type expressions:typeA = Type expr• Schematic type definitions:[ 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) |}Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect. 2, Subsubsect. 1 Support: 40. Slide: 912 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Types, Type Definitions, Concrete Types ]• 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)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 ina1 ′ = s a1(a) ∧ a2 ′ = s a2(a) ∧ ... ∧ ai ′ = s ai(a) endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect.2, Subsubsect. 2 Support: 40. Slide: 913 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Types, Type Definitions ]Subtypes• In RSL, each type represents a set of values. Such a set can bedelimited by means of predicates.• The set of values b which have type B and which satisfy thepredicate P, constitute the subtype A:typeA = {| b:B•P(b) |}Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.2, Subsect. 2, Subsubsect. 3 Support: 40. Slide: 914 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Types can be (abstract) sorts/home/db/de/rsl/rsl[ Types, Type Definitions ]Sorts — Abstract Types• in which case their structure is not specified:typeA, B, ..., CPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.3, Subsect.1 Support: 40. Slide: 915 of 894/home/db/de/rsl/rslThe RSL Predicate CalculusPropositional Expressionsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• Let identifiers (or propositional expressions) a, b, ..., c designateBoolean values (true or false [or chaos]).• Then:false, truea, b, ..., c ∼a, a∧b, a∨b, a⇒b, a=b, a≠b• are propositional expressions having Boolean values.• ∼, ∧, ∨, ⇒, = and ≠ are Boolean connectives (i.e., operators).• They can be read as: not, and, or, if then (or implies), equal andnot equal.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.3, Subsect. 2 Support: 40. Slide: 916 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ The RSL Predicate Calculus ]Simple Predicate Expressions• Let identifiers (or propositional expressions) a, b, ..., c designate Boolean values,• let x, y, ..., z (or term expressions) designate non-Boolean values• and let i, j, ..., k designate number values,• then:false, truea, b, ..., c∼a, a∧b, a∨b, a⇒b, a=b, a≠bx=y, x≠y,ij• are simple predicate expressions.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.3, Subsect.3 Support: 40. Slide: 917 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ The RSL Predicate Calculus ]Quantified Expressions• Let X, Y, ..., C be type names or type expressions,• and let P(x), Q(y) and R(z) designate predicate expressions inwhich 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.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.4, Subsect. 1 Support: 40. Slide: 918 of 894/home/db/de/rsl/rslConcrete RSL Types: Values and OperationsArithmeticc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31typeNat, Int, Realvalue+,−,∗: Nat×Nat→Nat | Int×Int→Int | Real×Real→Real/: Nat×Nat ∼ →Nat | Int×Int ∼ →Int | Real×Real ∼ →Real (Nat|Int|Real) → (Nat|Int|Real)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.2, Subsubsect. 1 Support: 40. Slide: 919 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]Set ExpressionsSet EnumerationsLet the below a’s denote values of type A, then the below designatesimple set enumerations:{{}, {a}, {e 1 ,e 2 ,...,e n }, ...} ∈ A-set{{}, {a}, {e 1 ,e 2 ,...,e n }, ..., {e 1 ,e 2 ,...}} ∈ A-infsetPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 2, Subsubsect. 2 Support: 40. Slide: 920 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Set Expressions ]Set Comprehension• The expression, last line below, to the right of the ≡, expresses setcomprehension.• The expression “builds” the set of values satisfying the given predicate.• It is abstract in the sense that it does not do so by following a concrete algorithm.typeA, BP = A → BoolQ = A ∼ → Bvaluecomprehend: A-infset × P × Q → B-infsetcomprehend(s,P,Q) ≡ { Q(a) | a:A • a ∈ s ∧ P(a)}Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.3, Subsubsect. 1 Support: 40. Slide: 921 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]Cartesian ExpressionsCartesian Enumerations• Let e range over values of Cartesian types involving A, B, ..., C,• then the below expressions are simple Cartesian enumerations:typeA, B, ..., CA × B × ... × Cvalue(e1,e2,...,en)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 4, Subsubsect. 1 Support: 40. Slide: 922 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible• Let a range over values of type A,/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]List ExpressionsList Enumerations• 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 〉klistb@〈ei..ej〉• The last line above assumes a i and a j to be integer-valued expressions.• It then expresses the set of integers from the value of e i to and including thevalue of e j .• If the latter is smaller than the former, then the list is empty.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.4, Subsubsect. 2 Support: 40. Slide: 923 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, List Expressions ]List Comprehension• The last line below expresses list comprehension.typeA, B, P = A → Bool, Q = A ∼ → Bvaluecomprehend: A ω × P × Q ∼ → B ωcomprehend(l,P,Q) ≡〈 Q(l(i)) | i in 〈1..len l〉 • P(l(i))〉Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 5, Subsubsect. 1 Support: 40. Slide: 924 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]Map ExpressionsMap Enumerations• Let (possibly indexed) u and v range over values of type T1 andT2, respectively,• then the below expressions are simple map enumerations:typeT1, T2M = T1 → m T2valueu,u1,u2,...,un:T1, v,v1,v2,...,vn:T2[ ], [ u↦→v ], ..., [ u1↦→v1,u2↦→v2,...,un↦→vn ] ∀ ∈ MPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.5, Subsubsect. 2 Support: 40. Slide: 925 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Map Expressions ]Map Comprehension• The last line below expresses map comprehension:typeU, V, X, YM = U → m VF = U → ∼ XG = V → ∼ YP = U → Boolvaluecomprehend: M×F×G×P → (X → m Y)comprehend(m,F,G,P) ≡•[ F(u) ↦→ G(m(u)) | u:U u ∈ dom m ∧ P(u) ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 6, Subsubsect. 1 Support: 40. Slide: 926 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009value221 ∈: A × A-infset → Bool222 ∉: A × A-infset → Bool223 ∪: A-infset × A-infset → A-infset224 ∪: (A-infset)-infset → A-infset225 ∩: A-infset × A-infset → A-infset226 ∩: (A-infset)-infset → A-infset227 \: A-infset × A-infset → A-infset228 ⊂: A-infset × A-infset → Bool229 ⊆: A-infset × A-infset → Bool230 =: A-infset × A-infset → Bool231 ≠: A-infset × A-infset → Bool232 card: A-infset ∼ → Natinvisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]Set OperationsSet Operator SignaturesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.6, Subsubsect. 2 Support: 40. Slide: 927 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslexamplesa ∈ {a,b,c}a ∉ {}, a ∉ {b,c}{a,b,c} ∪ {a,b,d,e} = {a,b,c,d,e}∪{{a},{a,b},{a,d}} = {a,b,d}{a,b,c} ∩ {c,d,e} = {c}∩{{a},{a,b},{a,d}} = {a}{a,b,c} \ {c,d} = {a,b}{a,b} ⊂ {a,b,c}{a,b,c} ⊆ {a,b,c}{a,b,c} = {a,b,c}{a,b,c} ≠ {a,b}card {} = 0, card {a,b,c} = 3[ Concrete RSL Types: Values and Operations, Set Operations ]Set ExamplesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 6, Subsubsect. 3 Support: 40. Slide: 928 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Set Operations ]Informal Explication221. ∈: The membership operator expresses that an element is a member of a set.222. ∉: The nonmembership operator expresses that an element is not a member of aset.223. ∪: The infix union operator. When applied to two sets, the operator gives the setwhose members are in either or both of the two operand sets.224. ∪: The distributed prefix union operator. When applied to a set of sets, theoperator gives the set whose members are in some of the operand sets.225. ∩: The infix intersection operator. When applied to two sets, the operator givesthe set whose members are in both of the two operand sets.226. ∩: 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.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.6, Subsubsect. 3 Support: 40. Slide: 929 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Set Operations, Informal Explication ]227. \: The set complement (or set subtraction) operator. When applied to two sets,the operator gives the set whose members are those of the left operand set whichare not in the right operand set.228. ⊆: The proper subset operator expresses that all members of the left operand setare also in the right operand set.229. ⊂: The proper subset operator expresses that all members of the left operand setare also in the right operand set, and that the two sets are not identical.230. =: The equal operator expresses that the two operand sets are identical.231. ≠: The nonequal operator expresses that the two operand sets are not identical.232. card: The cardinality operator gives the number of elements in a finite set.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 6, Subsubsect. 4 Support: 40. Slide: 930 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Set Operations ]Set Operator Definitionsvalues ′ ∪ 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 ∉ s ′′ }s ′ ⊆ s ′′ ≡ ∀ a:A • a ∈ s ′ ⇒ a ∈ s ′′s ′ ⊂ s ′′ ≡ s ′ ⊆ s ′′ ∧ ∃ a:A • a ∈ s ′′ ∧ a ∉ s ′s ′ = s ′′ ≡ ∀ a:A • a ∈ s ′ ≡ a ∈ s ′′ ≡ s⊆s ′ ∧ s ′ ⊆ss ′ ≠ s ′′ ≡ s ′ ∩ s ′′ ≠ {}card s ≡if s = {} then 0 elselet a:A • a ∈ s in 1 + card (s \ {a}) end endpre s /∗ is a finite set ∗/card s ≡ chaos /∗ tests for infinity of s ∗/Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.7 Support: 40. Slide: 931 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsltypeA, B, Cg0: G0 = A × B × Cg1: G1 = ( A × B × C )g2: G2 = ( A × B ) × Cg3: G3 = A × ( B × C )valueva:A, vb:B, vc:C, vd:D(va,vb,vc):G0,[ Concrete RSL Types: Values and Operations ]Cartesian Operations(va,vb,vc):G1((va,vb),vc):G2(va3,(vb3,vc3)):G3decomposition expressionslet (a1,b1,c1) = g0,(a1 ′ ,b1 ′ ,c1 ′ ) = g1 in .. endlet ((a2,b2),c2) = g2 in .. endlet (a3,(b3,c3)) = g3 in .. endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 8, Subsubsect. 1 Support: 40. Slide: 932 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009valuehd: A ω ∼ → Atl: A ω ∼ → Aωlen: A ω ∼ → Natinds: A ω → Nat-infsetelems: A ω → A-infset.(.): A ω × Nat ∼ → Â : A ∗ × A ω → A ω=: A ω × A ω → Bool≠: A ω × A ω → Boolinvisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]List OperationsList Operator SignaturesPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.8, Subsubsect. 2 Support: 40. Slide: 933 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, List Operations ]List Operation Examplesexampleshd〈a1,a2,...,am〉=a1tl〈a1,a2,...,am〉=〈a2,...,am〉len〈a1,a2,...,am〉=minds〈a1,a2,...,am〉={1,2,...,m}elems〈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〉 ≠ 〈a,b,d〉Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 8, Subsubsect. 3 Support: 40. Slide: 934 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, List Operations ]Informal Explication• hd: Head gives the first element in a nonempty list.• tl: Tail gives the remaining list of a nonempty list when Head isremoved.• len: Length gives the number of elements in a finite list.• inds: Indices give the set of indices from 1 to the length of anonempty list. For empty lists, this set is the empty set as well.• elems: Elements gives the possibly infinite set of all distinctelements in a list.• l(i): Indexing with a natural number, i larger than 0, into a list lhaving a number of elements larger than or equal to i, gives the ithelement of the list.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.8, Subsubsect. 3 Support: 40. Slide: 935 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Concrete RSL Types: Values and Operations, List Operations, Informal Explication ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl• ̂ : Concatenates two operand lists into one. The elements of theleft operand list are followed by the elements of the right. Theorder with respect to each list is maintained.• =: The equal operator expresses that the two operand lists areidentical.• ≠: The nonequal operator expresses that the two operand lists arenot identical.The operations can also be defined as follows:Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 8, Subsubsect. 4 Support: 40. Slide: 936 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009valueis finite list: A ω → Boolinvisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, List Operations ]List Operator Definitionslen q ≡case is finite list(q) oftrue → if q = 〈〉 then 0 else 1 + len tl q end,false → chaos endinds q ≡case is finite list(q) oftrue → { i | i:Nat • 1 ≤ i ≤ len q },false → { i | i:Nat • i≠0 } endelems q ≡ { q(i) | i:Nat • i ∈ inds q }Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.8, Subsubsect. 4 Support: 40. Slide: 937 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Concrete RSL Types: Values and Operations, List Operations, List Operator Definitions ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslq(i) ≡if i=1thenif q≠〈〉then let a:A,q ′ :Q • q=〈a〉 ̂ q ′ in a endelse chaos endelse q(i−1) endfq ̂ iq ≡〈 if 1 ≤ i ≤ len fq then fq(i) else iq(i − len fq) end| i:Nat • if len iq≠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 ′ ≠ iq ′′ ≡ ∼(iq ′ = iq ′′ )Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 9, Subsubsect. 1 Support: 40. Slide: 938 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations ]Map OperationsMap Operator Signatures and Map Operation Examplesvaluem(a): M → A ∼ → B, m(a) = bdom: M → A-infset [ domain of map ]dom [ a1↦→b1,a2↦→b2,...,an↦→bn ] = {a1,a2,...,an}rng: M → B-infset [ range of map ]rng [ a1↦→b1,a2↦→b2,...,an↦→bn ] = {b1,b2,...,bn}†: M × M → M [ override extension ][ a↦→b,a ′ ↦→b ′ ,a ′′ ↦→b ′′ ] † [ a ′ ↦→b ′′ ,a ′′ ↦→b ′ ] = [ a↦→b,a ′ ↦→b ′′ ,a ′′ ↦→b ′ ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.9, Subsubsect. 1 Support: 40. Slide: 939 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31[ Concrete RSL Types: Values and Operations, Map Operations, Map Operator Signatures and Map Operation Examples ]Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl∪: M × M → M [ merge ∪ ][ a↦→b,a ′ ↦→b ′ ,a ′′ ↦→b ′′ ] ∪ [ a ′′′ ↦→b ′′′ ] = [ a↦→b,a ′ ↦→b ′ ,a ′′ ↦→b ′′ ,a ′′′ ↦→b ′′′ ]\: M × A-infset → M [ restriction by ][ a↦→b,a ′ ↦→b ′ ,a ′′ ↦→b ′′ ]\{a} = [ a ′ ↦→b ′ ,a ′′ ↦→b ′′ ]/: M × A-infset → M [ restriction to ][ a↦→b,a ′ ↦→b ′ ,a ′′ ↦→b ′′ ]/{a ′ ,a ′′ } = [ a ′ ↦→b ′ ,a ′′ ↦→b ′′ ]=,≠: M × M → Bool◦ : (A → m B) × (B → m C) → (A → m C) [ composition ][ a↦→b,a ′ ↦→b ′ ] ◦ [ b↦→c,b ′ ↦→c ′ ,b ′′ ↦→c ′′ ] = [ a↦→c,a ′ ↦→c ′ ]Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 9, Subsubsect. 2 Support: 40. Slide: 940 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Map Operations ]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 toin a map.• rng: Range/Image Set gives the set of values which are mapped toin a map.• †: Override/Extend. When applied to two operand maps, it givesthe map which is like an override of the left operand map by all orsome “pairings” of the right operand map.• ∪: Merge. When applied to two operand maps, it gives a merge ofthese maps.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect.9, Subsubsect. 2 Support: 40. Slide: 941 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Map Operations, Map Operation Explication ]• \: Restriction. When applied to two operand maps, it gives the map which is arestriction of the left operand map to the elements that are not in the rightoperand set.• /: Restriction. When applied to two operand maps, it gives the map which is arestriction of the left operand map to the elements of the right operand set.• =: The equal operator expresses that the two operand maps are identical.• ≠: The nonequal operator expresses that the two operand maps are not identical.• ◦ : Composition. When applied to two operand maps, it gives the map fromdefinition set elements of the left operand map, m 1 , to the range elements of theright operand map, m 2 , such that if a is in the definition set of m 1 and maps intob, and if b is in the definition set of m 2 and maps into c, then a, in thecomposition, maps into c.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.4, Subsect. 9, Subsubsect. 3 Support: 40. Slide: 942 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009valuerng m ≡ { m(a) | a:A • a ∈ dom m }invisible/home/db/de/rsl/rsl[ Concrete RSL Types: Values and Operations, Map Operations ]Map Operation Redefinitionsm1 † m2 ≡[ a↦→b | a:A,b:B •a ∈ dom m1 \ dom m2 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]m1 ∪ m2 ≡ [ a↦→b | a:A,b:B •a ∈ dom m1 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]m \ s ≡ [ a↦→m(a) | a:A • a ∈ dom m \ s ]m / s ≡ [ a↦→m(a) | a:A • a ∈ dom m ∩ s ]m1 = m2 ≡dom m1 = dom m2 ∧ ∀ a:A • a ∈ dom m1 ⇒ m1(a) = m2(a)m1 ≠ m2 ≡ ∼(m1 = m2)m ◦ n ≡[ a↦→c | a:A,c:C • a ∈ dom m ∧ c = n(m(a)) ]pre rng m ⊆ dom nPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.5, Subsect.1 Support: 40. Slide: 943 of 894type /∗ 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), .../home/db/de/rsl/rslλ-Calculus + FunctionsThe λ-Calculus Syntaxc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect. 2 Support: 40. Slide: 944 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ λ-Calculus + Functions ]Free and Bound VariablesLet 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 ≠ 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).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect.3 Support: 40. Slide: 945 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ λ-Calculus + Functions ]Substitution• subst([N/x]x) ≡ N;• subst([N/x]a) ≡ a,for all variables a≠ 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 x≠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 y≠x and y is free in N and x is free in P(where z is not free in (N P)).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect. 4 Support: 40. Slide: 946 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ λ-Calculus + Functions ]α-Renaming and β-Reduction• α-renaming: λx•MIf x, y are distinct variables then replacing x by y in λx•M results inλy•subst([y/x]M). We can rename the formal parameter of aλ-function expression provided that no free variables of its body Mthereby become bound.• β-reduction: (λx•M)(N)All free occurrences of x in M are replaced by the expression Nprovided that no free variables of N thereby become bound in theresult. (λx•M)(N) ≡ subst([N/x]M)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect.5 Support: 40. Slide: 947 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ λ-Calculus + Functions ]Function SignaturesFor sorts we may want to postulate some functions:typeA, B, Cvalueobs B: A → B,obs C: A → C,gen A: B×C → APhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect. 6 Support: 40. Slide: 948 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ λ-Calculus + Functions ]Function DefinitionsFunctions can be defined explicitly:valuef: Arguments → Resultf(args) ≡ DValueExprg: Arguments ∼ → Resultg(args) ≡ ValueAndStateChangeClausepre P(args)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.5, Subsect.6 Support: 40. Slide: 949 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009[ λ-Calculus + Functions, Function Definitions ]Or functions can be defined implicitly:invisible/home/db/de/rsl/rslvaluef: Arguments → Resultf(args) as resultpost P1(args,result)g: Arguments ∼ → Resultg(args) as resultpre P2(args)post P3(args,result)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.6, Subsect. 1 Support: 40. Slide: 950 of 894Other Applicative ExpressionsSimple let ExpressionsSimple (i.e., nonrecursive) let expressions:/home/db/de/rsl/rsllet a = E d in E b (a) endis an “expanded” form of:(λa.E b (a))(E d )c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.6, Subsect.2 Support: 40. Slide: 951 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Other Applicative Expressions ]Recursive let ExpressionsRecursive let expressions are written as:let f = λa:A•is “the same” as:E(f) in B(f,a) endlet f = YF in B(f,a) endwhere:F ≡ λg•λa•(E(g)) and YF = F(YF)Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.6, Subsect. 3 Support: 40. Slide: 952 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Other Applicative Expressions ]Predicative let ExpressionsPredicative let expressions:let a:A•P(a) in B(a) endexpress the selection of a value a of type A which satisfies a predicateP(a) for evaluation in the body B(a).Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.6, Subsect.4 Support: 40. Slide: 953 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Other Applicative Expressions ]Pattern and “Wild Card” let ExpressionsPatterns and wild cards can be used:let {a} ∪ s = set in ... endlet {a, } ∪ s = set in ... endlet (a,b,...,c) = cart in ... endlet (a, ,...,c) = cart in ... endlet 〈a〉 ̂ l = list in ... endlet 〈a, ,b〉 ̂ l = list in ... endlet [ a↦→b ] ∪ m = map in ... endlet [ a↦→b, ] ∪ m = map in ... endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.6, Subsect. 5 Support: 40. Slide: 954 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rslif b expr then c expr else a exprendif b expr then c expr end ≡ /∗ same as: ∗/if b expr then c expr else skip endif 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 endcase expr ofchoice pattern 1 → expr 1,choice pattern 2 → expr 2,...choice pattern n or wild card → expr nend[ Other Applicative Expressions ]ConditionalsPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.6, Subsect.6 Support: 40. Slide: 955 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Other Applicative Expressions ]Operator/Operand Expressions〈Expr〉 ::=〈Prefix Op〉 〈Expr〉| 〈Expr〉 〈Infix Op〉 〈Expr〉| 〈Expr〉 〈Suffix Op〉| ...〈Prefix Op〉 ::=− | ∼ | ∪ | ∩ | card | len | inds | elems | hd | tl | dom | rng〈Infix Op〉 ::== | ≠ | ≡ | + | − | ∗ | ↑ | / | < | ≤ | ≥ | > | ∧ | ∨ | ⇒| ∈ | ∉ | ∪ | ∩ | \ | ⊂ | ⊆ | ⊇ | ⊃ | ̂ | † | ◦〈Suffix Op〉 ::= !Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.7, Subsect. 1 Support: 40. Slide: 956 of 894Unitvaluestmt: Unit → Unitstmt()/home/db/de/rsl/rslImperative ConstructsStatements and State Changes• Statements accept no arguments.c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31• 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 anargument of type Unit.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.7, Subsect.4 Support: 40. Slide: 957 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Imperative Constructs ]Variables and Assignment0. variable v:Type := expression1. v := exprStatement Sequences and skip2. skipdcomb@skip3. stm 1;stm 2;...;stm ndcomb@stm 1 ;stm 2 ;...;stm n ;Imperative Conditionals4. if expr then stm c else stm a end5. case e of: p 1→S 1(p 1),...,p n→S n(p n) endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.7, Subsect. 6 Support: 40. Slide: 958 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl6. while expr do stm end7. do stmt until expr end8. for e in list expr•[ Imperative Constructs ]Iterative ConditionalsIterative SequencingP(b) do S(b) endPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

Dines Bjorner: 1st DRAFT: January 2, 2009DOMAIN ENGINEERINGinvisible2009 LecturesAppendix O, Sect.8, Subsect.1 Support: 40. Slide: 959 of 894/home/db/de/rsl/rslc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Process ConstructsProcess ChannelsLet A and B stand for two types of (channel) messages and i:KIdx forchannel array indexes, then:channel c:Achannel { k[ i ]:B•i:KIdx }Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.8, Subsect. 2 Support: 40. Slide: 960 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Process Constructs ]Process Composition• Let P and Q stand for names of process functions,• i.e., of functions which express willingness to engage in inputand/or output events,• thereby communicating over declared channels.• Let P() and Q stand for process expressions, then:P ‖ QP ⌈⌉ ⌊⌋ QP ⌈⌉ QP –‖ QParallel compositionNondeterministic external choice (either/or)Nondeterministic internal choice (either/or)Interlock parallel compositionPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.8, Subsect.3 Support: 40. Slide: 961 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Process Constructs ]Input/Output EventsLet 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.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.8, Subsect. 4 Support: 40. Slide: 962 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsl[ Process Constructs ]Process DefinitionsThe below signatures are just examples. They emphasise that processfunctions must somehow express, in their signature, via whichchannels they wish to engage in input and output events.valueP: Unit → in c out k[ i ]UnitQ: i:KIdx → out c in k[ i ] UnitP() ≡ ... c ? ... k[ i ] ! e ...Q(i) ≡ ... k[ i ] ? ... c ! e ...The process function definitions (i.e., their bodies) express possibleevents.Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.9 Support: 40. Slide: 963 of 894Simple RSL Specificationsc○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisible/home/db/de/rsl/rsltype...variable...channel...value...axiom...Phone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db

DOMAIN ENGINEERING2009 LecturesAppendix O, Sect.9 Support: 40. Slide: 964 of 894c○ Dines Bjørner, 2009Fredsvej 11DK-2840 HolteDenmark January 2, 2009, 17:31Dines Bjorner: 1st DRAFT: January 2, 2009invisibleEnd of Support: An RSL PrimerPhone: +45 4542 2141, E-mail: bjorner@gmail.com, URL: www.imm.dtu.dk/˜db