Class Diagrams
Class diagrams show different objects within a system and how these objects associate with each other. In part, the diagram does this by showing the attributes and operations of each class within the system, and defining the constraints placed on these classes. The basic notation to show a class is a rectangular box containing the classname. However, you can add more information to the box, as you will see.
Note that the UML notation for class diagrams is extensive, so this appendix only shows you the most commonly used elements of the notation. Specifically, you will learn about five main types of notation:
Associations
If you want to show that an instance of a class has a relationship with an instance of another class, you join the two classes with a line, known as an association. Each end of the line is known as a role. You can further define the classes' relationships through the use of multiplicity and navigability. Multiplicity show how many objects can participate in a given relationship. For example, in Figure A.5, one customer (shown as 1) can have between zero and infinite policies (shown as *).
Figure A.5. An association.
There are four possible values for illustrating multiplicity:
Navigability shows the responsibilities of classes. The arrow head points to the class that is not responsible in the relationship. For example, the Policy must say which Customer it belongs to in Figure A.5, but the Customer does not have to say which Policy instances it has. In this example, the responsibility is unidirectional, but in some situations, both parties might hold responsibilities. In these instances, you mark both roles with an arrow head; this is known as bidirectional association.
Attributes
Attributes have different meanings, depending on the level at which you are modelling. At a conceptual level, an attribute simply defines that a class has a certain feature, such as the Vehicle class having a license number. At the specification level, an attribute indicates that a Vehicle object has a way of setting the value of its license, and that it also can provide you with the value of that license. Finally, at the implementation level, an attribute indicates that a Vehicle has a field for the license.
Figure A.6 simply shows the name of the attributes, but it could show more detail. The UML defines the following, which you can use to define an attribute:
visibility name: type = defaultValue
Figure A.6. Attribute notation.
The visibility of the attribute can be either
Public—Precede the name with a + (plus)
Protected—Precede the name with a # (hash)
Private—Precede the name with a – (minus)
The name, type, and default values represent the attribute's name, type (for example, String), and default value (for example, "unregistered"). In some instances, you might want to show the multiplicity of an attribute, possibly to show whether the system requires it. To do this, place the multiplicity value (any one of those shown in the previous section) in square brackets after the attribute name, as shown in the following:
# licence[1]: String = "unregistered"
Operations
Operations are the processes that a class performs and, again, this can have different meanings at different levels. At the conceptual level, operations illustrate the responsibilities of a class. At a specification level, they should correspond to methods with public visibility. Finally, at the implementation level, they can correspond to methods with any degree of visibility. Figure A.7 illustrates that you show operations in the lower section of the box that represents the class.
Figure A.7. Operations notation.
You can provide quite a lot of information about the operation within the box. To do this, use whichever parts of the UML syntax you require:
visbility name(parameter list): return-type-expression { property-strings }
As you can see, the syntax is similar to that used to show an attribute, but with a few notable exceptions. The return-type-expression indicates a comma-separated list of return types—yes, the UML permits multiple return types. The parameter list, shown in parentheses, indicates a comma-separated list of parameters, whose syntax is as follows:
direction name: type = defaultValue
The different parts of the syntax have the same value as when you have previously encountered them, with the exception of direction. This shows whether a parameter is used for input, output, or both input and output. The values to indicate the direction are as follows:
Finally, to show how all this syntax ties together, the following example shows a protected operation that accepts two input parameters and returns a String object:
# myOperation(arg1: String, arg2: Integer=0):String
Generalization
Figure A.8 shows that a large, unfilled arrow head depicts generalization. Like an association, a generalization shows a relationship between two classes. However, unlike an association, it shows a special type of relationship where one class is the child of the other class. In other words, one class is a subclass or subtype of the other class. In practice, the meaning of generalization differs according to the context within which you construct the model. At the conceptual level, classes B and C are subtypes of A if all instances of them are also instances of A. At the specification level, you are dealing with interfaces. Thus, B and C are subtypes of A if they include all the elements of the interface of A. Finally, at the implementation level, you are showing inheritance between classes, where classes B and C inherit all the methods and fields of A; of course, they can override the methods they inherit.
Figure A.8. Generalization notation.
Constraints
So far in this appendix, you have looked at a number of ways to model the relationships between classes. Often, these relationships act to constrain the classes within that relationship. For example, multiplicity constrains a class in terms of how many instances of it can exist. The UML also provides further syntax that allows you to show constraints, which are otherwise concealed. The syntax is as follows:
{ description of constraint }
You connect the constraint description to a class by using a dashed line. The description of the constraint can take any form you want, but if you want to use a formal syntax, you can use the Object Constraint Language (OCL). The example that Figure A.9 shows simply uses plain text. As you can see, the model shows a constraint on the Policy class, which states that if a customer is under the age of 25 years old, the system should classify him or her as high risk.
Figure A.9. Using constraints notation.
