Software

Design

Software Design
the process of applying various techniques
and principles for the purpose of defining a
device, a process, or a system in sufficient
detail to permit its physical realization.

Goal:
To produce a model or representation that
will later be built

Conceptual vs. Technical

Design
WHAT

HOW

CONCEPTUAL
DESIGN

TECHNICAL
DESIGN

function

System
designers

Customers

form

System
builders

Design Document
Introduction
Problem Statement
Document
Overview

Revised
Requirements
System Models
Data
Function
Procedure

Conceptual Design
Architecture
Diagram
Description

Detailed Design
Data Design
Procedural Design

UI Design
Sources
Appendix

Architectural Design
Objective is to develop a modular
program structure and represent the
control relationships between modules
Combines program and data structure
by defining interfaces that allows data
to flow throughout the program
Holistic view of software

Data Design
The primary activity during data design is to select
logical representations of data objects identified during the
requirements definition and specification phase. The selection
process may involve algorithmic analysis of alternative structures
in order to determine the most efficient design or may simply
involve the use of a set of modules that provide the operations
upon some representation of an object.
[Wasserman]

Identify the program modules that operate

upon the logical data structures
Data design leads to better program structure,
effective modularity, & reduced complexity

Procedural Design
After data & program structure have
been established, becomes necessary to
specify procedural detail without
ambiguity
Design Notations

Structured programming
Graphical design notation
Tabular design notation
Program design language (PDL)

Software design process

Requir
ements
Requir
ements
specifi
ca
tion
specifi ca
tion
Design acti
vities
Design acti
vities
Architectur
al
Architectur
al
design
design

Abstract
Abstract
specifi ca
tion
specifi ca
tion

Interface
Interface
design
design

Component
Component
design
design

Data
Data
structur
e
structur
e
design
design

Algorithm
Algorithm
design
design

System
System
architectur
e
architectur
e

Software
Software
specifi ca
tion
specifi ca
tion

Interface
Interface
specifi ca
tion
specifi ca
tion

Component
Component
specifi ca
tion
specifi ca
tion

Data
Data
structur
e
structur
e
specifi ca
tion
specifi ca
tion

Algorithm
Algorithm
specifi ca
tion
specifi ca
tion

Design pr
oducts
Design pr
oducts

Design Principle Coupling

Coupling is a term to describe the
interactions
between
components. The lower coupling,
the less interaction (i.e., the more
independence
)
between
components
Coupling
connections
cause
dependencies
between
components. The common design
principle is to minimize coupling.

Characteristics of Good
Design
Component independence
High cohesion
Low coupling

Exception identification and handling

Fault prevention and fault tolerance

Coupling: Degree of dependence

among components

No dependencies

Highly coupled-many dependencies

Loosely coupled-some dependencies

High coupling makes modifying parts

of the system difficult, e.g., modifying
a component affects all the
components to which the component
is connected.

Range of Coupling
Content

High Coupling

Common
Control

Loose

Stamp
Data
Uncoupled

Low

Content coupling
Definition: One component references
contents of another
Example:
Component directly modifies anothers data
Component refers to local data of another
component in terms of numerical
displacement
Component modifies anothers code, e.g.,
jumps into the middle of a routine

Common Coupling
Definition: Two components share data
Global data structures
Common blocks

Usually a poor design choice because

Lack of clear responsibility for the data
Reduces readability
Difficult to determine all the components that
affect a data element (reduces maintainability)
Difficult to reuse components
Reduces ability to control data accesses

Control Coupling
Definition: Component passes control
parameters to coupled components.
May be either good or bad,
depending on situation.
Bad when component must be aware of
internal structure and logic of another
module
Good if parameters allow factoring and
reuse of functionality

Stamp Coupling
Definition: Component passes a data
structure to another component that does
not have access to the entire structure.
Requires second component to know how
to manipulate the data structure (e.g.,
needs to know about implementation)
May be necessary due to efficiency
factors: this is a choice made by insightful
designer, not lazy programmer.

Data Coupling
Definition: Two components are data
coupled if there are homogeneous data
items.
Every argument is simple argument or
data structure in which all elements are
used
Good, if it can be achieved.
Easy to write contracts for this and modify
component independently.

Cohesion
The degree to which all elements of a
component are directed towards a single
task and all elements directed towards
that task are contained in a single
component.
Internal glue with which component is
constructed
All elements of component are directed toward
and essential for performing the same task
High is good

Range of Cohesion
Functional
Informational

High Cohesion

Sequential
Communicational
Procedural
Temporal
Logical

Low

Coincidental Cohesion
Definition: Parts of the
component are only related by
their location in source code
Elements needed to achieve some
functionality are scattered
throughout the system.
Accidental
Worst form

Logical Cohesion
Definition: Elements of component
are related logically and not
functionally.
Several logically related elements are
in the same component and one of
the elements is selected by the client
component.

Temporal Cohesion
Definition: Elements of a component
are related by timing.
Difficult to change because you may
have to look at numerous
components when a change in a data
structure is made.
Increases chances of regression fault
Component unlikely to be reusable.

Procedural Cohesion
Definition: Elements of a component
are related only to ensure a
particular order of execution.
Actions are still weakly connected
and unlikely to be reusable

Communicational Cohesion
Definition: Module performs a series
of actions related by a sequence of
steps to be followed by the product
and all actions are performed on the
same data

Sequential Cohesion
The output of one component is the
input to another.
Occurs naturally in functional
programming languages
Good situation

Informational Cohesion
Definition: Module performs a number of
actions, each with its own entry point, with
independent code for each action, all
performed on the same data.
Different from logical cohesion
Each piece of code has single entry and single
exit
In logical cohesion, actions of module
intertwined

ADT and object-oriented paradigm promote

Functional Cohesion
Definition: Every essential element to
a single computation is contained in
the component.
Every element in the component is
essential to the computation.
Ideal situation.

Structured Programming
structured programming: A technique
for organizing and coding computer
programs in which a hierarchy of modules
is used, each having a single entry and a
single exit point, and in which control is
passed downward through the structure
without unconditional branches to higher
levels of the structure. Three types of
control flow are used: sequential, test,
and iteration.

Advantages of Structured
Programming

Easy to write
Reusability
Easy to debug
Easy to Understand
Easy to Change

Top Down Design

Top Down Design is a method of
designing something that starts with
the complete item then breaks it
down into smaller and smaller
components. In programming it
means breaking a difficult task down
(divide and conquer) and solving
pieces independently until every step
can easily be implemented
(successive refinement).

Structured programming
Top-down vs bottom-up
Both are useful as a means to understand the relations between
high-level and low-level views of a program
Top-down
Code high level parts using stubs with assumed functionality for
low-level dependencies
Iteratively descend to lower-level modules

Bottom-up
Code and test each low-level component
Need test harness so that low-level can be tested in its correct context
Integrate components

Not hard-fast rules; combination often best

Coding style

Use meaningful variable names

Use comments to supplement the meaning
Indent code for each block/loop
Encapsulate groups of statements sensibly in
functions
Encapsulate related data sensibly in data
structures
Design top down
Code bottom-up or top-down, or a
combination