Modeling

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 to the purpose of the diagram. '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.

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.

Objects in an OO solution need to be connected to each other to form a network so that they can interact with each other. Such connections between objects are called associations.

Associations in an object structure can change over time.

Associations among objects can be generalized as associations between the corresponding classes too.

Implementing associations

You use instance level variables to implement associations.

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

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.

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.

Association Role 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 roles are optional to show. They are particularly useful for differentiating among multiple associations between the same two classes.

In each the three associations between the Flight class and the Airport class given below, the Airport class plays a different role.

When two classes are linked by an association, it does not necessarily mean both objects taking part in an instance of the association knows about (i.e., has a reference to) each other. The concept of navigability tells us if an object taking part in association knows about the other. In other words, it tells us if we can 'navigate' from the one object to the other in a given direction -- because if the object 'knows' about the other, it has a reference to the other object, and we can use that reference to 'navigate to' (i.e., access) that other object.

Navigability can be unidirectional or bidirectional. Suppose there is an association between the classes Box and Rope, and the Box object b and the Rope object r is taking part in one instance of that association.

• Unidirectional: If the navigability is from Box to Rope, b will have a reference to r but r will not have a reference to b. That is, one can navigate from b to r using the b's object reference of r (but not in the other direction).
  Similarly, if the navigability is in the other direction, r will have a reference to b but b will not have a reference to r.
• Bidirectional: b will have a reference to r and r will have a reference to b i.e., the two objects will be pointing to each other for the same single instance of the association.

Note that two unidirectional associations in opposite directions do not add up to a single bidirectional association.

class Person {
    Cat pet;
    //...
}

class Cat{
    Person owner;
    //...
}

    

    


    
    
    

      


    
    

class Person:

  def __init__(self):
    self.pet = None  # a Cat object


class Cat:

  def __init__(self):
    self.owner = None  # a Person object

    

    


    
    
    

      


    
    

class Person {
    Cat pet;
    //...
}

class Cat{
    Person breeder;
    //...
}

    

    


    
    
    

      


    
    

class Person:

  def __init__(self):
    self.pet = None  # a Cat object


class Cat:

  def __init__(self):
    self.breeder = None  # a Person object

    

    


    
    
    

      


    
    

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

  # ...

    

    


    
    
    

      


    
    

The arrowhead (not the entire arrow) denotes the navigability. The line denotes the association, as before. So, the navigability (i.e., the arrowhead) is an extra annotation added to an association line.

For example, both diagrams below show an association between Foo and Bar. But the one on the right shows the navigability as well.

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.

Multiplicity is the aspect of an OOP solution that dictates how many objects take part in each association.

Implementing multiplicity

A normal instance-level variable gives us a 0..1 multiplicity (also called optional associations) because a variable can hold a reference to a single object or null.

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

class Minefield {
    //...
}

    

    


    
    
    

      


    
    

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


class Minefield:
  # ...

    

    


    
    
    

      


    
    

A variable can be used to implement a 1 multiplicity too (also called compulsory associations).

class Logic {
    ConfigGenerator cg = new ConfigGenerator();
    ...
}

    

    


    
    
    

      


    
    

To implement other multiplicities, choose a suitable data structure such as Arrays, ArrayLists, HashMaps, Sets, etc.

class Minefield {
    Cell[][] cell;
    //...
}

    

    


    
    
    

      


    
    

class Minefield:

  def __init__(self):
    self.cells = {1:[], 2:[], 3:[]}

    

    


    
    
    

      


    
    

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 e.g., 2..5, 1..* (one or more), *..5 (up to five)

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.

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  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 start 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

Join nodes indicate the end of parallel paths.

Both have the same notation: a bar.

In a

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.

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:

A UML sequence diagram captures the interactions between multiple entities for a given scenario.

Consider the code below.

class Machine {

    Unit producePrototype() {
        Unit prototype = new Unit();
        for (int i = 0; i < 5; i++) {
            prototype.stressTest();
        }
        return prototype;
    }
}

class Unit {

    public void stressTest() {

    }
}


    

    


    
    
    

      


    
    

Here is the sequence diagram to model the interactions for the method call producePrototype() on a Machine object.

Notation:

This sequence diagram shows some interactions between a human user and the Text UI of a

CLI

Minesweeper game.

The player runs the newgame action on the TextUi object which results in the TextUi showing the minefield to the player. Then, the player runs the clear x y command; in response, the TextUi object shows the updated minefield.

