Difference between revisions of "Domain Analysis Model"
Rene spronk (talk | contribs) |
m |
||
| (One intermediate revision by the same user not shown) | |||
| Line 2: | Line 2: | ||
of interest, complete enough to allow instantiation of all necessary | of interest, complete enough to allow instantiation of all necessary | ||
concrete classes needed to develop child design artifacts." | concrete classes needed to develop child design artifacts." | ||
| − | + | NOTE: This definition has been replaced by the HL7 Specification: Domain Analysis Model Specifications and Requirements - Canonical Definition, Release 1 | |
| + | this page is kept for historical usage. | ||
| + | #see also [[Domain_Analysis_Model_ArB | Domain analysis model ARB]] | ||
#First, a DAM should represent the semantics-of-interest in terms that are understandable to domain experts, even though this may mean that 'not everyone gets to see their particular words represented,' i.e. they should, however, see the familiar concepts and relationships that describe the domain-of-interest in terms that are easily translatable to their favorite terms. | #First, a DAM should represent the semantics-of-interest in terms that are understandable to domain experts, even though this may mean that 'not everyone gets to see their particular words represented,' i.e. they should, however, see the familiar concepts and relationships that describe the domain-of-interest in terms that are easily translatable to their favorite terms. | ||
#Second, a DAM must be semantically robust enough to support the development of down-stream design artifacts. Note that, depending on the degree of rigor applied to the term 'analysis,' a DAM may or may not be bound to formal data types and may or may not be formally/computationally traceable to one or more design artifacts. | #Second, a DAM must be semantically robust enough to support the development of down-stream design artifacts. Note that, depending on the degree of rigor applied to the term 'analysis,' a DAM may or may not be bound to formal data types and may or may not be formally/computationally traceable to one or more design artifacts. | ||
Latest revision as of 17:46, 17 August 2016
Definition: A Domain Analysis Model is an abstract representation of a subject area of interest, complete enough to allow instantiation of all necessary concrete classes needed to develop child design artifacts."
NOTE: This definition has been replaced by the HL7 Specification: Domain Analysis Model Specifications and Requirements - Canonical Definition, Release 1 this page is kept for historical usage.
- see also Domain analysis model ARB
- First, a DAM should represent the semantics-of-interest in terms that are understandable to domain experts, even though this may mean that 'not everyone gets to see their particular words represented,' i.e. they should, however, see the familiar concepts and relationships that describe the domain-of-interest in terms that are easily translatable to their favorite terms.
- Second, a DAM must be semantically robust enough to support the development of down-stream design artifacts. Note that, depending on the degree of rigor applied to the term 'analysis,' a DAM may or may not be bound to formal data types and may or may not be formally/computationally traceable to one or more design artifacts.
Details
DAMs do give you an 'everyman' view of the domain. That's exactly their purpose, i.e. to be vettable by domain experts who know nothing of RIMs, DMIMs, RMIMs, XML, Java, etc. Every message specification should include BOTH the logical design specification AND the technology-specific specification (either V2 or V3). Only this way can you have a specification that everyone can understand. This draws a clear distinction between the Logical Design Model (aka DAM) and the Logical Design Specification, which does not have a recognised name in HL7 HDF.
If we were going to include a 'DAM,' we should include a complete DAM in the sense of both static (class and instance diagrams) and dynamic (activity and occasional state diagrams) semantics PLUS the Glossary that binds the two elements together. Someone looking at a particular RMIM or Interaction who didn't understand RIM-speak should be able to find the corresponding semantics expressed in domain-speak in the diagrams.
The type of diagram does not de novo determine the semantic content. Activity Diagrams can be used at multiple levels of abstraction, as well as on either side of the 'analysis.design' fence, i.e. an AD can very effectively describe a high-level business process in domain-speak and the same diagram type (but not the same diagram) can be used to describe a low-level (even machine level) algorithm.
A DAM has two basic uses: it reflects 'outward' to the community of SMEs who can vet it as representative of their domain's static and dynamic semantics; and it reflects 'inward' as a formal statement of implementation-independent semantics which an implementation tries (always imperfectly) to implement, thereby becoming a negotiation tool for developers and domain experts around the exact implications of the inevitable implementation-specific compromises. For HL7, the design level artifacts (i.e. RMIMs et al) should capture the relevant domain semantics exactly, the compromises occurring at the interface between design and implementation, e.g. XML ITS.
- Business Analysts have a set of tools which they can apply to almost any situation. They are NOT domain experts, at least when they start to look at a problem. Business analysts are facilitators.
- Domain Experts are End-users who are being consulted by a Business Analyst. The Domain Experts have a primary responsibility to explain the domain to business analysts. The Domain expert has to own and sign off the deliverable (the logical design specification).
- Any End User who is interested should be able to understand a logical design specification with help from either a Domain Expert or a Business Analyst.
