Recognizing Classes and Objects

Before you can go about modeling objects and classes with UML, get familiar with the entities in your system that match the definition of an object or a class:

Object: An object can be any useful item that has identity, structure, and behavior. When an object-oriented software system is running, the items in the system are interacting software objects. When a real-life physical enterprise is in operation, the individual interacting entities in the enterprise system are the business objects.
Class: A class is a family of objects. If several objects have similar structure, behavior, and meaning, then you can group the objects into a class—in effect, a template (or even a factory) you can use to create uniform individual objects. When you develop an object-oriented system, the system is described as being made up of classes—and that’s even true of a real-life enterprise system. Some examples of classes might be the Crash Dummy class, Lease class, Client class, or Owner class. Each class provides a generic scheme for one or more objects, and a class can be a template for many objects or only one.

There is often (and should be) a strong parallel between a software system and its underlying physical enterprise: The system’s software objects should parallel the enterprise’s business objects (actual, tangible things that the software objects represent). Imagine that you are constructing the software for a Rent-A-Crash Dummy business enterprise. As you walk through the enterprise in your mind’s eye, you recognize business objects: a particular Crash Dummy, a specific lease document, and a particular client. All these objects are useful, can be recognized, have structure, and have behavior. A well-designed system shows a parallel between the business and the software; every business object has a software object. There is a software object for each Crash Dummy, each document, and each client.

Even so, some additional software objects are necessary parts of the design and implementation of an object-oriented software system—even though they’re not strictly parallel to the business system. If you were to walk through your software system as a virtual traveler, many of the sights you could point out would be such objects: individual pieces of data such as records, software structures such as queues, working bits of code such as instance variables. These are the construction elements of the object-oriented software world; no less than the business objects, they too have identity, structure, and behavior. When you first start modeling your system, don’t include these design or implementation objects; they get added in later activities.

You can use many techniques to choose your objects and classes. Because your project will be using these objects and classes for a long time to come, thinking a bit about your choices is worthwhile. One of the most common techniques, called Underlining the Nouns (and Words That Relate to Nouns), can help you identify which classes and objects to use. You start by describing the system (or the system’s behavior). Then you examine each noun in the description and consider whether it meets the following criteria:

It’s a thing or family of things
It’s part of a problem to be solved
It’s not part of the implementation details
It’s not an event or occurrence
It’s not a property of a thing

After you underline all the nouns and related words in your system description, you can start weeding out the ones that might make good classes or objects. Table 3-1 can help you sort through these words.

Table 3-1: Sorting the Nouns (And Noun-Related Words)
Type of Noun	Example	It’s Likely to Be a(n)...
A family of things	Person, Crash Dummy	Class
A proper noun (name)	Max	Object
A property of something	Age, Color	Attribute (see the section “Identifying Attributes” later in this chapter)
A value or data	27 years, Red	Attribute’s value
A condition of a thing	Adult, New	State (see Chapter 16)
An occurrence, event, or time	Birthday Party, Telephone Ring	Operation (see the section “Performing Operations” later in this chapter) or event (see Chapter 17)
Part of the implementation	Database, Table, EJB	Leave for design (see Chapter 19)

Set up a list for the nouns that make the cut. Be generous: If you’re not sure whether something is a good candidate, add it to the list anyway. After you identify a noun as an object, look around for the class that this object is an instance of.

Tip Don’t completely discard the nouns that don’t qualify as objects. You’ll find that they may serve as attributes, states, operations, events, and so on—all of which have value later.

As mentioned earlier, the input to this technique is a description of the system or of the system’s behavior. If no description is available, construct your own. Sometimes the description of the system’s behavior is best organized as a set of outside entities, called actors, pursuing their individual goals, called use cases, which are invoked whenever they use the system. You can find actors and use cases covered in Chapter 8.