Classes are represented by compartmentalized rectangles. The first compartment contains the class name. The class name must facilitate the understanding of what the class is, not what it does. A class is not a function; a class is an abstract — condensed — description of a set of objects from the application domain. The two other compartments contain respectively the class's attributes and its operations.
A class always contains at least its name. When a name has not yet been found, or is not yet selected, it is recommended to show a generic name that is easy to identify, such as To_Be_Defined. Class compartments may be suppressed when their content is not relevant within the context of a diagram. Compartment suppression is purely visual; it does not mean that there are no attributes or operations.
The rectangle that acts as a symbol for the class may also contain a stereotype and properties. UML defines the following class stereotypes:
| Stereotype | Definition |
| «signal» | A notable event that triggers a transaction within a state machine. |
| «interface» | A description of visible operations. |
| «metaclass» | The class of a class, as in Smalltalk |
| «utility» | A class reduced to the concept of module and which cannot be instantiated |
Properties refer to all the values attached to a model element, such as attributes, associations, and tagged values. A tagged value is a (name, value) pair defined by the user; it allows, for example, the specification of code generation, identification, or cross-referencing information.
Attributes and operations may be shown exhaustively or non-exhaustively within class compartments. By convention, the first compartment contains the attributes and the second compartment contains the operations.
The syntax used for describing attributes takes the form:
Attribute_Name : Attribute_Type = Initial_ValueThis description can be completed gradually during the transition from analysis to design.
Redundant properties may be specified during the requirements analysis phase. Derived attributes offer a solution for allocating properties to classes, while clearly indicating that these properties are derived from other properties that have already been allocated. In the following example, the Rectangle class has a Length attribute, a Width attribute, and a derived attribute Area that may be built from the other two attributes.
Later on, during design, the derived attribute /Area will be transformed into an operation Area() that will encapsulate the computation of the area. This transformation may, however, be performed without waiting, as soon as the derived nature of the area property has been detected.
The syntax used for the description of operations takes the form:
Operation_Name (Argument_Name : Argument_Type = Default_Value,...)
: Return_TypeHowever, given the length of the specification, the operation arguments may be suppressed in graphical representations.
UML defines three visibility levels for attributes and operations:
public — the element is visible to all the clients of the classprotected — the element is visible to subclasses of the classprivate — the element is visible only to the class
Visibility information does not always appear explicitly in class diagrams, but that does not mean that visibility is not defined within the model. The visibility level is represented symbolically by the characters +, # and -, which correspond respectively to the levels public, protected and private.
Some attributes and operations may be visible globally, in the entire lexical scope of the class. These elements, also called class variables and class operations, are represented like objects, with an underlined name. This notation is sensible, since a class variable looks like an object shared by the instances of a class. By extension, class operations are also underlined.
An interface uses a type to describe the visible behavior of a class, a component (described later in the book), or a package. An interface is a stereotype of a type. UML represents interfaces using small circles connected with a line to the element that supplies the services described by the interface.
Interfaces may also be represented using stereotyped classes; the circle-and-line notation (often called a 'lollipop') is simply an equivalent, alternative notation.
An interface provides a total or partial view of a set of services provided by one or more elements. The dependents of an interface use all or some of the services described in the interface.
Template classes are models of classes. They correspond to the generic classes of Eiffel, and to the templates of C++. A template class cannot be used as is. It is first necessary to instantiate it, in order to obtain a real class that must in turn be instantiated to produce objects. During instantiation, actual parameters customize the real class based on the template class. Template classes facilitate the construction of universal collections, typed by parameters.
This type of class does not generally appear during analysis, except in the particular case of development environment modeling. Template classes are most often used in detailed design, to incorporate reusable components, for example. The following figure represents the instantiation of a generic table in order to implement a directory of people. Before instantiation, the formal parameter appears in the dotted rectangle of the template class, while afterwards the actual parameter is joined to the name of class obtained by instantiation. A dotted arrow is drawn from the instance to the template class.
It is sometimes useful to group elements (e.g. the functions of a mathematical library) within a module, without intending to build a complete class. The utility class makes it possible to represent such modules and to manipulate them graphically in much the same way as conventional classes.
Utility classes cannot be instantiated, as they are not data types. They must not, however, be confused with abstract classes, which cannot be instantiated because they are purely specifications (see the section that deals with generalization later in the chapter). In C++, a utility class corresponds to a class that contains only static members (functions and data).
The stereotype «utility» specializes classes as utility classes.
