What is meant by "A Domain Theory"?

• By a domain theory for railways is understood a set of descriptions of any describable facet of railways - such as outlined above.
• Each description is a pair of a narrative and a formal description.
• All narrative descriptions are in English. Formal descriptions are each expressed in one, or often several formal notations.

• To properly appreciate the concept of `domain' we put it in the context of computing systems development.
• From domains we develop requirements, and from requirements we develop, say software.

By a(n application) domain we understand an area of (possibly computing supportable) human activity -- such as a bank and its interfaces to its customers, other banks, regulatory agencies, etc.

We are to understand, in the "narrow" context of the term `domain', such a domain void of any reference to computing not already in the domain. That is: If the purpose of our trying to understand a domain is - later on - to install computing /and communication) in support of activities of the domain, then (requirements to, let alone software of) that future computing (and communications) is not to be mentioned in the domain.

• Examples of Domains:
  • The Financial Service Industry:

    This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.

    To `The Financial Service Industry' we "count" the sets of such enterprises as banks, insurance companies, securities institutions (trader, brokers and exchanges), venture capatial firms, etc., as well as the country's and/or region's regulatory agencies. We also "count" all the clients of these enterprises, including politicians.

    To describe `The Financial Service Industry', to us, means to describe all those enterprises, agencies, clients, etc., as well as their interaction. To wit: The opening and closing of accounts, as well as all the varieties of transactions "against" accounts: Deposits, withdrawals, transfers, etc.

  • Transportation & Logistics:

    This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.

    We refer to Railway Systems

  • Health-Care:

    This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.

    To `Health-Care' we count such enterprises as (1) healthy and sick people (ie., potential or actual patients), (2) private (family doctor) physicians, ie., general practitioners and specialist medical doctors, (3) community nurses, (4) hospitals, (5) ambulance services, (6) clinics (convalescence and special treatment), (7) pharmacists, (8) health insurance companies, (9) interfaces to the pharmaceutical industry, (10) the national board of health, (11) ministry of health, etc.

    To describe `Health-Care', to us, means to describe all those enterprises, agencies, clients, etc., as well as their interaction. To wit: Patient visits to family physicians, pharmacies, clinics, and hospitals, the actual functions performed at these places: analyses, diagnostics, treatment and treatment advice (incl. medication and their prescription), check-up on results of treatments, etc., MR and CT scanning, surgical operations, etc. Patient interaction with health insurance institutions: Registration, premium payments, claims, etc. Medical doctor, community nurse, clinic, pharmacy and hospital reportings to health authorities, etc.

  • "The Market":

    By "The Market" -- for goods (merchandise) and services we mean the aggregation of government agencies (G), businesses (B) and citizens (C). Here government institutions include such as social welfare, excises & tax, etc.; businesses include producers, wholesalers and retailers -- seen from the point of view of their interaction, and retailer interaction with consumers (ie., citizens). And citizens cover all of us in our relations to government agencies, businesses (usually retailers, agents on behalf of these, and brokers between them and citizens), and to other citizens (in for example citizen associations (societies), etc.).

    To describe "The Market" , to us, means to describe, from the point of view of the G2G, G2B, G2C, B2G, B2B, B2C, C2G, C2B, and C2C interactions, all those interacting "players" belonging the sets G, B and C. For example, the C2B (where B is a retailer) interactions are for example: (C) Inquire as to whether a retailer has a certain merchandise, price, delivery time, etc., (B) acknowledge such an inquiry, (C) order merchandise, (B) acknowledge or declien an order, (B) deliver ordered merchandise, (C) accept or reject delivery, (B) invoice delivery, (C) pay invoice, (C) return merchandise for repair or replacement, etc.

    Similar such interactions can be identified for each of the remaining G2G, G2B, G2C, B2G, B2B, B2C, C2G, and C2C.

