This wiki has undergone a migration to Confluence found Here
Domain Analysis Model ArB
Jump to navigation
Jump to search
Working 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. A complete DAM contains -at least- a static model (class and instance diagrams) and a dynamic model (activity and occasional state diagrams) semantics PLUS the Glossary that binds the two elements together."
- 1. 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.
- 2. 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.
Commentary
- The first sentence sounds a bit "abstract"(confusing) right from the get-go and techno-babbelly (is that a word?). It also never really says what it is, but introduces the notion of classes before informing that it is an object model. Perhaps something like: "A Domain Analysis Model is an object model that represents a subject area of interest. The complete DAM contains minimally a static model and a dynamic model, and the glossary that binds these elements together. The DAM is complete enough the allow complete development of child design artifacts."
- We should also capture the fact that it is not necessarily RIM-aligned, and that it may represent information in a logical way that differs from how the data will be organized in the design model. Finally, the definition should capture the purpose - capturing requirements and data relationships in a manner that is clear to business users and that can be used when constructing the formal design data models.
