Our object model has started to take shape! We have a good idea of what the static structure needs to be for the SRS—the classes, and their attributes and relationships with one another—and are able to communicate this knowledge in a concise, graphical form. There are many more embellishments to the UML notation that we haven't covered in this chapter, but we've presented the core concepts that will suffice for most "industrial-strength" modeling projects. Once you've mastered these, you can explore the Recommended Reading section in Chapter 17 of the book if you'd like to learn more about these notations.
There is an obvious "hole" in our class diagram, however: all of our classes have empty operations compartments. We'll address this deficiency by learning some complementary modeling techniques for determining the dynamic behavior of our intended system in Chapter 11.
In this chapter, you've learned
The noun phrase analysis technique for identifying candidate domain classes
The verb phrase analysis technique for determining potential relationships among these classes
That coming up with candidate classes is a bit subjective, and hence that we have to remain flexible, and willing to revisit our model, through many iterations until we—and our users—are satisfied with the outcome
The importance of producing a data dictionary as part of a project's documentation set
How to graphically portray the static structure of our model as a class diagram using UML
How important it is to have an experienced object modeling mentor available to a project team