Design Concepts and Principles

What is Design
Design is a meaningful engineering representation of
something that is to be built

Design is the only way that we can accurately translate a

customer’s requirements into a finished software product
or system
Definition of Design
The process of conceiving, inventing, or
planning a scheme for turning a specification
for a computer program into an operational
program;
The activity that links requirements
development to construction.
"Design" also refers to the result of the
design activity.
Two major phases:
Diversification- acquisition of a repertoire of
alternatives, the raw material of design
Convergence and elimination- choice and
combination of appropriate elements from
this repertoire to meet the design
objectives, as stated in the requirements
specification and as agreed by the
customer by elimination of all but one
particular configuration of components.
So ftw a re De sig n

Problem

15
There are four major areas of design
1. Data
2. Architecture
3. Interfaces
4. Components
Analysis to Design

Process Specification (PSPEC)

Data Object Description
Component- procedural
Entity- Data Flow level design design
Relationship Diagram
Diagram

interface
Data Dictionary
design

architectural
State-Transition design
Diagram

data
Control Specification (CSPEC) design

THE ANALYSIS MODEL THE DESIGN MODEL

Data Design
Transforms the information domain model created
during analysis into the data structures that will
be required to implement the software.
Discovering and completely defining application’s
data characteristics and processes.
A process of gradual refinement from the coarse
“What data does your application require?” to the
precise data structures and processes that provide
it.
Architectural Design
Defines the relationship between major structural
elements of the software, the “design patterns”
that can be used to achieve the requirements that
have been defined for the system, and the
constraints that affect the way in which
architectural design patterns can be applied.
be derived from the system specification, the
analysis model, and the interaction of subsystems
defined within the analysis model.
Interface design
Description of how the software
communicates within itself,with systems
that interoperate with it, and with humans
who use it.
An interface implies a flow of information
(e.g., data and/or control) and a specific
type of behavior.
component-level design
The component-level design transforms
structural elements of the software
architecture into a procedural
description of software components.
Information obtained from the PSPEC,
CSPEC, and STD serve as the basis for
component design
Design Principles

The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even
when aberrant data, events, or operating conditions are
encountered.
Design is not coding, coding is not design.
The design should be reviewed to minimize conceptual
(semantic) errors.
Fundamental Concepts of
design
1. Abstraction
Abstraction is the thought process where ideas are
distanced from objects.
The separation of the logical properties of data or
function from its implementation in a computer
program
Abstraction uses a strategy of simplification of detail,
wherein formerly concrete details are left ambiguous,
vague, or undefined; thus speaking of things in the
abstract demands that the listener have an intuitive
or common experience with the speaker, if the
speaker expects to be understood.
Abstraction
Highest level Problem-oriented

Lowest Level Implementation-oriented

Problem-oriented terminology is coupled with implementation-oriented

terminology in an effort to state a solution
Types of Abstraction
Procedural abstraction-
named sequence of instructions that has a specific
and limited function.

Data abstraction
named collection of data that describes a data
object.
Procedural Abstraction

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
Data Abstraction
door

manufacturer
model number
type
swing direction
inserts
type

weight
opening mechanism

implemented as a data structure

2. Modularity
Software
Divided
into
Modules
Integrated to satisfy

Requirements
Modular Design
easier to build, easier to change, easier to fix ...
Divide and Conquer
Software Architecture embodies modularity
Software is divided into separately named and addressable
components often called modules, that are integrated to
satisfy problem requirements
Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
3. Software Architecture
Simply stated : “Software Architecture is an arrangement
of components”
It is at a high-enough level of abstraction that the system
can be viewed as a whole
Software Architecture is a sketchy map of the system. It
describes
The components of the system
and the connectors between those components describe the
communication
In the implementation phase, components are refined into
actual components, e.g. classes and objects
and the connectors are usually implemented as interfaces
Contd…!!!
It is a high level abstraction of the system
The structure must support the functionality required of the
system
The structure or Architecture must conform to the system
qualities (non-functional requirements)
At the Architecture level, all implementation detail is
hidden

ADL (Architectural Descriptive language) is used to

