Chapt 3 Design

8/6/2019 Chapt 3 Design

1/64

Design Concepts And Principles

Software Design -- An iterative

process transforming requirements

into a blueprint for constructing thesoftware.


2/64

2

Topics

The Design Process

Design Principles

Design Concepts-Abstraction & Refinement

Software Architecture

Program Partitioning

Coupling and Cohesion


3/64

3

Relation of Analysis to Design


4/64

4

The Design Model Data Design

Transforms information

domain model into data

structures required to

implement software

Architectural Design Defines relationship among

the major structural

elements of a program

Procedural

Design

Interface Design

Architectural Design

Data Design

The Design Model

Which is mapped from the

Analysis model


5/64

5

The Design Model

Interface Design Describes how the software

communicates with itself, to

systems that interact with it

and with humans.

Procedural Design Transforms structural

elements of the architecture

into a procedural

description of softwareconstruction

Procedural

Design

Interface Design

Architectural Design

Data Design

The Design Model

Which is mapped from the

Analysis model


6/64

6

The Design Process

Mc Glaughlins suggestions for good

design:

Design must enable all requirements of the

analysis model and implicit needs of thecustomer to be met

Design must be readable and an understandable

guide for coders, testers and maintainers

The design should address the data, functional

and behavioral domains of implementation


7/64

7

Design Guidelines

A design should exhibit a hierarchical

organization

A design should be modular

A design should contain both data and

procedural abstractions

Modules should exhibit independent

functional characteristics Interfaces should reduce complexity

A design should be obtained from a

repeatable method, driven by analysis


8/64

8

Design Principles

Design Process:Iterative steps that enable description of all aspects

of the software

Designprinciples:The design process should consider various

approaches based on requirements

The design should be traceable to the requirements

analysis model

The design should not reinvent the wheel -- Reuse!

Design should mimic the structure in the problem

domain


9/64

9

Design Principles Design should be uniform and exhibit integrity

Design should accommodate change

Design should minimize coupling between modules

Design should be structured to degrade gently I

t should terminate gracefully and not bomb suddenly Design and coding are not interchangeable

Design should have quality assessment during

creation, not afterwards T

his is to reduce development time Design should be reviewed to minimize on

conceptual errors -- Formal design reviews!

There is a tendency to focus on the wrong things

All conceptual elements have to be addressed


10/64

10

Design Concepts- 1. Abstraction

Wasserman: Abstraction permits one toconcentrate on a problem at some level of

abstraction without regard to low level details

Data Abstraction

This is a named collection of data that describes adata object

Procedural AbstractionInstructions are given in a named sequence

Each instruction has a limited function

Control Abstraction

A program control mechanism without specifying

internal details, e.g., semaphore


11/64

11

2. Refinement

Refinement is a process where one or

several instructions of the program are

decomposed into more detailed instructions.

Stepwise refinement is a top down strategy

Basic architecture is developed iteratively

Step wise hierarchy is developed

Forces a designer to develop low level details asthe design progresses

Design decisions at each stage


12/64

12

3. Modularity

In this concept, software is divided intoseparately named and addressable components

called modules

Follows divide and conquer concept, acomplex problem is broken down into several

manageable pieces

Let p1 and p2 be two program parts, and E the

effort to solve the problem. Then,E(p1+p2) > E(p1)+E(p2), often >>

A need to divide software into optimal sized

modules


13/64

13

Modularity & Software Cost


14/64

14

Modularity

Objectives of modularity in a design method

Modular Decomposability

Provide a systematic mechanism to decompose a

problem into sub problems

Modular Composability

Enable reuse of existing components

Modular Understandability Can the module be understood as a stand alone unit?

Then it is easier to understand and change.


15/64

15

Modularity

Modular Continuity

If small changes to the system requirements result

in changes to individual modules, rather than

system-wide changes, the impact of the side effectsis reduced (note implications in previous example)

Modular Protection

If there is an error in the module, then those errors

are localized and not spread to other modules


16/64

16

4.Software Architecture

Desired properties of an architectural design

Structural PropertiesThis defines the components of a system and the

manner in which these interact with one another. Extra Functional Properties

This addresses how the design architecture

achieves requirements for performance,

reliability and security

Families of Related SystemsThe ability to reuse architectural building blocks


17/64

17

Kinds of Models Terminology

Structural models

Organized collection of components Framework models

