UML - Sequence Diagram

[jimin-kiim]

• Interaction Diagrams
• Interaction, Interaction Partners
• Sequence Diagram Frames
• Sequence Diagram Fragments
• reference, time constraints, state invariant

[jimin-kiim]

Interaction Diagrams

• used to specify interactions
• modeling concrete scenarios
• describing communication sequences at different levels of detail
• how objects interact via messages (dynamic object modeling)
• Interaction Diagrams show the following:
  • interaction of a system with its environment
  • interaction between system parts in order to show 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 behavior)

    Four Types of Interaction Diagrams

• Sequence Diagram
  • models the collaboration of objects based on a time sequence
  • chronological order of interactions
  • vertical axis: chronological order
  • horizontal axis: interaction partners
• Communication Diagram
  • models the relationships between communication partners
  • focus: who communicates with whom
  • time is not a separate dimension
  • message order via decimal classification
  • space efficient. better for hand writing discussions
• Timing Diagram
  • shows state changes of the interaction partners that result from the occurrence of events
  • vertical axis: interaction partners
  • horizontal axis: chronological order
• Interaction overview Diagram
  • visualizes order of different interactions
  • allows to place various interaction diagrams in a logical order
  • basic notation concepts of activity diagram

[jimin-kiim]

Sequence Diagram

• two-dimensional diagram
  • vertical axis: chronological order of the interaction
  • horizontal axis: involved interaction partners

Interaction Partners

• interaction = sequence of event specifications
• depicted as lifeline= head of the lifeline + body of the lifeline
• head of the lifeline: rectangle that contains the expression roleName:Class (lecturer: Professor)
  • roles are a more general concept than objects
  • Object can take on different roles over its lifetime
• body of the lifeline: vertical, usually dashed line
  • represents the lifetime of the object associated with it

Message

• message: defined via send event, receive event
  • execution specification = (continuous bar) + line with arrow + (dashed line with arrow )
  • send message
  • synchronous message: msg(par1, par2)
    • sender waits until it has received a response message before continuing
  • asynchronous message: msg(par1, par2)
    • sender continues without waiting for a response message
  • response message: att = msg(par1, par2): val
  • may be omitted if content and location are obvious
  • object creation
  • dashed arrow
  • arrowhead points to the head of the lifeline of the object to be created
  • with keyword 'new'
  • object destruction
  • object if deleted
  • large cross (X) at the end of the lifeline
  • found message: sender of a message is unknown or not relevant. starts from a circle
  • lost message: receiver of a message is unknown or not relevant. ends to a circle
  • time-consuming message: message with duration. expresses the time elapses between the sending and the receipt of a message. usually, messages are assumed to be transmitted without any loss of time
  • iteration over a collection
  • Lifeline participants should represent one object, not a collection.
  • invoking static methods: <>
  • a lifeline box label that indicates the receiving object is a class, or more precisely, an instance of a metaclass
  • polymorphic method call
  • Shows the polymorphic message to the abstract superclass or interface object,
  • and then separate sequence diagrams detailing each polymorphic case starting with a found polymorphic message.
  • asynchronous and synchronous calls
  • asynchronous: stick arrow
  • synchronous: filled arrow

    Frame

• frame: a rectangle with a pentagon in the upper left-hand corner called the name compartment

  • name compartment: sd interactionIdentifier

  • sd: sequence diagram

  • interactionIdentifier: a simple name or an operation specification(parameters) as in a class diagram

  • local attributes can also be expressed.

    Combined fragments

    

  • model various control structures

  • 12 predefined types of operators

  • branches and loops: alt, opt, loop, break

  • concurrency and order: seq, strict, par, critical

  • filters and assertions: ignore, consider, assert, neg

• alt: to model alternative sequences ~= switch
  • guards are used to select the one path to be executed
  • modeled in square brackets []
  • multiple operands can be used
  • guards have to be disjoint to avoid non-deterministic behavior
• opt: to model an optional sequence ~= if () {}
  • actual execution at runtime is dependent on the guard
  • exactly one operand
• loop: to express that a sequence is to be executed repeatedly ~= for loop, do while, while
  • exactly one operand
  • (min..max) or (min, max) or using *
  • (min, max): for loop
  • (1, max): do while
  • (*): while
• break: simple form of exception handling
  • exactly one operand
  • if the guard is true
  • interactions within this operand are executed and remaining operations of the surrounding fragments are omitted
  • interaction continues in the next higher level fragments
• seq: default order of events
  • weak sequencing
  • the ordering of events within each of the operands is maintained in the result.
  • events on different lifelines from different operands may come in any order.
  • events on the same lifeline from different operands are ordered such that an event of the first operand comes before that of the second operand.
  • restrictions: only lifeline
• strict: sequential interaction with order
  • order of event occurrences on different lifelines between different operands is significant
  • execution paths of different operands cannot be interleaved
  • restrictions: lifeline, within operand, operands
• par
  • to set aside chronological order between messages in different operands
  • execution paths of different operands can be interleaved
  • restrictions of each operand need to be respected
  • order of the different operands is irrelevant
  • restrictions: lifeline, within operand
• critical: atomic area in the interaction
  • exactly one operand
  • to make sure that certain parts of an interaction are not interrupted by unexpected events
• ignore: to indicate irrelevant messages
  • exactly one operand
  • irrelevant messages in curly brackets after the keyword ignore
  • messages may occur at runtime but have no further significance
• consider: to specify those messages that are of particular importance for the interaction under consideration
  • exactly one operand
  • considered messages in curly brackets after the keyword consider
• assert: to identify certain modeled traces as mandatory
  • exactly one operand
  • deviations that occur in reality but that are not included in the diagram are not permitted
• neg: to model invalid interactions
  • exactly one operand
  • describing situations that must not occur
  • explicitly highlighting frequently occurring errors
  • depicting relevant, incorrect sequences

else

• interaction reference: integrating one sequence diagram in another sequence diagram
• time constraints: point in time for event occurrence or time period between two events
• state invariant: asserts that a certain condition must be fulfilled at a certain time
  • always assigned to a specific lifeline
  • evaluation before the subsequent event occurs
  • If the state invariant is not true, either the model or the implementation is incorrect

[jimin-kiim]

Communication Diagram

• Link
  • a connection path between two objects
  • indicates some form of navigation and visibility between the objects is possible
  • More formally, a link is an instance of an association, dependency and aggregation (but not inheritance)
• Message
  • Each message between objects is represented with a message expression and small arrow indicating the direction of the message
  • Many messages may flow along a link
  • A sequence number is added to show the sequential order of messages in the current thread of control.
  • Creation
  • [Register] {number}: create({optional initializing parameters}) -> [Sale] ({new})
    • {new} may optionally added
  • [Register] << create >> {number}: make({optional initializing parameters}) -> [Sale]
  • Numbering
  • not numbered/ legal numbering
  • _ -> 1 -> 1.1 -> 2 -> 2.1 -> 2.2
  • Conditional / Mutually Exclusive messages
  • [{conditional messages}]
  • [color = red]
  • 1a [test1], 1b[not test 1] are mutually exclusive
  • Iterative messages
  • 1*[i=1..n]:st = getSibtotal -> [lineItems[i]: SalesLineItem]
    • it means iteration and recurrence clause indicating looping across each element of the lineItems collections
    • 1*:st = getSibtotal -> [lineItems[i]: SalesLineItem] is less precise but usually good enough to imply the iteration
  • Static Method call
  • [<<metaclass?? {className}]
  • Polymorphic Method Call

• Asynchronous and Synchronous Calls