cs540 software design lecture 8 1 lecture 8: structured design anita s. malik [email protected]...

21
CS540 Software Desi gn 2 Lecture 8 Data and Actions Data and Actions Two aspects of a product Two aspects of a product Actions which operate on data Actions which operate on data Data on which actions operate Data on which actions operate The two basic ways of designing The two basic ways of designing a product a product Action-oriented design Action-oriented design Data-oriented design Data-oriented design Third way Third way Hybrid methods Hybrid methods For example, object-oriented design For example, object-oriented design

Upload: emerald-wilkinson

Post on 16-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 2Lecture 8

Data and ActionsData and Actions Two aspects of a productTwo aspects of a product

Actions which operate on dataActions which operate on data Data on which actions operateData on which actions operate

The two basic ways of designing a The two basic ways of designing a productproduct Action-oriented designAction-oriented design Data-oriented designData-oriented design

Third wayThird way Hybrid methodsHybrid methods For example, object-oriented designFor example, object-oriented design

Page 2: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 3Lecture 8

Design ActivitiesDesign Activities

Architectural designArchitectural design Detailed designDetailed design Design testingDesign testing

Page 3: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 4Lecture 8

Architectural DesignArchitectural Design

Input: Input: SpecificationsSpecifications Output: Output: Modular decompositionModular decomposition AbstractionAbstraction

Page 4: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 5Lecture 8

Detailed DesignDetailed Design

Each module is designedEach module is designed Specific algorithmsSpecific algorithms Data structuresData structures

Page 5: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 6Lecture 8

Action-Oriented Design Action-Oriented Design MethodsMethods

Data flow analysisData flow analysis When to use itWhen to use it

With most specification methods (Structured With most specification methods (Structured Systems Analysis here)Systems Analysis here)

Key point: Have detailed action Key point: Have detailed action information from DFD information from DFD

Page 6: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 7Lecture 8

How to Perform Data Flow How to Perform Data Flow Analysis?Analysis?

Data Flow Analysis (DFA) is a design Data Flow Analysis (DFA) is a design technique for achieving modules with high technique for achieving modules with high cohesioncohesion

Using the Using the points of highest abstractionpoints of highest abstraction of of input and output, the product is input and output, the product is decomposed into three modules: decomposed into three modules: input input modulemodule, , transform moduletransform module and and output output modulemodule

This procedure is continued stepwise until This procedure is continued stepwise until each module performs a single action i.e., each module performs a single action i.e., the design consists of modules with high the design consists of modules with high cohesioncohesion

Page 7: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 8Lecture 8

Data Flow AnalysisData Flow Analysis Product transforms input into outputProduct transforms input into output DetermineDetermine

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

Page 8: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 9Lecture 8

Data Flow Analysis (contd)Data Flow Analysis (contd)

Decompose into three modulesDecompose into three modules Repeat stepwise until each module Repeat stepwise until each module

has high cohesionhas high cohesion Minor modifications may be needed Minor modifications may be needed

to lower coupling to lower coupling

Page 9: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 10Lecture 8

Data Flow Analysis (contd)Data Flow Analysis (contd) ExampleExample

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

Page 10: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 11Lecture 8

Data Flow Analysis Data Flow Analysis Example(contd)Example(contd) First refinementFirst refinement

Refine modules of communicational cohesionRefine modules of communicational cohesion

Page 11: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 12Lecture 8

Data Flow Analysis Data Flow Analysis Example(contd)Example(contd) Second refinementSecond refinement

All eight modules have functional cohesionAll eight modules have functional cohesion

Page 12: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 13Lecture 8

Multiple Input and Output Multiple Input and Output StreamsStreams Point of highest abstraction for each streamPoint of highest abstraction for each stream

Continue until each module has high cohesionContinue until each module has high cohesion Adjust coupling if neededAdjust coupling if needed

Page 13: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 14Lecture 8