• Domain Facets:

  In understanding a domain it seems advicable that one decomposed and "serialises" one's understanding into the understanding of a number of related facets. A facet is a way of viewing a thing, in this case `the domain'. We suggest to at least view a domain from the point-of-view of the folowing facets.

  • Domain Intrinsics:

    By the intrinsice of a domain we understand those properties, of a domain, which any other facet/view is based on. That is, each of the next facets to be treated all have their treatment, their understanding, their description, depend on there first being established an understanding of the very basics, the intrinsics.

    Example: We pursue the example of railways: It seems that whoever you are, a railway owner, a net operator, a train operator, a passenger, etc., (1) the net: the fact that there are stations and that some of these are "non-stop" connected by (rail) lines, and (2) the trains, running on the net, along lines and between stations, that that is part of the intrinsics of a railway system.

  • Domain Business Processes:

    To be written

  • Domain Support Technologies:

    By the supporting technologies of a domain we understand those facilities, of a domain, other than human actors, which support operations of the domain.

    Example: In "ye olde days of railways", switches (turn-outs, points, etc.) - units along the rail where a route through the rail units merges or diverges - were handled by humans throwing, by the shear force of their muscles, these switches. Later the switches became operated by mechanical means: From a cabin tower, levers, mechanical momentum amplifiers and wires connected, sometimes hundreds of feet away, to the switches. Yet later, to illustrate a thrid kind of supporting technology, the mmechanics was extended into electro-mechanics. Most recently we find that switches are operated in groups, involving also significant electronics, and, ever more recently, with these operations being controlled by computers.

    All of the above exemplified several ("generations" of) supporting technologies. In current domains we shall today find that several such supporting technologies co-exists. And have to be understood.

  • Domain Management & Organisation:

    By domain management & organisation we understand a structured decomposition of the work of domain staff into usually a hierarchical or a matrix structured organisation where "lines of command & reporting" flow along the hierarchical tree or the horisontal/vertical grid of the matrix organisation: Where managers formulate policies, rules & regulations, and issue directives to "levels below them" in the structure, where they respond to "alerts" and reports from"below them" in the structure, and where they "alert" and report to other managers, or the board, "above them" in that structure.

    Example: In China, along the rail lines, from station to station, the rescheduling of trains - due to late or early trains - involves certain procedures (ie., management) and certain communications with colleagues in neigbouring stations (ie., organisation), before a proposed new train schedule can be "universally" adopted.

  • Domain Rules & Regulations:

    By domain rules & regulations we understand two sets of "laws": One set, the regulations, which specify expectations of "acceptable" behaviour of equipment and humans; another set, the rules, which stipulate what corrective actions, against equipment, operations, and/or staff, are to be taken in case rules are not fulfilled.

    Example: In China, for reasons we shall not endeavour to explain, train traffic into and out of railway stations are expected to satisfy the following rule: In any two minute interval (ie., period), at most one train is allowed to either enter or to leave a(ny) station. The "pairing" regulations state how to achieve this, and also stipulates administrative (ie., "punitive") measures to be enacted if equipments and/or humans fail to satisfy the rule.

  • Human Behaviours of the Domain:

    Humans, whether staff of, or clients (customers) or others related to the enterprise, behave either (1) diligently: despatch their work within the enterprise with careful regards to rules & regulations (whether these are explicitly enunciated or are tactily understod), or they behave (2) sloppily, with casual, arrogant or indolent respect for such expected behaviours, or they behave (3) negligently, with somewhat recalsitrant (obstinately defiant of authority or restraint), or they behave (4) outright criminally, explicitly, and on purpose, with a specific, say destructive intent in mind, going against rules & regulations.

    To understand a domain is also to understand the possibilities of staff and clients (etc.) to create harmony or havoc.

• Domain Stake-holders:

  A doman is also characterised by its stake-holders. These are the various people and institutions "united" in separate interest groups - that potentially may have different, possibly inconsistent, either reconcilable or ir-reconcilable (ie., conflicting) views of (on) the domain.

  • Stake-holder Identification:

    An important aspect of domain identification and construction is to identify, record, and communicate, during the construction process with suitably selected members of each of the selected stake-holder groups. They are the ones from whom to acquire the appropriate domain knowledge, and they are the ones with whom to validate the emerging domain models.

    Typically, for a production company one can identify the following stake-holder groups: (i) Oweners, (ii) executive management, (iii) middle management, (iv) "floor", ie., "lowest" level management, (v) workers (in administration, sales, marketing, design, research, production, etc.), (vi) clients (who buy the products), (vii) suppliers (of parts and materials, power (electricity), water, IT, etc.), (vii) consumer/client organisations, (viii) regulatory agencies, (ix) politicians (who "meddle" in well-nigh every matter), (x) neighbours of the production company's sites, (xi) the media (newpapers, radio, TV), and (xii) the general public ("man on the street").

  • Stake-holder Perspectives:

    A model is only acceptable if it reflects the views of each and all of these stake-holder groups. Two (or more) such views may be inconsistently represented in a model (under development) -- in which case one has to inquire whether that inconsistence is due to an oversight on behalf either of the developers (then it can be remedied by them alone), or on behalf of the two (or more) stake-holder groups (in which case some mutual clarification process is needed); or that inconsistence may be due to an inherent conflict between stake-holder groups. In the latter case domain management must be brought in to reconcile the inconsistency.

    But, in any case, we can expect a domain model to consist of of a set of judiciously harmonised (integrated, unified) formal models.

Model

