Domain Modelling: A Foundation for Software Development

Abstract

Domain modelling, as per the approach of this paper, offers the possibility of describing software application domains in a precise and comprehensive manner – well before requirements capture can take place. We endow domain modelling with appropriate analysis and description calculi and a systematic method for constructing domain models. The present paper is a latest exposé of the domain science & engineering as published in earlier papers and a book. It reports on our most recent simplifications to the domain analysis & description approach.

In order to specify software, we must understand its requirements. In order to prescribe requirements, we must understand the domain. So we must study, analyse and describe domains.

The Triptych Dogma

1 Introduction

This paper introduces the possibility of a new phase of software development, one that precedes requirements engineering, as well as a new way of looking at the world around us!

Today’s well-managed software development projects usually start with some form of requirements “capture”. Now the possibility arises to precede this phase of requirements engineering with an initial phase of domain engineering.

The present paper is an improvement over previously published accounts [13, 16, 17]: builds upon a simpler domain ontology (Fig. 1 on page 4); has fewer domain concepts (Sects. 3 and 5); and presents a more rational way of “deriving” behaviours from parts (Sect. 6). Taken together the presentation is thus made shorter and more precise.

The approach to the modelling of domains put forward in this paper has two major phases: modelling external qualities of the world as we see it, as it manifests itself to us, or otherwise, and modelling the internal qualities, as we may not see it, but qualities that can be measured and/or spoken about. The modelling of external qualities has a few steps. The major step of modelling of external qualities is that of deciding upon the atomic-, Cartesian- and set-oriented parts. A minor step, following the major step, is that of identifying a notion of endurant state. The modelling of internal qualities has a few more steps. The modelling of unique identifiers; the modelling of mereologies; the modelling of attributes; and the modelling of ‘intentional pull’. It is this structuring into manageable stages and steps that reassures us, i.e., me, that the approach is sound.

1.1 What is a Domain ?

By a domain we shall understand a rationally describable segment of a discrete dynamics fragment of a human assisted reality, i.e., of the world: its endurants, i.e., solid and fluid entities: whether natural [“God-given”] or artefactual [“man-made”], their parts and living species entities: whether atomic or compound parts, respectively whether plant or animal living species, including humans—as well as its perdurants: the behaviours of parts and living species.

Clearly this characterisation does not possess the rigour that should be common in software development. Terms such as rationally describable, discrete dynamics and human assisted reality must be not just assumed, but must, below, be made more precise. Yet precision defies us: The domains we shall study, analyse and describe are not amenable to such precision. The world is not formal.

Thus the domain analysis & description methodology that we shall be concerned with is not directed at continuous dynamics systems such as we find them in for example aerospace applications. And we shall not, in this paper be concerned with the human assistance aspects. By domain modelling we mean the study, analysis and description of a domain.

If the domain already exists, then the modelling amounts to a faithful rendering of that domain but such that the resulting model, i.e., description, covers as wide a spectrum of domain instances as is deemed reasonable.¹

We shall, in this paper, assume already existing domains. By domain engineering we mean the construction of domain models.²

1.2 Non-computable and Computable Specifications

When specifying³ software we usually make use of a formal language – one whose semantics can be expressed mathematically. And the specification had better be logically tractable. Similarly for prescribing requirements: again a formal language can be deployed. And the requirement had better be computable. Typically, when we derive a software specification, $\mathcal {S}$, from a requirements prescription, $\mathcal {R}$, the testing, model checking and proof of some form of correctness, $\mathcal {D},\mathcal {S}\models \mathcal {R}$, of the software design relies on not only on relations between the two documents: the $\mathcal {R}$ and $\mathcal {S}$, but also on the domain description, $\mathcal {D}$. But in describing domains we cannot assume computability. It is the task of requirements engineering to “derive” computable requirements from domain models. [17, Chapter 9] shows how. We refer to Sect. 8.2.3 on page 38 for summary comments.

1.3 Formal Method and Methodology

By a method we shall understand a set of principles for selecting and applying a number of procedures, techniques and tools for [effectively] constructing an artefact. By methodology we shall understand the study and knowledge of one or more methods. By a formal method we shall understand a method which uses one or more formal specification languages as per their intention: specification and verification (formal tests, model checks and proofs of properties of domains descriptions,requirement prescriptions and software designs). By a formal specification language we shall understand a language with a formal syntax, a formal semantics and a proof system with which to describe & validate⁴ domains, prescribe & validate requirements and specify (design) & validate software.

Our domain analysis & description method has been developed, over the years, with this understanding of formal methods.

1.4 From Programming Languages to Domains

Domain stakeholders, those whose primary work is in and of the domain, name the entities of the domain and use these names, nouns and verbs, in communicating with other stakeholders. These utterings constitute a language, albeit an informal one. In a domain model we give abstract syntax to (roughly speaking) the nouns, Sects. 3 and 5, and semantics to (roughly speaking) the verbs, Sect. 6.

When, in comparison, we define the syntax and semantics of a programming language, that syntax and semantics covers all well-formed instances of programs in that language. Similarly, when, in consequence, we define the abstract syntax and semantics, i.e., a model, of a domain, that syntax and semantics covers all well-formed instances—we mean it, the model, to cover all well-formed instances of domains.

1.5 A Review

We present a latest exposé of the domain science & engineering of [13, 16, 17, 2015–2021]. The first inklings of this applied science were first reported in [3, 1995–1997], Volume III, Part IV, Chaps. 8–12, Pages 193–362 of [4, 2006] cover several aspects of domain engineering – but not what we now consider the most important contribution to the field: namely that of the First developments of the proposed analysis and description calculi were reported in [9, 10, Kyiv 2010]. The recently published papers and book [13, 16, 17, 2015–2021] illustrates the fact that the details of the calculi may change. The present paper reports on our most recent simplification to the domain analysis & description approach and the few extensions, RSL$^+$, to the RSL specification language [32]. The domain modelling approach presented here has been honed over the last 30 years in numerous experiments. Some of these are reported in [15, 18, 19, 22].

1.6 An Overview

1.6.1 A Domain Analysis and Description Ontology

Sections 3, 4, 5 and 6 represent the contribution of this paper. Figure 1 illustrates basic ideas of how we shall structure our domain analysis & description.

Fig. 1.

An Analysis & Description Methodology Ontology

The domain analyser cum describer, i.e., the domain modeller, is confronted by a domain. How and where to start! Figure 1 is intended to be read top-down, left-to-right. So it suggests that the domain modeller, starts by looking “at the whole domain!”. That is, at the $\bullet$ right under the term Universes, between the r and the s!

1.6.2 Step-Wise Analysis and Description

Figure 1 then suggests, by the two lines emerging from that $\bullet$, that the domain modeller poses the question, of the domain, is it (more or less) rationally describable, i.e., is_entity($\phi$), or not. If the domain modeller decides yes, it is so, then the analysis “moves” on to the Entity $\bullet$. Now the question is, is the entity being observed, an endurant or a perdurant, (to be explained below), and so on. We now assume that the analysis proceeds along the left hand side dashed line ($\cdots$- - -$\cdots$) box labeled ‘Endurants’.

The so-called external quality analysis of endurants ends when reaching either of the Atomic, Cartesian or Part Set $\bullet$s.⁵ At this point the description proceeds to that of the internal qualities of endurants. From Fig. 1 You observe seven vertical [dashed] lines, emanating downwards from endurant bullets to cross three horizontal (bottom of the figure) lines. They “call” for the domain modeller to now analyse and describe the internal qualities of endurants: their unique identification, their mereologies, and their attributes.

Eventually the domain modeller has “traversed” the left hand side of Fig. 1. At this point a transcendental deduction takes place: The domain modeller now “morphs” manifest endurant parts into behaviours. The focal point here are the part behaviour signatures and definitions. Figure 1’s right hand side hints at the issues to be covered and that the internal qualities are being a crucial element of behaviour definitions.

1.6.3 The Analysis and Description Prompts

Each $\bullet$ of Fig. 1 thus corresponds to an analysis or description prompt. There are two kinds of analysis prompts. Both are informal. The predicate analysis prompts and the function analysis prompts. There is two major kinds of description prompts. ($\alpha$) external quality description prompts – with there being two such specific prompts: one for describing so-called Cartesian endurants (Sect.  on page 12), another for describing so-called Part Set endurants (Sect. 3.3.2 on page 12), and ($\beta$) internal quality description prompts with there being three such specific prompts: the unique identifier description prompt (Sect. 5.1.1 on page 16), the mereology description prompt (Sect. 5.2.1 on page 17), and the attribute description prompt (Sect. 5.3.2 on page 18). The predicate analysis prompts yield truth values. The function analysis prompts yield part endurants and the names of their type – which we shall call sorts. And the description prompts yield domain description texts – here in a slight extended version of the RAISE⁶ [33] specification language RSL [32].⁷$^{,}$⁸

1.7 RSL, RSL-text and RSL$^{+}$

RSL is described in [32]. We use a subset of that RSL. Thus we shall not avail ourselves of the RSL module concepts of object, class and scheme. Basically, then, a specification expressed in RSL amounts to sequences of [alternating] type, value and axiom clauses – with, optionally, a single channel clause:

RSL-text is an addition to RSL. In describing domains in RSL we shall be introducing description prompts which are informal functions which yield values of type RSL-text, that is, proper RSL texts. Quoting an RSL text: “text". shall denote an RSL-text.

RSL$^{+}$ designate RSL-text plus, in this paper, one extension. That extension is that of the type and values of type names. If T denotes a type, i.e., a possibly infinite set of values, then $\eta$T denotes a value, the name of type T, with $\phi \mathbb {T}$ denoting the type of type names.

The domain analysis & description method is informally explained in a mixture of English and RSL$^{+}$. [12, 2014] attempts a formalisation of an early version of RSL$^{+}$.

1.8 A Computer Science Philosophy

We shall base our domain analysis & description approach on the philosophy of Kai Sørlander [53,54,55,56,57]. The issue here is: In studying, analysing & describing domains one is confronted with the basic [metaphysical] question[s]: which are the absolutely necessary conditions for describing any world ?, that is: what, if anything, is of such necessity, that it could under no circumstances be otherwise ?, or: which are the necessary characteristics of any possible world ? In his work Sørlander rationally argues that space, time, Newton’s laws, and a number of additional concepts are necessarily basic elements of any description of any domain.

1.9 Previous Work

We refer to Sect. 1.5 on page 3.

Axel van Lamsweerde [48, 2009] and Michael A. Jackson [43, 44, 1995–2010], as well as other requirements engineering researchers, do touch upon the issues of domains – such as that term is basically used here. But their requirements analysis and prescription do not “put it center stage”, let alone mandate that the[ir] requirements engineer rely on an a priori established domain description. So they and others do not establish, as is the main focus of this contribution, calculi for the analysis & description of domains.

1.10 Structure of Paper

There are basically two parts to this paper. The main part consists of Sects. 2–3 and Sects. 5–6. They present a terse, comprehensive exposé of the domain analysis & description method of this paper. An appendix, the other part, Appendix 7, brings an example. For the domain modelling approach to be believable the example must open up for a realistic domain, one that is not “small”.

$\bullet \bullet \bullet$

We now explain the domain description ontology as a structured set of concepts for modelling domains, a set that shows their properties and the relations between them. In simple terms, ontology seeks the classification and explanation of entities.⁹

Figure 1 on page 4 is a graphical rendition of a structured set of concepts for modelling domains.

2 Universe of Discourse

Domain descriptions start with a terse sketch of the main facets of the domain followed by the naming of the domain.

1  Example. Universe of Discourse: We refer to Sect.  on page 25.

3 External and Internal Qualities

Characterisation 1: External qualities: External qualities of endurants¹⁰ of a domain are, in a simplifying sense, those properties of endurants that we can see, touch and which have spatial extent. They, so to speak, take form.

Characterisation 2: Internal qualities: Internal qualities of endurants of a domain are those which we may not be able to see or “feel” when touching an endurant, but they can, as we now ‘mandate’ them, be reasoned about. They have unique identifiers and mereologies,¹¹ And they have attributes that can be measured by some physical/chemical means, or be “spoken of” by intentional deduction.

3.1 Predicate Analysis of External Qualities of Endurants

Characterisation 3: Phenomenon: By a phenomenon we shall understand a fact that is observed to exist or happen Examples of phenomena are: emotions of a human, the rivers, lakes, forests, mountains and valleys of mother nature; the railway tracks, their units, the locomotive of a railway system.

Domain Analysis Predicates: We shall define a number of domain analysis predicates. They are all referred to as prompts. Prompts are method tools. The domain modeller applies these to “real”, i.e., actual world phenomena, that is, not to formal values. In the next 18 paragraphs we shall “reveal” a number of such predicates. First with a reasonable definition (in slanted font), then with examples and some comments (in roman font).

Predicate Prompt 1: is_entity: By an entity we shall understand something that can be observed, i.e., be seen or touched by humans, or that can be conceived as an abstraction of an entity; alternatively, a tangible or conceivable phenomenon is an entity [49, Vol. I, pg. 665] Some, but not necessarily all aspects of a river can be rationally described, hence can be still be considered entities. Similarly, many aspects of a road net can be rationally described, hence will be considered entities.

Predicate Prompt 2: is_endurant: Endurants are those quantities of domains that we can observe (see and touch), in space, as “complete” entities at no matter which point in time –“material” entities that persists, endures [49, Vol. I, pg. 656] Street segments [links], street intersections [hubs], automobiles standing still in an automobile show room are endurants. Domain endurants, when eventually modelled in software, typically become data. Hence the careful analysis of domain endurants is a prerequisite for subsequent careful conception and analyses of data structures for software, including data bases.

Predicate Prompt 3: is_perdurant: By a perdurant we shall understand an entity for which only a fragment exists if we look at or touch at any given snapshot in time. Were we to freeze time we would only see or touch a fragment of the perdurant [49, Vol. II, pg. 1552] Automobiles in action, container vessels sailing on the 7 seas and loading and unloading containers in harbours are examples of perdurants. Domain perdurants, when eventually modelled in software, typically become processes.

Endurants are either solid endurants, or are fluid endurants.

Predicate Prompt 4: is_solid: By a solid endurant we shall understand an endurant which is separate, individual or distinct in form or concept, or, rephrasing: a body or magnitude of three-dimensions, having length, breadth and thickness [49, Vol. II, pg. 2046] Wells, pipes, valves, pumps, forks, joins, regulator, and sinks of a pipeline are solids.

Predicate Prompt 5: is_fluid: By a fluid endurant we shall understand an endurant which is prolonged, without interruption, in an unbroken series or pattern; or, rephrasing: a substance (liquid, gas or plasma) having the property of flowing, consisting of particles that move among themselves [49, Vol. I, pg. 774] Fluids are otherwise liquid, or gaseous, or plasmatic, or granular¹², or plant products¹³, et cetera. Specific examples of fluids are: water, oil, gas, compressed air, etc. A container, which we consider a solid endurant, may be conjoined with another, a fluid, like a gas pipeline unit may “contain” gas.

We analyse endurants into either of two kinds: parts and living species. The distinction between parts and living species is motivated in Kai Sørlander’s Philosophy [53,54,55,56,57].

Predicate Prompt 6: is_part: By a part we shall understand a solid endurant existing in time and space and subject to laws of physics, including the causality principle and gravitational pull¹⁴

Natural and man-made parts are either atomicor compound.

Predicate Prompt 7: is_atomic: By an atomic part we shall understand a part which the domain analyser considers to be indivisible in the sense of not meaningfully, for the purposes of the domain under consideration, that is, to not meaningfully consist of sub-parts The wells, pumps, valves, pipes, forks, joins and sinks of a pipeline can be considered atomic.

Predicate Prompt 8: is_compound: Compound parts are those which are either Cartesian-product- or are set- oriented parts

Predicate Prompt 9: is_Cartesian: Cartesian parts are those (compound parts) which consists of an “indefinite number” of two or more parts of distinctly named sorts   Some clarification may be needed. (i) In mathematics, as in RSL [32], a value is a Cartesian (“record”) value if it can be expressed, for example as (a, b, ..., c), where a, b, ..., c are mathematical (or, which is the same, RSL) values. Let the sort names of these be A, B, ..., C – with these being required to be distinct. We wrote “indefinite number”: the meaning being that the number is fixed, finite, but not specific. (ii) The requirement: ‘distinctly named’ is pragmatic. If the domain modeller thinks that two or more of the components of a Cartesian part [really] are of the same sort, then that person is most likely confused and must come up with suitably distinct sort names for these “same sort” parts! (iii) Why did we not write “definite number” ? Well, at the time of first analysing a Cartesian part, the domain modeller may not have thought of all the consequences, i.e., analysed, the compound part. Additional sub-parts, of the Cartesian compound, may be “discovered”, subsequently and can then, with the approach we are taking wrt. the modelling of these, be “freely” added subsequently! We refer to the road transport system example above. We there viewed (hubs, links and) automobiles as atomic parts. From another point of view we shall here understand automobiles as Cartesian parts: the engine train, the chassis, the car body, four doors (left front, left rear, right front, right rear), and the wheels. These may again be considered Cartesian parts.

Predicate Prompt 10: is_part_set: Part sets are those which, in a given context, are deemed to meaningfully consist of an indefinite number of sub-parts of the same sort  Examples of set parts are: the set of hubs of a road net hub aggregate, the set of links of a road net link aggregate, and the set of automobiles of an automobile aggregate – all of the road net transport that we are exemplifying.

Predicate Prompt 11: is_living_species: By a living species we shall understand a solid endurant, subject to laws of physics, and additionally subject to causality of purpose. Living species must have some form they can develop to reach; a form they must be causally determined to maintain. This development and maintenancemust further engage in exchanges of matter with an environment   It must be possible that living species occur in two forms: plants, respectively animals. Although we have not yet come across domains for which the need to model the living species of plants were needed. Hence:

Predicate Prompt 12: is_plant: Plants are living species which are characterised by development, form and exchange of matters with an environment

Predicate Prompt 13: is_animal: Animals are living species which are additionally characterised by the ability of purposeful movement

Predicate Prompt 14: is_human: A human (a person) is an animal, with the additional properties of having language, being conscious of having knowledge(of its own situation), and responsibility

Characterisation 4: Manifest Part: By a manifest part we shall understand a part which ‘manifests’ itself either in a physical, visible manner, “occupying” an $\mathbb {AREA}$ or a $\mathbb {VOLUME}$ and a $\mathbb {POSITION}$ in $\mathbb {SPACE}$, or in a conceptual manner forms an organisation in Your mind! As we have already revealed, endurant parts can be transcendentally deduced into perdurant behaviours – with manifest parts indeed being so.

Predicate Prompt 15: is_manifest: is_manifest(e) holds if e is manifest  

Characterisation 5: Structure: By a structure we shall understand an endurant concept that allows the domain modeller to rationally decompose a domain analysis and/or its description into manageable, logically relevant sections, but where these abstract endurants are not further reflected upon in the domain analysis and description   Structures are therefore not transcendentally deduced into perdurant behaviours.

Predicate Prompt 16: is_structure: is_structure(e) holds if e is a structure  

Examples of structures arise as the result of our analysis of parts. Thus a road net could be modelled as the composite of two structures: a set of hubs and a set of links (the stretches between two adjacent hubs, i.e., road intersections), cf. Items 6–7 on page 25.

Predicate Prompt 17: is_stationary: An endurant part is stationary if it never changes position in space

Predicate Prompt 18: is_mobile: An endurant part is mobile if it may possibly change position in space

We may need, occasionally, the distinction as now outlined:

Endurants are either natural endurants, or are artefactual endurants.

Predicate Prompt 19: is_natural: By a natural endurant we shall understand one which has been created by nature.

Predicate Prompt 20: is_artefactual: By an artefactual endurant we shall understand one which has been created by humans.

Discrete Dynamic and Artefactual Domains: In our initial characterisation of domains, Page 2, an emphasis was put on their discrete dynamics and human assistedness. The analysis and description calculi and, hence, our domain modelling, are therefore “geared” in that direction.

We are not offering to model time continuous domains. See Sect. 8.2.9 on page 39.

We summarise¹⁵:

2 Example. Analysis Predicates: In the example of Appendix 7–on page 25–37 we do not [explicitly] show the “application” of analysis predicates. They are tacitly assumed.

3.2 Functional Analysis of External Qualities of Endurants

