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:
The most important characteristics that classes share are captured as attributes and operations. These terms are defined as follows:
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.
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).
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” nota tions in a given context.
Figure 1-3 shows some examples of 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:
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.
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:
Figure 1-5 shows the notation for both a named object (left) and an anonymous object (right).
Classes appear primarily on class diagrams; objects appear primarily on object diagrams. Chapter 3 describes both of these diagrams.
blog comments powered by Disqus