Unit 3

SOFTWARE DESIGN

Software design is the practice of taking a specification of externally

observable behavior and adding details needed for actual computer
system implementation, including human interaction, task management,
and data management details.

Software design is a kind of problem solving. Thinking about design as

problem solving has many advantages.

First it suggests that information may be partitioned between the problem

and the solution.

A second advantage of thinking about design as problem solving is the

perspective it gives on the design activity.

A third advantage of thinking about design as problem solving is that it

suggests the use of time honoured general problem solving techniques in
design.

Good Design Vs Bad Design

Characteristic Good Design Bad Design

Change Change in one part of system One conceptual change requires

doesn’t always require a changes to many parts of the
change in another part of the system.
system.
Logic Every piece of logic has one Logic has to be duplicated.
and one home
Nature Simple Complex
Cost Small Very High
Extension System can be extended with System cannot be extended
changes in onlyone place soeasily.
 Software Design Principles
• Design must specify systems that satisfy product requirements
in accord with design constraints.

• Designs must specify systems that can be constructed on time and within budget
• Designs that specify systems that are easy to change are better.

• Modules should not be too big

• Modules should hide private information
• Modules should not have access to unneeded resources.
• Module coupling should be minimized.
• Module Cohesion should be maximized.
• Simpler designs are better.
• Systems should be designed to reuse existing assets as much as possible.
• Simple and powerful designs are better.

Software Design Models

Software design models may be divided into two broad classes:

• Static Models

o These models represent aspects of software systems that do not change during
execution.

o These models represent software components, their characteristics

and unvarying relationships between software components.
• Dynamic Model

o These models show what happens during software execution.

Examples – interaction diagrams, state charts, DFDs, decision trees and tables, mini
specs.

Software Design process

Software design phase helps the programmer in software coding and
implementation. Software design phase transform the SRS document into the
design document.
Objectives of Software Design

1. Efficiency
2. Correctness
3. Understandability
4. Usability
5. Reliability
6. Maintainability

Characteristics of a good software design

1. Efficiency
2. Correctness
3. Understandability
4. Usability
5. Reliability
6. Maintainability

Levels of Software Design

1. Architectural Design
2. Detailed design (Low Level Design)
3. High-level design
Architectural Design
.
Large systems are always decomposed into subsystems that provide some related
set of services. The initial design process of identifying these sub−systems and
establishing a framework for sub− system control and communication is called
architectural design.
Architectural design methods look into various alternate architectural style of
designing a system. These are:
Data centric architecture approach involves the use of a central database
operations of inserting, updating it in the form of a table.

Data flow architecture is applied when input data takes the form of output after
passing through various phases of transformations. These transformations can be
through various computations done on data.
Object oriented architecture, the software design moves around the
classes and objects of the system. The class encapsulates the data and
methods.
Layered approach defines the number of layers and each layer performs
tasks. The outermost layer handles the functionality of user interface and the
innermost layer handles interaction with the hardware.
Call and return architecture

Issues in architectural design include:

• Gross decomposition of the system into major components.

• Allocation of functional responsibilities to components.
• Component interfaces.
• Communication and interaction between components.
Detailed Design
It Is also called Low Level design

High-level design involves decomposing the system into modules, and

representing the interfaces and the invocation relationships among the modules. During
detailed design, internals of the individual modules are designed in greater detail (e.g.,
the data structures and algorithms of the modules are designed and documented).

It is the specification of the internal elements of all major system components, their
structure properties, relationships, processing and other their algorithms and data
structures.

1. Modularization
2. Structure Charts
3. Pseudo Codes
4. Flow Charts

1. Modularization

There are many definitions of the term module. They range from “a module is a
FORTRAN subroutine” to “a module is an ADA package” to “a module is a work
assignment for an individual programmer. ”All of these definitions are correct, in the
sense that modular systems incorporate collections of abstractions in which each
functional abstraction, each data abstraction, and each control abstraction handles a
local aspect of the problem being solved. Modular system consists of well-defined,
manageable units with well-defined interfaces among the units

Desirable Properties of modular systems include

• Each function in each abstraction has a single, well-defined purpose.

• Each function manipulates no more than one major data structure.
• Functions share global data selectively. It is easy to identify all routines
that share a major data structure.
• Functions that manipulate instances of abstract data types are encapsulated
with the data structure being manipulated.

What for Modularization?

Modularity enhances design clarity, which in turn eases implementation, debugging,

testing, documenting, and maintenance of the software product .
Modules that may be created during program modularizations are:

Process support modules: In these all the functions and data items that are
required to support a particular business process are grouped together.

