design concepts and principles

8/9/2019 Design Concepts And Principles

1/40

Design Concepts And Principles

Software Design -- An iterative process transforming requirements

into a blueprint for constructing thesoftware.


2/40

Sep. 2003 2S.E. - RSP

Topics

T he Design ProcessDesign PrinciplesDesign Concepts-Abstraction & RefinementSoftware ArchitectureProgram PartitioningCoupling and Cohesion


3/40


4/40

Sep. 2003 4S.E. - RSP

The Design ModelData Design T ransforms information

domain model into datastructures required toimplement software

Architectural Design Defines relationship among

the major structuralelements of a program

ProceduralDesign

Interface Design

Architectural Design

Data Design

T he Design Model

Which is mapped from the

Analysis model


5/40

Sep. 2003 5S.E. - RSP

The Design Model

I nterface Design Describes how the software

communicates with itself, tosystems that interact with it

and with humans.Procedural Design T ransforms structural

elements of the architectureinto a procedural

description of softwareconstruction

ProceduralDesign

Interface Design

Architectural Design

Data Design

T he Design Model

Which is mapped from the

Analysis model


6/40

Sep. 2003 6S.E. - RSP

The Design ProcessMc Glaughlins suggestions for gooddesign: Design must enable all requirements of the

analysis model and implicit needs of thecustomer to be met

Design must be readable and an understandableguide for coders, testers and maintainers

T he design should address the data, functionaland behavioral domains of implementation


7/40

Sep. 2003 7

Design GuidelinesA design should exhibit a hierarchicalorganizationA design should be modular A design should contain both data and

procedural abstractionsModules should exhibit independent

functional characteristicsI nterfaces should reduce complexityA design should be obtained from arepeatable method, driven by analysis


8/40

Sep. 2003 8S.E. - RSP

Design PrinciplesDesign Process: I terative steps that enable description of all aspects

of the software

Design principles: T he design process should consider various

approaches based on requirements T he design should be traceable to the requirements

analysis model T he design should not reinvent the wheel -- Reuse! Design should mimic the structure in the problem

domain


9/40

Sep. 2003 9S.E. - RSP

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

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

Design should have quality assessment duringcreation, not afterwards

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

conceptual errors -- Formal design reviews! T here is a tendency to focus on the wrong things

All conceptual elements have to be addressed


10/40

Sep. 2003 10

Specification

Body

Module

T ype definitions

Subprogram profiles

Constants

Specification

Encapsulated dataSubprogram definitions

Body


11/40

Sep. 2003 11

Proc Main;

x: tp;ax: a;

p(x);

ax = F;...

type tp is ..type a is

access tp;

Proc P(z: tp);func F ret a;

Y: tp;Proc P isend P;func F is end F;

//

//

C aution

withpointers!!


12/40

Sep. 2003 12

type shuttle is recordx: float; -- wrt to coord sysy: float; -- wrt to coord sys

z: float: -- wrt to coord sysroll: float; pitch: float;yaw: float;

end record;function get return shuttle;

Module A specification

s: A.shuttle;

x_coord: float;

s := A.get;

display(s);

x_coord := s.x;

...

Module B body

Body A


13/40

Sep. 2003 13

type shuttle is recordx: float; -- latitudey: float; -- longitude

z: float: -- elevationroll: float; pitch: float;yaw: float;

end record;function get return shuttle;


s: A.shuttle;

x_coord: float;

s := A.get;

display(s);

x_coord := s.x;

...

Module B body

Body A


14/40

Sep. 2003 14

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);privatetype shuttle is record

x,y,z: float;roll, pitch,yaw: float;

end record;


s: A.shuttle;

x_coord: float;

s := A.get;

A.display(s);

x_coord := A.get_x(s);

...

Module B body


15/40

Sep. 2003 15S.E. - RSP

Design Concepts- AbstractionWasserman: Abstraction permits one toconcentrate on a problem at some level of abstraction without regard to low level detailsData Abstraction T his is a named collection of data that describes a

data objectProcedural Abstraction I nstructions are given in a named sequence Each instruction has a limited functionControl Abstraction A program control mechanism without specifying

internal details, e.g., semaphore.


16/40

Sep. 2003 16S.E. - RSP

R efinement

Refinement is a process where one or several instructions of the program aredecomposed 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


17/40

Sep. 2003 17S.E. - RSP

ModularityI n this concept, software is divided intoseparately named and addressable componentscalled modules

Follows divide and conquer concept, acomplex problem is broken down into severalmanageable piecesL et p 1 and p 2 be two program parts, and E the

