Software Design -- An iterative

process transforming requirements

into a “blueprint” for constructing
the software.
Design Concepts
Design Concepts-Abstraction

door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

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

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
 Refinement

• Refinement is actually a process of elaboration.

• Refinement causes the designer to elaborate on the original
statement, providing more and more detail as each
successive refinement (elaboration) occurs.
• Abstraction and refinement are complementary concepts.
Abstraction enables a designer to specify procedure and data
and yet suppress low-level details.
• Refinement helps the designer to expose low-level details as
design progresses.
 Stepwise Refinement
open

walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
 Refactoring
• A reorganization technique that simplifies the design (or
internal code structure) of a component without changing its
function or external behaviour.

• When software is refactored, the existing design is examined

for
– Redundancy
– Unused design elements
– Inefficient or unnecessary algorithms
– Poorly constructed or inappropriate data structures
– Or any other design failure that can be corrected to yield a
better design.
 Architecture

Software architecture suggest “ the overall structure of the

software and the ways in which that structure provides
conceptual integrity for a system.
Architectural Style describes a system category that encompasses
1. A set of components (e.g., a database, computational
modules) that perform a function required by a system;
2. a set of connectors that enable “communication, co-
ordinations and cooperation” among components;
3. constraints that define how components can be integrated
to form the system
4. semantic models that enable a designer to understand the
overall properties of a system
 Architectural Style

It can be represent by
• Data-centered architecture
• Data flow architecture
• Call and return architecture
• Object oriented architecture
• Layered architecture.
Data-centered architecture
 Data-centered architecture
• A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that
update, add, delete, or otherwise modify data within the store.
• Client software accesses a central repository which is in passive
state (in some cases).
• client software accesses the data independent of any changes to
the data or the actions of other client software.
• So, in this case transform the repository into a “Blackboard”.
• A blackboard sends notification to subscribers when data of
interest changes, and is thus active.
• Data-centered architectures promote integrability.
• Existing components can be changed and new client components
can be added to the architecture without concern about other
clients.
• Data can be passed among clients using the blackboard
mechanism. So Client components independently execute
processes
Data Flow architecture

Pipes and filters

Batch Sequential
 Data Flow architecture

• This architecture is applied when input data are to be transformed

through a series of computational or manipulative components
into output data.
• A pipe and filter pattern has a set of components, called filters,
connected by pipes that transmit data from one component to the
next.
• Each filter works independently (i.e. upstream, downstream) and is
designed to expect data input of a certain form, and produces data
output (to the next filter) of a specified form.
• the filter does not require knowledge of the working of its
neighboring filters.
• If the data flow degenerates into a single line of transforms, it is
termed batch sequential.
Call and return architecture
 Call and return architecture

• Architecture style enables a software designer (system architect) to

achieve a program structure that is relatively easy to modify and scale.
• Two sub-styles exist within this category:
1. Main/sub program architecture:
• Program structure decomposes function into a control hierarchy
where a “main” program invokes a number of program components,
which in turn may invoke still other components.
2. Remote procedure Call architecture:
• The components of a main program/subprogram architecture are
distributed across multiple computers on a network
 Object-oriented architecture

• The object-oriented paradigm, like the abstract data type paradigm

from which it evolved, emphasizes the bundling of data and methods
to manipulate and access that data (Public Interface).
• Components of a system summarize data and the operations that
must be applied to manipulate the data.
• Communication and coordination between components is
accomplished via message passing.
Object-oriented architecture
 Layered Architecture
• A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine
instruction set.
• At the outer layer, components examine user interface operations.
• At the inner layer, components examine operating system
interfacing.
• Intermediate layers provide utility services and application software
functions.
Layered Architecture
 Modularity

• Architecture and design pattern embody modularity.

• Software is divided into separately named and addressable
components, sometimes called modules, which are
integrated to satisfy problem requirement.
• It leads to a “divide and conquer” strategy. – it is easier to
solve a complex problem when you break into a manageable
pieces.
Modularity and software cost
• Undermodularity and overmodularity should be
avoided.
• We modularize a design so that development can be
more easily planned.
• Software increments can be defined and delivered.
• Changes can be more easily accommodated.
• Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.
 EFFECTIVE MODULAR DESIGN

• Effective modular design consist of three things:

• Functional Independence
• Cohesion
• Coupling
 Functional Independence

• Functional independence is achieved by developing modules with

"single-minded“ function and an "aversion" to excessive interaction
with other modules.
• In other words - each module addresses a specific sub-function of
requirements and has a simple interface when viewed from other
parts of the program structure.
• Independence is important –
• Easier to develop
• Easier to Test and maintain
• Error propagation is reduced
• Reusable module.
Coupling and Cohesion
 Coupling: Degree of dependence
among components

No dependencies Loosely coupled-some dependencies

High coupling makes modifying

parts of the system difficult, e.g.,
Highly coupled-many dependencies modifying a component affects
all the components to which the
component is connected.
Range of Coupling
High Coupling
Content

Common

Control

Loose
Stamp

Data

Uncoupled
Low
 Data coupling

• Dependency between the modules based on the fact that

they will communicate by passing only data
 Stamp coupling

• The complete data structures is passed from one module

to another
 Control coupling

• Modules communicate via passing control information

• One module controls flow of other module
 Common coupling

• Modules have shared data structures such as global data

structure
 Content Coupling

• One module can modify the data of another module or

control flow is passed from one module to another
module.
 Cohesion

• Cohesion is a measure of the degree to which the

elements of the module are functionally related.
• A good software design will have high cohesion.
Range of Cohesion
High Cohesion
Functional
Informational

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
 Functional Cohesion

• In functional cohesion, all the statements in the

procedure are related in the performance of a single
function.
 Sequential Cohesion

• An element output s some data that becomes the input

for another element. The data flow happens between the
parts.
 Communicational Cohesion

• When two elements operates on same input data or

contribute towards the same output data.
 Procedural Cohesion

• Ensure the order of the execution. Actions are weakly

connected and unlikely to be reusable.
 Temporal Cohesion

• Elements are related by their timing involved.

• A module connected with temporal cohesion all the task
must be executed in the same time span.
 Logical Cohesion

• Elements are logically related but not functionally.

 Coincidental Cohesion

• Elements are unrelated.

• Parts of the component are only related by their location
in source code
 Examples of Cohesion-1
Function A Function A Time t0
Function Function
B C Function A’ Time t0 + X
logic
Function Function Time t0 + 2X
D E Function A’’

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

Communicational Sequential
Access same data Output of one is input to another

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions