Transcript Structured Design

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
Transaction Analysis (contd)

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


Three very similar methods




The structure of a product must conform to the structure of its data
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


Design team should not do too little


Detailed design should not become code
It is essential for the design team to produce a
complete detailed design
Difficult to find ‘great designers’
CS540 Software Design
Lecture 8
22