Data abstraction modules: These are abstract types that are created by
associating data with processing components.

Functional modules: In these all the functions that carry out similar or
Closely related tasks are grouped together.

Hardware modules: In these all the functions, which control particular

Hardware are grouped together.

Advantages of Modular Systems

1. Modular systems are easier to understand and explain because their parts are
functionally independent.
2. Modular systems are easier to document because each part can be
documented
as an independent unit.
3. Programming individual modules is easier because the programmer can focus
on just one small, simple problem rather than a large complex problem.
4. Testing and debugging individual modules is easier because they can be dealt
with in isolation from the rest of the program.
5. Bugs are easier to isolate and understand, and they can be fixed without fear
of introducing problems outside the module.
6. Well-composed modules are more reusable because they are more likely to
comprise part of a solution to many problems. Also, a good module should be
easy to extract from one program and insert into another.

Modularity is an important property of most engineering processes and products. For

example, in the automobile industry, the construction of cars proceeds by assembling
building blocks that are designed and built separately. Furthermore, parts are often
reused from model to model, perhaps after minor changes. Most industrial processes
are essentially modular, made out of work packages that are combined in simple ways
(sequentially or overlapping) to achieve the desired result.

2. Structure Charts
• A Structure Chart is a chart which shows the breakdown of a system to its
lowest manageable parts.
• They are used in structured programming to arrange program modules into a
tree.
• Each module is represented by a box, which contains the module's name.

• The tree structure visualizes the relationships between modules, showing data
transfer between modules using arrows. Structured Charts are an example of a
top−down design where a problem (the program) is broken into its components.

• The tree shows the relationship between modules, showing data transfer
between the models.

Structure charts are used during architectural design to document hierarchical

structures, parameters, and interconnections in a system.

It partitions a system into black boxes. A black box means that functionality is known to
the user without the knowledge of internal design. Inputs are given to a black box and
appropriate outputs are generated by the black box. This concept reduces complexity
because details are hidden from those who have no need or desire to know. Thus,
systems are easy to construct and easy to maintain. Here, black boxes are arranged in
hierarchical format as shown below.

Hierarchical Format of a Structure Chart

Modules at the top level call the modules at the lower level. The connections between
modules are represented by lines between the rectangular boxes. The components are
generally read from top to bottom, left to right. Modules are numbered in a hierarchical
numbering scheme. In any structure chart there is one and only one module at the top
called the root.
Basic Building Blocks of a Structure Chart

The basic building blocks of a structure chart are the following:

1. Rectangular Boxes. A rectangular box represents a module. Usually a
rectangular box is annotated with the name of the module it represents.

A control module branches to more than one sub−module. Library Modules are
re−usable and invokable from any module.

2. Arrows. An arrow connecting two modules implies that during program

execution, control is passed from one module to the other in the direction of
the connecting arrow.

A directed arrow with filled circle at the end represents control flow.
3. Data-flow Arrows. Data-flow arrows represent that the named data passes
from one module to the other in the direction of the arrow.

A directed arrow with empty circle at the end represents data flow.

4. Library Modules. Library modules are the frequently called modules and are
usually represented by a rectangle with double edges. Usually when a module
is invoked by many other modules, it is made into a library module.
5. Selection. The diamond symbol represents that one module out of several
modules connected with the diamond symbol are invoked depending on the
condition satisfied, which is written in the diamond symbol.

It is represented by small diamond at the base of module. It depicts that control module
can select any of sub−routine based on some condition.

6. Repetitions. A loop around the control-flow arrows denotes that the respective
modules are invoked repeatedly.

A curved arrow represents loop in the module. All sub−modules covered by loop
repeat execution of module.
Example
An example of structure chart representing the logic for calculating average:
 Pseudocode
A pseudocode is an informal way of writing a program. However, it is not a computer program. It only
represents the algorithm of the program in natural language and mathematical notations. Besides,
there is no particular programming language to write a pseudocode. Unlike in regular programming
languages, there is no syntax to follow when writing a pseudocode. Furthermore, it is possible to use
pseudocodes using simple English language statements.

• A pseudocode to find the total of two numbers is as follows.

Sum_Of_Two_Numbers()
Begin
Set sum =0;
Read: number 1, number 2;
Set sum = number1 + number 2;
Print sum;
End

• A pseudocode to find the area of a triangle is as follows.

Area_of_Trinagle()
Begin
Read: base, height;
Set area = 0.5 * base * height;
Print area;
End

So, after writing the pseudocode, we can write the actual program using that pseudocode. Moreover,
as it represents the algorithm, we can implement it using any programming language.

Advantages
• It is easy to understand even a complex program
• It does not follow any programming language syntax
• Programs can be easily generated by pseudo−code
• It allows us to understand the logic of a program very quickly
• Pseudo−code can be modified easily

Disadvantages
• Unlike the programs, a pseudo−code cannot be compiled or interpreted from which errors
cannot be identified
• As pseudo−code can be written in any order, so it becomes difficult to understand the flow of
a program
Flowchart
A flowchart represents an algorithm using a diagram. Flow charts, use rectangles, ovals, diamonds and
potentially numerous other shapes to define the type of step, along with connecting arrows to define
flow and sequence. They are widely used in multiple fields to document, study, plan, and communicate
often complex processes in clear, easy−to−understand diagrams.

• A simple flowchart for marks calculation is as follows.

In it, the oval shape denotes the start and end. And, the rhombus shape represents inputs and outputs.
Entering marks is an input while displaying marks is an output. Further, the diamond shape symbol
represents the decision selection. Depending on the decision, the correct output will be displayed.

Flow Chart
In overall, a flow chart represents the sequence of steps to follow in order to solve the problem.
Thus, the flowchart diagrams are easier to draw and understand.

Advantages of Flowchart
• Effective Communication: Flowcharts are better way of communicating the logic of the
system.
• Effective Analysis: Flowchart which gives broad idea about the logic so that problem can be
analyzed more efficiently.
• Easy Debugging and Efficient Testing: The Flowchart helps in debugging and testing process.
• Efficient Coding: The flowcharts are very useful during program development phase.
• Proper Documentation: Flowcharts serves as a good program documentation, which is
needed for various purposes.
• Efficient Program Maintenance: Maintenance of operating programs becomes easy with the
help of flowchart.
Disadvantages of Flowchart
• Complex Logic: For complicated logic, flowchart becomes complex and clumsy.
• Difficulty in Modifications: If change is required in the logic then
flowchart needs to be redrawn and requires a lot of time.

Difference between Pseudocode and Flowchart

• Definition
Pseudocode is an informal high−level description of the operating principle of
an algorithm while a flowchart is a diagrammatic representation that illustrates
a solution model to a given problem.
• Representation
A pseudocode is written in natural language and mathematical notations help
to write pseudocode. However, a flowchart is written using various symbols.

Structured Design
Structured design gives better understanding of how the problem is
being solved. Structured design is mostly based on ‘divide and conquer’
strategy where a problem is broken into several small problems and
each small problem is individually solved until the whole problem is
solved.
• Structured design is a top-down decomposition of system
functionality
• Process and procedures
• DFD
• Decision Tree
• ER Diagram
Object Oriented Design
Object-oriented methodology is defined as the system of principles and
procedures applied to object-oriented software development. Each
object can hide data from other objects.
• Focus on object
• Use Case Model
• Object Model
Concepts of Object-Oriented Design:

1. Objects
2. Classes
3. Polymorphism
4. Encapsulation
5. Inheritance

Difference Between Function Oriented Design and

Object Oriented Design

Function Oriented Design Object Oriented Design

Uses Inmutable Data Use Mutable Data
It is a top down approach. It is a bottom up approach.
It is Based on Data and Function It is Based On object and Models
Does Not Support Parallel Support Parallel programming
programming
Data Hiding Less secure Data Hiding more secure
Data flow diagram Carried out using UML
What you are doing? How You are doing
Function/procedure level. We decompose in class level.
System Design Strategy
1. Top-downapproach

Main module is divided into several smaller and simpler submodules or

segments based on the task performed by each module

2. Bottom-up approach
These modules are further combined to form the next higher-level modules.
process of grouping several simpler modules to form higher level modules
continues until the main module of system development process is achieved.
Difference between top down and bottomup
approach
Top down Approach Bottom up Approach

In this approach We focus on breaking In bottom up approach, we solve

up the problem into smaller parts. smaller problems and integrate it as
whole and complete the solution.
It is used in debugging It is basically used in testing.
Used by structured programming Used by object oriented programming
language language
Decomposition takes place. Composition takes place.
Less Flexibility More Flexibility
Top-Down Approach is Theory-driven Bottom-Up Approach is Data-Driven.
Coupling

Module Coupling

In software engineering, the coupling is the degree of interdependence between software

modules. Two modules that are tightly coupled are strongly dependent on each other.
However, two modules that are loosely coupled are not dependent on each other.
Uncoupled modules have no interdependence at all within them.

A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls
between modules increase or the amount of shared data is large. Thus, it can be said that a
design with high coupling will have more errors.

