Dines Bjørner in numerous publications suggested a triptych view of software engineering, specified in this paper as follows: “before hardware and software systems can be designed and coded, we must have a reasonable grasp of ‘its’ requirements; before requirements can be prescribed, we must have a reasonable grasp of ‘the underlying’ domain.” Such an approach has been successfully used in other engineering disciplines for millennia: for a well-known example, when we want to get from here to there, we use a roadmap, the concept of which is based on Hellenistic mathematical geography, a typical scientific theory using a model of the surface of the Earth on a spherical surface with two spherical coordinates and using projections in order to represent the spherical surface on plane charts [1]. The roadmap is a business domain model. Without this domain model, activities associated with the domain (like traveling, building new roads, or adding capacity to existing ones) would be rather difficult. Regretfully, “in contrast with other types of engineers, ‘software engineers [generally] do not know how to model the domain in which their software operates’ (D. Bjørner). If only those who are mesmerized by their employees’ C++ skills would finally understand this!” [2].

This buzzword-free paper is one of the recent foundational presentations of domain engineering by the author. He defines a manifest domain as “a human- and artifact-assisted arrangement of endurant, that is spatially ‘stable,’ and perdurant, that is temporally ‘fleeting,’ entities. Endurant entities are either parts or components or materials. Perdurant entities are either actions or events or behaviors.” Thus, entities do not exist in isolation. A domain description is a collection of pairs of narrative and corresponding formal texts, each pair describing aspects of an entity. (Presumably, the narratives are to be understandable by domain stakeholders.) The concepts of (atomic or composite) part, component, material, and so on are defined later, based on the decisions of the domain engineer during modeling. These decisions include the choice of domain phenomena to be included in the model, the endowment (or not) of modeled entities with internal qualities, and so on. Clearly, a good domain engineer makes such decisions in cooperation with domain stakeholders, but stakeholders and their conceptually (or otherwise!) different views are considered elsewhere, for example, in [3], that, in my opinion, may be read simultaneously with or even before reading this paper. The domain engineer’s decisions are based on a structured set of principles, techniques, and tools described in the paper, and this set is “embodied in a set of analysis and description prompts” which, in the opinion of Bjørner, is novel. (This set is in fact a structured system because the prompts are not isolated.)

Bjørner stresses that “at the present time, domain analysis appears to be partly an artistic, partly a scientific endeavor. Until such a time when domain analysis and description principles, techniques and tools have matured, it will remain so.” Furthermore, “of course, analysis and description is a trial-and-error, iterative process. During a sequence of analyses, that is, analysis prompts, the analyzer ‘discovers’ either more pleasing abstractions or that earlier analyses or descriptions were wrong, or that an entity either need be abstracted or made less abstract. So they are corrected.” This is where, one hopes, tacit assumptions will be articulated. Also, different domain engineers and stakeholders will usually focus on different aspects of the domain leading to different domain models. This is as it should be: Bjørner emphasizes that there is beauty not only in the result, but also in the process of analyzing and describing a domain. This process, in particular, includes conjectures and refutations associated with types. Based on my own experience, I wholeheartedly agree.

The paper includes many realistic examples, and a lengthy reference list of other contributions by Bjørner (some with coauthors) that, in turn, include more or less complete sketches of realistic models of such domains as container lines, pipelines, road transportation, a credit card system, a weather information system, and the Tokyo Stock Exchange. These models take care also of unpleasant events or behaviors: “In the real world, i.e., in the domain, all is possible: Diligent staff will indeed follow-up on inquiries, orders, payments, etc. Loyal consumers will indeed respond likewise. But sloppy such people may not. And outright criminals may wish to cheat, say on payments or rejects. And we shall model them all” [4].

Bjørner concludes his paper with a detailed overview of and comparison with related contributions (quite a few of which are software-based, “cooked-up with a new jargon”), properly noting the ontology work and Michael Jackson’s problem frames as “relevant comparisons.” I would have liked to see more discussion of domain structure including emergence (see, for example, Bjørner and Eir [5], Ehresmann and Vanbremeersch [6], and an international standard [7]).

Summing up, I enjoyed this paper, together with other related papers by the author, and wholeheartedly recommend his work.