describe software Architecture
Properties of Architecture
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.” [SHA95a]

Structural properties. This aspect of the architectural design

representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are packaged
and interact with one another. For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and
interact via the invocation of methods .
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other system
characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of
families of similar systems. In essence, the design should have the ability
to reuse architectural building blocks.
Different models of architecture
design
Structural Models: represents architecture as an
organized collection of program components
Framework Models: identify repeatable architectural
design frameworks (patterns)
Dynamic Models: address the behavioral aspects of the
program architecture
Process Models: focus on the design of business or
technical process
Functional Models: represent the functional hierarchy of
a system
3. Control Hierarchy
Represents the organization of program components
and implies the hierarchy of control

o Fan-In
How many modules directly control a given module
o Fan-Out
How many modules are directly controlled by another
module
 EXECUTIVE
EXECUTIVE

Fan out

MODULE A MODULE B MODULE C MODULE D MODULE E MODULE F MODULE G

Depth

Module X Module Y Module Q Module R Module M Module N

Fan in

Module K Module L Module S

Breadth
4. Structural Partitioning
 Horizontal Partitioning
Defines separate branches of the modular hierarchy for each
major program function
o Change tend to be less complex
o Extensions are easier to accomplish without side effects
o On the negative side, it causes more data to be passed across
module interfaces
 Vertical Partitioning
Suggests that control (decision making) and work should be
distributed top-down in the program structure
o A change in a control module will have a higher probability of
propagating side effects to modules that are subordinate to it
5. Data Structure
Data Structure is a representation of the logical
relationship among individual elements of data
It dictates
• The organization of data
• Methods of Access
• Degree of Associativity
• Processing alternatives for information

Scalar Vector n-dimensional space

6. Information Hiding

module • algorithm
controlled
interface • data structure

• details of external interface

• resource allocation policy

clients "secret"

a specific design decision

Why Information Hiding?
reduces the likelihood of “side effects”
limits the global impact of local design decisions
emphasizes communication through controlled
interfaces
discourages the use of global data
results in higher quality software
EFFECTIVE MODULAR
DESIGN
 So ftwa re De sig n

 A m o d ule sho uld , id e a lly, o nly p e rfo rm o ne

func tio na l ta sk, a nd a vo id e xc e ssive
inte ra c tio n with o the r m o d ule s. This iso la te s
e rro rs to tha t sing le m o d ule a nd m a ke s the
p ro c e ss o f c o d ing , te sting , d e b ug g ing a nd
m a inte na nc e m uc h e a sie r.
 2 q ua lita tive c rite ria :
• c o he sio n
• c o up ling

28
Functional Independence

You don't want a change in one

module to cause errors to ripple throughout
your system. Encapsulate information, make modules
highly cohesive, seek low coupling among modules.

Functional Independence, we mean that a cohesive module

performs a single task or function. A functionally independent
module
has minimal
interaction with other modules
Need for functional independence
Error isolation: Functional independence reduces error
propagation. The reason behind this is that if a module is
functionally independent, its degree of interaction with the
other modules is less. Therefore, any error existing in a module
would not directly effect the other modules.
Scope of reuse: Reuse of a module becomes possible.
Because each module does some well-defined and precise
function, and the interaction of the module with the other
modules is simple and minimal. Therefore, a cohesive module
can be easily taken out and reused in a different program.
Understandability: Complexity of the design is reduced,
because different modules can be understood in isolation as
modules are more or less independent of each other.
Functional Independence

COHESION - the degree to which a

module performs one and only one
function.

COUPLING - the degree to which a

module is "connected" to other
modules in the system.
Contd…!!!

GOAL
Low Coupling
High Cohesion
Cohesion
Extension of information hiding
Performs a single task within a software
procedure, requiring little interaction
with procedures being performed in
other parts of a program.
Cohesion
Internal glue with which component is
constructed
All elements of component are directed toward
and essential for performing the same task
 So ftwa re De sig n