• General:

  By a model we mean a description, both in plain natural (cum national) language, and in formal terms: In any combinations of mathematics and various, one or more, formal specification languages.

  A model is not the reality of the domain, only a reflection of it.

• Model Attributes:

  Models involve iconic, analogic and analytic facets, are either prescriptive or descriptive, or combinations thereof, and models may also involve variations or combinations of intensionality and exensionality ("white" versus "black" box views).

  Models are constructed in order (a) to understand that which is being modelled [ie., the domain], (b) to inform others about that "thing", (c) to perform predications about the behaviour of the "real thing" (based on computations over the, ie., "its" model), (d) to implement computing support for activities of the domain, (e) to perform business process reengineering of operations (human or otherwise) of the domain, (f) or other.

• Model Documents:

  A model usually consists of different types of document parts:

  • Informative Document Parts:

    Informative document parts, as the term says, inform: Presents a (1) reason for why the model is constructed, its rationale so-to-speak, that is: The (prior) needs for and (subsequent [planned]) uses of the model (that is: The "customers"); (2) lists who is constructing, or has constructed, the model (the partners); (3) a budget for and accounts of economic aspects of constructing the models (imcl. project time & resource plans, etc.); and possibly other information.

  • Descriptive Document Parts:

    There usually are four kinds of descriptive document parts:

    • Rough Domain Sketches:

      When initially starting work on a model the developer cum researcher rough sketches. Rough sketches serve to form concepts based on (ie., around) which the model is eventually expressed. The concepts are abstractions of "actual world" phenomena.

    • Domain Terminology cum Ontology:

      Along the road of model development specific terms of the domain are identified and defined. And these terms eventually enter into some ontology for the domain.

    • Domain Narrative:

      Based on clear concepts, and evolving terminology and ontology, the developer can now formulate, in precise, but informal, natural and professional (term) language a description of the entities, functions and behaviours (events, interactions and processes) of the domain.

    • Formal Domain Specification:

      Usually the narrative goes hand-in-hand with a set of one or, usually more, formalisations, ie., formal specifications. Usually one formalism does not suffice. It appears that no one specification language can equally elegantly and expressible model all domain attrubutes, facets and stake-holder perspectives. One is therefore forced to use several formalisms.

      We alphabetically mention a few formalisms: ASM (Abstract-State Machines) (since early 1990s), B ("Bourbaki") (since early 1990s), CASL (Common Algebraic Specification Language (since 1997), CafeOBJ (since 1997), DC (Duration Calculi) (since 1990), ITL (Interval Temporal Logic) (since late 1980s), RAISE (Rigorous Approach to Industrial Software Engineering) (since 1986), TLA+ (Temporal Logic of Actions + Set Theory) (since mid 1990s), Petri Nets (since 1963), CSP (since 1978), Statecharts (since mid 1980s), pi-Calculus (of Mobile Processes) (since late 1990s), VDM (Vienna Development Method) (since 1973), and Z ("Zermelo") (snce 1980).

      We refer to Recent Trends in Formal Techniques and Tools for Software Development for Transportation Applications - A Survey and TLA+ as sources for references to the above-listed approaches to formal specifications.

    It is to be hoped that a set of theories can be brought about, theories which "unify" pair- or triple-wise combinations of the above and other formal method approaches. We refer to Unifying Theories of Formal Methods - Integrating Formal Methods

  • Analytic Document Parts:

    Analytic document parts arise as the result of analysing descriptive document parts.

    There usually are four kinds of analytic document parts:

    • Domain Concept Formation: As mentioned above, under rough sketches, these latter serve to form concepts. Thus these concepts are the result of analysing rough sketches, and concept formation document parts thus record considerations of these (and other, usually rejected) concepts.

    • Domain Validation: Validation is the R&D process of making sure that the domain model "squares" with the views of the various stake-holdrs of the domain. As such the validation process, ie., the analyses that are, or have taken place, ought also be carefully recorded, ie., documented.

    • Domain Verification: Verification is the R&D process of reasoning over, and between pairs (or more) of specifications. The former reasoning lead to the domain theory formation. The latter usually is needed when a model is developed in stages of increasing specificity.

    • Domain Theory Formation: A main, but not the only main, purpose of a model, is to form the basis for a theory. See previous item.

Theory

When models are formalised, then it is possible to derive properties from the model that are believed to be properties of the domain (being modelled). The set of axioms and inference rules upon which the formal description of the models are based, as well as the possible lemmas, propostions and theorems derived from those axioms and deduction rules, form a theory.

See the last two entries itemised above.

Computing Systems Engineering

Computing systems engineering, to us, is concerned with the development of hardware + software solutions to problems. As such it involves software engineering and hardware engineering and their interplay, usually referred to as co-design. We shall only further characterise software engineering.

• Software Engineering:

  Software engineering, to us, is a convergence, a fusion, between domain engineering, requirements engineering and software design - in the context of computer systems engineering, ie., with due considerations, also, of interfaces to hardware.

• Domain Engineering:

  Domain engineering - in the light of the above, to us - is concerned with the analysis and syntehsis (ie., construction), ie., development of domain models (incl., domain theories) - thus with due respect to all relevant stake-holder groups.

• Requirements Engineering:

  Requirements engineering, to us, is concerned with the development of requirements. At this place in our presentation we shall not mention the relevant issues of requirements acquisition and validation, but focus exclusively on the structure of a (set of) requirements models.

  But first we need a crucial definitions:

  • Machine: A main purpose of computing systems development is to construct a machine. The concept of a `machine' is here seen as the conglomeration of both hardware and software. The hardware may (mostly) already be available, but may be "connected" up with additional, auxiliary equipment, and/or systems software packages. The software is usually, we assume without any loss of generality, to be developed.

  We postulate that there are basically three requirements document parts, either presented, in the model, separately, or intertwined, but in a clearly recognisable fashion:

  • Domain Requirements: The domain requirements are those requirements which can be expressed sôlely with reference to the domain model. That is without any reference to the machine to be constructed.

  • Machine Requirements: The machine requirements are those requirements which can be expressed solely in terms of the hardware and software to be developed. That is without any reference to the domain. Machine requirements come in many froms and shades: Performance requirements, dependability requirements (safety, security, timeliness, accessability, availability, etc.), maintenance requirements (adaption, perfection, correction, prevention), platform requirements (development, execution and maintenance platforms: hardware and pre-existing software), documentation, etc.

    Hence:

  • Interface Requirements: The interface requirements are those requirements which can be expressed in terms of both the domain and the machine - where the and is a logical conjunction: That is, any interface requirements statement crucially depend, in its implications, of "connecting" up what can be said to be shared between the domain and the machine: Those phenomena of the domain which are represented "inside" the machine and for which input to the machine, and/or output from, eg. display of, the machine, is necessary. Hence the term `interface'.

  Wirhnin `Domain Requirements' we can identify a number of principles and techniques that huide us in their construction and expression. We mention some:

  • Projection:

    Usually a domain model consists of very many specfications and covers a large "terrain". For any specific requirements only a fraction of the domain is relevant. Projection is like an algebraic operation which "narrows" the domain model into those parts of relevance to the requirements.

  • Determination:

    Usually a domain behaviour is non-deterministic and so are, therefore, its models. Determination is like an algebraic operation which removes undesired non-determinisms.

  • Extension:

    Sometimes domains do not admit certain kinds of functionalities: They are simply not (humanly or, up to this moment, technologically) feasible. With the advent of computing and communication some such functionalities are now made feasible. Extension is like an algebraic operation which extends, basically the domain - but phrased, usually, within the requirements.

  • Instantiation:

    Normally a domain model generically covers sets of domain instances: Many different railway systems, or may different health-care systems, etc. Instantiation is like an algebraic operation which binds certain loosely specified properties of a generic doman model to specific such properties. Examples could be: (1) A specific set of train despatch rules & regulations - although even these may be left "programmable"; or (2) a specific kind of railway net topology, topologically bound by certain kinds of local practices.

  • Fitting:

    Normally required software is to work together with pre-existing hardware and software sub-systems. And although basically a machine requirements (ie., a platform) issue, we consider fitting like an algebraic operation which concretises certain domain properties in certain directions as biased by the chosen pre-existing hardware and software sub-systems.

  • Initialisation:

    Invariantly the required software, before installation, need be initialised to some basic data, ie., an initial database need be established, or an existing need be migrated. Initialisation binds certain facets of domain configurations to to static, ie., contextual "values", while others are initially set to some dynamically changing initial "values". Initialisation requirements further prescribe how the configuration contexts and states may be kept "up-to-date".

• Software Design:

  By software design we understand the derivation, from requirements, of provably correct software.

  The design process can be structured, for example, as follows:

  • Software Architecture Design:

    Usually a set of requirements models give little hint as to the overall structure of the software design: A computable structure, called the software architecture, must be set up. Depending on machine requirements issues the developer may be forced to consider such issues before domain, or before interface requirements concerns.

  • Component Design:

    By a component we understand a set of modules such that the coherence between the modules in the component set (c) is high, or higher than any other set of modules (c') overlapping with c. Usually a component is determined by either considerations of domain requirements, or considerations of machine requirements, or considerations of interface requirements.

  • &c.

    The "etcetera" covers over such things as module design and code development.