Structured Design

advertisement

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

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

Download