View page as slide show

Communications Software, Protocols and Architecture

Communications software challenges

  • Needs to work often in variety of environments
  • Single protocol may be used by variety of applications
  • Different parts will be implemented by different groups or even companies on different platforms
  • May have to support protocols on different layers
  • Design phase helps us in implementation phase and guarantee that we get what we want.
  • Different applications have different requirements from protocols

General process

  • Defining use cases for protocol
    • To describe different scenarios where the protocol is used
  • Extracting the requirements and constraints
    • Find out from use cases what the protocol has to do and what kind of restrictions there are
  • Protocol development
    • Develop protocol that fulfils the requirements
  • Protocol specification
    • Write a document about the protocol so that someone else can create compatible application

Design of communication software

  • Questions that need answers
    • What kind of services are needed from communication software
    • Can we use existing protocols to get what we need
    • How many protocol layers we should create for that
    • What services will be provided on which layer
    • What kind of applications our protocol layer should support
  • Design tools
    • Use cases will describe different scenarios where our solution is used
    • requirements define what we need from communication system in order to fullfil use cases
    • constraints describe what kind of limitations we will have
    • collabaration describes how different pieces work together

Use cases

  • “Use case is a narrative document that describes the sequence of events of an actor” - Jacobson
    • narrative!
    • sequence of events.
    • example: client connects to server, fetches a file and shows it to user.
  • Illustrate and imply the requirements.
  • It is good to start development on high level use cases.
    • Do not go too much in detail on your use cases.

Use case contents

  • Use case name
  • Actors
    • participants of the use case
  • Purpose
    • what the use case is used for
  • Description
    • the sequence of events
  • overview
    • for detailed use cases it is good idea to have overview of events described in short
  • cross references can be used to point out related use cases.

Use case diagrams

  • Describes a set of use cases in a system, the actors and the relations between actors an use cases
  • Actor
    • represent functional entities (human, machine, software)
    • Actor in communication software can be in the system
      • In traditional software engineering Actors are external from system.
    • denoted with stick figure
  • Use cases
    • possible use of software under development
    • denoted with ellipse
  • relation
    • denoted with line
    • «uses», «extends», «includes»
      • special relations
    • generalisation
      • TCP client → client (actor)
      • make TCP connection → make connection (use case)
  • Constraints
    • e.g. authenticate or select free service
    • dotted arrow
  • Notes
    • Used for more detailed textual information (e.g. defining constraint).

Requirements

  • Every software has a goal what to do
    • protocols provide services
  • Requirements answer to question “what must be done?” to provide the protocol service
    • need or desire for a software
  • Functional requirements define desired system behaviour
    • e.g. transmit instant message
  • Nonfunctional requirements define additional attributes related to behaviour
    • e.g. message should be answered within five seconds
  • Constraints
    • e.g. target environment may cause constraints to requirements
  • Requirements form a base for testing
    • It is easier to test that behaviour is as desired, when we know what the software should do.
    • requirement should be unambiquous

Models

  • Requirements model
    • defines one functional requirement
    • modelled in use case diagram
  • analysis model
    • collaboration of objects
    • realisation of requirements model

Requirements modelling

  • Requirements model
  • defines one functional requirement
  • Modelled in use case diagram
  • use case != requirement
  • use cases help to understand the requirements
  • requirements can be found in specification, use cases don´t
  • Requirements can be translated to test model
    • test model is used as basis and verification
    • TTCN (tree and tabular combined notation) used for test cases and testing (testing chapter)
  • Detailed UML models can be used for automating test cases
    • Model bugs are hard to find
      • application behaviour testing required.
    • Error in model will cause erraneous testing.

Analysis

  • How can we fulfil the requirements?
  • What parts are required for the system
    • Parts that we have to make.
    • Parts that we have to communicate with.
  • How different parts collaborate with each other to provide the desired result

analysis model

  • describe the parts of system
  • high level definitions
  • High level collaboration diagrams
    • What are the functional parts and their relations
    • What kind of communication is happening between entities

Collaboration diagram

  • Illustrates object interactions in graph format
  • 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

Specification

  • Specification describes the communication services and behaviour of communicating protocol objects, their interfaces and interactions
    • Should fulfil the requirements found out from use cases.
  • Specification is needed for
    • Implementation to enable interoperability of different implementations
    • Analysis to find out flaws and evaluate protocol behaviour and performance.
    • Testing to validate that implementation corresponds to what was wanted

Specification content

  • Service description
    • What kind of service is provided and how it is related to other protocols
  • Protocol entities
    • Communicating objects and their state machines
  • Communication Interfaces
    • How the service is used and how the communication is conducted between peer entities
  • Message definitions
    • Abstract definition and transfer syntax
  • Interaction
    • MSC Diagrams for different cases
  • List of References

Service description

  • Textual definition of the service the protocol provides
    • What services the protocol provides (e.g secure connection, connectionless data transfer
    • What kind of use this protocol is meant for (e.g. streamed video)
    • List of requirements.
    • List of constraints.
  • Overview of system
    • List of communicating entities of system (computers, devices), ..
      • Also gives roles for them, eg. client - server, peer to peer. These roles will dictate the communication model in more detailed parts.
      • Big picture how the entities are connected to each other
  • Protocol stack
    • If more protocols are defined in specification the relation of the protocols and their interaction

Protocol entities

  • Description of behaviour of CPO's of the system
    • Communicating finite state machines
  • Description of Timers and their use
  • Internal parameters
    • e.g. buffer size
  • Relation of state machines in entity
    • e.g. Creation and destruction of communication entities

Communication Interfaces and messages

  • Service interface for use of this protocol
    • What are the primitives that are used for communicating with upper layer
  • Peer interface
    • What are the PDUs that are used for communication between peers
  • Abstract definition of primitives and PDUs to be used
    • For clear description what is transferred
  • Transfer syntax
    • The format in which the message leaves from one entity and arrives to another

Interaction

  • Description of message flow between entities in different important cases
  • Used for clarifying the wanted behaviour
  • MSC diagram
  • Used for validating the implementation

Specification quality requirements

  • Working.
    • Communications specification is a part of working software (and hardware) system, so it have to represent operational subsystem model.
  • Complete.
    • Specification have to be define everything to make communications to be interoperable. Note: implementation specific details do not belong to specification.
  • Exact.
    • Definition have to be clearly understand.
  • Unambiguous.
    • Specification may not specify same definition by multiple semantics.
  • Focused.
    • Specification should concentrate only to its communication service modelling. Channels to other components (communication layers, databases, user interfaces, sensors, ..) have to be acknowledged by needed interface modelling, but theirs design or even implementation is not current specification business.
  • Consistent.
    • All specifications have to be consistent with each other.
  • Minimal.
    • Specifications should be only defined once and in other occurrences referred (if needed for readability).
  • Referable.
    • Specification works as a agreement between different multiple implementations. Implementation should be able to refer specific parts in specification pages (well keep sense here, and think about reader).
Last modified: 2013/07/01 14:42