DESIGN CHAPTER 14

(1)

CHAPTER 14 DESIGN

(2)

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 MSG Foundation case study

(3)

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

(4)

Data and Actions

 Two aspects of a product

– Actions that operate on data – Data on which actions operate

 The two basic ways of designing a product

– Operation-oriented design – Data-oriented design

 Third way

– Hybrid methods

– For example, object-oriented design

(5)

14.1 Design and Abstraction

 Classical design activities

– Architectural design – Detailed design

– Design testing

 Architectural design

– Input: Specifications

– Output: Modular decomposition

 Detailed design

– Each module is designed

» Specific algorithms, data structures

(6)

14.2 Operation-Oriented Design

 Data flow analysis

– Use it with most specification methods (Structured Systems Analysis here)

 Key point: We have detailed action information from the DFD

Figure 14.1

(7)

Data Flow Analysis

 Every product transforms input into output

 Determine

– “Point of highest abstraction of input”

– “Point of highest abstract of output”

Figure 14.2

(8)

Data Flow Analysis (contd)

 Decompose the product into three modules

 Repeat stepwise until each module has high cohesion

– Minor modifications may be needed to lower the coupling

(9)

14.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 14.3

(10)

Mini Case Study: Word Counting (contd)

 First refinement

 Now refine the two modules of communicational cohesion

Figure 14.4

(11)

Mini Case Study: Word Counting (contd)

 Second refinement

 All eight modules now have functional cohesion

Figure 14.5

(12)

Word Counting: Detailed Design

 The architectural design is complete

– So proceed to the detailed design

 Two formats for representing the detailed design:

– Tabular

– Pseudocode (PDL — program design language)

(13)

Detailed Design: Tabular Format

Figure 14.6(a)

(14)

Detailed Design: Tabular Format (contd)

Figure 14.6(b)

(15)

Detailed Design: Tabular Format (contd)

Figure 14.6(c)

(16)

Detailed Design: Tabular Format (contd)

Figure 14.6(d)

(17)

Detailed Design: PDL Format

Figure 14.7

(18)

14.3.2 Data Flow Analysis Extensions

 In real-world products, there is

– More than one input stream, and – More than one output stream

(19)

Data Flow Analysis Extensions (contd)

 Find the point of highest abstraction for each stream

 Continue until each module has high cohesion

– Adjust the coupling if needed

Figure 14.8

(20)

14.4 Transaction Analysis

 DFA is poor for transaction processing products

– Example: ATM (automated teller machine)

Figure 14.9

(21)

Transaction Analysis (contd)

 This is a poor design

– There is logical cohesion and control coupling

(22)

Corrected Design Using Transaction Analysis

 Software reuse

 Have one generic edit

module, one generic update

module

 Instantiate them 5 times

Figure 14.10

(23)

14.5 Data-Oriented Design

 Basic principle

– The structure of a product must conform to the structure of its data

 Three very similar methods

– Michael Jackson [1975], Warnier [1976], Orr [1981]

 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

(24)

14.6 Object-Oriented Design (OOD)

 Aim

– Design the product in terms of the classes extracted during OOA

 If we are using a language without inheritance (e.g., C, Ada 83)

– Use abstract data type design

 If we are using a language without a type statement (e.g., FORTRAN, COBOL)

– Use data encapsulation

(25)

Object-Oriented Design Steps

 OOD consists of two steps:

 Step 1. Complete the class diagram

– Determine the formats of the attributes

– Assign each method, either to a class or to a client that sends a message to an object of that class

 Step 2. Perform the detailed design

(26)

Object-Oriented Design Steps (contd)

– The formats of the attributes can be directly deduced from the analysis artifacts

 Example: Dates

– U.S. format (mm/mm/yyyy)

– European format (dd/mm/yyyy)

– In both instances, 10 characters are needed

 The formats could be added during analysis

– To minimize rework, never add an item to a UML diagram until strictly necessary

(27)

Object-Oriented Design Steps (contd)

– Assign each method, either to a class or to a client that sends a message to an object of that class

 Principle A: Information hiding

 Principle B: If an operation is invoked by many clients of an object, assign the method to the object, not the clients

 Principle C: Responsibility-driven design

(28)

14.7 Object-Oriented Design: The Elevator Problem Case Study

 Consider the second iteration of the CRC card for the elevator controller

(29)

OOD: Elevator Problem Case Study (contd)

 CRC card

Figure 13.9 (again)

(30)

OOD: Elevator Problem Case Study (contd)

 Responsibilities

– 8. Start timer

– 10. Check requests, and – 11. Update requests

are assigned to the elevator controller

 Because they are carried out by the elevator controller

(31)

OOD: Elevator Problem Case Study (contd)

 The remaining eight responsibilities have the form

– “Send a message to another class to tell it do something”

 These should be assigned to that other class

– Responsibility-driven design – Safety considerations

 Methods open doors, clos^{e doors}are assigned to class Elevator Doors Class

 Methods turn off button, turn on button are assigned to classes Floor Button Class and Elevator Problem Class

(32)

Figure 14.11

Detailed Class Diagram: Elevator Problem

(33)

Detailed Design: Elevator Problem

 Detailed design of elevatorEventLoop

is constructed from the

statechart

Figure 14.12

(34)

14.8 Object-Oriented Design: The MSG Foundation Case Study

 The final class diagram is shown in the next slide

– Date Class is needed for C++

– Java has built-it functions for handling dates

(35)

Final Class Diagram: MSG Foundation

Figure 14.13

(36)

Class Diagram with Attributes: MSG Foundation

Figure 14.14

