DOMAINS MODELS
By a domain description we mean a document, or a set of documents which describe a domain as it is, with no references to, i.e., with no implicit requirements to, software. The informal language part of a domain description is such that a stakeholder of that domain recognizes that it is a faithful description of the domain. So, a domain description describes something real, something existing. Usually a domain description describes not just a specific instance of a domain, but a set of such, not just one bank but a set of “all” banks!
By a domain description we mean any text that clearly designates an phenomena, an entity, or a function (which when applied to some entities become an action), or an event, or a behaviour (i.e., a sequence of actions and events) of the domain, or a concept defined, i.e., abstracted from other domain descriptions. Domain descriptions are indicative. Domain descriptions described what there is, the domain as it is, not as the stakeholder would like it to be.
Informal and Formal Domain Descriptions
Domain descriptions come in four, mutually supportive forms, three informal texts and one formal:
Rough sketches are informal, incomplete and perhaps not very well structured descriptions;
Terminologies — explaining all terms: names of phenomena or concepts of the domain;
Narratives —“tell the story”, in careful national/natural and professional language; and
Formal specification — formalising in mathematics the narrative and provides the ultimate answer to questions of interpretation of the informal texts.
Initial descriptions necessarily are rough sketches. They help us structure our thinking and generate entries for the terminology. Terminologies, narratives and formalisations are deliverables.
Domain Stakeholders
All relevant stakeholders must be identified. For, say a railway domain, typical stakeholder groups are: the owners of a railway; the executive, strategic, tactical and operational management — that is several groups; the railway (“blue collar”) workers — station staff, train staff, line staff, maintenance staff, etc.; potential and actual passengers and relatives of these; suppliers of goods and services to the railway; railway regulatory authorities; the ministry of transport; and politicians “at large”. Liaison with representatives of these stakeholder groups must be regular — as some, later, become requirements stakeholders.
Domain Acquisition
The domain engineer need acquire information (“knowledge”) about the domain. This should be done pursuing many different approaches. The two most important seems to be:
reading literature, books, pamphlets, Internet information, about the domain, and
(ii) eliciting hopefully commensurate information from stakeholders. From the former the domain engineer is (hopefully) able to formulate a reasonable questionnaire. Elicitation is then based on distributing and the domain engineers personally “negotiating” the questionnaire with all relevant stakeholders. The result of the latter is a set of possibly thousands of domain description units.
Domain Analysis
The domain description units are then subjected to an analysis. First they must be annotated with attribute designators,
ontological such as entity, function, event, behaviour;
facets such as intrinsics, support technology, management & organisation, rules & regulation, script, human behaviour;
Administrative such as source of information, date, time, locations, who acquired, etc.: etcetera.
Problems:
Analysis of the description units involve looking for and resolving incompleteness, inconsistency and conflicts.
Concepts
Analysis of the description units primarily aims at discovering concepts, that is, notions that generalise a class of phenomena, and for discovering metaconcepts, that is “high level” abstractions that together might help develop as generic and hence, it is believed, applicable, reusable domain model as possible.
Domain Modelling Proper
Domain modelling is then based on the most likely database-handled domain description units. The domain model, that is, the meaning of the domain description must capture:
intrinsics: that which is at the basis of, or common to all facets,
technologies which support phenomena of the domain,
management & organisation: who does what, who reports to whom, etc.,
rules & regulations — governing human behaviour and use of technologies —
sometimes manifested in scripts, and (vi) human behaviour — diligent, sloppy, delinquent or outright criminal. It must all be described!
Domain Verification
Verification — only feasible when a formal description is available — proves properties of the domain model not explicitly expressed, and serves to ensure that we got the model right.
Domain Validation
Validation is the human process of “clearing” with all relevant stakeholders
that we got the right model.
Discussion
Thus domain engineering is a highly professional discipline. It requires many talents: interacting with stakeholders, ability to write beautifully and concisely, ability to formalise and analyse formal specifications, etc. Domain engineers are also researchers: physicists of human made universes.
REFERENCE: Dines Bjørner, DOMAIN ENGINEERING, Technology Management, Research and Engineering, February 16, 2009