View page as slide show

ommunications software and architecture

Communications modeling

Different message flow Models

  • UML Interaction diagrams
    • Collaboration diagram
    • Sequence diagram
  • Message Sequence charts (MSC)
    • ITU-T standard
    • Graphical and textual representation

Uses

  • Describing communication between system component under certain scenario (use case)
    • Sequence and message flow
    • Part of design phase
    • It is not feasible to show all possible scenarios simultaneously in one chart
      • charts and diagrams are usually ambiguous
  • Visualising observed behaviour
    • testing, simulation, evaluation, discussion,validation, simulation
  • Specification
    • Requirement, interface, test case
  • Documentation

Common building blocks

  • Instances
    • those who communicate
  • Events
    • Activities during communication (update variable)
  • Messages
    • the information flowing between instances
  • Comments
    • to make everything clear
  • notation vary slightly between different charts

Collaboration diagram

  • Emphasis in structural organization of whole system
    • Easy to described e.g. layered architecture and the relations of different objects
    • Suited best to describe communications between tens of entities is described
  • Object is denoted with box
    • instance-name:class-name
  • Communication between instances is denoted with line
    • Messages can be numbered to describe sequence of events
    • arrow can show the direction of message
  • Events are described in standard UML comment box
  • Collaboration diagram can be mapped to sequence diagram
    • Same semantic information which is rendered differently
  • Problems
    • It may be hard to follow the order of messages
    • Adding timers and affecting events
    • Event timing is hard to describe

Sequence diagram

  • Emphasis on time ordering of messages
    • Easy to see the sequence of messages and their timing
    • First events at top last at bottom
  • Visualises the behaviour of given use case.
  • Suits best for simple cases
    • Branching makes diagram easily unreadable
    • Instead of putting all in one diagram, use separate diagrams to describe different behaviour.
  • Objects are denoted with Boxes object:class
  • Object lifeline is denoted with vertical dashed line
    • Messages can create objects
    • Objects may cease to exist during communication
    • Usually object will last through whole communication
  • Focus of control is vertical thin rectangle
    • Describes the time during which object is making action
  • Messages are denoted with horizontal arrows
    • «create» and «destroy» create and destroy an object

MSC

  • Standardized graphical notation for descriptive interactions between any communicating entities within system
    • ITU-T standard (recommendation Z.120)
    • Part of Specification and Description Language (SDL) family.
  • Can be used to describe signalling within whole system or some detailed case
  • Two descriptive forms
    • Visual syntax with graphical representation (for human use)
    • Program-like textual syntax (for moving descriptions between applications)
  • Collection of MSCs describing the system are collected into MSC document

MSC general rules

  • Names within MSC document must be unambiquous
  • Identifiers and keywords are case-insensitive
  • National characters are allowed within identifiers
  • Sequence diagram can be thought as simplified MSC

Basic MSC

  • Describe single communication scenario
    • frame with the name of MSC
  • Instance
    • denoted with empty horizontal box at head, and black horizontal box as end
    • vertical line is the lifeline like in Sequence chart
  • Messages denoted with arrows
    • Lost message ends with black circle after arrow
    • Found message starts with empty circle

Incomplete messages

  • Lost message
    • When message is sent but never consumed
    • Intended target may be given
    • used usually to describe error cases
  • Found message
    • Message appearing from nowhere
    • Supposed instance or gate may be given

Timers

  • Graphical symbol is hourglass
    • must be attached to an instance
  • Timeout correspond to consumption of hourglass (arrow leaving from hourglass)
  • reset timer is denoted with X
    • Resetting timer

Creation and destruction

  • Instance creation is denoted with dotted arrow
  • Stop symbol is used for instance termination

Other features

Things to remember

  • Think what you want to model with your diagram
    • If you want to describe transport layer protocol, then there is no need to add network layer messaging
  • Choose the diagram that best fits for your task
    • Collaboration for describing the system structure
    • Sequence diagram to describe specific use cases.
  • Do not try to fit everything in one diagram
    • Have different diagrams to describe different cases to keep everything readable
Last modified: 2013/07/01 14:42