Types of Module Coupling

 The various types of coupling techniques are shown in fig:

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.
Data Coupling: When data of one module is passed to another module, this is called data coupling.

2. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items
such as structure, objects, etc. When the module passes non-global data structure or entir e structure to
another module, they are said to be stamp coupled. For example, passing structure variable in C or
object in C++ language to a module.

3. Control Coupling: Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.

4. External Coupling: External Coupling arises when two modules share an externally imposed data
format,communication protocols, or device interface. This is related to communication to external tools
and devices.

5. Common Coupling: Two modules are common coupled if they share information through some
global data items.

6. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch
from one module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module belong
together. Thus, cohesion measures the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low
cohesion."
 Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module,
cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module form
the components of the sequence, where the output from one component of the sequence is input to the
next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the
module refer to or update the same data structure, e.g., the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module
are all parts of a procedure in which particular sequence of steps has to be carried out for achieving a
goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the
methods must be executed in the same time, the module is said to exhibit temporal cohesion.
 6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a
similar operation. For example Error handling, data input and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that
are associated with each other very loosely, if at all.

Coupling Cohesion
Coupling shows the relationships between Cohesion shows the relationship within the
modules. module
Coupling is also called Inter-Module Cohesion is also called Intra-Module
Binding Binding
In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.
Loose coupling is the best for software. Highly cohesion is the best for software.
high coupling will have more errors Low cohesion is the Error of software.
It represents the independence among the It represents the independence among the
modules. modules.

Software Measurement and Metrics

Functional Point (FP) Analysis

1. Used To Estimate Complexity ,size and Functionality of software Project
2. A measure of the software's functionality based on user requirements and features.
3. It is less dependent on the programming language used, as it's based on functionality.
4. Estimating model is expensive
5. Process of implementing it in software is time-consuming.
Unadjusted Function Point (UFP)
It Count only 5 Factor

1.Number of External Inputs(EI)

2. Number of External Output (EO)
3. Number of External inquiries (EQ)
4. Number of Internal files (ILF)
5. Number of External interfaces (EIF)
Measurement Low Complexity Average High Complexity
Complexity
External Inputs (EI) 3 4 6
External Output (EO) 4 5 7
External inquiries (EQ) 3 4 6
Internal files (ILF) 7 10 15
External interfaces 5 7 10
(EIF)

2.Value Adjustment Factor (VAF)

It Count only 14 Factor

Its Value May Vary 0 to 35
It is Rated on Scale 0(Lowest) to 5(Highest)

VAF = 0.65 + (0.01 *TDI)

Where TDI= Total Degree of Influence

FP (Function Point)= UFP× VAF

Where VAF = Value Adjustment Factor
UAF= Unadjusted Function Point

Production P=FP/Effort
Example 1

Consider a software project with the following information domain characteristics for calculation of
function point metric.

Number of external inputs (I) = 30

Number of external outputs (O) = 60

Number of external inquiries (E) = 23

Number of files (F) = 08

Number of external interfaces (N) = 02

It is given that the complexity weighting factors for I, O, E, F and N are 4, 5, 4, 10 and 7, respectively.
It is also given that, out of fourteen value adjustment factors that influence the development effort,
four factors are not applicable, each of the other four factors have value 3, and each of the remaining
factors have value 4. The computed value of function point metric is _________.

Answer

Step 1 Calculate Unadjusted Function Point UFP

UFP( Unadjusted Function Point) =30*4+60*5+23*4+08*10+02*7

UFP =606

Step 2 Calculate TDI= Total Degree of Influence

four factors are not applicable Value is Zero
4*0=0
other four factors have value 3
4*3=12
remaining factors have value 4
remaining(14-4-4)=6*4=24
TDI=0+12+24=36

Step 3 Calculate VAF = Value Adjustment Factor

VAF = 0.65 + (0.01 *TDI)
VAF=0.65+(0.01*36)
VAF=1.01
Step 4 Calculate Function Point (FP)

FP (Function Point)= UFP× VAF

=606*1.01
=612

Halestead’s Software Science

Computer program is considered to be a collection of tokens, which may be classified as either
operators or operands. All software science metrics can be defined in terms of these basic symbols.
These symbols are called as a token.

Advantages of Halstead Metrics:

1. It is simple to calculate.
2. It measures overall quality of the programs.
3. It predicts the rate of error.
4. It predicts maintenance effort.
5. It does not require the full analysis of programming structure.
6. It is useful in scheduling and reporting projects.
7. It can be used for any programming language.

Disadvantages of Halstead Metrics:

1. It depends on the complete code.
2. It has no use as a predictive estimating model.