Be st Func tio na l
Se q ue ntia l
Co m m unic a tio na l
Pro c e d ura l
Te m p o ra l
Lo g ic a l
Wo rst Co inc id e nta l
30
Range of Cohesion
High Cohesion
Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
Functional Cohesion
Contains elements that all contribute to the execution of one
and only one problem-related task.
Example
• Compute cosine of angle
• Verify alphabetic syntax
• Read transaction record
• Determine customer mortgage repayment
• Compute point of impact of missile
• Calculate net employee salary
• Assign seat to airline customer
Each of these modules has a strong, single-minded purpose.
Sequential Cohesion
Elements are involved in activities such that output
data from one activity serves as input data to the next.
Example
• Clean car body
• Fill in holes in car
• Sand car body
• Apply primer
This group of four activities cannot be summed up as a
single function
The output from one activity serves as input to the
next
Communicational Cohesion
Elements contribute to activities that use the
same input or output data.
Example
• Find title of book
• Find price of book
• Find publisher of book
• Find author of book
They all work on the same input data, the
book
Procedural Cohesion
Elements are involved in different and possibly unrelated
activities in which control flows from each activity to the
next.
Example
• Clean utensils from previous meal
• Prepare turkey for roasting
• Make phone call
• Take shower
• Chop vegetables
• Set table
They are related by order of execution rather than by any
single problem-related function.
Temporal Cohesion
Elements are involved in activities that are
related in time.
Example
• PUT OUT MILK BOTTLES
• PUT OUT CAT
• TURN OFF TV
• BRUSH TEETH
These activities are unrelated to one another
except that they’re carried out at a particular
time. They’re all part of an end-of-day routine
Logical Cohesion
Elements contribute to activities of the same
general category in which the activity or activities to
be executed are selected from outside the module
Example
• Go by car
• Go by train
• Go by boat
• Go by plane
Contains a number of activities of the same general
kind.
Coincidental Cohesion
Elements contribute to activities with no meaningful
relationship to one another
Example
• Fix car
• Bake cake
• Walk dog
• Fill out astronaut-application form
• Have a glass of juice
• Get out of bed
• Go to the movies
Activities are related neither by flow of data nor by flow of
control, nor even part of same category.
Examples of Cohesion-1
Function A Function A Time t0
Function Function
B C logic Function A’ Time t0 + X
Function Function
D E Function A’’
Time t0 + 2X
Coincidental Logical Temporal
Parts unrelated Similar functions Related by time

Function A

Function B

Function C

Procedural
Related by order of functions
Examples of Cohesion-2

Function A
Function A
Function B
Function B
Function C
Function C
Sequential
Communicational Output of one is input to another
Access same data

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions
Coupling
A measure of interconnection among
modules in a software structure.
Depends upon
Interface complexity between modules
Point at which entry or reference is made
to a module
What data pass across the interface
S
o
f
t
w
a
r
eD
e
s
i
g
n
t N
B
e
s o
d
i
r
e
c
t

D
a
t
a

S
t
a
m
p

C
o
n
t
r
o
l

E
x
t
e
r
n
a
l

C
o
m
m
o
n

tC
W
o
r
s o
n
t
e
n
t
3
2
Coupling
Degree of dependence among components.

No dependencies Loosely coupled-some dependencies

Highly couples-many dependencies

Range of Coupling
High Coupling
Content

Common

External

Control
Loose
Stamp

Data

Uncoupled Low
Content Coupling : (worst) When a module uses/alters data in
another module
Common Coupling : 2 modules communicating via global data
External Coupling : Modules are tied to an environment
external to the software
Control Coupling : 2 modules communicating with a control
flag
Stamp Coupling : Communicating via a data structure passed
as a parameter. The data structure holds more information than
the recipient needs.
Data Coupling : (best) Communicating via parameter passing.
The parameters passed are only those that the recipient needs.
No data coupling : independent modules.
Summary
COHESION COUPLING

The measure of strength The measure of

of the association of interdependence of one
elements within a module module to another
It is the degree to which It describes the
the responsibility of a relationship between
single component form a software components
meaningful unit
It is a property or It is a property of a
characteristic of an collection of modules
individual module