REQUIREMENTS SPECIFICATION - Model the behaviour with respect to the environment

·       Context Diagram 

·       shows data flow across system and software boundaries.

·       UML does not directly support this diagram

·       Use Object Diagram

System object interacting with external objects.

·       Domain Constraints.

·       Identify problem Domain Constraints.   

·       e.g. “The safety tolerance level should be exceeded  less than 1 per 100,000 containers.”

·       Use Case Analysis

·       Identify scenarios of system/environment interaction.

·       e.g. “1. A container is scanned, found to be sound and caged.”

·       Mode diagram

State transition diagram for whole system.

·       Interaction Diagram

shows sequence of messages across system and software boundaries.

·       Class Diagram

Shows entities and there relationships in the problem domain

Context Diagram for Conveyor System

Use-case structure for the conveyor system

Message Sequences at the Software Interface for the Conveyor System

Design  - Modelling the generation of the software boundary

·       From the model of system interaction, the required behaviour is defined.

·       The class structure to provide this behaviour must now be designed and modelled.

1. Identify Object/Classes

Noun/noun phrase recognition

·       Identifying problem domain entities and their associations

Object  Structuring Categories

·         Several common object types may been identified

Application of Scenarios

·       Identifies solution based entities

·       Refines object model

·       identify object methods

·       identify more object attributes

·       identify object behaviour

NOUN/NOUN PHRASE RECOGNITION

·       Noun from problem description  = possible object

·       Go through description and underline nouns/noun phases.

·       Reject possible objects that are not relevant to the actual working of the system.

·       Some may be useful as object attributes

·       E.g

The Blue Arrow Distribution Company

maintains a series of depots throughout the country from which it distributes retail products on behalf of a range of suppliers. Each depot has a unique depot number as well as an address. Each depot has at least one manager, who can be identified by his/her staff number. In addition, a record is required of a manager's name, address and telephone number. A manager is responsible for no more than one depot at a time.

The Blue Arrow Distribution Company maintains a series of depots throughout the country from which it distributes retail products on behalf of a range of suppliers. Each depot has a unique depot number as well as an address. Each depot has at least one manager, who can be identified by his/her staff number. In addition, a record is required of a manager's name, address and telephone number. A manager is responsible for no more than one depot at a time.

key domain abstractions:

depot(depot number, address), manager(name,address,telephone number,staff number), product and supplier

The others may be discarded because they are out of scope, such as country, or part of the language used to describe the problem, such as record or series.

OBJECT STRUCTURING CATEGORIES

·       Several common object types have been identified

·       These types may recognised directly in requirements descriptions – or used to select objects from noun lists.

Interface object

Object that interfaces to the external environment.

·       Sometimes also referred to as boundary objects. Interface objects can be further categorized as:

·       Device interface object. Interfaces to a hardware I/O device.

·       User interface object. Provides an interface to a human user.

·       System interface object. Interfaces to an external system or subsystem.

Entity object

Long-living object that stores information

Commonly associated with real world entities

Control object

Provides the overall coordination for a collection of objects in a use case.

·       Tend to arise on consideration of dynamic behaviour

Application logic object

·       information systems

Contain business rules = business logic

                                objects

·       real-time, engineering applications.

Contain algorithms = algorithmic objects

Transactions object

Transactions are instances of associations between objects that persist for some significant period of time.

·       E.g transfer money from account A to B

CONVEYOR SYSTEM OBJECTS

·       Interface Objects

Assume one object for each peripheral

                Simple behaviour.

·       Control Objects

Scan and Route procedures require co-ordination.

·       Assume a controller object.

·       Application Objects

The system will need to retain knowledge of Scanning and routing algorithms. This knowledge should be encapsulated.

·       Assume scan and route objects.

APPLICATION OF SCENARIOS

Map scenarios of system/environment interaction onto interacting objects that collectively provide required system behaviour during scenario and define system architecture.

PROBLEM

| |

| |

                                  V

Object Interaction

Given a first cut of proposed objects, system behaviour as directed by use-cases must be generated by co-operation of these objects.

·       NOTE: This represents a dynamic view.

Interaction Diagrams

One method of achieving this is to extend the interaction diagrams of the system interaction model to include internal system behaviour that supports that interaction.

·       Used to refine object properties

·       identify object methods

·       identify more object attributes

·       identify object behaviour

·       Interactions usually highlights several problems

·       gaps in the processing

·       unnatural combination of tasks in an object

·       high levels of interaction

·       e.g conveyor with scan and route objects

 Grouping Objects into Classes

Object Role Superposition

·       Each use-case and associated interaction will provide a view of system behaviour.

·       Message calls to object

·       Calls made by object

·       State behaviour of object

·       Objects instances can be thought of as playing roles in each use case.

·       E.g in scanning the controller plays the role of scanner coordinator.

·       The class definition of an object must accommodate all possible object roles.

·       As each use case is considered, each object role must be superimposed into a class structure that will accommodate all behaviours.

·       All Message calls to object

·       All Calls made by object

·       All State behaviour of object

IDENTIFY CLASS RELATIONSHIPS

Object interactions will imply an association between their respective classes

·       Hence the class structure may be implied by these interactions.

IMPLEMENTATION STRUCTURE

·       The design must now be implemented in code.

·       Object interaction and state behaviour must be implemented.

·       Class definitions and some procedural element.

·       e.g ‘main’ function in Java, C++

OBJECT INTERACTION

one                            two

Start Scan     

Implement as a class C_TWO with a method ‘startScan’ which is referenced by a call from class C_ONE.

Class C_ONE                  Class  C_TWO

{                                      {

………..                                  …………

C_TWO two;                  public void startScan();

two.startScan                        

                                                …………..}

OR

Public Void f1(C_TWO two){

two.startScan;}

//reference of server passed

to client as a function parameter.

………..  }