5.1 Classes

We base the abstractions on the conceptual entities in a domain. An online bookstore, for example, will process many shipments to send orders to customers.

We abstract these shipments into the class Shipment, as shown in Figure 5.1.

Figure 5.1. Instances and Classes

Definition: A class is an abstraction from a set of conceptual entities in a domain so that all the conceptual entities in the set have the same characteristics, and they all are subject to and behave according to the same rules and policies.

Put another way, a class abstracts common characteristics and common behavior.

5.1.1 Finding Classes

Start out by asking yourself, "What are the conceptual entities^[1] in this domain?" Most of the concepts are likely to fall into the following five categories: tangible things, roles, incidents, interactions, and specifications. These categories aren't offered as a classification system but as a set of starter ideas for finding classes in a new domain.^[2]

^[1] More colloquially, we might say "thing" instead of "conceptual entity." However, as we shall see, conceptual entities need not be tangible: Indeed, the BookProduct abstraction captures not a physical book, but a kind of book, as in "Do you have a copy of Executable UML?"

^[2] This classifcation scheme, and much of the text describing it, was first proposed in [1].

Tangible things.

These are the easiest to find. Given the appropriate domain, it's hard to miss:

Airplane	Pipe Support	Magnet	Book
Nuclear Reactor	Racehorse	National Landmark	Dog
Circuit Breaker	Power Supply	Vehicle	Car

Underlining the nouns in a requirements document or in the use cases sometimes helps find the simple tangible things, but this technique has a tendency to stifle the abstraction process; also, it does not help identify the more interesting and valuable kinds of classes described below.

Roles played by people or organizations.

This category is described by examples:

Doctor	Shipping Clerk	Client	Department
Patient	Tenant	Employee	Taxpayer
Customer	Account Holder	Supervisor	Trustee

Frequently, if you have one role, you will have others also. This comes about when distinguishing between different roles played by the same or different people; hence, one would expect to find Customer, Shipping Clerk, and Salesperson in a model of a bookstore. By creating separate classes, we allow for a Shipping Clerk also to be a Customer, with the characteristics and behavior of a Customer classified separately from that of a Shipping Clerk. Strong models make heavy use of role classes.

The alternative is to model the tangible thing Person, and then to constrain its behavior in a variety of difficult-to-check ways so as to distinguish among the cases. (Can a Shipping Clerk ship a book to a Customer? What if they are the same person? This is not just an academic question: Many systems prohibit a Payroll Clerk from approving his own paycheck.)

Combining multiple roles into a single class does not "save classes." It just makes a lot of extra work during state modeling.

Incidents.

Incidents represent an occurrence or event: something that happens at a specific time. Some reasonable incidents are:

Flight	Accident
Performance (of a play, for example)	Event (in a physics experiment)
System Crash	Service Call (appliance repair)

Abstract an incident to capture data about it, such as the departure time of a flight. Classes abstracted from incidents often have behavior: The flight is scheduled to occur at some time; at some time, a plane is available; the flight departs at some time and eventually lands. We will model this lifecycle behavior with a statechart diagram.

Interactions.

Interactions generally have a "transaction" or "contract" quality, and relate to two or more other classes in the model. Examples are:

Purchase (relating buyer, seller, and thing purchased)

Credit Card Charge (relating an account and a purchase)

Arc (relating two nodes in a graph)

Interaction classes may also come up when modeling geometrical or topological systems: an electrical network, the piping in a refinery, or the trackwork of a railroad.

Specifications.

Specification classes are used when a set of things all share certain characteristics.

For example, you and your colleague may have a copy of "the same book." The title of the two physical books are the same that's what it means to be "the same" but the books are themselves different ("This one's mine, that one's yours."). Examples are:

Insurance Policy Product, which specifies policy types you can buy

Book Product, which specifies the book you can buy

Credit Card Type, which specifies the brand of credit card used on a charge

When you have a specification class, you generally also have another related class that represents instances of things that meet the specifications. For example, your insurance policy has attributes that capture premiums paid, amount paid out, and so on, while the insurance product captures the deductible that applies to all insurance policies, yours included, that conform to this insurance product.

