Design Concepts And Principles

Software Design -- An iterative

process transforming requirements
into a “blueprint” for constructing the
software.
 Topics

• The Design Process

• Design Principles
• Design Concepts-Abstraction & Refinement
• Software Architecture
• Program Partitioning
• Coupling and Cohesion

2
Relation of Analysis to Design

3
 The Design Model
• Data Design
– Transforms information
domain model into data
structures required to
implement software Procedural
Design
• Architectural Design
– Defines relationship among Interface Design
the major structural
elements of a program Architectural Design

Data Design

The Design Model

Which is mapped from the
Analysis model
4
 The Design Model
• Interface Design
– Describes how the software
communicates with itself,
Procedural
to systems that interact with Design
it and with humans.
• Procedural Design Interface Design

– Transforms structural
Architectural Design
elements of the architecture
into a procedural
description of software Data Design
construction
The Design Model
Which is mapped from the
Analysis model
5
 The Design Process
• Mc Glaughlin’s suggestions for good
design:
– Design must enable all requirements of the
analysis model and implicit needs of the
customer 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

6
 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
7
 Design Principles
• Design Process:
– Iterative steps that enable description of all aspects of
the software
• Design principles:
– 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

8
 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 during
creation, not afterwards
• This 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
9
Design Concepts- 1. Abstraction
• Wasserman: “Abstraction permits one to concentrate
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 a data
object
• Procedural Abstraction
– Instructions 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

10
 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 as
the design progresses
– Design decisions at each stage

11
 3. Modularity
• In this concept, software is divided into separately
named and addressable components called
modules
• Follows “divide and conquer” concept, a complex
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
12
Modularity & Software Cost

13
 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.

14
 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 effects
is 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

15
 4.Software Architecture
Desired properties of an architectural design
• Structural Properties
– This 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 Systems
– The ability to reuse architectural building blocks

16
 5. Control Hierarchy
• Is a program structure , represents the
organization of program components and
implies a hierarchy of control.
• Tree like diagram is used to represent
hierarchical control.

18
 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 by
another 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

19
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.

20
6. Program Structure Partitioning
• Horizontal Partitioning
– Easier to test
– Easier to maintain (questionable)
– Propagation of fewer side effects (questionable)
– Easier to add new features
F1 (Ex: Input) F2 (Process) F3(Output)

21
Program Structure Partitioning
• Vertical Partitioning
– Control and work modules are distributed top
down
– Top level modules perform control functions
– Lower modules perform computations
• Less susceptible to side effects
• Also very maintainable

22
 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
23
 Module A specification

Module B body type shuttle is private;

function get return shuttle;
s: A.shuttle; function get_lat(s) return float;
function get_x(s) return float;
x_coord: float; function get_long(s) return float;
… …
s := A.get; procedure display(s:shuttle);
…
A.display(s); private
… type shuttle is record
x_coord := A.get_x(s); x,y,z: float;
roll, pitch,yaw: float;
... end record;
24
 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

25
 Modular Design -- Cohesion
• A cohesive module performs a single task
• Different levels of cohesion
– Coincidental, logical, temporal, procedural,
communications, sequential, functional

26
 Modular Design -- Coupling
• Coupling describes the interconnection
among modules
• Data coupling
– Occurs when one module passes local data values
to another as parameters
• Stamp coupling
– Occurs when part of a data structure is passed to
another module as a parameter

29
Examples of Coupling

31
 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
32
 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

33
Documentation

35
 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

36
 Design Method
---data and architectural design

Design -- A multistep process in

which representations of data
structure, program structure, interface
characteristics, and procedural detail
are synthesized.
 Data Design
• What is data design?
– Transform the information domain model
created during analysis into data structure
required to implement the software
– Well-designed data lead to better program
structure and modularity, reduced procedural
complexity

38
 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 design decisions
• Or, from OO perspective, define all operations
performed on the data structure

39
 Principles of Data Design
• A data dictionary should be established and
used for both data and program design
• Low-level data design decisions should be
deferred 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

40
 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 within
the structure.
– Information hiding
• The software design and programming
languages should support the specification
and realization of abstract data types.

41
 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)

42
 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

43
Architectural Design Process

(cont.)
• Transform Flow

incoming flow outgoing flows

A B
transform
center
C

44
Architectural Design Process

(cont.)
• Transaction Flow
Transaction
Action
paths
T
Transaction
center

45
 Transform Mapping
• Allow data flow diagram(DFD) with
transform flow characteristics to be mapped
into a predefined template for program
structure

46
Level 0 Safehome DFD

47
Level 1 Safehome DFD

48
R. A. Volz -- Assistance - Haichen 48
Level 2 Safehome DFD -
Monitor

49
49
 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

50
Level 3 DFD for Monitor
Sensors

51
51
 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.

52
First Level Factoring

53
R. A. Volz -- Assistance - Haichen 53
 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 improved
software quality.

54
Second Level Factoring

55
R. A. Volz -- Assistance - Haichen 55
First-Cut Program Structure

56
56
Refined Program Structure

57
R. A. Volz -- Assistance - Haichen 57
 Transaction Mapping
A single data item triggers one or more information flows

58
R. A. Volz -- Assistance - Haichen 58
 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 or
transaction 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.

59
 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 action
modules
• each action path mapped to corresponding structure

60
Transaction Mapping

61
R. A. Volz -- Assistance - Haichen 61
First Level Factoring

62
62
First-cut Program Structure

63
 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

64