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 are 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:

The equivalent code

---

The 'Operations' compartment and/or the 'Attributes' compartment may be omitted if such details are not important for the task at hand. Similarly, some attributes/operations can be omitted if not relevant. '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:

The equivalent code

---

Generic classes can be shown as given below. The notation format is shown on the left, followed by two examples.

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

Use arrowheads to indicate the navigability of an association.

In this example, the navigability is unidirectional, and is from the Logic class to the Minefield class. That means if a Logic object L is associated with a Minefield object M, L has a reference to M but M doesn't have a reference to L.

class Logic {
    Minefield minefield;
    // ...
}

class Minefield {
    //...
}

    

    


    
    

class Logic:
  
  def __init__(self):
    self.minefield = None
    
  # ...


class Minefield:
  # ...

    

    


    
    

Here is an example of a bidirectional navigability; i.e., if a Dog object d is associated with a Man object m, d has a reference to m and m has a reference to d.

class Dog {
    Man man;
    // ...
}

class Man {
    Dog dog;
    // ...
}

    

    


    
    

class Dog:
  
  def __init__(self):
    self.man = None
    
  # ...


class Man:
  def __init__(self):
    self.dog = None

  # ...

    

    


    
    

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

According to this object diagram, the given Logic object is associated with and aware of two MineField objects.

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;
}

    

    


    
    

class Man:
  def __init__(self):
    self.wife = None # a Woman object

class Woman:
   def __init__(self):
     self.husband = None # a Man object

    

    


    
    

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

class Admin {
    List<Student> charges;
}

    

    


    
    

class Admin:
  def __init__(self):
    self.charges = [] # list of Student objects

    

    


    
    

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 within n to m inclusive.

In the diagram below, an Admin object administers (is 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.

UML uses a dashed arrow to show dependencies.

Two examples of dependencies:

Dependencies vs associations:

• An association is a relationship resulting from one object keeping a reference to another object (i.e., storing an object in an instance variable). While such a relationship forms a dependency, we need not show that as a dependency arrow in the class diagram if the association is already indicated in the diagram. That is, showing a dependency arrow does not add any value to the diagram.
  Similarly, an inheritance results in a dependency from the child class to the parent class but we don't show it as a dependency arrow either, for the same reason as above.
• Use a dependency arrow to indicate a dependency only if that dependency is not already captured by the diagram in another way (for instance, as an association or an inheritance) e.g., class Foo accessing a constant in Bar but there is no association/inheritance from Foo to Bar.

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

Association multiplicities and the default value 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 Squares can be shown in either of these two ways:

Show each association as either an attribute or a line but not both. A line is preferred as it is easier to spot.

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

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

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 to indicate an aggregation.

Notation:

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 object diagram shows an object structure at a given point of time.

An example object diagram:

Notation:

Notes:

• The class name and object name e.g. car1:Car are underlined.
• objectName:ClassName is meant to say 'an instance of ClassName identified as objectName'.
• Unlike classes, there is no compartment for methods.
• Attributes compartment can be omitted if it is not relevant to the task at hand.
• Object name can be omitted too e.g. :Car which is meant to say 'an unnamed instance of a Car object'.

Some example objects:

A solid line indicates an association between two objects.

UML  activity diagrams (AD) can model workflows.  Flow charts are another type of diagram that can model workflows. Activity diagrams are the UML equivalent of flow charts.

An activity diagram (AD) captures an activity through the actions and control flows that make up the activity.

• An action is a single step in an activity. It is shown as a rectangle with rounded corners.
• 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.

Note the slight difference between the start node and the end node which represent the start and the end of the activity, respectively.

This activity diagram shows the action sequence of the activity a passenger rides the bus:

A branch node shows the start of alternate paths. Each control flow exiting a branch node has a guard condition: a boolean condition that should be true for execution to take that path. Exactly one of the guard conditions should be true at any given branch node.

A merge node shows the end of alternate paths.

Both branch nodes and merge nodes are diamond shapes. Guard conditions must be in square brackets.

The AD below shows alternate paths involved in the workflow of the activity shop for product:

Some acceptable simplifications (by convention):

• Omitting the merge node if it doesn't cause any ambiguities.
• Multiple arrows can starting from the same corner of a branch node.
• Omitting the [Else] condition.

The AD below illustrates the simplifications mentioned above:

Fork nodes indicate the start of flows of control.

Join nodes indicate the end of parallel paths.

Both have the same notation: a bar.

In a , execution along all parallel paths should be complete before the execution can start on the outgoing control flow of the join.

In this activity diagram (from an online shop website) the actions User browses products and System records browsing data happen in parallel. Both of them need to finish before the log out action can take place.

UML notes can augment UML diagrams with additional information. These notes can be shown connected to a particular element in the diagram or can be shown without a connection. The diagram below shows examples of both.

Example:

Compared to the notation for class diagrams, object diagrams differ in the following ways:

• Show objects instead of classes:
  • Instance name may be shown
  • There is a : before the class name
  • Instance and class names are underlined
• Methods are omitted
• Multiplicities are omitted. Reason: an association line in an object diagram represents a connection to exactly one object (i.e., the multiplicity is always 1).

Furthermore, multiple object diagrams can correspond to a single class diagram.

Both object diagrams are derived from the same class diagram shown earlier. In other words, each of these object diagrams shows ‘an instance of’ the same class diagram.

When the class diagram has an inheritance relationship, the object diagram should show either an object of the parent class or the child class, but not both.

Suppose Employee is a child class of the Person class. The class diagram will be as follows:

Now, how do you show an Employee object named jake?

• This is not correct, as there should be only one object.

• This is OK.

• This is OK, as jake is a Person too. That is, we can show the parent class instead of the child class if the child class doesn't matter to the purpose of the diagram (i.e., the reader of this diagram will not need to know that jake is in fact an Employee).

Association labels/roles can be omitted unless they add value (e.g., showing them is useful if there are multiple associations between the two classes in concern -- otherwise you wouldn't know which association the object diagram is showing)

Consider this class diagram and the object diagram:

We can clearly see that both Adam and Eve lives in hall h1 (i.e., OK to omit the association label lives in) but we can't see if History is Adam's major or his minor (i.e., the diagram should have included either an association label or a role there). In contrast, we can see Eve is an English major.