SOFTWARE DESIGN

 Software Design is a blue print for Software constructer.

 It translates SRS in to blue Print that can be used for Software

Construction .
 It is a multi steps process consisting of :-
1.) Informal design outline

2.) Informal design

3.) Formal design

4.) More formal design

4.) Finished Design

CONTD…
Software design focuses on creating four distinct attribute of software :-

1.) Data Structure : Required to implement Software ERD, Data

Dictionary

2.) Software Architecture : The sub system making up the System

and their relationship , modular frame work of
a software

3.) Interface Design : How Software Communicates with itself for

each Sub system, how it interface other sub
system.

4.) Producer Detail : Producer description of software Components .

DESIGN DESCRIPTION

 Graphical Notations : Used to display relationship between modules to

form abstract design

 Program Description Language : Control Structure intention of

Designer

 Informal Techniques: Information about Design rational or non

Functional Consideration.
CONCEPTUAL AND TECHNICAL DESIGN
Design is a two part, iterative process.

1.) First, the conceptual design is produced.

CONCEPTUAL DESIGN : It tells the customer what system will do.

2.) Once the customer approves the conceptual design, then it is

translated into a more detailed document, the technical design.

TECHNICAL DESIGN : It allows the system developers to

understand the actual hardware and software needed to solve the
customer’s problem.
Design Strategies
1. Functional Design and
2. Object Oriented Design
Functional Design
The system is designed from Functional view
point starting with high level view and
progressively refining it in to more detailed
design . The system state is centralized and
shared between the functions operating on
that state.
 Object oriented Design : The system is viewed as
collection of objects (Booch , Jacobon and Rumbugh)

Identify objects , attributes , operations,

Organistaion of objects using aggregation’
Construction of Use case diagram’
which object service is used by other object
-specification of object interface design
 Advantages of OO approach

• High Level of abstraction-no different Language for

analysis , design
• No valuating between phases( programming ,
transition time is less
• code Reuse
• good programming techniques are support by OO
Approach
FUNCTIONAL ORIENTED DESIGN
 The system is designed from functional view point starting with high
Level view and progressing refining it in to more detailed design until
no more refinement is possible top down, bottom up or hybrid.

 The steps of Functional oriented design are:

(1) Data Flow Design : Model the system using data flow diagram which
shows how data passes through system

(2) Derive structure chart from DFD using transform analysis or

transaction analysis
STRUCTURE CHART
Structure chart is software architecture that depict graphically
hierarchical implementation model of software system
in terms of modules and shows exchange of data between
these modules.

Data Couple o→ Shows actual data exchange

Control Data .→ control information
FORM OF A STRUCTURE CHART
Module A
Data 1
Data 2
1 2
Module B Module C

1.1 1.2 2.1 2.2 2.3

Module D Module E Module F Module G Module H

1.11
Module I
PRINCIPAL DESIGN CRITERION
Principal Design Criterion : The modular structure identified
should reflect the structure of the
problem.
Modular Structure Properties
1. Inter-module property : Modules should be as loosely interconnected as
possible
- highly coupled modules are strongly inter-connected
- loosely coupled modules are weakly inter-connected
- Decoupled modules exhibit no inter-connection.

2. Intra-module property : Modules should be cohesive.

A module should capture in it strongly-related elements of the problem

3. Some heuristics help in constructing good modules.

GOOD QUALITY STRUCTURE CHART
 The aim of the structured design is to produce a good quality structure
chart .

 Criterion to measure the design quality is to measure coupling and

cohesion
COHESION
 It is a measure of the degree to which elements of modules are
functionally related.
 Every component is responsible for implementing a function.
 Its element should be logically related and concentrate towards
implementation of that function .
 A module should be highly Cohesive
 Different types of cohesion are:
1.) Coincidental cohesion
2.) Logical cohesion
3.) Temporal cohesion
4.) Procedural cohesion
5.)Communicational cohesion
6.) Sequential cohesion
7.) Functional cohesion
TYPES OF COHESION
i.) Coincidental Cohesion(Worst) :
A module whose elements have no apparent relationship . They are put
together by coincidence. The operations can be different modules.
Example:-
If train-type > 5 or Value < 0 do TR-error
Read Master in to Q
Add 3 to REPT-LINES
Draw backs : Does not reflect problem structure
CONTD…
2.) Logical Cohesion :
Module forming by putting together a class of functions to be
performed similar function on set of data elements which are
unrelated.
Read , Disk , Terminal , MTape etc .
Example:-
1. Produce job control reports, Library file listings, operator summaries
and customer run support.
2. Collect Run statistics for the program, commands executed, IO
usage, errors and CPU time used.
Draw back : Results in control coupling between Modules
CONTD…
3.) Temporal Cohesion :

Modules Formulation by putting together all functions/operations which

happens at same time. X and Y are not related but they should be performed at
same time.
input all, compute all , Initialize Variable , Initialize system state etc.

Example :-
1.) Before sorting, write a proof tape and check totals.

2.) An error module which is invoked whenever failure takes place. The module
 Cancels all tasks
 Closes all windows
 Saves all data files
 Shuts down the machine
These are tasks which are not logically or functionally related but take place
when failure takes place.
CONTD…
4.) Procedural Cohesion:
When a sequence of operations are to be performed in some order like
input data , check data , process / manipulate data. These operations
are independent but put together in a Module.
An example :-
Employee
detail Net salary

Validate Compute Check Calculate

employee monthly loan net
salary detail salary
CONTD…
5.) Communicational Cohesion:
A module with communicational type of cohesion is concerned with
the same input or output data. Sequence is not important in this case
as shown in the figure below :-Update master time clock record, the
employee time record, and the current pay entry - all from the same
record
Salary details