effort to solve the problem. T hen,E(p 1+p 2) > E(p 1)+E(p 2), often >>

A need to divide software into optimal sizedmodules


18/40

Sep. 2003 18

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);privatetype shuttle is record


end record;


s: A.shuttle;

x_coord: float;

s := A.get;

A.display(s);


...

Module B body


19/40

Sep. 2003 19

Modularity & Software Cost


20/40

Sep. 2003 20S.E. - RSP

ModularityO bjectives of modularity in a design method

Modular Decomposability Provide a systematic mechanism to decompose a

problem into sub problemsModular Composability Enable reuse of existing components

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

T hen it is easier to understand and change.


21/40

Sep. 2003 21S.E. - RSP

ModularityModular Continuity I f 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 I f there is an error in the module, then those errors

are localized and not spread to other modules


22/40

Sep. 2003 22S.E. - RSP

S oftware Architecture

Desired properties of an architectural designStructural Properties T his defines the components of a system and the

manner in which these interact with one another.Extra Functional Properties T his addresses how the design architecture

achieves requirements for performance,reliability and security

Families of Related Systems T he ability to reuse architectural building blocks


23/40

Sep. 2003 23

Structural Diagrams


24/40

Sep. 2003 24

K inds of ModelsT erminology Structural models

O rganized 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


25/40

Sep. 2003 25S.E. - RSP

Program S tructure Partitioning

H orizontal Partitioning Easier to test Easier to maintain (questionable) Propagation of fewer side effects (questionable)

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


26/40

Sep. 2003 26S.E. - RSP

Program S tructure PartitioningV

ertical Partitioning Control and work modules are distributed topdown

T op level modules perform control functions

L

ower modules perform computations Less susceptible to side effectsAlso very maintainable


27/40

Sep. 2003 27

I nformation H idingModules are characterized by design

decisions that are hidden from othersModules communicate only through welldefined interfacesEnforce access constraints to local entitiesand those visible through interfacesV ery important for accommodating changeand reducing coupling


28/40

Sep. 2003 28

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);privatetype shuttle is record


end record;


s: A.shuttle;

x_coord: float;

s := A.get;

A.display(s);


...

Module B body


29/40

Sep. 2003 29

Functional I ndependence

Critical in dividing system into independentlyimplementable partsMeasured by two qualitative criteria Cohesion

Relative functional strength of a module

CouplingRelative interdependence among modules


30/40

Sep. 2003 30

Modular Design -- CohesionA cohesive module performs a single task

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

communications, sequential, functional


31/40

Sep. 2003 31S.E. - RSP

Modular Design -- Cohesion

Coincidental Cohesion O ccurs when modules are grouped together for

no reason at all

L ogical Cohesion Modules have a logical cohesion, but no actual

connection in data and controlT emporal Cohesion Modules are bound together because they must

be used at approximately the same time


32/40

Sep. 2003 32S.E. - RSP

Modular Design -- Cohesion

Communication Cohesion Modules grouped together because they access

the same I nput/ O utput 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 the performance of a single function


33/40

Sep. 2003 33S.E. - RSP

Modular Design -- Coupling

Coupling describes the interconnectionamong modulesData coupling O ccurs when one module passes local data values

to another as parametersStamp coupling O ccurs when part of a data structure is passed to

another module as a parameter


34/40

Sep. 2003 34S.E. - RSP

Modular Design -- Coupling

Control Coupling O ccurs when control parameters are passed

between modules

Common Coupling O ccurs when multiple modules access common

data areas such as Fortran Common or C extern

Content Coupling O ccurs when a module data in another moduleSubclass Coupling T he coupling that a class has with its parent

class


35/40

Sep. 2003 35

Examples of Coupling


36/40

Sep. 2003 36

Design H euristicsEvaluate 1st iteration to reduce coupling &improve cohesionMinimize structures with high fan-out;strive for depthK eep scope of effect of a module withinscope of control of that moduleEvaluate interfaces to reduce complexityand improve consistency


37/40

Sep. 2003 37

Design H euristicsDefine 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 thingsPackage software based on design constraintsand portability requirements


38/40

Sep. 2003 38

Program Structure


39/40

Sep. 2003 39

Documentation


40/40

Sep. 2003 40S.E. - RSP

S ummary

Design is the core of software engineeringDesign concepts provide the basic criteriafor design qualityModularity, abstraction and refinementenable design simplificationA design document is an essential part of the process

design concepts and principles

Documents