Chapter 16: UML Class Diagrams

16.1 Introduction

We already used UML Class Diagrams for domain modeling during analysis.

As with the previous chapter this is just a reference chapter:

16.2 Common Class Diagram Notation

Most elements in class diagrams are optional. See Figure 16.1 for a summary of the

notation.

Figure 16.1 Class Diagram Notation Summary

16.3 From Domain Model to Design Model

In the same way as the domain model included conceptual class diagram, vision, use cases etc., the design model includes design class diagrams, interaction and package diagrams (etc.).

From analysis to design we move from a conceptual view to a software view of the problem:

16.4 Class Attributes Visualisation Attributes can be shown visually : for class associations; or in

text : for basic data types only;

Semantically, showing attributes as text or as visual association is equivalent: the code will be the same e.g. for the above:public class Register {

private int id;

private Sale currentSale;

private Store location;

// … }

The full format of the attribute text notation is:visibility name : type multiplicity = default {property-string}

Visibility marks include ‘+’ (public) and ‘–’(private). In a design class diagram the associations have the

following properties (using the previous diagram as example): a navigability arrow pointing from the source (Register) to

target (Sale) object, indicating a Register object has an attribute of one Sale;

a multiplicity at the target end, but not the source end; a rolename (currentSale) only at the target end to show the

attribute name; no association name;

As mentioned, association ends can have a role name, show a multiplicity value but also have a keyword: Examples of keywords include {ordered} to indicate that the

elements of a collection are to be kept in some kind of order by the data structure that will hold the many target objects associated with the source object.

We can even specify what data structure should be used to hold the many objects (e.g. a List): use the user-defined keyword {List}:

We should prefer the visual version rather than the text version …

Operations syntax in UML is:

visibility name (parameter-list) : return-type {property-string}

Operations are usually assumed public if no visibility is shown. Property-string contains additional information, such as exceptions

that may be raised, if the operation is abstract, etc. An operation is not a method. A UML operation is a declaration,

with a name, parameters, return type, exceptions list, and possibly a pre-and post-condition (as in a contract). But, it isn't an implementation: methods are implementations.

A UML method is the implementation of an operation, it may be illustrated using: An interaction diagram (which shows the details and sequence of

messages); A note in a class diagram (using actual or pseudo-code);

16.5 Operations and Methods

The create message in an interaction diagram is normally interpreted as the invocation of the new operator and a constructor call. If we wish we can show constructors in a class diagram.

Accessor and mutator operations retrieve or set attributes, such as getPrice and setPrice. These operations are often excluded (or filtered) from the class diagram.

16.6 Keywords We have already seen some of these: :

<<actor>> <<interface>> {abstract} {ordered}

There are many other keywords available in the UML 2.0…

16.7 Stereotypes Stereotypes provide an extension mechanism in the UML. The UML predefines many stereotypes such <<destroy>> in

sequence diagrams.

16.8 Generalisation, Abstract Classes, Abstract Operations

Generalisation relationship scan be shown on UML’s class diagram see Figure 16.1.

Inheritance is specific to an OO programming language (e.g. Java and C++ inheritance mechanisms differ).

Thus, the UML's generalisation relationship is not similar to an OOPL inheritance mechanism although they are, of course, likely to be very closely related: the gap between an OO design and an OO implementation will be narrow.

Abstract classes or operations are indicated using the {abstract} keyword.

16.9 Dependency Relationships The UML includes a general dependency relationship that

indicates that a client element (of any kind, including classes, packages, use cases, and so on) has knowledge of another supplier element and that a change in the supplier could affect the client. Dependency is illustrated using a dashed arrow line from the client to the supplier.

Dependencies shows coupling between UML elements. There are many kinds of dependency; here are some

common types in terms of objects and class diagrams: having an attribute of the supplier type; sending a message to a supplier; the visibility to the supplier

could be: an attribute, a parameter variable, a local variable, a global

variable, or class visibility (invoking static or class methods);

receiving a parameter of the supplier type; the supplier is a superclass or interface;

Of course many of these dependencies have already special UML notations : e.g. for superclass, interface implementation and attributes as associations. So, for those cases, it is not useful to use the dependency line … Guideline : In class diagrams use the dependency line to depict

global, parameter variable, local variable, and static-method (when a call is made to a static method of another class) dependency between objects.

Example:public class Sale

{

public void updatePriceFor( ProductDescription description )

{

Money basePrice = description.getPrice();

//…

}

// …

}

In this example the updatePriceFor method receives a ProductDescription parameter object and then sends it a getPrice message. Therefore, the Sale object has parameter visibility to the ProductDescription, and message-sending coupling, and thus a dependency on the ProductDescription. If the latter class changed, the Sale class could be affected. This dependency can be shown in a class diagram…

We can also annotate a dependency line with a label such as <<call>>, <<create>> etc. to indicate more precisely the type of dependency.

16.10 Interfaces Interfaces (classes that only contain pure abstract-

virtual in C++-operations; an interface provides no implementation whatsoever) can be visualised in UML to show interface implementation (aka interface realisation in UML) and interface dependency.

See Figure 16.2

Figure 16.2 Different notations to show interfaces in UML.

16.11 Composition Aka composite aggregation is a strong kind of whole-part

relationship and is useful to show in some models. A composition relationship implies that

1) an instance of the part (such as a Square, a Finger) belongs to only one composite instance (such as one Board, one hand) at a time;

2) the part must always belong to a composite (no free-floating Fingers);3) the composite is responsible for the creation and deletion of its parts

either by itself creating/deleting the parts, or by collaborating with other objects. Related to this constraint is that if the composite is destroyed, its parts must either be destroyed, or attached to another composite (no free-floating Fingers allowed!)

Guideline:

The association name in composition is always implicitly some variation of "Has-part," therefore don't bother to explicitly name the association.

16.12 Constraints Constraints may be used on most UML diagrams, but are

especially common on class diagrams. A UML constraint is a restriction or condition on a UML element. It is visualized in text between braces; for example: { size >= 0 }. The text may be natural language or anything else, such as UML's formal specification language, the Object Constraint Language (OCL).

16.13 Qualified Association A qualified association has a qualifier that is used to select

an object (or objects) from a larger set of related objects, based upon the qualifier key. Informally, in a software perspective, it suggests looking things up by a key, such as objects in a Hash Table.

16.14 Association Class An association class allows you treat an association itself as

a class, and model it with attributes, operations, and other features. For example, if a Company employs many Persons, modelled with an Employs association, you can model the association itself as the Employment class, with attributes such as startDate.

16.15 Singleton Classes One OO design pattern that is very common is the

singleton pattern: a class with only one instance ever instantiated, never two.

16.16 Template Classes and Interfaces

Many programming languages support templates (aka parameterised types or generics); they are widely used for data structures.

E.g. you can define behaviour for sets in general by defining a template class Set:class Set <T> {

void insert (T newElement);

void remove (T anElement);

}

When you have done this, you can use the general definition to make Set classes for more specific elements:

Set <Employee> employeeSet; You can also declare template interfaces. See below for a UML representation of the Set example

16.17 Conclusion

As with the previous chapter on Interaction Diagrams, this chapter on Class Diagrams focused on the notation only: there is no need to remember all of the notation that we’ve seen; use these chapters as references…

We can view the class diagram as a summary of the static characteristics of the design elicited during the creation of the interaction diagrams.

In practice we should reflect changes in the set of interaction diagrams as soon as possible the partial class diagram to gain an overview of the software classes.

In the next few chapters we will review the much more important skills (over knowing the UML notation in details) of thinking in terms of objects to derive interaction diagrams and a class diagram.