UML

UML class diagrams describe the structure (but not the behavior) of an OOP solution. These are possibly the most often used diagrams in the industry and an indispensable tool for an OO programmer.

{Give some example class diagrams here}

The above illustrates the basic notations of a class diagram: attributes represent the data of the class; methods represent the operations (or behavior).

Example:

The ‘Operations’ compartment (or even both ‘Attributes’ and ‘Operations’ compartments) may be omitted if such details are not important for the task at hand.

Example:

The visibility of attributes and operations is used to indicate the level of access allowed for each attribute or operation. The types of visibility and their exact meanings depend on the programming language used. Here are some common visibilities and how they are indicated in a class diagram:

We use a solid line to show an association between two classes.

We use arrow heads to indication the navigability of an association.

Logic is aware of Minefield, but Minefield is not aware of Logic

‘Role’ labels are optionally used to indicate the role played by the classes in the association.

Example:

This association represents a marriage between a Man object and a Woman object. The respective roles played by objects of these two classes are husband and wife.

Example:

Association labels describe the association. The arrow head indicates the “direction” in which the label is to be read.

Example:

an Admin object uses Student objects” or “Student objects are used by an Admin object”.

A class diagram can also indicate the multiplicity of an association. Multiplicity is the number of objects of a class that participate in the association.

Commonly used multiplicities:

• 0..1 : optional, can be linked to 0 or 1 objects
• 1 : compulsory, must be linked to one object at all times.
• • : can be linked to 0 or more objects.
• n..m : the number of linked objects must be n to m inclusive

In the diagram below, an Admin object administers (in charge of) any number of students but a Student object must always be under the charge of exactly one Admin object

Example:

• Each Student must be supervised by a Professor.
• Students have matriculation numbers. A Professor cannot supervise more than 5 students.
• Admin staff handles Professors as well.

We use a dashed arrow to show dependencies.

An attribute is sometimes used to represent an association. The diagram below depicts a multiplayer Square Game being played on a board comprising of one hundred squares. Each of the squares may be occupied with any number of Pieces, each belonging to a certain player. A piece may or may not be on a square. Note how the association ’is on’ can be replaced by an isOn attribute of the Piece class. In order to realize the 0..1 multiplicity, the isOn attribute can either be null or hold a reference to a Square object.

In addition, association multiplicities of two or more can be made as part of the attribute using

• name: type [multiplicity] = default value

An << enumeration >> is used to indicate that an attribute can only take on a fixed set of values.

Example:

In UML class diagrams, underlines are used to denote class-level attributes and variables.

Example:

Association classes are denoted as a connection to an association link using a dashed line as shown below.

Example:

We use a solid diamond symbol to denote composition.

Example:

We use a hollow diamond is used to indicate an aggregation.

Example:

We uses a triangle and a solid line (not to be confused with an arrow) to indicate class inheritance.

Example:

We use the keyword << interface >> to indicate an interface. Interface inheritance is shown similar to class inheritance except a dashed line is used instead of a solid line.

Example:

We can use italics or {abstract} keyword to denote abstract classes/methods.

Example:

Workflows define the flow or a connected sequence of steps in which a process or a set of tasks is executed. Understanding the workflow of the problem domain is important if the problem that is to be solved is connected to the workflow.

A UML Activity diagram (AD) can model workflows.

An activity diagram (AD) consists of a sequence of actions and control flows. An action is a single step in an activity. It is shown as a rectangle with rounded edges. A control flow shows the flow of control from one action to the next. It is shown by drawing a line with an arrow-head to show the direction of the flow.

Branch nodes and merge nodes have the same notation: a diamond shape. They are used to show alternative (not parallel) paths through the AD. Each control flow exiting a Branch node has a guard condition which allows control to flow only if the guard condition is satisfied. Therefore, a guard is a boolean condition that should be true for execution to take a specific path.

Example: AD for the Minesweeper (MS) that shows actions done by the player and the game (MS).

Forks and joins have the same notation: a bar. They indicate the start and end of concurrent flows of control. The following diagram shows an example of their use. For join, execution along all incoming control flows should be complete before the execution starts on the outgoing control flow.

Here is the AD for a game of ‘snakes and ladders’.

The rake symbol (in the “Move piece” action above) is used to show that an action is described in another subsidiary activity diagram elsewhere. That diagram is given below.

It is possible to partition an activity diagram to show who is doing which action. Such partitioned activity diagrams are sometime called swimlane diagrams.

Note: Only essential elements of ADs are covered in this handout.