Data and Actions
Two aspects of a product
Actions which operate on data
Data on which actions operate
The two basic ways of designing a product
Action-oriented design
Data-oriented design
Third way
Hybrid methods
For example, object-oriented design
CS540 Software Design Lecture 8 2
Design Activities
Architectural design
Detailed design
Design testing
CS540 Software Design Lecture 8 3
Architectural Design
Input: Specifications
Output: Modular decomposition
Abstraction
CS540 Software Design Lecture 8 4
Detailed Design
Each module is designed
Specific algorithms
Data structures
CS540 Software Design Lecture 8 5
Action-Oriented Design Methods
Data flow analysis
When to use it
With most specification methods (Structured
Systems Analysis here)
Key point: Have detailed action information from DFD
CS540 Software Design Lecture 8 6
How to Perform Data Flow Analysis?
Data Flow Analysis (DFA) is a design technique for achieving modules with high cohesion
Using the points of highest abstraction of input and output, the product is decomposed into three modules: input module , transform module and output module
This procedure is continued stepwise until each module performs a single action i.e., the design consists of modules with high cohesion
CS540 Software Design Lecture 8 7
Data Flow Analysis
Product transforms input into output
Determine
“Point of highest abstraction of input”
“Point of highest abstract of output”
CS540 Software Design Lecture 8 8
Data Flow Analysis (contd)
Decompose into three modules
Repeat stepwise until each module has high cohesion
Minor modifications may be needed to lower coupling
CS540 Software Design Lecture 8 9
Data Flow Analysis (contd)
Example
Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc )
CS540 Software Design Lecture 8 10
Data Flow Analysis Example(contd)
First refinement
Refine modules of communicational cohesion
CS540 Software Design Lecture 8 11
Data Flow Analysis Example(contd)
Second refinement
All eight modules have functional cohesion
CS540 Software Design Lecture 8 12
Multiple Input and Output Streams
Point of highest abstraction for each stream
Continue until each module has high cohesion
Adjust coupling if needed
CS540 Software Design Lecture 8 13
Transaction Analysis
DFA poor for transaction processing products
Example: ATM (Automatic Teller Machine)
CS540 Software Design Lecture 8 14
Poor design
Logical cohesion, control coupling
On the other hand it seems a waste of time and effort to have five very similar edit modules and five very similar update modules
CS540 Software Design Lecture 8 15
Corrected Design Using Transaction Analysis
Software reuse (Section 8.1)
A basic edit module should be designed, coded, documented and tested, then instantiated five times. Each version will be slightly different but the differences will be small enough to make this worthwhile.
Similarly a basic update module can be instantiated five times and slightly modified to cater to the five different update types.
The resulting design has high cohesion and low coupling
CS540 Software Design Lecture 8 16
Data-Oriented Design
Basic principle
The structure of a product must conform to the structure of its data
Three very similar methods
Warnier
Orr
Jackson
Data-oriented design
Has never been as popular as action-oriented design
With the rise of OOD, data-oriented design has largely fallen out of fashion
CS540 Software Design Lecture 8 17
Design of Real-Time Systems
Difficulties associated with real-time systems
Inputs come from real world
Software has no control over timing of inputs
Frequently implemented on distributed software
Communications implications
Timing issues
Problems of synchronization
Race conditions
Deadlock (deadly embrace)
Major difficulty in design of real-time systems
Determining whether the timing constraints are met by the design
CS540 Software Design Lecture 8 18
Real-Time Design Methods
Usually, extensions of nonreal-time methods to real-time
We have limited experience in use of any real-time methods
The state-of-the-art is not where we would like it to be
CS540 Software Design Lecture 8 19
Testing during the Design Phase
Design reviews
Design must correctly reflect specifications
Design itself must be correct
Transaction-driven inspections
CS540 Software Design Lecture 8 20
Metrics for the Design Phase
The five basic metrics
Cyclomatic complexity is problematic
Data complexity is ignored
Little use with object-oriented paradigm
CS540 Software Design Lecture 8 21
Challenges of the Design Phase
Design team should not do too much
Detailed design should not become code
Design team should not do too little
It is essential for the design team to produce a complete detailed design
Difficult to find ‘great designers’
CS540 Software Design Lecture 8 22