Chapter 10. Modeling the Static/Data Aspects of the System

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 can meet those requirements in an object-oriented (OO) fashion. It's important when undertaking any code development project to spend time analyzing and designing the application before starting to write the actual code—and that's what we'll do with the SRS in this chapter. Writing code without proper planning is like driving somewhere new without looking at a map or using a GPS. You might get where you want to go, but not without a lot of wrong turns and backtracking.

You saw in Part One of the book that objects form the building blocks of an OO system, and classes are the templates used to define and instantiate objects. An OO model, then, must specify the following:

• What types of objects we'll need to define and instantiate in order to represent the proper abstraction. In particular, the fields, properties, and methods the classes will declare; and their structural relationships with one another. Because these elements of an OO 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, 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 might be registering a Student object, and the next, it might be responding to a query by a Professor object as to the current student head count. 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 OO "blueprint" that we'll work from in implementing an OO SRS 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 the following:

• A technique for identifying the appropriate classes and their fields

• How to determine the structural relationships that exist among these classes

• How to graphically portray this information as a class diagram using Unified Modeling Language (UML) notation