Slide 13A.1

© The McGraw-Hill Companies, 2005

Object-Oriented and Classical Software

Engineering

Sixth Edition, WCB/McGraw-Hill, 2005

Stephen R. Schachsrs@vuse.vanderbilt.edu

Slide 13A.2

© The McGraw-Hill Companies, 2005

CHAPTER 13 — Unit A

DESIGN

Slide 13A.3

© The McGraw-Hill Companies, 2005

Overview

Design and abstraction Operation-oriented design Data flow analysis Transaction analysis Data-oriented design Object-oriented design Object-oriented design: The elevator problem case

study Object-oriented design: The Osbert Oglesby case

study

Slide 13A.4

© The McGraw-Hill Companies, 2005

Overview (contd)

The design workflow The test workflow: Design Formal techniques for detailed design Real-time design techniques CASE tools for design Metrics for design Challenges of the design workflow

Slide 13A.5

© The McGraw-Hill Companies, 2005

Data and Actions

Two aspects of a productActions that operate on dataData on which actions operate

The two basic ways of designing a productOperation-oriented designData-oriented design

Third wayHybrid methodsFor example, object-oriented design

Slide 13A.6

© The McGraw-Hill Companies, 2005

13.1 Design and Abstraction

Classical design activities Architectural designDetailed designDesign testing

Architectural design Input: SpecificationsOutput: Modular decomposition

Detailed designEach module is designed

» Specific algorithms, data structures

Slide 13A.7

© The McGraw-Hill Companies, 2005

13.2 Operation-Oriented Design

Data flow analysisUse it with most specification methods (Structured

Systems Analysis here)

Key point: We have detailed action information from the DFD

Figure 13.1

Slide 13A.8

© The McGraw-Hill Companies, 2005

Data Flow Analysis

Every product transforms input into output Determine

“Point of highest abstraction of input” “Point of highest abstract of output”

Figure 13.2

Slide 13A.9

© The McGraw-Hill Companies, 2005

Data Flow Analysis (contd)

Decompose the product into three modules

Repeat stepwise until each module has high cohesionMinor modifications may be needed to lower the

coupling

Slide 13A.10

© The McGraw-Hill Companies, 2005

13.3.1 Mini Case Study: Word Counting

Example:Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc )

Figure 13.3

Slide 13A.11

© The McGraw-Hill Companies, 2005

Mini Case Study: Word Counting (contd)

First refinement

Now refine the two modules of communicational cohesion

Figure 13.4

Slide 13A.12

© The McGraw-Hill Companies, 2005

Second refinement

All eight modules now have functional cohesion

Mini Case Study: Word Counting (contd)

Figure 13.5

Slide 13A.13

© The McGraw-Hill Companies, 2005

Word Counting: Detailed Design

The architectural design is completeSo proceed to the detailed design

Two formats for representing the detailed design:TabularPseudocode (PDL—program design language)

Slide 13A.14

© The McGraw-Hill Companies, 2005

Detailed Design: Tabular Format

Figure 13.6(a)

Slide 13A.15

© The McGraw-Hill Companies, 2005

Detailed Design: Tabular Format (contd)

Figure 13.6(b)

Slide 13A.16

© The McGraw-Hill Companies, 2005

Detailed Design: Tabular Format (contd)

Figure 13.6(c)

Slide 13A.17

© The McGraw-Hill Companies, 2005

Detailed Design: Tabular Format (contd)

Figure 13.6(d)

Slide 13A.18

© The McGraw-Hill Companies, 2005

Detailed Design: PDL Format

Figure 13.7

Slide 13A.19

© The McGraw-Hill Companies, 2005

13.3.2 Data Flow Analysis Extensions

In real-world products, there is More than one input stream, and More than one output stream

Slide 13A.20

© The McGraw-Hill Companies, 2005

Data Flow Analysis Extensions (contd)

Find the point of highest abstraction for each stream

Continue until each module has high cohesionAdjust the coupling if needed

Figure 13.8

Slide 13A.21

© The McGraw-Hill Companies, 2005

Continued in Unit 13B