Transaction AnalysisTransaction Analysis DFA poor for transaction processing DFA poor for transaction processing

products products Example: ATM (Automatic Teller Example: ATM (Automatic Teller

Machine)Machine)

Page 14: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 15Lecture 8

Transaction Analysis Transaction Analysis (contd)(contd)

Poor designPoor design Logical cohesion, Logical cohesion,

control couplingcontrol coupling On the other hand On the other hand

it seems a waste of it seems a waste of time and effort to time and effort to have five very have five very similar edit similar edit modules and five modules and five very similar update very similar update modulesmodules

Page 15: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 16Lecture 8

Corrected Design Using Corrected Design Using Transaction AnalysisTransaction Analysis

Software reuse (Section 8.1)Software reuse (Section 8.1) A basic edit module should be designed, A basic edit module should be designed,

coded, documented and tested, then coded, documented and tested, then instantiated five times. Each version will be instantiated five times. Each version will be slightly different but the differences will be slightly different but the differences will be small enough to make this worthwhile. small enough to make this worthwhile.

Similarly a basic update module can be Similarly a basic update module can be instantiated five times and slightly modified to instantiated five times and slightly modified to cater to the five different update types.cater to the five different update types.

The resulting design has high cohesion and The resulting design has high cohesion and low couplinglow coupling

Page 16: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 17Lecture 8

Data-Oriented DesignData-Oriented Design

Basic principleBasic principle The structure of a product must conform to the structure of its The structure of a product must conform to the structure of its

datadata

Three very similar methodsThree very similar methods WarnierWarnier OrrOrr JacksonJackson

Data-oriented designData-oriented design Has never been as popular as action-oriented Has never been as popular as action-oriented

designdesign With the rise of OOD, data-oriented design has With the rise of OOD, data-oriented design has

largely fallen out of fashionlargely fallen out of fashion

Page 17: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 18Lecture 8

Design of Real-Time Design of Real-Time SystemsSystems

Difficulties associated with real-time systemsDifficulties associated with real-time systems Inputs come from real worldInputs come from real world

Software has no control over timing of inputsSoftware has no control over timing of inputs Frequently implemented on distributed softwareFrequently implemented on distributed software

Communications implicationsCommunications implications Timing issuesTiming issues

Problems of synchronizationProblems of synchronization Race conditionsRace conditions Deadlock (deadly embrace)Deadlock (deadly embrace)

Major difficulty in design of real-time Major difficulty in design of real-time systems systems Determining whether the timing constraints are met by Determining whether the timing constraints are met by

the designthe design

Page 18: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 19Lecture 8

Real-Time Design MethodsReal-Time Design Methods

Usually, extensions of nonreal-time methods to Usually, extensions of nonreal-time methods to real-time real-time

We have limited experience in use of any real-We have limited experience in use of any real-time methodstime methods

The state-of-the-art is not where we would like The state-of-the-art is not where we would like it to beit to be

Page 19: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 20Lecture 8

Testing during the Design Testing during the Design PhasePhase

Design reviewsDesign reviews Design must correctly reflect Design must correctly reflect

specificationsspecifications Design itself must be correctDesign itself must be correct Transaction-driven inspectionsTransaction-driven inspections

Page 20: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 21Lecture 8

Metrics for the Design Metrics for the Design PhasePhase

The five basic metricsThe five basic metrics Cyclomatic complexity is problematicCyclomatic complexity is problematic

Data complexity is ignoredData complexity is ignored Little use with object-oriented paradigmLittle use with object-oriented paradigm

Page 21: CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix

CS540 Software Design 22Lecture 8

Challenges of the Design Challenges of the Design PhasePhase

Design team should not do too muchDesign team should not do too much Detailed design should not become Detailed design should not become

codecode Design team should not do too littleDesign team should not do too little

It is essential for the design team to It is essential for the design team to produce a complete detailed designproduce a complete detailed design

Difficult to find ‘great designers’Difficult to find ‘great designers’