Halestead’s Table Formula

Measure Symbol Formula
Program length N N = N1 + N2
Program vocabulary N n = n1 + n2
Volume V V = N * (log2 n)
Difficulty D D = (n1 / 2) * (N2 / 2)
Effort E E=D*V
Halstead’s uses certain measures such as program length, program vocabulary, volume,
difficulty, and effort for the given algorithm. By this Halstead’s is trying to show that the
program length can be calculated, volume of algorithm can be estimated. The above given table
shows how actually these measure can be obtained.

The Halstead’s measures are applicable to operational system and to development efforts once
the code has been written. Thus using Halstead’s measurement experimental verification can be
performed in software science.

Program length:

The length of a program is total usage of operators and operands in the program.

Length (N) = N1 + N2

Program vocabulary:

The Program vocabulary is the number of unique operators and operands used in the program.

Vocabulary (n) = n1 + n2

Program Volume:

The Program Volume can be defined as minimum number of bits needed to encode the program.

Volume (V) = N log2 n

Length estimation:

N = n1 log2 n1 + n2 log2 n2

Guideline for calculating operands and operators:

1. All the variables and constants are considered as operands.

2. Local variables with same name, if occurring in different functions are counted as unique
operand.
3. Function calls are considered as operators.
 4. The looping statements, do … while, while, for, are operators. The statements if, if …
else, are operators. The switch … case statements are considered as operators.
5. The reserve worlds, returns, default, continue, break, sizeof are all operators.
6. The brackets, commas, semicolons, are operators.
7. The unary and binary operators are considered as operators. The & is considered as
operator.
8. In arrays, array name and index are considered as operands and [ ] is considered as
operator.
9. All hash directives can be ignored.
10. Comments are not considered.
11. In Goto statement, goto is considered as operator and label as operand.

Example: Obtain Halstead’s length and volume measure for following C function.

Void swap (int a[ ], int i)

int temp;

Temp = a[i];

a[i] = a[i+1];

a[i+1] = temp;

We first find out the operands and operators from above function along with their occurrences.

Operands Occurrences Operators Occurrences

swap 1 () 1
a 5 {} 1
i 5 void 1
temp 3 int 3
1 2 [] 5
 , 1
; 4
= 3
+ 2
n1 = 5 N1 = 16 n2 = 9 N2 = 21

N = N1 + N2

= 16 +21 = 37

N = 37

n = n1 + n2

= 5 + 9 = 14

n = 14

Estimated length = n1 log n1 + n2 log n2

= 5 log 5 + 9 log 9

= 5 * 2.32 + 9 * 2.19 = 31.37

Estimated length = 31.37

Volume = N * log n

= 37 * log (14)

37 * 2.63 = 97.64

Volume (V) = 97.64

Cyclomatic Complexity Measures
Cyclomatic complexity is a software metric used to measure the complexity of
a program. It gives the quantitative measure of logical complexity of the program.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator
of software
complexity. The cyclomatic number is equal to the number of linearly
independent paths through a program in its graphs representation. For a program
control graph G, cyclomatic number, V (G), is given as:

V (G) = E - N + 2 * P
Or
V (G) = E - N + 2
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.
Advantages:
1. Gives complexity of various designs
2. Computed early in life cycle
3. Easy to apply
4. Measures minimum effort
Disadvantages:
1. Measures program’s control complexity and not the data complexity
2. Nested conditional structures are harder to understand
3. Ignore the size of the program
Method 1: Total number of regions in the flow
graph is a Cyclomatic complexity.+1
Method 2: The Cyclomatic complexity, V (G) for a
flow graph G can be defined as V (G) = E - N + 2
Where: E is total number of edges in the flow graph.
N is the total number of nodes in the flow graph.
Method 3: The Cyclomatic complexity V (G) for a
flow graph G can be defined as V (G) = P + 1 Where:
P is the total number of predicate nodes contained
in the flow G.

Example 1

1) Cyclomatic complexity V(G) = Total number of

Region+1 = 2+1=3
2) Cyclomatic complexity V(G) = E - N + 2
Cyclomatic complexity V (G) = 7- 6 +2 = 3
3) Cyclomatic complexity V(G) =P+1 V (G) = 2 + 1 =3

Example 2

1. Cyclomatic complexity V(G) = Total number of

Region+1 =V(G) = R + 1 = 2 + 1 = 3
2. Cyclomatic complexity V(G) = E - N + 2
V(G) = E - N + 2 = 8 - 7 + 2 = 3
3. Cyclomatic complexity V(G) =P+1 V (G
V(G) = P + 1 = 2 + 1 = 3