Abstract to repeatable architectural patterns

Dynamic models

Behavioral (dynamic) aspects of structure Process models Business or technical process to be built

Functional models Functional hierarchy of the system


18/64

18

5. Control Hierarchy

Is a program structure , represents the

organization of program components andimplies a hierarchy of control.

Tree like diagram is used to represent

hierarchical control.


19/64

19

Structural Diagrams

Depth Indication of the number of levels of control

Width Indication of the overall span of control

Fan-out : Number of

modules that are

directly controlled byanother module

Fan-out (M) = 3

Fan-in (M) = 0

Fan-in : Number of

modules directly control

a given module

Fan-out ( r ) = 0

Fan-in ( r) = 4


20/64

20

Control Hierarchy .

Represents 2 different characteristics of the

software architecture. Visibility

Set of program components that may be invoked or

used as data by a given component either directly or

indirectly. Connectivity

Set of components that are directly invoked or used

as data by a given component.


21/64

21

6. Program Structure Partitioning

Horizontal Partitioning Easier to test Easier to maintain (questionable)

Propagation of fewer side effects (questionable)

Easier to add new featuresF1 (Ex: Input) F2 (Process) F3(Output)


22/64

22

Program Structure Partitioning Vertical Partitioning

Control and work modules are distributed top

down

Top level modules perform control functions

L

ower modules perform computations Less susceptible to side effects Also very maintainable


23/64

23

Information Hiding

Modules are characterized by design

decisions that are hidden from others Modules communicate only through well

defined interfaces

Enforce access constraints to local entities

and those visible through interfaces

Very important for accommodating change

and reducing coupling


24/64

24

type shuttle is private;

function get return shuttle;

function get_lat(s) return float;

function get_x(s) return float;

function get_long(s) return float;

procedure display(s:shuttle);

private

type shuttle is record

x,y,z: float;

roll, pitch,yaw: float;

end record;

Module A specification

s: A.shuttle;

x_coord: float;

s := A.get;

A.display(s);

x_coord := A.get_x(s);

...

Module B body


25/64

25

Functional Independence

Critical in dividing system into independently

implementable parts

Measured by two qualitative criteria

Cohesion

Relative functional strength of a module

Coupling Relative interdependence among modules


26/64

26

Modular Design -- Cohesion

A cohesive module performs a single task

Different levels of cohesion Coincidental, logical, temporal, procedural,

communications, sequential, functional


27/64

27


Coincidental CohesionOccurs when modules are grouped together for

no reason at all

Logical Cohesion Modules have a logical cohesion, but no actual

connection in data and control

Temporal Cohesion

Modules are bound together because they must

be used at approximately the same time


28/64

28


Communication Cohesion Modules grouped together because they access

the same Input/Output devices

Sequential Cohesion

Elements in a module are linked together by the

necessity to be activated in a particular order

Functional Cohesion

All elements of a module relate to theperformance of a single function


29/64

29

Modular Design -- Coupling

Coupling describes the interconnectionamong modules

Data couplingOccurs when one module passes local data values

to another as parameters

Stamp couplingOccurs when part of a data structure is passed to

another module as a parameter


30/64

30

Modular Design -- Coupling

Control Coupling

Occurs when control parameters are passed

between modules

Common CouplingOccurs when multiple modules access common

data areas such as Fortran Common or C extern

Content Coupling

Occurs when a module data in another module

Subclass Coupling

The coupling that a class has with its parent

class


31/64

31

Examples of Coupling


32/64

32

Design Heuristics

Evaluate 1st iteration to reduce coupling &

improve cohesion

Minimize structures with high fan-out;

strive for depth

Keep scope of effect of a module within

scope of control of that module

Evaluate interfaces to reduce complexity

and improve consistency


33/64

33

Design Heuristics

Define modules with predictable function &

avoid being overly restrictive

Avoid static memory between calls where

possible

Strive for controlled entry -- no jumps into the

middle of things

Package software based on design constraints

and portability requirements


34/64

34

Program Structure


35/64

35

Documentation


36/64

36

Summary

Design is the core of software engineering

Design concepts provide the basic criteria

for design quality

Modularity, abstraction and refinement

enable design simplification

A design document is an essential part of

the process


37/64

Design Method---data and architectural design

Design -- A multistep process inwhich representations of data

structure, program structure, interface

characteristics, and procedural detail

are synthesized.


38/64