(37)

Assigning Methods to Classes: MSG Foundation

 Example: setAssetNumber^,getAssetNumber

– From the inheritance tree, these accessor/mutator methods should be assigned to Asset Class

– So that they can be inherited by both subclasses of

Asset Class (Investment Class and Mortgage Class)

Figure 14.15

(38)

Assigning Methods to Classes: MSG Foundation (contd)

 Assigning the other methods is equally straightforward

– See Appendix G

(39)

Detailed Design: MSG Foundation

 Determine what each method does

 Represent the detailed design in an appropriate format

– PDL (pseudocode) here

(40)

Method

EstimateFundsForWeek::computeEstimatedFunds

Figure 14.16

(41)

Method

Mortgage::totalWeeklyNetPayments

Figure 14.17

(42)

14.9 The Design Workflow

 Summary of the design workflow:

– The analysis workflow artifacts are iterated and integrated until the programmers can utilize them

 Decisions to be made include:

– Implementation language – Reuse

– Portability

(43)

The Design Workflow (contd)

 The idea of decomposing a large workflow into independent smaller workflows (packages) is carried forward to the design workflow

 The objective is to break up the upcoming

implementation workflow into manageable pieces

– Subsystems

 It does not make sense to break up the MSG

Foundation case study into subsystems — it is too small

(44)

The Design Workflow (contd)

 Why the product is broken into subsystems:

– It is easier to implement a number of smaller subsystems than one large system

– If the subsystems are independent, they can be

implemented by programming teams working in parallel

» The software product as a whole can then be delivered sooner

(45)

The Design Workflow (contd)

 The architecture of a software product includes

– The various components – How they fit together

– The allocation of components to subsystems

 The task of designing the architecture is specialized

– It is performed by a software architect

(46)

The Design Workflow (contd)

 The architect needs to make trade-offs

– Every software product must satisfy its functional requirements (the use cases)

– It also must satisfy its nonfunctional requirements, including

» Portability, reliability, robustness, maintainability, and security

– It must do all these things within budget and time constraints

 The architect must assist the client by laying out the trade-offs

(47)

The Design Workflow (contd)

 It is usually impossible to satisfy all the

requirements, functional and nonfunctional, within the cost and time constraints

– Some sort of compromises have to be made

 The client has to

– Relax some of the requirements;

– Increase the budget; and/or – Move the delivery deadline

(48)

The Design Workflow (contd)

 The architecture of a software product is critical

– The requirements workflow can be fixed during the analysis workflow

– The analysis workflow can be fixed during the design workflow

– The design workflow can be fixed during the implementation workflow

 But there is no way to recover from a suboptimal architecture

– The architecture must immediately be redesigned

(49)

14.10 The Test Workflow: Design

 Design reviews must be performed

– The design must correctly reflect the specifications – The design itself must be correct

 Transaction-driven inspections

– Essential for transaction-oriented products

– However, they are insufficient — specification-driven inspections are also needed

(50)

14.11 The Test Workflow: The MSG Foundation Case Study

 A design inspection must be performed

– All aspects of the design must be checked

 Even if no faults are found, the design may be changed during the implementation workflow

(51)

14.12 Formal Techniques for Detailed Design

 Implementing a complete product and then proving it correct is hard

 However, use of formal techniques during detailed design can help

– Correctness proving can be applied to module-sized pieces

– The design should have fewer faults if it is developed in parallel with a correctness proof

– If the same programmer does the detailed design and implementation

» The programmer will have a positive attitude to the detailed design

» This should lead to fewer faults

(52)

14.13 Real-Time Design Techniques

 Difficulties associated with real-time systems

– Inputs come from the real world

» Software has no control over the timing of the inputs

– Frequently implemented on distributed software

» Communications implications

» Timing issues

– Problems of synchronization

» Race conditions

» Deadlock (deadly embrace)

(53)

Real-Time Design Techniques (contd)

 The major difficulty in the design of real-time systems

– Determining whether the timing constraints are met by the design

(54)

Real-Time Design Techniques (contd)

 Most real-time design methods are extensions of non-real-time methods to real-time

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

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

(55)

14.14 CASE Tools for Design

 It is critical to check that the design artifacts incorporate all aspects of the analysis

– To handle analysis and design artifacts we therefore need upperCASE tools

 UpperCASE tools

– Are built around a data dictionary

– They incorporate a consistency checker, and – Screen and report generators

– Management tools are sometimes included, for

» Estimating

» Planning

(56)

CASE Tools for Design (contd)

 Examples of tools for object-oriented design

– Commercial tools

» Software through Pictures

» IBM Rational Rose

» Together

– Open-source tool

» ArgoUML

(57)

14.15 Metrics for Design

 Measures of design quality

– Cohesion – Coupling

– Fault statistics

 Cyclomatic complexity is problematic

– Data complexity is ignored

– It is not used much with the object-oriented paradigm

(58)

Metrics for Design (contd)

 Metrics have been put forward for the object- oriented paradigm

– They have been challenged on both theoretical and experimental grounds

(59)

14.16 Challenges of the Design Phase

 The design team should not do too much

– The detailed design should not become code

 The design team should not do too little

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

(60)

Challenges of the Design Phase (contd)

 We need to “grow” great designers

 Potential great designers must be

– Identified,

– Provided with a formal education, – Apprenticed to great designers, and

– Allowed to interact with other designers

 There must be a specific career path for these designers, with appropriate rewards

(61)

Overview of the MSG Foundation Case Study

Figure 14.18

(62)

Overview of the Elevator Problem Case Study

Figure 14.19