Given a compound endurant, that is, either a Cartesian or a part set, we analyse that compound, at the two $\bullet$’s of Fig. 1 on page 4, into its constituent endurants, respectively parts, and the name of the sort:

The above calculation function signatures and characterisations illustrate two extensions to RSL [32]: $\eta$P expresses the name of a sort P, and $\eta$ $\varPhi$ expresses the type of sort names.

Again we emphasize that these calculations are performed by the domain modeller. They are used in subsequent schemas for describing external qualities of endurants.

3.3 Descriptions of External Qualities of Endurants

Similarly, again at the two ’s of Fig. 1 on page 4, we are now ready to describe respectively Cartesian parts and part set parts.

3.3.1 Describing Cartesian Parts

 

3  Example. Cartesians: We refer to Sect.  on page 25.

3.3.2 Describing Part Sets

 

4  Example. Part Sets: We refer to Sect.  on page 25.

3.4 Endurant States

Characterisation 6: Endurant State: By an endurant state we shall understand

any collection of endurant parts  

5  Example. Endurant State Examples: We refer to Sect.  on page 26.

3.5 An Explication, I

The concept of analysis predicates and part observer functions is due to McCarthy [51, Sect. 12–13].

In [51] McCarthy introduces a notion of abstract syntax, Sect. 12, and semantics, Sect. 13. So far we have dealt, in our domain analysis, with syntax. There are three elements, according to McCarthy, to consider: the is_... predicates, the obs_... [“destructor”] functions, and, not shown, so far, in this paper, the mk_... constructor functions.

For compound abstract syntactic entities they are related as follows:

The mk_... constructors were not introduced above. The reason is simple; a pragmatic decision: As the domain modeller proceeds in their work they may, when encountering Cartesian compounds, be free to leave some components (of the Cartesian) out, components that they may later introduce. So really, the first of the identities above ought be expressed as

We continue this explication in Sect. 5.5 on page 20.

4 Space and Time

The concepts of space and time can be transcendentally deduced, by rational reasoning, as has been shown in [53, 54, 55, 56, 57, Kai Sørlander], from the facts of symmetry, asymmetry, transitivity and intransitivity relations.

They are therefore facts of every possible universe.

4.1 Space

There is one given space. As a type we name it $\mathbb {SPACE}$. We do not bother, here, about textual representation of spatial locations, but here is an example that would work in or near this globe we call our earth: Latitude 55.805600, Longitude 12.448160, Altitude 35 m¹⁶.

Also, in this paper, we do not present models of $\mathbb {SPACE}$. But we do introduce such notions as (i) $\mathbb {POINT}$: as $\mathbb {SPACE}$ being some dense and infinite collection of points; (ii) $\mathbb {LOCATION}$: as the location in space of some point;

(iii) $\mathbb {CURVE}$: as an infinite collection of points forming a mathematical curve – having a (finite or infinite) length; (iv) $\mathbb {SURFACE}$: as an infinite collection of points forming a mathematical surface – having a (finite or infinite) area; and (v) $\mathbb {VOLUME}$: as an infinite collection of points forming a mathematical volume – having a (finite or infinite) volume. We suggest it, as a domain science & engineering research topic, that somebody studies a calculus or calculi of spatial modelling.

4.2 Time

There is one given time. As a type we name it $\mathbb {TIME}$. We do not bother, here, about textual representation of time, but here is an example: July 10, 2023: 15:19¹⁷. But we do introduce such crucial notions as time interval $\mathbb{T}\mathbb{I}$ and operations on $\mathbb {TIME}$ and $\mathbb{T}\mathbb{I}$:

A crucial time-related operation is that of record_$\mathbb {TIME}$. It applies to “nothing”: record_$\mathbb {TIME}$ () and yields $\mathbb {TIME}$.

5 Internal Qualities

We refer to the Internal Qualities characterisation on Page 8. We can justify the grouping of internal endurant qualities into three kinds: unique identifiers, cf. Sect. 5.1, mereologies, cf. Sect. 5.2, and attributes, cf. Sect. 5.3. To this we add the concept of intentional pull, cf. Sect. 5.4.

5.1 Unique Identification

On the basis of philosophical reasoning, within metaphysics, we [can] argue that parts are uniquely identifiable [53, 54, 55, 56, 57, Kai Sørlander]

5.1.1 Calculate Unique Identifiers

6  Example. Unique Identifiers: We refer to Sect.  on page 26.

5.1.2 Endurant Identifier States

Given the endurant state values, for the whole domain or for respective, manifest part sorts, one can define corresponding unique identifier values.

7  Example. Unique Identifier State: We refer to Sect.  on page 27.

5.1.3 Axioms

The number of manifest parts is the sames as the number of manifest part unique identifiers.

8  Example. Unique Identifier Axiom: We refer to Sect.  on page 27.

5.1.4 Endurant Retrieval

Given a unique identifier, $\pi$, of a manifest part, p, of an endurant state, $\sigma$, of a domain one can retrieve that part:

5.2 Mereology

Mereology is the study and knowledge of parts and part relations. It was first put forward, around 1916, by the Polish logician Stanisław Leśniewski [26, 50].

Which are the relations that can be relevant to being an endurant ? There are basically two relations: (i) physical ones, and (ii) conceptual ones. (i) Physically two or more endurants may be topologically either adjacent to one another, like rails of a line, or within an endurant, like links and hubs of a road net, or an atomic part is conjoined to one or more fluids, or a fluid is conjoined to one or more parts. The latter two could also be considered conceptual “adjacencies”. (ii) Conceptually some parts, like automobiles, “belong” to an embedding endurant, like to an automobile club, or are registered in the local department of vehicles, or are ‘intended’ to drive on roads.

5.2.1 Calculate Mereologies

 

$\mathcal {M}$ (p) is usually a type expression over unique identifiers of mereology-related parts.

9  Example. Mereology: We refer to Sect.  on page 27.

Given the definition of external qualities of a domain, and its unique identifier and mereology internal qualities one can analyse and describe many properties of that domain. The routes subsection (Page 28) of the mereology example, Example 9, illustrates one such property.

5.3 Attributes

Parts and fluids are typically recognised because of their spatial form and are otherwise characterised by their intangible, but measurable attributes. That is, whereas endurants, whether solid (as are parts) or fluids, are physical, tangible, in the sense of being spatial [or being abstractions, i.e., concepts, of spatial endurants], attributes are intangible: cannot normally be touched, or seen, but can be objectively measured. Thus, in our quest for describing domains where humans play an active rôle, we rule out subjective “attributes”: feelings, sentiments, moods. Thus we shall abstain, in our domain science also from matters of psychology and aesthetics.

5.3.1 Functional Analysis of Attributes

Given a manifest part, p, that is, either an atom, or a Cartesian, or a part set, we calculate from that part, its constituent attributes values and types:

5.3.2 Describe Attributes

 

The domain modeller has thus determined/decided that A1, A2, ..., Aa are the “interesting” attributes of of parts of sort P. Attributes are often given a “concrete” form, hence the [ = ... ] where the ... is some type expression.

