Introduction
A domain model is the most importantand classicmodel in OO analysis .[1] It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case studies. This chapter also shows the value of OOA/D knowledge over UML notation; the basic notation is trivial, but there are subtle modeling guidelines for a useful modelexpertise can take weeks or months. This chapter explores basic skills in creating domain models.
[1] Use cases are an important requirements analysis artifact, but are not object -oriented. They emphasize an activity view.
more advanced domain modeling p. 507 [View full size image]As with all things in an agile modeling and UP spirit, a domain model is optional. UP artifact influence emphasizing a domain model is shown in Figure 9.1. Bounded by the use case scenarios under development for the current iteration, the domain model can be evolved to show related noteworthy concepts. The related use case concepts and insight of experts will be input to its creation. The model can in turn influence operation contracts, a glossary, and the Design Model, especially the software objects in the domain layer of the Design Model.
Figure 9.1. Sample UP artifact influence.
domain layer p. 136