Chapter 1: Classes | Fast Track UML 2.0

Let's begin our look at the details of the Unified Modeling Language (UML) by exploring how we do basic modeling of things and concepts in the real world.

Classes and Objects

A class is a collection of things or concepts that have the same characteristics. Each of these things or concepts is called an object.

An object that belongs to a particular class is often referred to as an instance of that class. You can think of a class as being an abstraction and an object as being the concrete manifestation of that abstraction.

The class is the most fundamental construct within the UML. Reasons why this is so include the following:

Classes define the basic vocabulary of the system being modeled . Using a set of classes as the core glossary of a project tends to greatly facilitate understanding and agreement about the meanings of terms.
Classes can serve as the foundation for data modeling. Unfortunately, there is no standard for mapping between a set of classes and a set of database tables, but people like Scott Ambler ^[1] are working to change that.
Classes are usually the base from which visual modeling tools ‚ such as Rational Rose XDE, Embarcadero Describe, and Sparx Systems' Enterprise Architect ‚ generate code.

The most important characteristics that classes share are captured as attributes and operations. These terms are defined as follows :

Attributes are named slots for data values that belong to the class. Different objects of a given class typically have at least some differences in the values of their attributes.
Operations represent services that an object can request to affect behavior. (A method is an implementation of an operation; each operation of a given class is represented by at least one method within each of the objects belonging to that class.)

The standard UML notation for a class is a box with three compartments. The top compartment contains the name of the class, in boldface type; the middle compartment contains the attributes that belong to the class; and the bottom compartment contains the class's operations. See Figure 1-1.

Figure 1-1: Class notation

You can, however, show a class without its attributes or its operations, or the name of the class can appear by itself (see Figure 1-2).

Figure 1-2: Alternate class notations

The level of detail you choose to show for your classes depends on who is reading the diagrams on which they appear. For example, a stakeholder who's focused on the "big picture" is probably interested only in the names of the classes, while a developer working at a more detailed level probably wants to see a full set of attributes and operations. You can also "mix and match" notations in a given context.

Figure 1-3 shows some examples of classes.

Figure 1-3: Sample classes

The names of the classes, attributes, and operations in Figure 1-3 adhere to conventions that aren't carved in stone but are in fairly wide use. These conventions are as follows:

Class names are simple nouns or noun phrases. Each word is capitalized.
Attribute names are also simple nouns or noun phrases. The first word is not capitalized, but subsequent words are. Acronyms tend to appear in all uppercase letters .
Operation names are simple verbs. As with attributes, the first word is not capitalized and subsequent words are; acronyms tend to appear in all uppercase letters here as well.

Note that all words in class, attribute, and operation names are generally run together, as shown in Figure 1-3.

Whether you choose these simple conventions ‚ or more elaborate ones ‚ the naming of classes, attributes, and operations should be consistent with the language or platform that you're using or with your company-specific coding standards.

Note ‚

The title attribute of the Book class has an associated data type (String), whereas the other three attributes in the figure ( emailAddress , ID , and password ) don't have types. Note also that each of the three operations ( verifyPassword , assignRating , and computeAvgRating ) has a different appearance. There are various kinds of details that you can attach to attributes and operations. These are explored in the section "Attribute and Operation Details," later in this chapter.

It's often desirable to define explicit responsibilities for a class. These represent the obligations that one class has with regard to other classes. Figure 1-4 shows how you can use an extra compartment within a UML class box to indicate responsibilities for a class.

Figure 1-4: Class responsibilities

The idea of assigning responsibilities to classes is at the center of Class-Responsibility-Collaboration (CRC) cards. ^[2] This idea is also central to Responsibility-Driven Design. ^[3]

As development proceeds, responsibilities tend to get explicitly addressed by operations as classes get refined. So, you shouldn't be surprised if you don't see the responsibility compartment in later versions of models that include class boxes.

Note ‚

You can also extend a class box with other compartments that contain whatever information you want to see. You find examples of these other compartments later in the book.

The notation for an object takes the same basic form as that for a class. There are three differences between the notations, as follows:

Within the top compartment of the class box, the name of the class to which the object belongs appears after a colon. The object may have a name, which appears before the colon, or it may be anonymous, in which case nothing appears before the colon .
The contents of the top compartment are underlined for an object.
Each attribute defined for the given class has a specific value for each object that belongs to that class.

Figure 1-5 shows the notation for both a named object (left) and an anonymous object (right).

Figure 1-5: UML object notation

Classes appear primarily on class diagrams; objects appear primarily on object diagrams. Chapter 3 describes both of these diagrams.

^[1] Scott Ambler, Agile Database Techniques: Effective Strategies for the Agile Software Developer (New York, NY: John Wiley & Sons, 2003).

^[2] David Bellin and Susan Suchman Simone, The CRC Card Book (Boston, MA: Addison-Wesley, 1997).

^[3] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software (Englewood Cliffs, NJ: Prentice-Hall, 1990).