Definition of Software design:

Process of :
- Defining architecture of the system
- components used in the design
- Interfaces to be established
- incorporate the salient features of the
system.
It’s a process of producing model of the system
It’s a phase in software engineering life cycle
process.
Its platform independent or platform dependent
design
Design Types:
Structural Design model: Represent architecture as
an organized collection of program components.
Static components needs to be developed so that
it can be developed as independent unit.
Framework design model: Helps to increase the
level of design abstraction. It identifies repeatable
architecture design or framework or patterns that
are encountered in similar type of applications.
Dynamic design model: It address behavior aspects
of program architecture configuring the system
and respond to external events.
Process design model: Deals with the technical
aspects that the system must accommodate.
Functional design model: Represents functional
hierarchy of a system.
Design Process
System design process involves deciding
which system capabilities are to be
implemented in software and which in
hardware. .
The process of converting a system
specification in to an executable system is
called software design.
Designers do not arrive at a finished design
immediately but develop the design iteratively
through a number of different versions.
Levels of design process:
Design process has two levels.
 System design or Top-level design
 Detailed design or Logic design
System design
makes use of modules needed for the
system, specifications of the modules and
module interconnections are decided.
Detailed design concentrates on:
the internal design of the modules,
processing logic and data structures.
Detailed design may be function-oriented or
object-oriented.
Design process activities 

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design
Architectural design
The design process for identifying the sub-
systems making up a system and the framework
for sub-system control and communication is
architectural design.
The output of this design process is a description
of the software architecture.
An early stage of the system design process.
Represents the link between design and
requirements engineering process
Software architecture document serves as design plan. It acts
as a starting point for design. It hides details and allows
designers to focus on key system abstractions.

System architecture affects performance, robustness,

maintainability etc
Architectural design is a creative process involving decisions
like :
What architectural style - repository or layered etc
What control strategy - centralised or event driven
How to document architectural design
How to evaluate
Whether system is distributed across processors etc
3 activities common to architectural design process are
System structuring
Control modelling
Modular decomposition
 Radar Transponder Data comms. Aircraft Telephone
system system system comms. system

Position Backup Comms. Backup comms.

processor position processor processor
processor

Aircraft Flight plan ATC system

simulation database
system architecture

Weather map
system
Controller Controller
Accounting info. system consoles
system

Activitylogging
system

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ##
System structuring:
First activity in architectural design
Concerned with decomposing the system into
interacting sub-systems.
The architectural design is normally expressed as a
block diagram presenting an overview of the system
structure.
More specific models showing how sub-systems share
data, are distributed and interface with each
other may also be developed.
Following models are used for structuring the system:
Repository model
Client-server model
Layered model
Architectural models 

Static structural model shows the major system

components.
Dynamic process model shows the process
structure
Interface model shows sub-system interfaces and
services offered by each sub-system .
Ex: Layered model
Relationships model shows sub-system
relationships.
Ex: Data flow model
Distribution model that shows how sub-systems are
distributed across computers.
Ex: Client server architectural models
Control modeling:
 A general model of controlling between subsystems is
established.
 Since structural models do not constitute control information,
control models should do this
 Two types of control models:
Centralized control model
Event driven control model
Modular decomposition
 Another structural level where sub-systems are decomposed
into modules. Two modular decomposition models
Object oriented decomposition
Function oriented decomposition
 An object model where the system is decomposed into
interacting object;
 A pipeline or data-flow model where the system is
decomposed into functional modules
Abstract specification:

Each sub system must provide abstract

specification consisting of:
-services to be offered
-constraints under which it must operate.
Interface design
Subsystems must interface with other subsystems.
Interface specification is very important
It is a codification part that interface the other
subsystems
Interface design focuses on 3 important areas:
- Design of interfaces between software modules
- Design of interfaces between the subsystems
- Design of interface between system and external
factors.
Component design:

Every system requires many components.

Components may be re usable. With little
modifications, re-usable components may be
designed to suit system.
For each component design, specifications
are very important.
Data structure design:
Logical representation of data objects identified
helps in data structure design
It translates data objects defined in analysis
model into data structures that reside within the
software.
Choice of data structure depends on data
attributes, relationship between these data
objects their use within the program.
Data structures used in the system depends on
the type of system.
Specification of data structure is essential to
draw architectural design.
Algorithm design:

