|
|
Having employed use case analysis techniques in Chapter 9 to round out the Student Registration System (SRS) requirements specification, we're ready to tackle the next stage of modeling, which is determining how we're going to meet those requirements in an object-oriented fashion.
We saw in Part One of the book that objects form the building blocks of an OO system, and that classes are the templates used to define and instantiate objects. An OO model, then, must specify the following:
What types of objects we're going to need to create and instantiate in order to represent the proper abstraction: In particular, their attributes, methods, and structural relationships with one another. Because these elements of an object-oriented system, once established, are fairly static— in the same way that a house, once built, has a specific layout, a given number of rooms, a particular roofline, and so forth—we often refer to this process as preparing the static model.
We can certainly change the static structure of a house over time by undertaking remodeling projects, just as we can change the static structure of an OO software system as new requirements emerge by deriving new subclasses, inventing new methods for existing classes, and so forth. However, if a structure—whether a home or a software system—is properly designed from the outset, then the need for such changes should arise relatively infrequently over its lifetime and shouldn't be overly difficult to accommodate.
How these objects will need to collaborate in carrying out the overall requirements, or "mission," of the system: The ways in which objects interact can change literally from one moment to the next based upon the circumstances that are in effect. One moment, a Course object may be registering a Student object, and the next, it might be responding to a query by a Professor object as to the current student headcount. We refer to the process of detailing object collaborations as preparing the dynamic model. Think of this as all of the different day-to-day activities that go on in a home: same structure, different functions.
The static and dynamic models are simply two different sides of the same coin: they jointly comprise the object-oriented "blueprint" that we'll work from in implementing an object-oriented Student Registration System application in Part Three of the book.
In this chapter, we'll focus on building the static model for the SRS, leaving a discussion of the dynamic model for Chapter 11. You'll learn
A technique for identifying the appropriate classes and their attributes
How to determine the structural relationships that exist among these classes
How to graphically portray this information as a class diagram using the Unified Modeling Language (UML) notation
|
|