10  Example. Attributes: We refer to Sect.  on page 29.

5.3.3 Attribute Categories

Michael A. Jackson has proposed a structure of attributes [43].

Attribute Category 1: Static: By a static attribute we shall understand an attribute whose values are constants, i.e., cannot change.

Attribute Category 2: Dynamic: By a dynamic attribute we shall understand an attribute whose values are variable, i.e., can change. Dynamic attributes are either inert, reactive or active attributes.

Attribute Category 3: Inert: By an inert attribute we shall understand a dynamic attribute whose values only change as the result of external stimuli where these stimuli prescribe new values.

Attribute Category 4: Reactive: By a reactive attribute we shall understand a dynamic attribute whose values, if they vary, change in response to external stimuli, where these stimuli either come from outside the domain of interest or from other endurants.

Attribute Category 5: Active: By an active attribute we shall understand a dynamic attribute whose values change (also) of its own volition. Active attributes are either autonomous, or biddable or programmable attributes.

Attribute Category 6: Autonomous: By an autonomous attribute we shall understand a dynamic active attribute whose values change only “on their own volition”. The values of an autonomous attributes are a “law onto themselves and their surroundings”.

Attribute Category 7: Biddable: By a biddable attribute we shall understand a dynamic active attribute whose values are prescribed but may fail to be observed as such.

Attribute Category 8: Programmable: By a programmable attribute we shall understand a dynamic active attribute whose values can be prescribed.

We modify Jackson’s categorisation. This is done in preparation for our exposé of behaviour signatures, cf. Sect. 6.4.1 on page 23. Figure 2 shows groupings of some of M. A. Jackson’s basic categories.

Fig. 2.

An Attribute Ontology

Our motivation for modifying Jackson’s attribute categories is as follows: when transcendentally deducing behaviours from parts we find that there are basically a need for distinguishing between only three major attribute categories the static, the monitorable, and the programmable attributes. Static attributes have their values passed “by value”, as constants, programmable attributes have their values passed by “by reference”, as variables who value can be changed, and monitorable attributes have their values passed by “by name” – as we shall see!

5.4 Intentional Pull

5.4.1 Characterisations

Intentionality as a philosophical concept is defined by the Stanford Encyclopedia of Philosophy¹⁸ as “the power of minds to be about, to represent, or to stand for, things, properties and states of affairs.”

Intent is then a usually clearly formulated or planned intention. An example of intent is that of roads made for automobiles and automobiles meant for roads.

Intentional Pull¹⁹: Two or more artefactual parts of different sorts, but with overlapping sets of intents may excert an intentional “pull” on one another. This intentional “pull” may take many forms. Let $p_x$ $:X$ and $p_y$:Y be two parts of different sorts (X,Y), and with common intent, $\iota$. Manifestations of these, their common intent, must somehow be subject to constraints, and these must be expressed predicatively. When a composite artefact has an intentionality then its constituents have individual intentionalities that relate to these. The composite road transport system has intentionality of the roads serving the automobiles, and the automobiles have the intent of being served by the roads.

11  Example. Intentional Pull: Road Transport: We refer to Sect.  on page 30.

12  Example. Intentional Pull: Double-entry Bookkeeping: Double-entry bookkeeping, also known as double-entry accounting, is a method of bookkeeping that relies on a two-sided accounting entry to maintain financial information. Every entry to an account requires a corresponding and opposite entry to a different account. The double-entry system has two equal and corresponding sides known as debit and credit. A transaction in double-entry bookkeeping always affects at least two accounts, always includes at least one debit and one credit, and always has total debits and total credits that are equal.²⁰.

5.5 A Proof-Theoretic Explication, II

We remind You of Sect. 3.5 on page 14.

With the introduction of analysis functions and observers for unique identifiers, mereology and attributes we can now augment the is_..., uid_..., mereo_..., attr_A... observers introduced since Page 14.

6 Perdurants

A key point of our domain science & engineering approach is this: to every manifest part we transcendentally deduce a unique behaviour.

By transcendental we shall understand the philosophical notion: the a priori or intuitive basis of knowledge, independent of experience.

By a transcendental deduction we shall understand the philosophical notion: a transcendental ‘conversion’ of one kind of knowledge into a seemingly different kind of knowledge.

6.1 Channels

Part behaviours may interact. To express part behaviours and their interaction we use Hoare’s CSP [38, 39]. One may question this choice. In [7, 11, 14, 2009–2017] we show “that to every mereology there is a CSP expression”. On that background we maintain that CSP is a reasonable choice—but invite the reader to suggest more appropriate mechanisms for handling behaviours and their communication.²¹

So, in general, we declare a RSL/CSP channel:

Here ch is the name of the indexed array of channels and the indexes are, in general, any two element sets of unique part identifiers. That is: For every pair of part behaviours – identified but their unique part identifiers (ui,uj) – there is a channel, say ch[$\{$ui,uj$\}$ ].

M is the type of the messages communicate between behaviours of index ui,uj.

We shall develop, in Sect. 6.2.2, the specifics of the type, M, of channel messages.

6.2 Actors

By an actor we shall understand either an action, or an event, or a behaviour.

6.2.1 Actions

By an action of a behaviour we shall understand something which is local to a behaviour, and, which, when applied, potentially changes the states. Generally action clauses are expressed in RSL [32].

13  Example. Road Transport Actions: We refer to Sect.  on page 33.

6.2.2 Events

By an event of a behaviour we shall understand something that involves two behaviours, and, which, when applied, potentially changes the states of both behaviours. Event clauses are expressed using the CSP elements of RSL. That is, the CSP output “!” and input events “?”:

14  Example. Road Transport Events: We refer to Sect.  on page 33.

6.3 State Access and Updates

We need define two functionals: one for changing the mereology of a part and another for changing the attribute value of a part. We therefore informally define the following functionals:

6.3.1 Update Mereologies

• part_update_mereology is a functional: it takes the following arguments: a part p of type P and a mereology value and yields a part of type P.

• The yielded result, p$'$, has the same unique identifier, as the argument part p,

• a new, the argument, mereology, as the argument part p,

• and the same attribute values for all attributes, as the argument part p.

6.3.2 Update Attributes

• part_update_attribute is a functional: it takes the following arguments: a part p of type P and a pair of an attribute name and value, and yields a part p$'$ of type P.

• The argument attribute name must be that of an attribute of the part.

• The yielded result p$'$ has the same unique identifier and mereology as the argument part p,

• and the same attribute values for all attributes, as the argument part p, except for argument attribute (name) for which it now yields the argument attribute value.

Examples of monitorable attributes are: an automobile’s velocity and engine (cooler) temperature. Monitorable attributes usually change their values surreptitiously. That is, “behind the back”, so-to-speak, of the part behaviour.

6.4 Behaviours

By a behaviour we shall understand a set of sequences of actions, events and behaviours.

6.4.1 Behaviour Signatures