The :TextUi in the above example denotes an unnamed instance of the class TextUi. If there were two instances of TextUi in the diagram, they can be distinguished by naming them e.g. TextUi1:TextUi and TextUi2:TextUi.

Arrows representing method calls should be solid arrows while those representing method returns should be dashed arrows.

Note that unlike in object diagrams, the class/object name is not underlined in sequence diagrams.

The arrowhead style depends on the type of method call. Arrows showing synchronous (i.e., the caller method is blocked from doing anything else until the called method returns) should use filled arrowheads (e.g., ). Most method calls (e.g., normal Java method calls) are synchronous. Asynchronous method calls (i.e., the caller method does not have to wait till the called method returns) are shown using lined arrowheads (e.g., ). As the latter is out of scope for this textbook, all sequence diagram arrow heads you encournter in this textbook will be of the first type.

[Common notation error] Activation bar too long: The activation bar of a method cannot start before the method call arrives and a method cannot remain active after the method has returned. In the two sequence diagrams below, the one on the left commits this error because the activation bar starts before the method Foo#xyz() is called and remains active after the method returns.

[Common notation error] Broken activation bar: The activation bar should remain unbroken while the method is being executed, from the point the method is called until the method returns. In the two sequence diagrams below, the one on the left commits this error because the activation bar for the method Foo#abc() is broken in the middle.

Notation:

The Player calls the mark x,y command or clear x y command repeatedly until the game is won or lost.

Notation:

• The arrow that represents the constructor arrives at the side of the box representing the instance.
• The activation bar represents the period the constructor is active.

The Logic object creates a Minefield object.

To reduce clutter, optional elements (e.g, activation bars, return arrows) may be omitted if the omission does not result in ambiguities or loss of

A minimal sequence diagram

If method parameters don't matter to the purpose of the sequence diagram, you can omit them using ... e.g., use foo(...) instead of foo(int size, double weight).

UML uses an X at the end of the lifeline of an object to show its deletion.

Notation:

Note how the below diagram shows the deletion of the Minefield object.

Although languages such as Java do not support a delete operation (because they use automatic memory management), you can use the object deletion notation to indicate the point at which the object becomes ready to be garbage-collected (i.e., the point at which it ceases to be referenced).

Note how d lifeline ends with an X to show that it is 'deleted' (i.e., ready to be garbage collected) after the cook() method returns.

class Chef {
    void cook() {
        Dish d = new Dish();
    }
}

    

    


    
    
    

      


    
    

UML can show a method of an object calling another of its own methods.

Notation:

The markCellAt(...) method of a Logic object is calling its own updateState(...) method.

In this variation, the Book#write() method is calling the Chapter#getText() method which in turn does a call back by calling the getAuthor() method of the calling object.

'Unroll' chained/compound method calls before drawing sequence diagram. Consider the Java statement new Book().add(new Chapter());. How do we show it as a sequence diagram? First, 'unroll' it into a simpler series of statements, which can then be drawn as a sequence diagram easily. For example, that statement is equivalent to the following:

Book b = new Book();
Chapter c = new Chapter();
b.add(c);

    

    


    
    
    

      


    
    

UML uses alt frames to indicate alternative paths.

Notation:

Minefield calls the Cell#setMine method if the cell is supposed to be a mined cell, and calls the Cell:setMineCount(...) method otherwise.

No more than one alternative partitions be executed in an alt frame. That is, it is acceptable for none of the alternative partitions to be executed but it is not acceptable for multiple partitions to be executed.

UML uses opt frames to indicate optional paths.

Notation:

Logic#markCellAt(...) calls Timer#start() only if it is the first move of the player.

Method calls to static (i.e., class-level) methods are received by the class itself, not an instance of that class. You can use <<class>> to show that a participant is the class itself.

In this example, m calls the static method Person.getMaxAge() and also the setAge() method of a Person object p.

Here is the Person class, for reference:

UML uses par frames to indicate parallel paths.

Notation:

Logic is calling methods CloudServer#poll() and LocalData#poll() in parallel.

If you show parallel paths in a sequence diagram, the corresponding Java implementation is likely to be multi-threaded because a normal Java program cannot do multiple things at the same time.

UML uses ref frame to allow a segment of the interaction to be omitted and shown as a separate sequence diagram. Reference frames help you to break complicated sequence diagrams into multiple parts or simply to omit details you are not interested in showing.

Notation:

The details of the get minefield appearance interactions have been omitted from the diagram.

Those details are shown in a separate sequence diagram given below.