They are set of statements in step wise

manner to explain the working of the system.
It gives skeletal framework of the problem
and solution.
Repository model
It is a model in architectural design to structure
the system.
Sub systems must communicate to exchange
information. This can be possible in 2 ways:
1. Shared data is held in central database that
can be accessed by all sub systems. A system
model based on a shared database is sometimes
called a repository model.
2. Each subsystem maintains its own database.
Data is interchanged with other subsystems by
passing messages to them.
This model suits to applications where data is
generated by one sub system and used by
another.
 Design
Design editor
analyser

Design Program
translator Project repository editor

Code Report
generator generator
Advantages
 Efficient way to share large amounts of data.
 Subsystems that produce data need not be concerned with how data is
used by other sub systems
 Activities such as backup, security, access control and recovery are
centralized so that sub systems can concentrate on their principle
functionality rather than be concerned with these issues.
 Its easy to integrate new tools given that they are compatible with the
agreed data model.
Disadvantages:
 Subsystems must agree on repository model where performance may
be compromised
 Some times may be difficult to integrate new sub-systems if their
data models do not fit agreed schema
 Different subsystems may have different requirements for security,
recovery etc and repository model forces for same policy in all subsystems.
 Although it is possible to distribute the logically centralized repository
there may be problems with data redundancy and inconsistency
Client server model:
In this model system is organized as set of services
and associated servers and clients that access and
use services.
Major components of the model:
- Set of servers that offer services to other
subsystems.
Examples of servers are print servers, file
servers etc - Set of clients that call on the services
offered by servers. These are considered
subsystems.
- Network that allows clients to access these
services. Necessary if client and server are in
distributed systems
Architecture of a firm and picture library
system

Client 1 Client 2 Client 3 Client 4

Internet

Catalogue Picture Web

Video
Server Server Server
Server
Library Digitized Film and
Film clip
Catalogue photograph Photo info
files
s
Advantages:
This model is in distributed architecture, networked
systems with distributed processors.
It is easy to add a new server and integrate it with rest
of the system
Existing servers can be upgraded without affecting
other components of the system.
Disadvantages:
Every server must take responsibility of data
management activities like back-up, recovery etc.
Integration of new server may require changes in
existing clients and servers to gain full benefits of new
server.
Lack of shared model
Layered model Or Abstract machine model:
Organizes system into layers, each layer
provide set of services.

Configuration management system layer

Object management system layer

Database system layer

Operating system layer

Configuration management system manages
versions of objects and provides general
configuration management facilities.
It uses an object management system that
provides information storage and
management services for configuration items
or objects.
This is built on top of data base system to
provide basic data storage and services such
as transaction management, roll back etc
Data base management uses operating
system facilities in its implementation.
The layered approach supports the incremental
development of the system
As a layer is developed, some of the services provided
by that layer may be available to users.
A layer can be replaced by another equivalent layer if
interface is unchanged
If interface is changed , adjacent layers may get
affected.

Disadvantage :
Structuring system in this way is difficult.
Services required by a user of bottom level may
therefore have to punch through adjacent layers to get
access to services that are provided several levels
beneath
Performance can be problem if there are many layers
before it is processed.

Control models:

Control models are concerned with control

flow between subsystems.
2 generic control styles :
Centralized control
Event based control
Centralized control:
One sub system is designated as system
controller and has responsibility for
managing the execution of other sub system.
It may also devolve control to another
subsystem but will expect to have this control
responsibility returned to it
2 types:
Call return model
Manager model
Call return model:
Familiar top down subroutine model
Applicable to sequential systems.
Control starts at top of the subroutine and through subroutine
calls passes to lower levels in the tree.
Strength: Is relatively simple to analyse control flows
Weakness: To handle exceptions to normal operations
 Main program

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

Manager model:
Appropriate for concurrent systems
One system component is designed as a
system manager that manages the starting,
stopping and coordination of other system
processes.
Subsystems can be executed parellelly
 System 1

System System 2
System 4 controller

System 3
Event driven Models:

Apt for modeling systems which are driven by

external events.
Two types:
Broad cast model
Interrupt driven model
Broad cast model:
Appropriate for integrating sub systems distributed
across different computers on the network.
The occurrence of event is broad casted to all
subsystems
Subsystem which can handle that event responds to
it.
Broad casting to all subsystem is an overhead.
Message handler maintains a register of subsystems
and events of their interest.
It detects the event, confirms with the event register
and transfers the event to those subsystems that have
registered an interest in the event.
Broad cast control model:

Subsystem Subsystem
1 2

Event and message handler

Subsystem Subsystem
3 4
Advantages:
1.New subsystems can be easily added to
handle particular class of events
2.Any sub system can activate any other sub
system without knowing its name and
location.

Disadvantages:
1.Different subsystems may register their
interest for the same event, causing conflict
2.Difficult to determine when the result of the
event will be available.
Interrupt driven model:
Exclusively used in real time systems with
stringent timing requirement.
Real time systems are provided with interrupt –
driven control
In this model:
 Events are linked to Interrupts
 Each interrupt is associated with memory location
where handler’s address is stored.
 The table containing the addresses of Interrupt
handler’s is called Interrupt vector table.
At occurrence of an interrupt, the control is
transferred to its handler.
Now handler takes control of the process.
 Interrupts

Interrupt
vector

Handle Handle Handle

r1 r2 r3

Proces Proces Proces

s1 s2 s3
Advantages:
 It responds very fast to the events to be
implemented

Disadvantages:
 It involves complex programming and
validation to generate same interrupt timing
during testing
 Number of interrupts to be handled is limited
by hardware.
Modular decomposition:

Decomposition of subsystems into modules

happens.
Decomposition based on 2 models:
- Function oriented
- Object oriented
Object oriented model:

System is decomposed into a set of loosely

coupled, communicating objects with well
deined interfaces.
This decomposition deals with object classes
their attributes and operations.
Objects are created from these classes.
Objects call on services offered by other
objects.
To coordinate the object operation, this
control model is used.
Object model of an invoice processing
system:
Customer Receipt
Customer# Invoice#
Name IInvoice Date
Address Invoice# Amount
Credit period Date Custmer#
Amount
Customer