We now come to a crucial point in our unrolling the domain science & engineering method. It is that of explaining the signature of behaviours, that is, the arguments ascribed to part behaviours. The general form of part p behaviour signatures is as follows.

Yes, that is it! The behaviour of a[ny] (manifest) part, p, is a function whose only argument is that part! The signature informs of the channels that p_behaviour may communicate with. The literal Unit informs that the behaviour may not yield any value, but, for example, go on “forever” having possibly effected a state change!

6.4.2 Behaviour Definitions

Behaviours, besides their signatures, are defined. That is, a behaviour definition ‘body’ describes, in, for us, using RSL [32] with its embodiment of a variant of CSP [39], basically CSP clauses how it interacts with other behaviours, and, in basically RSL’s functional specification (read: programming) clauses, how it otherwise “goes about its business”!

In fragment I the focus is on the possible [action] update of either biddable or programmable attributes.

In fragment II the focus is on the possible [action] value access to any attributes.

In fragment III the focus is on the possible interaction with other behaviours, hence illustrates two events as seen from one behaviour.

15  Example. Road Transport Behaviour Definitions: We refer to Sect.  on page 33.

6.5 Domain Initialisation

By domain initialisation we mean the “start-up” of a behaviour for all manifest parts.

16  Example. Road Transport Domain Initialisation: We refer to Sect.  on page 36.

6.6 End of Domain Modelling Presentation

This concludes the four sections, Sects. 2, 3, 4 and 6, on domain modelling.

7 A Road Transport Domain Example

7.1 Naming and Sketch of Domain

We refer to Sect. 2 on page 7.

Narration:

• 1 The domain is referred to as RTD, the road transport domain.

• 2 The road transport domain comprises a set of automobiles and a road net of street intersections, called hubs, and [uninterrupted] street segments, called links. Automobiles drive in and out of hubs and links.

7.2 Endurants: External Qualities

7.2.1 Cartesian Examples

We refer to Sect. 3.3.1 on page 12.

7.2.2 Part Sets

We refer to Sect. 3.3.2 on page 12.

• 8 There are hubs; from aggregate of hubs one can observe sets of hubs.

• 9 There are links; from aggregate of links one can observe sets of links.

• 10 There are automobiles; from aggregate of automobiles one can observe sets of automobiles.

7.2.3 Endurant States

We refer to Sect. 3.4 on page 13.

• 11 The singleton value rtd represents a road transport [domain] state.

• 12 The set value hs represents a state of all hubs of that road transport domain.

• 13 The set value ls represents a state of all links of that road transport domain.

• 14 The set value as represents a state of all automobiles of that road transport domain.

7.3 Unique Identifiers

We refer to Sect. 7.3.1 on page 15.

7.3.1 Unique Identifiation

We shall only consider hubs, links and automobiles.

• 15 Hubs have unique identifiers.

• 16 Links have unique identifiers.

• 17 We define also a unique identifier observer for hubs and links.

• 18 Automobiles have unique identifiers.

7.3.2 Unique Identifier State

• 19 The variable his contains all unique hub identifiers of the road transport domain 3 on page 25.

• 20 The variable lis contains all unique link identifiers of the road transport domain 3 on page 25.

• 21 The variable ais contains all unique automobile identifiers of the road transport domain 3 on page 25.

7.3.3 Unique Identifier Axiom

• 22 No two hubs, links and automobiles have the same unique identifier.

• 23 ps is the set of all hubs, links and automobiles.

• 24 uis is the set of all unique hub, link and automobile identifiers.

7.4 Mereology

We refer to Sect. 7.4 on page 17.

• 28 Link and automobile identifiers of hub mereologies must be of the road transport domain.

• 29 Hub and automobile identifiers of hub mereologies must be of the road transport domain and there must be exactly two hub identifiers of those mereologies.

• 30 Hub and links identifiers of automobile mereologies must be of the road transport domain.

7.4.1 Routes

• 31 By a route (of a road net) we shall understand

  • a an alternating sequence of one or more hub and link identifiers

• 32 such that

  • a basis clause 0: the empty list is a route;

  • b basis clause 1: a singleton list of a hub or a link identifier of the road net is a route;

  • c inductive clause: the concatenation of a route, r, and the tail of a route r$'$ where the last element of r is identical to the first element of r$'$ is a route; and

  • d extremal clause: and only such routes that can be formed using the above clauses are routes.

7.5 Attributes

We refer to Sect. 7.5 on page 17.

7.5.1 Hubs, Links and Automobiles

• Hub Attributes

• 33 Hubs have [traffic signal] states which are set of pairs, li,lj, of identifiers of the mereology links “signaling” that automobiles can connect from link li to link lj.

• 34 Hubs have [traffic signal] state spaces – designating the set of all possible hub states.

• 35 Hubs have a history; see Item 46 on page 31.

• Link Attributes

• 36 Links have lengths.

• 37 Links have a history; see Item 47 on page 31.

• Automobile Attributes

• 38 Automobiles have positions on the road net:

  • a either at a hub,

  • b or on a link, some fraction

  • c down from an entry hub towards the exit hub.

• 39 Automobiles have a history; see Item 48 on page 31.

We postpone treatment of hub, link and automobile histories till Sect. 7.6.1.

We omit treatment of such automobile attributes as speed, acceleration, engine temperature, energy (gas, oil, electricity) level, mileage and trip counters, GPS (map) position, road surface temperature, gear position (reverse, neutral, forward (1, 2, 3, 4, 5), hand brake position, clutch position, accelerator pressure, brake pedal position, etc.

• 40 The link identifiers of a hub state must be of the mereology of that hub.

• 41 A hub state must be in the hub state space.

• 42 The automobile position must be on the road net.

These were some well-formedness axioms. In Sect. 7.6.1 we shall treat well-formedness of hub, link and automobile histories.

7.5.2 Attribute Category Examples

Attribute categories are: H$\varSigma$ (Item 33 on the preceding page) is a programmable attribute; H$\varOmega$ (Item 34 on the previous page) is a static attribute; LEN (Item 36 on the preceding page) is a static attribute; A_Pos (Item 38 on the previous page) is a programmable attribute; GPS_Map is an inert attribute; Speed is a biddable attribute; Road_Surface_Temperature is an autonomous attribute; etcetera.

7.6 Intentional Pull

We refer to Sect. 7.6 on page 20.

7.6.1 Further Attributes

We start by formulating the hub, link and automobile history attribute definitions.

• 43 Hubs and links are entered and left by automobiles, i.e., marked by corresponding events.

• 44 Automobile enters and leaves hubs, i.e., marked by corresponding events.

• 45 Automobile enters and leaves links, i.e., marked by corresponding events.

• 46 Hub histories are time-stamped sequences of automobile enter/leave events – in decreasing order (most recent events are listed first),

• 47 Link histories are time-stamped sequences of automobile enter/leave events – in decreasing order (most recent events are listed first),

• 48 Automobile histories are time-stamped sequences of hub and link enter/leave events – in decreasing order (most recent events are listed first),

• 49 For convenience we “lump” hub and link histories into hub-link histories.

• 50 Automobile histories

  • a alternate between being on hubs and being on links.

  • b such that the enter hub event time is identical to the immediately “prior” leave link event time,

  • c and such that these events are otherwise ordered in decreasing order of time.

We leave the (narrative and formal) expression of the well-formedness of hub and link histories to the reader! The above indicates that one has to be very careful concerning well-formedness.

But we have not captured all of the constraints, i.e., well-formedness of the history attributes. Next we secure full care!

7.6.2 An Intentional Pull

• 51 For all automobiles,

  • a if their traffic history records that the automobile was entering [leaving] a hub (link) at a certain time,

  • b then that hub’s (link’s) traffic history shall record that that automobile left [entered] that hub (link) at exactly that time;

• 52 and vice versa, for all hubs an links:

  • a if the hub or link traffic history records that an automobile was leaving [entering] that hub, respectively link at a certain time,

  • b then that automobile’s traffic history shall record that that automobile entered [left] that hub, resp. link, at exactly that time.

7.7 Perdurants

7.7.1 Channels

We refer to Sect. 7.7.1 on page 21.

M will be defined in Sect. 7.7.2.2 on the facing page.

7.7.2 Domain Actions and Events

7.7.2.1 Domain Actions 

We refer to Sect. 6.2.1 on page 22.

Automobile actions are here simplified to be those of

• 53 remaining (staying) in a hub (Item 64a on the following page) and

• 54 remaining (staying) on a link (Item 65a on the next page).

7.7.2.2 Domain Events 

We refer to Sect. 6.2.2 on page 22.

Automobile events are here simplified to be those of

• 55 leaving a hub [in order to enter a link] (Item 66d on page 35 and Item 70 on page 36) and

• 56 entering a link [after having left a hub] (Item 66d on page 35 and Item 70 on page 36) and

• 57 leaving a link in order to enter a hub (Item 67c on page 35 and Item 75 on page 36).

• 58 entering a hub [after having left a link] (Item 67c on page 35 and Item 75 on page 36).

Thus contributions to M of Sect. 7.7.1 on the preceding page are:

7.7.3 Behaviour Signatures

We refer to Sect. 7.7.3 on page 23.

7.7.4 Behaviour Definitions

We refer to Sect. 7.7.4 on page 24.

• Automobile Behaviour

We omit consideration of the monitorable GPS_Map, Speed and Road_Surface_Temperature attributes.

• 59 One interpretation of an automobile, auto,

• 60 focuses on its road position.

• 61 Either the automobile is at a hub,

• 62 or it is on a link.

• 63 There could be other focal points.

• 64 In traversing a hub an automobile

  • a is either, internal non-deterministically, $\lceil \!\rceil$, moving on inside the hub

  • b or, internal non-deterministically, entering a link from the hub.

• 65 In traversing a link an automobile

  • a is either, internal non-deterministically, $\lceil \!\rceil$, moving on inside the link

  • b – possibly advancing a bit, i.e., increasing its fraction position “down” the link,

  • c or, internal non-deterministically, entering a hub from the link.

• 66 In entering a link

  • a the automobile internal non-deterministically selects the link to be entered, and thus the next hub,

  • b records the time,

  • c updates its history and automobile position accordingly,

  • d so informs the behaviour of the hub being left and the link being entered, while resuming being an automobile – with the updated history.

^{22 23}

• 67 In entering a hub

  • a the time is recorded,

  • b the automobile history and position is updated,

  • c and the behaviours of the link left link and hub entered are being so informed while the automobile resumes being an automobile – in the updated state.

Hub Behaviour

• 68 The hub behaviour

• 69 externally non-deterministically ($\lceil \!\rceil \!\!\!\!\!\!\;\lfloor \!\rfloor$) offers

• 70 to accept, non-deterministically, a leave message,

• 71 from any automobile in its mereology;

• 72 it prepares for proper insertion of this event into its traffic history

• 73 updating to an augmented traffic history, and, hence, hub state;

• 74 resuming to be the hub behaviour in the updated state;

• 75 or to accept, non-deterministically, an enter message,

• 76 again from any automobile in its mereology;

• 77 updating to an augmented traffic history, and, hence, hub state;

• 78 resuming to be the hub behaviour in the updated state.

We leave the definition of link behaviours as an exercise!

7.8 Domain Initialisation

We refer to Sect. 7.8 on page 24.

We initialise a domain behaviour for all atomic endurants: hubs, links and automobiles.

• 79 The domain behaviour is the parallel composition of

• 80 the distributed parallel composition of all hub behaviours, with

• 81 the distributed parallel composition of all link behaviours, with

• 82 the distributed parallel composition of all automobile behaviours.

7.9 Verification

It remains to verify that the automobile, hub and link behaviours and the road transport domain initialisation satisfy the appropriate axioms and the intentional pull.

• End of Example

8 Closing

8.1 The Current Calculi

The treatment of behaviours of Sect. 6.4.2 differs very much from that of Sects. 7.6 and 7.7 of [17]. The present one is very short, but results in a repeated use of the part_update functional. Our domain modelling approach allows a wide spectrum, in-between these behaviour signature and definition styles, for expressing behaviours. What remains fixed in the treatment of endurants: both of their external qualities, and of their internal qualities.

8.2 Some Issues

A number of issues need be addressed.

8.2.1 A New View of Software Development ?

Yes, we claim that this paper presents an additional view of software development! Aircraft designers and manufacturers employ professionally educated aeronautics engineers having state-of-the-art insight into aerodynamics. But, we claim, software companies do not, today, 2023/07/29 13:16:53, exhibit the same professionalism in their staffing. Software for health care (hospitals, etc.) are often developed by programmers with no previous professional insight into that area. Likewise for domains such as law, public administration, health care and tax administration. With sound methods for “deriving” requirements from domain models, cf. Sect. 8.2.7 on page 39, these software houses now have a possibility of becoming professional.

8.2.2 From Programming Language Semantics to Domain Models

Domain models give semantics to the nouns (endurants) and verbs (perdurants) spoken by domain workers. Just like the development of compilers for programming languages were based on formal models of their semantics, so we can now give semantics to the nouns and verbs spoken by domain workers, and, from these, using rigorous development methods, similar to those used for compiler development [25, 28], develop trustworthy domain software.

8.2.3 Correctness: Verification, Checking, Testing

This paper has not dealt with the issue of correctness of domain models. A number of endurant and perdurant $\mathcal {D}$escription prompts have indicated that axioms and assertions²⁴ need be expressed. For domain assertions their correctness must, of course, be shown – using whichever (testing, model checking and proof) techniques are adequate. The axioms and assertions carry over into $\mathcal {R}$equirements prescriptions and, from there, into software $\mathcal {S}$pecifications. Now the full-blown force of testing, model checking and proofs must be applied. As indicated in formula $\mathcal {D},\mathcal {S}\models \mathcal {R}$, Sect. 1.2 on page 3, domain models now make proof obligations more clear.

8.2.4 No Recursive Domains!

Surprise, surprise! Yes, there are no recursively defined endurant sorts. Domains do not contain “recursive endurants”.²⁵

8.2.5 Domain Facets

There is more to domain engineering than this paper can cover. A main element of domain modelling is that of modelling also other than the intrinsics of domains – as so far covered. By a domain facet we shall understand 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 these views together cover the domain.²⁶ [17, Chapter 8] covers methods for modelling additional facets – such as support technology, rules & regulations, scripts (or contracts), license languages, management & organisation, and human behaviour.

8.2.6 Algorithmics

Algorithms are the hall-mark and corner-stone of computing. So where is “algorithmics” [34, 36, Harel] in all this ? ! The straight answer is: algorithm concerns are not concerns of domain modelling!

Domain models focus on expressing properties. They do so using abstraction in general, and simple combinations of proof theoretic and model theoretic means such as defining abstract types, here called sorts, comprehension over sets, sequences and maps , , and . The predicates, $\mathcal {P},\mathcal {Q}$ and $\mathcal {R}$ further raise the level of abstraction. It is in the efficient realization of these abstractions that algorithms play their part.

8.2.7 Requirements

In [17, Chapter 9, 2021] we show how to “derive”, in a systematic manner, requirements prescriptions from domain descriptions. Requirements are for a machine²⁷ The machine is the hardware upon which the software to be developed is to be executed – as well as the [auxiliary] software “under which” that new software is performing (operating system, database system, data communications software, etc.). First requirements development proceeds in three stages: (i) a domain requirements stage in which requirements that can be expressed sôlely using terms from the domain are developed; (ii) an interface requirements stage in which requirements that can be express using terms from both the domain and the machine are developed; and (iii) a domain requirements stage in which requirements that can be expressed solely using terms from the machine are developed. [17] shows how domain requirements stage can be decomposed, sequentially, into projection, initialisation, determination, extension and fitting steps. For details on this and more we refer to [17].

8.2.8 Software Design

[4, 2005-2006] shows how to further develop software from their requirements prescriptions.

8.2.9 Continuity

As remarked in Sect. 3.1 on page 11 the calculi of this paper do not address the issue of modelling continuous dynamic phenomena. This is clearly a weakness. The Integrated Formal Methods conferences [45] initially set out to spur research aimed at amalgamating continuous and discrete specifications. Not much progress has been made, except: TLA$^{+}$ offers some form of hybrid systems [46]; Hybrid Event-B [2] likewise; and for Back’s Action Systems there is a hybrid version [1].²⁸ We also refer to [59, 60].

8.2.10 Modelling Concurrency

We have used Hoare’s CSP [39] to model concurrency. There are other, in this case, graphical languages for modelling concurrency. We refer to Chaps. 12–15 of [5]. In these chapters I treat the modelling of four graphical specification languages: Petri Nets [52], Message Sequence Charts [40, 41], State Charts [35] and Live Sequence Charts [29, 37]. All of them are fascinating. Their graphics appeal to many of us – so I recommend to use them informally, aside, for the textual modelling shown in this paper. But they do not “merge” into formal, textual specification languages, like VDM-SL, RSL, Z, Alloy.

8.2.11 Modelling Temporality

Although time is modelled, as part of internal attribute properties, we have not shown the modelling of temporality of behaviours. In Chap. 15 of [5] I show how to merge Duration Calculus, DC [61] with RSL-Text. Another fascinating such formal specification language is Leslie Lamport’s TLA+: Temporal Logic of Actions [47].

8.2.12 Domain Specific Languages

A domain specific language, DSL, is a computer programming language specialised to a particular application domain. What we have shown here is not a DSL. Examples of DSLs could be programming languages for expressing calculations for railways or financial services or hospitals or other. [27, Actulus] reports on an actuarial programming language for life insurance and pensions. To give semantics for a specific DSL one invariably specifies a domain model. So that, then, is a rôle for domain modelling.

8.2.13 Three Rôles for Domain Models

There are three rôles for domain models: (i) to just simply study and understand a domain – irrespective of any ensuing software for that domain; (ii) to serve as a basis for the development of a DSL; and (iii) to serve as a basis for the development of [other] software for the domain.

8.2.14 How Comprehensive Should a Domain Model Be?

Clearly domain models for any reasonable domain can potentially be very large in terms of pages of description. So the question is: how much of the “domain at large” should be included in a domain description ?. We cannot, of course, give a general answer to that question. But we can say that the domain model must at least encompass those domain entities that will, or might, be referred to in a requirements prescription. That is, if it is found when developing a domain requirements²⁹ of a requirements prescription, that terms thought to be of the domain was not covered by the domain description, then, obviously, that description must be augmented.

We do expect there to be, eventually, available for general use, a few, domain models for selected domains.

For physics Newton and Leibniz³⁰ has given us a calculus with which to – more or less quickly – establish a model for some physical phenomenon. When control engineers then wish to set up some automatic control system for a phenomenon they first apply the Newton/Leibniz calculi to model the phenomenon, then, from that, somehow derive a control model. We advocate a similar approach, as already hinted at in our expressing the Triptych Dogma (Page 1).

The road transport domain modelled in Appendix 7 is one such domain. It has here been expressed in a way, devoid of any specific orientation. Based on the model of Appendix 7 we can envisage some such orientations as a road pricing domain, a cadastral³¹ map domain, a road development domain, a road maintenance domain, etc.

8.2.15 Domain Laws

Physics has excelled in our understanding the world we live in by its laws and by the calculi it has spawned – calculi that enables us to explain what has happened and to predict what will or might happen. Domain modelling has already lead to some domain laws – such as illustrated by for example intentional pulls, cf. Sect. 5.4 on page 20 (approx. half a page) and Appendix 7.6 on page 30 (two pages). The study of intentional pull in domains has just started! Its counterpart in physics, gravitational pull, is “behind” many laws of physics.

8.2.16 A Domain Modelling Science?

A science of domain modelling systematically builds and organizes knowledge about the ways and means of modelling domains such that that knowledge can explain what these models express. As an example of there not yet being a sufficient scientific knowledge of domains we refer to our informal coverage of the concept of domain facets, cf. footnote 26 on page 38. A formal understanding of domains and what “facet”–distinguishes them, could help sharpen the characterisation of Sect. 8.2.5 on page 38. Such a formal understanding was first reported in [12, 2014]. Of more specific nature we suggest, next, studies of some specific issues³².

• (i) An “integrated” form of use of differential equations with the present RSL $^+$, i.e., the extension of our approach to domain modelling to cover more specifically issues of continuity.

• (ii) A “further detailed” understanding of the concept of intentional pull.

• (iii) A study of a possible Calculus of Perdurants.

• (iv) A study of examples of domain models with an emphasis on human interaction.

• (v) Formal models of the analysis predicates and functions and the description functions, cf. [12].