|
|
Thus far, we've been focused on the static structure of the problem being modeled—the floor plan for our custom home, as it were. As we learned in Chapter 10, this static structure is communicated via a class diagram plus supporting documentation. The building blocks of a class diagram are
Classes.
Associations/aggregations.
Attributes.
Generalization/specialization hierarchies (also known as inheritance relationships).
Operations/methods. These are conspicuously absent from our class diagram. Why? Because they aren't part of the static structure, so we haven't discussed how to determine these yet; this will be the focus of this chapter.
As we've said many times already, an OO software system is a set of collaborating objects, each with a "life" of its own. If each object went about its own business without regard to what any other object needed it to do, however, utter chaos would reign! The only way that objects can collaborate to perform some overall system mission, such as registering a student for a course, is if each class defines the appropriate methods—services—that will enable its instances to fulfill their respective roles in the collaboration.
In order to determine what these methods/services must be, we must complement our knowledge of the static structure of the system to be built by also modeling the dynamic aspects of the situation: that is, the ways in which concurrently active objects interact over time, and how these interactions affect each object's state. Producing a dynamic model to complement the static model will not only enable us to determine the methods required for each class, but also give us new insights into ways to improve upon the static structure.
In this chapter, you'll learn about the building blocks of a dynamic model:
Events
Scenarios
Sequence diagrams
Collaboration diagrams
and how to use the knowledge gleaned from these to identify the operations/ methods that are needed to complete our class diagram.
|
|