Week 6. UML sequence diagrams and refactoring

We use user interaction models to help identify user requirements. Modelling system-to-system interaction highlights communication problems that may arise. Modelling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability.

Interaction Diagrams

Interaction Diagram

An interaction diagram is used to specify interactions and is used to model concrete. They allow us to describe communication sequences at different levels of detail.

They show:

• interaction of a system with its environment
• interaction between system parts in order to show how a specific use case can be implemented
• inter-process communication in which the partners involved must observe certain protocols
• communication at class level (operation calls, inter-object behaviour)

Link to original

Sequence Diagram

Sequence diagram (UML)

A sequence diagram shows an object message passing structure, it is a two-dimensional diagram. It consists of:

• horizontal axis: involved interaction partners
• vertical axis: chronological order of the interaction

Interaction (UML Sequence)

An interaction is a sequence of event specifications.

Link to original

Interaction Partners (UML Sequence)

Interaction partners are depicted as lifelines.

• The head of the lifeline is a rectangle that contains the expression roleName:Class, roles are a more general concept than objects and objects can take on different roles over their lifetime.
• The body of the lifeline is a vertical (usually dashed) line which represents the life time of the object associated with it.

Link to original

Messages

Message (UML Sequence)

A message is defined via a send and receive event, it is used to visualise when an Interaction Partners (UML Sequence) executes some behaviour.

There are several different types of message we need to know about:

• Synchronous message (UML Sequence)

  Synchronous message: sender waits until it has received a response message before continuing. Syntax is msg(...parameters).

  

  Link to original

• Asynchronous message (UML Sequence)

  Asynchronous message: sender continues without waiting for a response message. Syntax is msg(...parameters).

  

  Link to original

• Response message (UML Sequence)

  Response message: may be omitted if the content and location are obvious. Syntax is attribute = msg(...parameters): return value.

  

  Link to original

• Found Message (UML Sequence)

  Found message: sender of a message is unknown or not relevant.

  

  Link to original

• Lost Message (UML Sequence)

  Lost message: receiver of a message is unknown or not relevant.

  

  Link to original

• Time-consuming Message (UML Sequence)

  Time-consuming message: a message with a set duration. Usually we assume messages are transmitted with no loss of time, we express time elapses between the send and receipt of a message.

  

  Link to original

• Object Creation (UML Sequence)

  Object creation is represented by a dashed arrow with an arrowhead pointing to the head of the lifeline of the object to be created. We use the keyword new.

  

  Link to original

• Object Destruction (UML Sequence)

  Object destruction is indicated by a large cross at the end of the lifeline.

  

  Link to original

Link to original

Combined Fragments

Combined Fragments (UML Sequence)

We can use combined fragments to model various control structures.

There are three categories of types of fragments:

• Branches and loops: alt, opt, loop, break
• Concurrency and order: seq, strict, par, critical
• Filters and assertions: ignore, consider, assert, neg

The types of fragments are:

• Alt Fragment (UML Sequence)

  alt: to model alternative sequences, similar to a switch case.

  • Guards are used to select the one path to be executed. They are modelled in square brackets. We may use [else] to signify any other case if other guards fail.
  • Guards must be disjoint to avoid in deterministic behaviour.

  

  Link to original

• Opt Fragment (UML Sequence)

  opt: to model optional sequence actual execution at runtime is dependent on the guard.

  • Exactly one operand.
  • Similar to if without else branch.
  • Equivalent to Alt Fragment (UML Sequence) with two operands where one is empty.

  

  Link to original

• Loop Fragment (UML Sequence)

  loop: to express that a sequence is to be executed repeatedly.

  • Exactly one operand.
  • Keyword is followed by minimal / maximal number of iterations. (min..max) or (min, max) Examples of equivalent notation:
    • loop(3,8) = loop(3..8)
    • loop(8,8) = loop(8)
    • loop = loop(*) = loop(0, *)
  • Guard is evaluated as soon as the minimum number of iterations has taken place, then checked also for each iteration within the limits. If the guard evaluates to false, the execution of the loop is terminated.

  

  Link to original

• Break Fragment (UML Sequence)

  break: simple form of exception handling.

  • Exactly one operand with a guard.
  • If the guard is true:
    1. Interactions within the operand are executed.
    2. Remaining operations of surrounding fragment are omitted.
    3. Interaction continues in next higher lever fragment.

  

  Link to original

• Strict Fragment (UML Sequence)

  strict: sequential interaction with order

  • Order of event occurrences on different lifelines between different operands is significant.
  • Messages in an operand that is higher up on the vertical axis are always exchanged before the messages in an operand that is lower down on the vertical axis.

  

  Link to original

In addition, we may apply:

• Coregion (UML Sequence)

  A coregion is used to model concurrent events of a single lifeline.

  • The order of event occurrences within a coregion is not restricted.
  • Area of the lifeline to be covered by the coregion is marked by square brackets rotated by 90 degrees.

  

  Link to original

• Interaction Reference (UML Sequence)

  An interaction reference integrates one sequence diagram into another.

  

  Link to original

• Gate (UML Sequence)

  A gate allows you to send and receive messages beyond the boundaries of the interaction fragment.

  

  Link to original

• Time Constraints (UML Sequence)

  We may specify time constraints such as:

  • The point in time for event occurrence.
    • Relative: after(5sec)
    • Absolute: at(12.00)
  • Time period between two events:
    • {lower..upper}

  

  Link to original

Link to original

Link to original

Refactoring

Object oriented code can have quality flaws such as:

• “God Class”: one class carries out most of the system functionality, others are auxiliary
• “Excessive Class / Method Length” or “Excessive Inheritance Use”
• “Excessive Parameter List”: more than 10 parameters in an operation
• “Duplicate Code”: sections of identical code in different locations
• “Cyclomatic Complexity”: high number of logical loop / if conditions in a method
• “Too Many Methods”: more than 20 in a class
• “Too Many Fields”: more than 20 in a class

Code design errors make maintenance of the system more expensive and increase the likelihood of functional errors.

Duplicate code means any change must also be duplicated. Refactoring can be used to remove these flaws and improve structure.

Refactoring

Refactoring is modifying a model to improve its structure while keeping the same semantics.

Link to original

Class Diagram Refactoring

Class Diagram Refactoring

Class diagrams can be refactored to improve structure, remove redundancies, and improve correspondence to requirements:

• Pull up attribute refactoring

  “Pull up attribute” refactoring: if all (or at least 2) direct sub-classes of class $E$ declare an attribute, say $T$, we can replace this with a single definition in $E$.

  

  Link to original

• Move operation refactoring

  “Move operation” refactoring: if operation op of $E$ refers mainly to attributes and roles of class $F$ via association $E$-$F$, try moving op to $F$.

  

  Link to original

• Merge classes refactoring

  “Merge classes”: if all sub-classes of abstract class $C$ are empty, replace sub-classes by flag attribute of $C$ of enumeration making $C$ concrete.

  

  Link to original

Link to original

State Diagram Refactoring

State Diagram Refactoring

We can try to refactor State diagram (UML) by introducing composite state.

Composite State (UML State Machine)

If a group of states $s_1,\dots ,s_n$ all have identical outgoing transitions to states not in the group, then create a new superstate of $s$ of these. Replace common outgoing transitions by transitions from $s$.

Link to original

Link to original