Communications Software and architecture

requirements and use cases

Literature: Any good book about UML and software design

• 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

• questions that need answers
  • What kind of services we need
  • 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 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 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.

• 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).

• 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

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

• 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.

• 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

• 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

• 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