These "actual classes" need not represent something tangible: They could represent roles or incidents. See Figure 5.2 for examples.

Figure 5.2. Specification Classes and Actual Classes

To avoid confusion between the name of the specification class and the related class, write class descriptions (see Section 5.4.2: Class Descriptions) to define each of the names properly.

5.1.2 Naming Classes

A good choice of names for the classes will contribute significantly to the clarity of the model. Strive for names that are clear, direct, and honest. As in real life, this is not always easy.

We prefer to name a class in the model with the common name used for a typical thing in the domain. Unfortunately, this often turns out to be difficult. Unless the organization involved has been through a terminology formalization process in the recent past, one is likely to find that a single common name refers to two or more different things, and two or more common names refer to the same thing.

Although this can be confusing for the unfortunate developer, it leads to less confusion in the organization than one might expect, as most terminology references take place in ordinary conversation, which supplies context for each reference. Terminology references are exchanged among application experts people who have large amounts of special knowledge in and context for the subject at hand.

People are extremely adept at using context information to establish meaning. When it becomes necessary to transfer the special application knowledge to experts in a different area (to us developers, for example), imprecise context-dependent terminology frequently causes confusion and misunderstanding. It is critical, therefore, to formalize that knowledge, selecting clear and unambiguous names and representing that knowledge in our model.

A class diagram, acting in Executable UML as a semantic information model, can be dramatically helpful in exposing and resolving these problems. For this reason, it is useful to regard the class diagram as a dictionary in which each name has only one meaning. Against this background, we offer the following suggestions in naming classes.

Common names.

Use common names where these are, or can be made to be, well-defined. For example, Signaling Unit is OK, but Traffic Light is better. On the other hand, if a traffic light is just one of several ways of signaling, all of which have the same behavior, Signaling Unit could be acceptable. As another example, Part Transporter is OK, but Conveyor Belt is better.

When there is confusion in common names for the layperson, use industry-standard names.

Should both these strategies fail, use a made-up name. Sometimes your work will identify an abstraction for which no common name exists.

Strong names.

Use strong, everyday words with extended meanings in preference to vague, unnecessarily technical, or esoteric terms. For example, the concept described as "a room, closet, or defined warehouse area used to store…" could be named as a Storage Environment, but Room would be better. Similarly, the concept "a cupboard, refrigerator, set of open shelves, or freezer used to store…" could be named a Storage Location, but Cabinet would be better because the term is both strong and common.

Precise names.

Append adjectives to common short names to make names more precise. The name Storeroom describes "a room, closet, or defined warehouse area used to store…" more precisely than Room.

Same dimension names.

Use names that contrast in the same dimension. The pair of names High Voltage Power Supply and Continuous Power Supply can be confusing because it raises the question, "Is a High Voltage Power Supply pulsed and high voltage? Or is the Continuous Power Supply necessarily low voltage?" If the fundamental difference between the two is that one power supply is pulsed and the other is continuous, then it is better to use names that make that distinction: pulsed vs. continuous.

Names based on essential nature.

Use made-up names, even if they are lengthy, if they capture the essential character of the abstraction better than more customary, but less precise terms. For example, this concept:

A piece of territory, not necessarily contiguous that is defined by the intersection of all election districts. As a consequence of the mechanism by which a territory is defined, all voters residing in the territory receive identical ballots for any particular election.

is commonly known as a Precinct or Precinct-Split, but the essence of the concept is better captured in the name Smallest Territorial Unit. (It is the smallest because the intersection of all districts is necessarily indivisible.)

Content-based names.

Name the class by its information content, not by the form or document commonly used to carry information. Hence, a person legally entitled to operate a motor vehicle shouldn't be named Driver's License. The content is better captured by the name Licensed Driver. Note that the class name "Driver's License" might be appropriate if the concept we're naming were "a little piece of paper, about 2.25 by 3.25 inches, bearing an identifying number…".

Avoid abused words.

And finally, avoid "abused words" in naming your classes words that have many meanings or great context dependence. Everyone knows what they mean, but no one seems to agree in any given situation. Exactly what constitutes an abused word depends a great deal on the audience for your model, but the following are classic examples: person, user, account, order, task, form, operation, schedule, part, and assembly.