Issue()
Send
remainder()
Payment Acceptpayment(
Invoice# )
Date
Amount
Customer#
Advantages:
The implementation of objects can be modified without
affecting other objects because objects are loosely coupled.
It makes the system structure easily understandable
Object oriented programming facilitates implementation of
objects in parallel.
Objects can be reused
Disadvantages:
The objects must explicitly refer names and interface of
other objects offering the services.
Complex activities are difficult to represent as object
If an interface change, the effect of that change on all users
of the changed object must be evaluated.
Function oriented pipelining:
This model shows how inputs are processed by
functional transformation and how outputs are
produced.
Each processing step is a functional
transformation
These transformations may execute
sequentially or in parallel.
Pipeline model of an invoice processing
system:
Issue Receipts
receipts

Read Identify
issued payment
invoices s
Issue
Find payment
payment remaind
s due er
Invoices Payments

Remainder
s
Advantages of function oriented pipelining:
Reuse of transformations is possible
New transformations are easy to add
It is simple to implement and transformations
may execute sequentially or in parallel
It is easy to understand the system in terms of
input and output processing
Disadvantages:
It requires a common format for data transfer
that can be recognized by all transformations
Interactive systems are difficult to write using
data flow model because of the need for a
stream of data to be processed
Domain specific
architectures
Some architectural models are specific to
particular application domain, called Domain
specific architecture.
2 types of domain specific architectural
models are:
- Generic models
- Reference models
Generic model:

Used to represent real time systems.

Generic models are reused in design
Best example for generic architecture model
is compiler.
 Data flow model of
compiler

Symbol table

Syntax tree

Lexical Syntax Semantic Code

analyser analyser analyser generation
1. A lexical analyzer which takes input language
tokens and converts them to some internal form
2. A symbol table holds information about the names
of classes, objects, variables etc used
3. A syntax analyzer checks the syntax of language
being translated and syntax tree is built
4. Syntax tree is an internal structure representing the
program being compiled
5. A semantic analyzer, uses info from the syntax tree
and the symbol table to check the semantic
correctness of the input language text
6. Code generator generates abstract machine code
Reference Architecture:

Describes layered systems

They are abstract presentation of system
domain
They incorporate all features that include in
system being developed
Example is OSI model
 It’s a layered model
 Each layer provides specific service
 If needed any layer can be reimplemented
with out affecting other layers.
Application

Presentation

Session

Transport

Network

Datalink

Physical
 OSI MODEL:
 It is a way of sub-dividing a communications system into
smaller parts called layers. A layer is a collection of
conceptually similar functions that provide services to the
layer above it and receives services from the layer below
it.
 Physical Layer: defines the electrical and physical
specifications for devices. It defines the relationship
between a device and a transmission medium, such as a
copper or optical cable.
 Establishment and termination of a connection to a
communications medium
 Data Link Layer provides the functional and procedural
means to transfer data between network entities and to
detect and possibly correct errors that may occur in the
Physical Layer
 The Network Layer provides the functional and procedural
means of transferring variable length data sequences from
a source to a destination via one or more networks, while
maintaining the quality of service requested by the
Transport Layer
The Transport Layer provides transfer of data
between end users, providing reliable data
transfer services to the upper layers
The Session Layer controls the connections
between computers. It establishes, manages and
terminates the connections between the local
and remote application.
The Presentation Layer establishes context
between Application Layer entities, in which the
higher-layer entities may use different syntax
and semantics if the presentation service
provides a mapping between them.
The Application Layer is the OSI layer closest to
the end user, which means that both the OSI
application layer and the user interact directly
with the software application.
Design quality 
 Design quality is an elusive concept.
 A good design may be a design that allows efficient code to be produced
 A 'good' design may have characteristics like:
- Capturing all the functionalities of the system correctly
- Easily understandable
- Efficient
- Easily amenable to change
 Adaptability, robustness, clarity, compactness , flexibility etc
 Understandability is major factor because it influences maintainability.
 However, goodness of design involves many factors, which depend on
particular application. A design solution which is good for one application
may not be good for another application
 Ex: For embedded applications, comprehensibility takes back seat .since
it must be implemented in a limited size of memory. So to achieve
compactness, comprehensibility is sacrificed.
 Quality characteristics are equally applicable to function-oriented and
object-oriented designs
Cohesion
Cohesion is measure of relative functional strength of
elements of a module
Cohesion implies that a component or class
encapsulates only attributes and operations that are
closely related to one another .
Modules with good cohesion require less coupling
Strong cohesion is desirable
A cohesive module performs a single task within a
software procedure with little interaction with
procedures that are performed in other parts of a
program.
Various types in cohesion:

Coincidental cohesion
Logical cohesion
Communication cohesion
Sequential cohesion
Functional cohesion
Procedural cohesion
Coincidental cohesion
This cohesion occurs when parts of a module
are grouped arbitrarily (randomly)
Only relationship between parts is that they
have been grouped together.
Ex: Utility class consisting of utility functions
like cleaning disk, antivirus, copying from
external disk etc.
Logical cohesion

This cohesion occurs when parts of module

are grouped because they are categorized
logically to do same thing even if they are
different by nature.
Ex: Grouping all mouse and keyboard input
handling routines
Communicational Cohesion:

This cohesion occurs when parts of module are

grouped because they operate on same data.

Module Module Module Module

1 2 3 4

Data Set

Output
Sequential cohesion

Output of one module serves as input to other module

Intention is to implement a sequence of operations.

Module 1

Module 1 Module 1
Functional Cohesion:

This level of cohesion occurs when a module

performs one and only one computation and
then returns a result.
Specific functional module.
Procedural cohesion:

Modules perform a series of steps

Components or operations are grouped in a
manner that allows one to be invoked
immediately after the preceding one was
invoked, even when there is no data passed
between them.
That is, elements in the module must take up
single control sequence and must be executed
in a specified order.
Coupling:
In analysis and design of OOPs systems, Communication
between objects is essential
But as the amount of communication and collaboration
increases, the complexity of the system also increases.
So, implementation, testing, maintenance of software also
increases.
Coupling is qualitative measure of degree to
which classes are connected to one another.
As classes are more interdependent, coupling increases
Keeping less coupling levels is desirable.
Content coupling:
This coupling occurs when one component modifiies data that is
internal to another component.
 Violates information hiding – a basic design concept.

Module 1 Module 2
Common coupling:
This coupling occurs when a number of components
all make use of global variable.
Although this is sometimes necessary, common
coupling can lead to uncontrolled error propagation
and unforeseen side effects when changes are made.

Data
Module 1 sharing Module 2
Control coupling:
This coupling occurs when one module controls the
logic flow of another module.
Passing Yes or No flag from one module to another
Module A sends control flag to Module B.
Depending on the type of flag the sequence of
processing in module B is controlled

Module 1 Module 2
Stamp coupling:
This coupling occurs when Class B is declared as
a type for an argument of an operation of Class
A, Because Class B is now a part of the
definition of Class A, modifying the system
becomes more complex

Data

Module 1 Module 2
Data coupling:
This coupling occurs when operations pass
long strings of data arguments
Since communication between classes grows
and complexity increases
Testing and maintenance are more difficult.

Module 1 Module 2
External coupling:
 This coupling occurs when one component communicates and
collaborates with infrastructure components (eg., Operating system
functions) . Modules share external data format. Mostly used in
communication protocols and device interfaces. Ex: CAN
(Controlled Area Network) protocol used in Automotive
applications
 Although this type of coupling is necessary, it should be limited to a
small number of components or classes within the system.

Module A

Protocol Device
Interface
Design Principles
Design principles enable software designers to come up
with a good design to the system
Problem partitioning
Abstraction
Modularity

Problem Partitioning:
Dividing complex problems into small sub programs.
Each sub program can be handled independently.
Then integrate to form whole executable program.
It’s a method of DIVIDE AND CONQUER
Abstraction:
Method of describing the program functionality
Levels of Abstraction:
Data abstraction:
Collection of data describing the data object
Ex: Door – Type of door, door weight etc
Procedural abstraction: Reflects functional
abstraction.
Sequence of instructions that has specific
functionality
Ex: Open door.:
Control Abstraction: States desired state with out
specifying exact control mechanism.
Ex: Applying the break
Modularity: Module contains :
Set of instructions,
Some processing logic
Some Data structures
Module can be compiled and stored in library and
included in program.
Modularity is Logical partitioning of software design
Modularity does imply interface overheads related to
info exchange
Modularity has 5 important critiria.
Modular decomposition
Modular composability
Modular understandability
Modular continuity
Modular Protection
Modular Decomposition:
Systematic method of decomposing a problem into
sub problems, to reduce complexity of overall
problems
 Modular composability:
It’s a method that enables the existing design
components to be assembled into a new system
 Modular understandability:
Making a module understand as a single unit without
referring to other modules.
 Modular continuity:
Any small change in the system requirements ,
changes individual modules, but try to make the
impact less
 Modular Protection:
Any problem in the module and its effects are
constrained within the module, so that impact of that
error will be minimum.
Design Notation:
Design notation along with structural programming
concepts help designer to represent Procedural details
Structured Programming is Procedural design
technique.
Some constructs are
Sequential Construct
Conditional construct
Repetitive construct
The notations are :
Graphical Notation
Flow charts
Box diagrams
Tabular Design Notation
Decision table
State diagrams
PDL
Flow charts: Popular way of representing
programming logic.
Conditional

Sequence

Repetition
Box diagrams:

Sequential box notation

F T
cLoop

Else
Loop
Then
Part condition
part
Conditional box notation Looping box notation
Tabular design notation:

Decision tables:
It translates actions and conditions into
tabular form. It is divided into action stub and
condition stub
State machine model
A state machine is a different way of thinking
about computation
A state machine has some number of states,
and transitions between those states
Transitions occur because of inputs
A “pure” state machine only knows which
state it is in—it has no other memory or
knowledge
 Switch on Input to the Set the
the system system timer

E1 E2 E3

Washing machine

W T
R1 R4
TIMER
LINKED TO R2
WHISTLE
WHISTLE
BLOWS R3
WHISTLE
FIRST TIME BLOWS
SECOND
TIME
PDL:
Programming design language
Also called psuedocode
It uses vocabulary of English and overall syntax
of structured programming language
It’s a generic reference
PDL may look like programming language.
PDL cannot be compiled
PDL uses English words embedded directly
within statements
While using PDL no need to worry about syntax
Design Strategies:
Functional Design
Object oriented design