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.

📦 An example class diagram:

The basic UML notations used to represent a class:

📦 A Table class shown in UML notation:

class Table{
    
    Integer number;
    Chair[] chairs = null;
    
    Integer getNumber(){
        ...
    }
    
    void setNumber(Integer n){
        ...
    }
}

The 'Operations' compartment and/or the 'Attributes' compartment may be omitted if such details are not important for the task at hand. 'Attributes' always appear above the 'Operations' compartment. All operations should be in one compartment rather than each operation in a separate compartment. Same goes for attributes.

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:

• + : public
• - : private
• # : protected
• ~ : package private

📦 Table class with visibilities shown:

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

class Logic{
    Minefield minefield;
}

class Minefield{
    ...
}

Navigability can be shown in class diagrams as well as object diagrams.

Association Role labels are used to indicate the role played by the classes in the association.

📦 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.

Note how the variable names match closely with the association roles.

class Man{
    Woman wife;
}

class Woman{
    Man husband;
}

📦 The role of Student objects in this association is charges(i.e. Admin is in charge of students)

class Admin{
    List<Student> charges;
}

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

📦 In this example, the same association is described using two different labels.

• Diagram on the left: Admin class is associated with Student class because an Admin object uses a Student object.
• Diagram on the right: Admin class is associated with Student class because a Student object is used by an Admin object.

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

📦 In the diagram below,

• Each student must be supervised by exactly one professor. i.e. There cannot be a student who doesn't have a supervisor or has multiple supervisors.
• A professor cannot supervise more than 5 students but can have no students to supervise.
• An admin can handle any number of professors and any number of students, including none.
• A professor/student can be handled by any number of admins, including none.

In a UML class diagram, a dependency is a weaker form of an association where there is an interactions between objects that do not result in a long-term relationship between the said objects.

class Foo{
    
    int calcualte(Bar bar){
        return bar.getValue();
    }
}

class Bar{
    int value;
    
    int getValue(){
        return value;
    }
}

UML uses a dashed arrow to show dependencies.

📦 Two examples of dependencies:

An association can be shown as an attribute instead of a line.

Association multiplicities and the default value too can be shown as part of the attribute using the following notation. Both are optional.

name: type [multiplicity] = default value

📦 The diagram below depicts a multi-player Square Game being played on a board comprising of 100 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 that association can be replaced by an isOn attribute of the Piece class. The isOn attribute can either be null or hold a reference to a Square object, matching the 0..1 multiplicity of the association it replaces. The default value is null.

The association that a Board has 100 Sqaures can be shown in either of these two ways:

Notation:

📦 In the class diagram below, there are two enumerations in use:

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

📦 In the class below, totalStudents attribute and the getTotalStudents method are class-level.

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

📦 In this example Loan is an association class because it stores information about the borrows association between the User and the Book.

UML uses a solid diamond symbol to denote composition.

Notation:

📦 A Book consists of Chapter objects. When the Book object is destroyed, its Chapter objects are destroyed too.

UML uses a hollow diamond is used to indicate an aggregation.

📦 Example:

You can use a triangle and a solid line (not to be confused with an arrow) to indicate class inheritance.

Notation:

📦 Examples: The Car class inherits from the Vehicle class. The Cat and Dog classes inherit from the Pet class.

An interface is shown similar to a class with an additional keyword << interface >>. When a class implements an interface, it is shown similar to class inheritance except a dashed line is used instead of a solid line.

📦 The AcademicStaff and the AdminStaff classes implement the SalariedStaff interface.

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

Example:

A UML Activity diagram (AD) can model workflows.

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.

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 : a boolean condition that should be true for execution to take that path. only one of the alternative paths can be taken at any time.

📦 The activity diagram 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. In a set of parallel paths, execution along all parallel paths should be complete before the execution can start on the outgoing control flow of the join.

📦 The following diagram shows an example of their use.

The rake notation is used to indicate that a part of the activity is given as a separate diagram.

📦 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 the 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.

📦 A simple example of a swimlane diagram: