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
Access provided by Autonomous University of Puebla. Download chapter PDF
Similar content being viewed by others
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.Footnote 1
We shall, in this paper, assume already existing domains. By domain engineering we mean the construction of domain models.Footnote 2
1.2 Non-computable and Computable Specifications
When specifyingFootnote 3 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 & validateFootnote 4 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.
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.Footnote 5 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 RAISEFootnote 6 [33] specification language RSL [32].Footnote 7\(^{,}\)Footnote 8
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.Footnote 9
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 endurantsFootnote 10 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,Footnote 11 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 granularFootnote 12, or plant productsFootnote 13, 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 pullFootnote 14
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 summariseFootnote 15:
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 mFootnote 16.
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:19Footnote 17. 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.
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 PhilosophyFootnote 18 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 PullFootnote 19: 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.Footnote 20.
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.Footnote 21
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
-
a
-
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.
-
a
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.
-
a
-
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.
-
a
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;
-
a
-
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.
-
a
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.
-
a
-
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.
-
a
-
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.
-
a
-
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.
-
a
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 assertionsFootnote 24 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”.Footnote 25
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.Footnote 26 [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 machineFootnote 27 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].Footnote 28 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 requirementsFootnote 29 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 LeibnizFootnote 30 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 cadastralFootnote 31 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 issuesFootnote 32.
-
(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].
Notes
- 1.
Thus a railway domain model should desirably cover such instances as the railways of Denmark and Norway and Sweden, each one individually.
- 2.
The approach taken here can, however, also be used to devise new domains.
- 3.
By specifying software we mean specifying the design of the software. That design is derived from the software requirements.
- 4.
test, check and verify.
- 5.
We shall, in this paper, not exemplify living species endurants.
- 6.
Rigorous Approach to Idustrial Software Engineering.
- 7.
RSL: RAISE Specification Language.
- 8.
- 9.
Google’s English Dictionary as provided by Oxford Languages.
- 10.
We refer to predicate prompt # 2 below for a definition of endurant.
- 11.
- 12.
This is a purely pragmatic decision. “Of course” sand, gravel, soil, etc., are not fluids, but for our modelling purposes it is convenient to “compartmentalise” them as fluids!.
- 13.
i.e., chopped sugar cane, threshed, or otherwise. See footnote 12.
- 14.
This characterisation is the result of our study of relations between philosophy and computing science, notably influenced by Kai Sørlander’s Philosphy.
- 15.
Framed texts highlight domain analysis & description prompts.
- 16.
The author’s house location!.
- 17.
The time this text was last compiled!
- 18.
Jacob, P. (Aug 31, 2010). Intentionality. Stanford Encyclopedia of Philosophy (seop.illc.uva.nl/entries/intentionality/ October 15, 2014, retrieved April 3, 2018.
- 19.
The term intentional pull is chosen so as to connote with the term gravitational pull.
- 20.
https://en.wikipedia.org/wiki/Double-entry_bookkeeping.
- 21.
Please bear in mind that the use, here, of CSP, is in the following context: the CSP clauses are not to be “interpreted” on a computer where this “computerisation” has to be “shared” with other computations; hence CSP synchcronisation & communication is “ideal” and reflects reality.
- 22.
For retr_\(\cdots \) see Sect. 5.1.4 on page 16.
- 23.
For record_\(\mathbb {TIME}\) see Sect. 4.2 on page 15.
- 24.
i.e., proof obligations.
- 25.
Some readers may object, but we insist! If trees are brought forward, as an example of a recursively definable domain, then we argue: Yes, trees can be recursively defined. Trees can, as well, be defined as a variant of graphs, and you wouldn’t claim, would you, that graphs are recursive ? We shall consider the living species of trees (that is, plants), as atomic. In defining attribute types You may wish to model certain attributes as ‘trees’. Then, by all means, You may do so recursively. But natural trees, having roots and branches cannot be recursively defined, since proper “sub-trees” of trees would then have roots!
- 26.
This characterisation clearly lacks sufficient formality. We refer to Sect. 8.2.16 below.
- 27.
– as suggested by Michael A. Jackson [43].
- 28.
I acknowledge the mentioning of these three references to one of the reviewers of the resent paper.
- 29.
Cf. Sect. 8.2.7 on the previous page.
- 30.
- 31.
- 32.
References
Back, R.J., Petre, L., Porres, I.: Generalizing action systems to hybrid systems. In: Formal Techniques in Real-Time and Fault-Tolerant Systems, pp. 202–213 (2000). https://doi.org/10.1007/3-540-45352-0_17, www.researchgate.net/publication/221654900_Generalizing_Action_Systems_to_Hybrid_Systems
Banach, R., Butler, M.: Modelling hybrid systems in event-B and hybrid event-B: a comparison of water tanks. In: Ogata, K., Lawford, M., Liu, S. (eds.) ICFEM 2016. LNCS, vol. 10009, pp. 90–105. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-47846-3_7
Bjørner, D.: UNU/IIST reports on domain modelling. Research Report, UNU/IIST (1995–1997), UNUIIST:46: New Software Technology Development, UNUIIST:47: Software Support for Infrastructure Systems, UNUIIST:48: Software Systems Engineering - From Domain Analysis to Requirements Capture [- an Air Traffic Control Example], UNUIIST:58: Infrastructure Software Systems, UNUIIST:59: New Software Development, UNUIIST:60: Models of Enterprise Management: Strategy, Tactics & Operations - Case Study Applied to Airlines and Manufacturing, UNUIIST:61: Federated GIS+DIS-based Decision Support Systems for Sustainable Development - a Conceptual Architecture, UNUIIST:96: Models of Financial Services & Industries
Bjørner, D.: Software Engineering, Vol. 1: Abstraction and Modelling; Vol. 2: Specification of Systems and Languages; Vol. 3: Domains, Requirements and Software Design. Texts in Theoretical Computer Science, the EATCS Series. Springer, Heidelberg (2006)
Bjørner, D.: Software Engineering, Vol. 2: Specification of Systems and Languages. Texts in Theoretical Computer Science, the EATCS Series. Springer, Heidelberg (2006). Chapters 12–14 are primarily authored by Christian Krog Madsen. See [6, 8]
Bjørner, D.: Software Engineering, Vol. 2: Specification of Systems and Languages. Qinghua University Press (2008)
Bjørner, D.: On mereologies in computing science. In: Roscoe, A.W., Jones, C.B., Wood, K.R. (eds.) Reflections on the Work of C.A.R. Hoare, pp. 47–70. Springer, London (2010). https://doi.org/10.1007/978-1-84882-912-1_3, www.imm.dtu.dk/~dibj/bjorner-hoare75-p.pdf
Bjørner, D.: Chinese: Software Engineering, Vol. 2: Specification of Systems and Languages. Qinghua University Press (2010). Translated by Dr Liu Bo Chao et al
Bjørner, D.: Domain science & engineering - from computer science to the sciences of informatics, part I of II: the engineering part. Kibernetika sistemny analiz 2(4), 100–116 (2010)
Bjørner, D.: Domain science & engineering - from computer science to the sciences of informatics part II of II: the science part. Kibernetika sistemny analiz 2(3), 100–120 (2011)
Bjørner, D.: A rôle for mereology in domain science and engineering: to every mereology there corresponds a \(\lambda \)–expression. In: Calosi, C., Graziani, P. (eds.) Mereology and the Sciences. SL, vol. 371, pp. 323–357. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-05356-1_12
Bjørner, D.: Domain analysis: endurants - an analysis & description process model. In: Iida, S., Meseguer, J., Ogata, K. (eds.) Specification, Algebra, and Software. LNCS, vol. 8373, pp. 1–34. Springer, Heidelberg (2014). https://doi.org/10.1007/978-3-642-54624-2_1, www.imm.dtu.dk/~dibj/2014/kanazawa/kanazawa-p.pdf
Bjørner, D.: Manifest domains: analysis & description. Formal Aspects Comput. 29(2), 175–225 (2017). www.imm.dtu.dk/~dibj/2015/faoc/faoc-bjorner.pdf. Accessed 26 July 2016
Bjørner, D.: To every manifest domain a CSP expression. J. Log. Algebraic Methods Program. 1(94), 91–108 (2018). www.imm.dtu.dk/~dibj/2016/mereo/mereo.pdf
Bjørner, D.: slAn assembly plant domain - analysis & description. Technical report, Technical University of Denmark, Fredsvej 11, DK-2840 Holte, Denmark (2019). www.imm.dtu.dk/~dibj/2021/assembly/assemblyline.pdf
Bjørner, D.: Domain analysis & description - principles, techniques and modelling languages. ACM Trans. Software Eng. Methodol. 28(2), 68p (2019). www.imm.dtu.dk/~dibj/2018/tosem/Bjorner-TOSEM.pdf
Bjørner, D.: Domain Science & Engineering - A Foundation for Software Development. EATCS Monographs in Theoretical Computer Science. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-73484-8. A revised version of this book is [21]
Bjørner, D.: Rigorous Domain Descriptions. A compendium of draft domain description sketches carried out over the years 1995–2021 (2021). www.imm.dtu.dk/~dibj/2021/dd/dd.pdf
Bjørner, D.: Documents: a basis for government. In: United Natonans Inst., Festschrift for Tomas Janowski and Elsa Estevez, Guimaraes, Portugal (2022). www.imm.dtu.dk/~dibj/2022/janowski/docs.pdf
Bjørner, D.: Domain modelling - a primer (2023). A short version of [21]. xii+227 pages
Bjørner, D.: Domain science & engineering - a foundation for software development (2023). Revised edition of [17]. xii+346 pages
Bjørner, D.: Pipelines: a domain science & engineering description. In: FSEN 2023: Fundamentals of Software Engineering, 3–5 May 2023, Teheran, Iran (2023). www.imm.dtu.dk/~dibj/2023/tehran/tehran.pdf
Bjørner, D., Jones, C.B. (eds.): The Vienna Development Method: The Meta-Language. LNCS, vol. 61. Springer, Heidelberg (1978). https://doi.org/10.1007/3-540-08766-4
Bjørner, D., Jones, C.B. (eds.): Formal Specification and Software Development. Prentice-Hall, Hoboken (1982)
Bjørner, D., Nest, O.N. (eds.): Towards a Formal Description of Ada. LNCS, vol. 98. Springer, Heidelberg (1980). https://doi.org/10.1007/3-540-10283-3
Casati, R., Varzi, A.C.: Parts and Places: The Structures of Spatial Representation. MIT Press, Cambridge (1999)
Christiansen, D.R., Grue, K., Niss, H., Sestoft, P., Sigtryggsson, K.S.: Actulus modeling language - an actuarial programming language for life insurance and pensions. Technical report, edlund.dk/sites/default/files/Downloads/paper_actulus-modeling-language.pdf, Edlund A/S, Denmark, Bjerregårds Sidevej 4, DK-2500 Valby. (+45) 36 15 06 30. edlund@edlund.dk (2015). http://www.edlund.dk/en/insights/scientific-papers. This paper illustrates how the design of pension and life insurance products, and their administration, reserve calculations, and audit, can be based on a common formal notation. The notation is human-readable and machine-processable, and specialised to the actuarial domain, achieving great expressive power combined with ease of use and safety
Clemmensen, G.B., Oest, O.N.: Formal specification and development of an Ada compiler - a VDM case study. In: Proceedings of the 7th International Conference on Software Engineering, 26–29 March 1984, Orlando, Florida, pp. 430–440. IEEE (1984)
Damm, W., Harel, D.: LSCs: breathing life into message sequence charts. Formal Methods Syst. Design 19, 45–80 (2001). Early version appeared as Weizmann Institute Technical report CS98-09, April 1998. An abridged version appeared in Proceedings of the 3rd IFIP International Conference on Formal Methods for Open Object-based Distributed Systems (FMOODS 1999), pp. pp. 293–312. Kluwer (1999)
Fitzgerald, J., Larsen, P.G.: Modelling Systems - Practical Tools and Techniques in Software Development. Cambridge University Press, Cambridge (1998). iSBN 0-521-62348-0
Futatsugi, K., Nakagawa, A., Tamai, T. (eds.): CAFE: An Industrial-Strength Algebraic Formal Method. Elsevier, Amsterdam (2000). Proceedings from an April 1998 Symposium, Numazu, Japan
George, C.W., et al.: The RAISE Specification Language. The BCS Practitioner Series, Prentice-Hall, Hemel Hampstead (1992)
George, C.W., Haxthausen, A.E., Hughes, S., Milne, R., Prehn, S., Pedersen, J.S.: The RAISE Development Method. The BCS Practitioner Series, Prentice-Hall, Hemel Hampstead (1995)
Harel, D.: Algorithmics –The Spirit of Computing. Addison-Wesley (1987)
Harel, D.: StateCharts: a visual formalism for complex systems. Sci. Comput. Program. 8(3), 231–274 (1987)
Harel, D.: The Science of Computing – Exploring the Nature and Power of Algorithms. Addison-Wesley (1989)
Harel, D., Marelly, R.: Come, Let’s Play - Scenario-Based Programming Using LSCs and the Play-Engine. Springer, Cham (2003). https://doi.org/10.1007/978-3-642-19029-2
Hoare, C.A.R.: Communicating sequential processes. Commun. ACM 21(8), 666–677 (1978)
Hoare, C.A.R.: Communicating Sequential Processes. C.A.R. Hoare Series in Computer Science. Prentice-Hall International, Hoboken (1985). Published electronically: usingcsp.com/cspbook.pdf (2004)
ITU-T: CCITT Recommendation Z.120: Message Sequence Chart (MSC) (1992)
ITU-T: ITU-T Recommendation Z.120: Message Sequence Chart (MSC) (1999)
Jackson, D.: Software Abstractions: Logic, Language, and Analysis. The MIT Press, Cambridge (2006). iSBN 0-262-10114-9
Jackson, M.A.: Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices. ACM Press, Addison-Wesley, Reading (1995)
Jackson, M.A.: Program verification and system dependability. In: Boca, P., Bowen, J. (eds.) Formal Methods: State of the Art and New Directions, pp. 43–78. Springer, London (2010). https://doi.org/10.1007/978-1-84882-736-3_2
Araki, K., et al. (eds.): IFM 1999–2013: Integrated Formal Methods. LNCS, vols. 1945, 2335, 2999, 3771, 4591, 5423, 6496, 7321, 7940, etc. Springer, Cham (1999–2019)
Lamport, L.: Hybrid Systems. In: Rischel, H., Ravn, A.P. (eds.) Workshop on Theory of Hybrid Systems. Lecture Notes in Computer Science, Springer (1992), https://lamport.azurewebsites.net/pubs/lamport-hybrid.pdf
Lamport, L.: Specifying Systems. Addison-Wesley, Boston (2002)
Lamsweerde, A.: Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley, Hoboken (2009)
Little, W., Fowler, H., Coulson, J., Onions, C.: The Shorter Oxford English Dictionary on Historical Principles. Clarendon Press, Oxford (1973, 1987). Two volumes
Luschei, E.: The Logical Systems of Leśniewksi. North Holland, Amsterdam, The Netherlands (1962)
McCarthy, J.: Towards a mathematical science of computation. In: Popplewell, C. (ed.) IFIP World Congress Proceedings, pp. 21–28 (1962)
Reisig, W.: Petrinetze: Modellierungstechnik, Analysemethoden, Fallstudien, 1st edn. Leitfäden der Informatik, Vieweg+Teubner (2010). 248 p.; ISBN 978-3-8348-1290-2
Sørlander, K.: Det Uomgængelige - Filosofiske Deduktioner [The Inevitable - Philosophical Deductions, with a foreword by Georg Henrik von Wright], 168 p. Munksgaard \(\cdot \) Rosinante, Copenhagen (1994)
Sørlander, K.: Under Evighedens Synsvinkel [Under the viewpoint of eternity], 200 p. Munksgaard \(\cdot \) Rosinante, Copenhagen (1997)
Sørlander, K.: Den Endegyldige Sandhed [The Final Truth], 187 p. Rosinante, Copenhagen (2002)
Sørlander, K.: Indføring i Filosofien [Introduction to The Philosophy], 233 p. Informations Forlag, Copenhagen (2016)
Sørlander, K.: Den rene fornufts struktur [The Structure of Pure Reason]. Ellekær, Slagelse (2022)
Woodcock, J.C.P., Davies, J.: Using Z: Specification, Proof and Refinement. Prentice Hall International Series in Computer Science (1996). http://www.comlab.ox.ac.uk/usingz.html
Xie, W., Xiang, S., Zhu, H.: A UTP approach for rTiMo. Formal Aspects Comput. 30(6), 713–738 (2018). https://doi.org/10.1007/s00165-018-0467-1
Xie, W., Zhu, H., QiWen, X.: A process calculus BigrTiMo of mobile systems and its formal semantics. Formal Aspects Comput. 33(2), 207–249 (2021)
Zhou, C.C., Hansen, M.R.: Duration Calculus: A Formal Approach to Real-time Systems. Monographs in Theoretical Computer Science. An EATCS Series, Springer, Cham (2004). https://doi.org/10.1007/978-3-662-06784-0
Acknowledgment
A referee of this paper, many thanks to all five (!), suggested the following, slightly edited acknowledgment:
Laudatio: Prof. He Jifeng
– He Jifeng’s work on a Unifying Theory of Programming, UTP – a monumental contribution – is seen as a domain model for programming languages covering a wide range of programming language paradigms.
– UTP is about unifying axiomatic, denotational and operational semantics all of which can be expressed in RSL. Hence, RSL could be used as a concrete language to define a unifying theory of programming.
– One could combine domain modelling and UTP in order to systematically develop and define formal domain specific languages, DSLs. It might result in a new unifying theory of DSLs.
I fully concur.
I gratefully acknowledge the opportunity given to me, to write this paper, during my PhD lectures, October–November 2022, at the TU Wien Informatics, Vienna, Austria, by Prof. Laura Kovacs. I also gratefully acknowledge comments by Klaus Havelund, Kazuhiro Ogata and Wolfgang Reisig. Finally, many thanks to Jonathan Bowen for his indefatigable work on getting this paper in proper form and this volume finished.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2023 The Author(s), under exclusive license to Springer Nature Switzerland AG
About this chapter
Cite this chapter
Bjørner, D. (2023). Domain Modelling: A Foundation for Software Development. In: Bowen, J.P., Li, Q., Xu, Q. (eds) Theories of Programming and Formal Methods. Lecture Notes in Computer Science, vol 14080. Springer, Cham. https://doi.org/10.1007/978-3-031-40436-8_7
Download citation
DOI: https://doi.org/10.1007/978-3-031-40436-8_7
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-40435-1
Online ISBN: 978-3-031-40436-8
eBook Packages: Computer ScienceComputer Science (R0)