38

Data Design

What is data design?

T

ransform the information domain modelcreated during analysis into data structure

required to implement the software

Well-designed data lead to better program

structure and modularity, reduced proceduralcomplexity


39/64

39

Data Design Process Define data structures identified during the

requirements and specification phase.

Often base decision on algorithm to be used. Identify all program modules that must operate

directly upon the data structure

Constrain the scope of effect of data designdecisions

Or, from OO perspective, define all operations

performed on the data structure


40/64

40

Principles of Data Design A data dictionary should be established and

used for both data and program design

Low-level data design decisions should bedeferred until late in the design process

A library of useful data structures and the

operations that may be applied to them should

be developed. -- Reuse

E.g., stacks, lists, arrays, queues


41/64

41

Principles of Data Design (cont.) The representation of data structures should

be known only to those modules that must

make direct use of the data contained withinthe structure.

Information hiding

The software design and programminglanguages should support the specification

and realization of abstract data types.


42/64

42

Architectural Design Objective develop a modular program structure and represent

control relationships between modules

Data flow-oriented design amenable to a broad range of applications

very useful when information is processed sequentially,

such as microprocessor control application; complex,

numerical analysis procedure; etc.

two approaches (transform and transaction mapping)


43/64

43

Architectural Design Process

Five-step Process

the type of information flow is established

flow boundary are indicated

data flow diagram is mapped into program

structure

control hierarchy is defined by factoring

resultant structure is refined using design

measures heuristics


44/64

44

Architectural Design Process(cont.)

Transform Flow

A Btransform

center

incoming flow outgoing flows

C


45/64

45

Architectural Design Process(cont.)

Transaction Flow

T

Transaction

center

T

ransactionAction

paths


46/64

46

Transform Mapping

Allow data flow diagram(DFD) with

transform flow characteristics to be mapped

into a predefined template for program

structure


47/64

47

Level 0 Safehome DFD


48/64

48R. A. Volz --Assistance- Haichen 48

Level 1 Safehome DFD


49/64

4949

Level 2 Safehome DFD -

Monitor


50/64

50

Transform Mapping (cont) Design steps

Step 1. Review the fundamental system model.

Step 2. Review and refine data flow diagrams for

the software.

Step 3. Determine whether DFD has transform or

transaction flow characteristics. in general---transform flow

special case---transaction flow


51/64

51

5

1

Level 3 DFD for Monitor Sensors


52/64

52

Transform Mapping (cont) step 4. Isolate the transform center by specifying

incoming and outgoing flow boundaries different designers may select slightly differently

transform center can contain more than one bubble. step 5. Perform first-level factoring

program structure represent a top-down distribution

control.

factoring results in a program structure(top-level,

middle-level, low-level)

number of modules limited to minimum.


53/64

53R. A. Volz --Assistance- Haichen5

3

First Level Factoring


54/64

54

Transform Mapping (cont)

step 6. Perform second-level factoring

mapping individual transforms(bubbles) to

appropriate modules.

factoring accomplished by moving outwards from

transform center boundary.

step 7. Refine the first iteration program

structure using design heuristics for improvedsoftware quality.


55/64


Second Level Factoring


56/64

56

56

First-Cut Program Structure


57/64


Refined Program Structure


58/64


Transaction MappingA single data item triggers one or more information flows


59/64

59

Transaction Mapping Design Step 1.Review the fundamental system model.

Step 2.Review and refine DFD for the software

Step 3.Determine whether the DFD has transform ortransaction flow characteristics

Step 4. Identify the transaction center and flow

characteristics along each of the action paths isolate incoming path and all action paths

each action path evaluated for its flow characteristic.


60/64

60

Transaction Mapping (cont) step 5. Map the DFD in a program

structure amenable to transaction

processing

incoming branch

bubbles along this path map to modules

dispatch branch

dispatcher module controls all subordinate actionmodules

each action path mapped to corresponding structure


61/64


Transaction Mapping


62/64

62

62

First Level Factoring


63/64

63

First-cut Program Structure


64/64

Transaction Mapping (cont)

step 6. Factor and refine the transaction

structure and the structure of each action

path

step 7. Refine the first iteration program

structure using design heuristics for

improved software quality

Date post:	08-Apr-2018
Category:	Documents
Upload:	shekhar-shelke
View:	228 times
Download:	0 times

Chapt 3 Design

Documents