Employee Lease
record record Project details

Calculate employee
information
CONTD…
6.) Sequential Cohesion :
X output some data that is input to Y , so X-Y are put together.
They could have been put into separate module like sequence of
transformation in DFD put together. Ex: Update the current inventory
record and write it to disk.

Employee
Net salary
details

Calculate employee
information

Compute salary
CONTD…
7.) Functional Cohesion :
 This is the most desirable kind of cohesion with in a module.
 In such type of module all components/instructions contribute to
one single function.
 This feature is better supported in object oriented languages.
 In functionally cohesive modules, all elements together perform a
single function and nothing else.
COUPLING
Coupling is a measure of the strength of the inter-connection between
modules
 Highly coupled : Strongly connected and they share a great deal of
dependence between Module
 Loosely Coupled : Relatively independent
 Decoupled Module : No inter connection

 Four Measures of coupling are:-

 Type of inter connection between Modules(Number of calls)

 Complexity of Module interface (number of parameters passed)
 Nature of infmn Flow across Modules
 Binding time of connection.
TYPES OF COUPLING (BEST TO WORST)
1.) Data coupling :
A and B communicate only by passing parameters .If a procedure
needs a part of data structure , just that part should be passed and not
total data structure.

2.) Stamp coupling:

A and B make use of common data type but perform different
operations on it. [complete data structure is passed]
Employee
Employee
management
Salary
record details
Salary Employee Print salary
Calculate salary details record detail
CONTD…
3.) Control coupling:
 In such type of coupling between modules, one module controls the
execution of second module by passing a control information.
 It means that inner details of second module are known to the first
module and black box concept no longer exists.
 In this type of coupling at least one control flag exists between the
two modules as shown in Fig.

Get input from user

C-flag Account Data

number

Process transaction
CONTD…
4.) Common Coupling:
A and B both use some shared data area. If shared data is changed ,
both modules have to modify their procedure. Hence system becomes
difficult to maintain and is un necessarily constrained.

5.) Content coupling :

When A modifies B by directly branching in to Middle of B or
modifying local data of B or instruction. This is least wanted coupling.
TRANSFORMATION FROM DFD TO STRUCTURE CHART
There are two types of analysis
1.) Transform Analysis System focuses on deriving new information from
existing data
2. ) Transaction Analysis System focuses on dispatch data to their
appropriate locations for processing

I.) TRANSFORM ANALYSIS

It identifies the primary functional components and high level input
and outputs for these components.
CONTD…
There are three steps in the transformation analysis:
 First step
Divide the DFD into three parts
Afferent branch
Starting from the physical inputs move inwards
along the DFD till a stream is identified that can
no longer be considered as incoming data elements.
Efferent branch
Starting from the physical output move inwards till a stream is
identified that can no longer be considered as outgoing data
elements
Central Transform
All transforms that lie between these streams are called central
transforms
CONTD…
 Second step
 Derive the structure chart by drawing on module for each of the
afferent branch, central transform, and the efferent branch
 They are drawn below a module called the root module which
invokes these modules
 Third step
 Refine the structure chart by adding sub modules required by each
of the high-level functional components
 Factoring
 Process of breaking functional components into subcomponents is
called factoring
 The factoring process should be repeated until all bubbles in the
DFD are represented in the structure chart
 Fourth step
Add the control Flags at appropriate points
LEVEL 1 DFD SHOWING CENTRAL TRANFORM
Example 1 :-
Input A,B,C

CHECK
INPUTS Central Transform
1

Valid Data A,B,C

COMPUTE

RMS
Afferent 2 RMS value

DISPLAY
RESULT
3
Output RMS
Efferent
EXAMPLE 1 (CONTD…)
DERIVED STRUCTURE CHART

RMS
Valid input RMS
Figure: Level 1 DFD Showing Central Transform

Student_list
I/P Sort list
a
Stored_Student_list(b)

Result(e)

Sessional Marks list (c) Compute Summari O/P

I/P Result ze- result
Result_Summary
(e)

Final Marks list (d)

I/P
Main

b e
b e
c d c
d
Get Get
Get Compute Output
Sessional_ Final_Mark
Student_List Result Result
marks s

Figure: First level structure chart

b

Get
Student_List

a a
b

Read
Sort_List
Student_List

Figure: Afferent portion of a structure chart

DETAILED STRUCTURE CHART
Example (contd…)
Main

b e
b
c EOF d EOF c e
marks
missing
d

Get Student Get Sessional Get final Compute Output

list marks marks result result
b e f
a
EOF a f

Read Summarize
Sort list Print result
student list result
LEVEL 1 DFD SHOWING CENTRAL TRANFORM
Example 2 :-
Customer data file
Customer
record
Central Transform
Customer 4.4
Valid
record 4.3
account 4.1
number Print
Get Authorize transaction
customer
Record
payment
& update
account

4.2

Get
customer valid
Amount to be amount
withdrawn
EXAMPLE 2 (CONTD…)
DERIVED STRUCTURE CHART
Cash With
Authorized
drawl payment
Input
customer
record Authorized
Valid payment
Valid
amount
amount
Get Get valid Authorize Print
customer amount to payment & transaction
record withdraw update detail
Valid
Input
amount
amount
Input
amount
Validate
Get amount
amount to be
to withdraw withdrawn
ASSUMPTIONS MADE IN TRANSFORM
CENTRED METHOD

- All afferent modules will have afferent modules and transform modules
as subordinates

- All efferent modules shall have efferent modules and transform modules
as subordinates

- All transform modules shall have transform modules as subordinates

These assumptions are violated in practice. For example, it is possible to

have transform modules with afferent modules as subordinates.
Thank You !!