|
|
The first thing you need to do in building a static model of your system is to find appropriate classes that accurately represent the real abstractions that the problem domain presents. If you execute this activity well, you will have not only a solid foundation on which to build the system but also excellent prospects for reuse by systems that will be designed and built down the line.
The best sources of domain classes are likely to be the high-level problem statement, lower-level requirements, and expert knowledge of the problem space. To get started on the road to discovery, lay out as many relevant statements from these sources (and others, such as marketing literature) as you can find, and then circle or highlight all the nouns and noun phrases. Chances are that you will find a large majority of the important domain objects (classes) this way.
After refining the lists as work progresses, this is what tends to happen:
Nouns and noun phrases become objects and attributes.
Verbs and verb phrases become operations and associations.
Possessive phrases indicate that nouns should be attributes rather than objects.
The next step is to sift through your list of candidate classes and eliminate the items that are unnecessary (because they're redundant or irrelevant) or incorrect (because they're too vague, they represent things or concepts outside the scope of the model, or they represent actions even though they're phrased as nouns).
While you're building your class diagram(s), you can also make some initial decisions about generalization ("kind of" or "is a" relationships among classes). If you need to, and if you're comfortable doing so at this stage of your project, you can generalize to more than one level of subclass. Remember to look for "kind of" statements that are true in the real world. Domain modeling is also the appropriate area for decisions about aggregations ("part of" or "has" relationships) among classes.
Finally, much like an entity-relationship diagram (ERD), our domain model, updated to show associations-the static relationships between pairs of classes-should be a true statement about the problem space, independent of time (that is, static). This model serves as the foundation of our static class model.
We recommend that you establish a time budget for building your initial domain model. You're not going to make it perfect, anyway, so do it quickly and expect to fix it up as you proceed. You should be vigilant about making necessary adjustments to your analysis-level class model in response to occurrences during robustness analysis and throughout the project.
|
|