View page as slide show

Communications software, Protocols and Architecture

Communication modelling

  • Communication systems are complex
    • Full system can consist several interacting objects
  • Communication modelling helps understand the communication protocol
    • Describing different situations
    • Describing the flow of messages in communication
  • Need for tools to develop protocols
    • Drafting
    • Analysing

Graphical representation of message flow

  • Easier to see how the communication is working
    • Easier to see relations between different entities
  • Help people understand how protocol works in different situations
    • Connection forming
    • Error situations
    • The task that you want to describe how it works
  • Focus on the message flow, not the internal behaviour of entities.
    • Only the messages (events) sent and received by entities are shown
  • Detail level depends on what you want to say with diagram
    • You can omit irrelevant entities for example
    • e.g. you can treat connection as point-to-point if routing is irrelevant for what you say.

Different message flow Models

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


  • 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

  • Entities (or instances)
    • Those who communicate
  • Event
    • Situation to which entity has to react e.g message arrives into entity
  • Action
    • Activities during communication (e.g. update variable)
  • Messages
    • The pieces of information going from one entity to another
  • 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

Sequence Diagram Example


  • 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) (sequence diagram is based actually on this)
    • 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
    • Instances can be created and and destroyed within MSC
    • No buffering, messages are consumed on arrival

  • Messages are denoted with arrows
    • Message has name and optionally parameters
    • Message must be sent before it is consumed
    • Instances may exchange messages between themselves or with environment
    • Message may overtake another message e.g. message sent earlier may arrive later.
      • May happen due the network delays for example

Incomplete messages

  • Lost message
    • When message is sent but never consumed
      • e.g. error in network
    • Intended target may be given
    • used usually to describe error cases
    • Described with arrow that ends with black circle
  • Found message
    • Message appearing from nowhere
      • E.g. network duplicates the message due the error
    • Supposed source instance may be given
    • Denoted with arrow that starts with empty circle


  • Timer has name and optionally duration
  • Timer must be attached to an instance
  • Setting timer has graphical symbol of hourglass
  • Reset timer is denoted with X
    • Timer is stopped
  • Timeout correspond to consumption of hourglass (arrow leaving from hourglass)
    • Timer message arrives to instance

Creation and destruction

  • Instance can be created by another instance
    • Creation is denoted with dotted arrow
    • E.g. new instance for handling new user
  • Instance may terminate itself
    • Stop symbol is used for instance termination


  • Says described condition when the MSC is used or continued
    • To keep presentation clear from unnecessary details for given case
  • Condition can be global or non-global
  • Global condition affects on all instances
  • Non-global condition describes state of one or more instances but not all

Additional features

  • Event order description
    • line with arrow in the middle
    • When you want to show the order of events without specifying message
  • Coregion
    • allows exception to rule of ordering events in instance axis
    • events in coregion are unordered
      • messages in coregion can arrive in any order
    • Ordering symbols may be used inside coregion to add some order for events
    • denoted with dotted line in instance axis
  • Loops and other symbols
    • There are many other symbols for MSC which you can find from MSC specification
    • Before using other symbols think if you could actually describe the case more clearly by using more than one MSC charts.
      • Complex structures in MSC can make the diagram hard to read and thus reduce the usability.

Things to remember

  • Think what you want to model with your diagram
    • If you want to describe remote ticket reservation, there is no need to have routing messages in diagram
  • 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
  • Test simple diagrams at:
Last modified: 2013/07/01 14:42