UNIT 3:

SOFTWARE DESIGN
TOPICS: Software Design: Basic Concept of Software Design, Architectural Design, Low Level Design:
Modularization, Design Structure Charts, Pseudo Codes, Flow Charts, Coupling and Cohesion Measures, Design
Strategies: Function Oriented Design, Object Oriented Design, Top-Down and Bottom-Up Design. Software
Measurement and Metrics: Various Size Oriented Measures: Halestead’s Software Science, Function Point (FP) Based
Measures, Cyclomatic Complexity Measures: Control Flow Graphs.

SOFTWARE DESIGN BASICS:

Software design is a process to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation.
For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas
for coding and implementation, there is a need of more specific and detailed requirements in software terms.
The output of this process can directly be used into implementation in programming languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from
problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

SOFTWARE DESIGN LEVELS

Software design yields three levels of results:
 Architectural Design - The architectural design is the highest abstract version of the system. It
identifies the software as a system with many components interacting with each other. At this level,
the designers get the idea of proposed solution domain.
 High-level Design - The high-level design breaks the ‘single entity-multiple component’ concept of
architectural design into less-abstracted view of sub-systems and modules and depicts their interaction
with each other. High-level design focuses on how the system along with all of its components can be
implemented in forms of modules. It recognizes modular structure of each sub-system and their
relation and interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as a system and
its sub-systems in the previous two designs. It is more detailed towards modules and their
implementations. It defines logical structure of each module and their interfaces to communicate with
other modules.

MODULARIZATION
Modularization is a technique to divide a software system into multiple discrete and independent modules,
which are expected to be capable of carrying out task(s) independently. These modules may work as basic
constructs for the entire software. Designers tend to design modules such that they can be executed and/or
compiled separately and independently.
Modular design unintentionally follows the rule of ‘divide and conquer’ problem-solving strategy, this is
because there are many other benefits attached with the modular design of a software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
STRUCTURE CHARTS:
Structure Chart represent hierarchical structure of modules. It breaks down the entire system into lowest
functional modules, describe functions and sub-functions of each module of a system to a greater detail.
Structure Chart partitions the system into black boxes (functionality of the system is known to the users but
inner details are unknown). Inputs are given to the black boxes and appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from top to bottom and left to right.
When a module calls another, it views the called module as black box, passing required parameters and
receiving results.
Symbols used in construction of structured chart
 Module: It represents the process or task of the system. It is of three types.
o Control Module: A control module branches to more than one sub module.
o Sub Module: Sub Module is a module which is the part (Child) of another module.
o Library Module: Library Module are reusable and invokable from any module.
 Conditional Call: It represents that control module can select any of the sub module on the basis of
some condition.
 Loop (Repetitive call of module): It represents the repetitive execution of module by the sub module.
and a curved arrow represents loop in the module.
 Data Flow: It represents the flow of data between the modules. It is represented by directed arrow with
empty circle at the end.
 Control Flow: It represents the flow of control between the modules. It is represented by directed arrow
with filled circle at the end.
 Physical Storage: Physical Storage is that where all the information are to be stored.

“Structure chart for E-mail server”

Types of Structure Chart:

 Transform Centered Structured: These type of structure chart are designed for the systems that receives
an input which is transformed by a sequence of operations being carried out by one module.
 Transaction Centered Structure: These structure describes a system that processes a number of
different types of transaction.

PSEUDO CODE:
Pseudo code is written more close to programming language. It may be considered as augmented programming
language, full of comments, and descriptions. Pseudo code avoids variable declaration but they are written
using some actual programming language’s constructs, like C, Fortran, Pascal, etc.
Pseudo code contains more programming details than Structured English. It provides a method to perform the
task, as if a computer is executing the code.
Advantages of Pseudocode
 Improves the readability of any approach. It’s one of the best approaches to start implementation of an
algorithm.
 Acts as a bridge between the program and the algorithm or flowchart. Also works as a rough
documentation, so the program of one developer can be understood easily when a pseudo code is
written out. In industries, the approach of documentation is essential. And that’s where a pseudo-code
proves vital.
 The main goal of a pseudo code is to explain what exactly each line of a program should do, hence
making the code construction phase easier for the programmer.
Disadvantages of Pseudocode
 Pseudocode does not provide a visual representation of the logic of programming.
 There is no proper format for writing the for pseudocode.
 In Pseudocode there is extra need of maintain documentation.
 In Pseudocode there is no proper standard very company follow their own standard for writing the
pseudocode.

FLOW CHARTS:
Flowchart is a graphical representation of an algorithm. Programmers often use it as a program-planning tool
to solve a problem. It makes use of symbols which are connected among them to indicate the flow of
information and processing. The process of drawing a flowchart for an algorithm is known as “flowcharting”.
Basic Symbols used in Flowchart Designs

 Terminal: The oval symbol indicates Start, Stop and Halt in

a program’s logic flow. A pause/halt is generally used in a
program logic under some error conditions. Terminal is the
first and last symbols in the flowchart.
 Input/Output: A parallelogram denotes any function of
input/output type. Program instructions that take input from
input devices and display output on output devices are
indicated with parallelogram in a flowchart.
 Processing: A box represents arithmetic instructions. All
arithmetic processes such as adding, subtracting,
multiplication and division are indicated by action or
process symbol.
 Decision: Diamond symbol represents a decision point.
Decision based operations such as yes/no question or
true/false are indicated by diamond in flowchart.
 Connectors: Whenever flowchart becomes complex or it
spreads over more than one page, it is useful to use
connectors to avoid any confusions. It is represented by a
circle.
 Flow lines: Flow lines indicate the exact sequence in which
instructions are executed. Arrows represent the direction of
flow of control and relationship among different symbols of flowchart.

Advantages of Flowchart:
 Flowcharts are better way of communicating the logic of system.
 Flowcharts act as a guide for blueprint during program designed.
 Flowcharts helps in debugging process and provides better documentation.
 With the help of flowcharts programs can be easily analyzed.
  Flowcharts serve as a good proper documentation.

Disadvantages of Flowchart:
 It is difficult to draw flowchart for large and complex programs.
 In this there is no standard to determine the amount of detail.
 Difficult to reproduce the flowcharts.
 It is very difficult to modify the Flowchart.

COUPLING AND COHESION

When a software program is modularized, its tasks are divided into several modules based on some
characteristics. As we know, modules are set of instructions put together in order to achieve some tasks. They
are though, considered as a single entity but, may refer to each other to work together. There are measures by
which the quality of a design of modules and their interaction among them can be measured. These measures
are called coupling and cohesion.

Cohesion:
Cohesion is a measure that defines the degree of intra-dependability within elements of a module. The greater
the cohesion, the better is the program design.
There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of breaking
the program into smaller modules for the sake of modularization. Because it is unplanned, it may serve
confusion to the programmers and is generally not-accepted.
 Logical cohesion - When logically categorized elements are put together into a module, it is called
logical cohesion.
 Emporal Cohesion - When elements of module are organized such that they are processed at a similar
point of time, it is called temporal cohesion.
 Procedural cohesion - When elements of module are grouped together, which are executed sequentially
in order to perform a task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are grouped together, which are executed
sequentially and work on same data (information), it is called communicational cohesion.
 Sequential cohesion - When elements of module are grouped because the output of one element serves
as input to another and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly expected.
Elements of module in functional cohesion are grouped because they all contribute to a single well-
defined function. It can also be reused.

Coupling:
Coupling is a measure that defines the level of inter-dependability among modules of a program. It tells at
what level the modules interfere and interact with each other. The lower the coupling, the better the program.
There are five levels of coupling, namely -
 Content coupling - When a module can directly access or modify or refer to the content of another
module, it is called content level coupling.
 Common coupling- When multiple modules have read and write access to some global data, it is called
common or global coupling.
 Control coupling- Two modules are called control-coupled if one of them decides the function of the
other module or changes its flow of execution.
 Stamp coupling- When multiple modules share common data structure and work on different part of
it, it is called stamp coupling.
  Data coupling- Data coupling is when two modules interact with each other by means of passing data
(as parameter). If a module passes data structure as parameter, then the receiving module should use
all its components.

DESIGN STRATEGIES:
Software design is a process to conceptualize the software requirements into software implementation.
Software design takes the user requirements as challenges and tries to find optimum solution. While the
software is being conceptualized, a plan is chalked out to find the best possible design for implementing the
intended solution. There are multiple variants of software design

1. Function Oriented Design

In function-oriented design, the system comprises of many smaller sub-systems known as functions. These
functions are capable of performing significant task in the system. The system is considered as top view of all
functions. Function oriented design inherits some properties of structured design where divide and conquer
methodology is used.
This design mechanism divides the whole system into smaller functions, which provides means of abstraction
by concealing the information and their operation. These functional modules can share information among
themselves by means of information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the function changes the state of
the program, which sometimes is not acceptable by other modules. Function oriented design works well where
the system state does not matter and program/functions work on input rather than on a state.
Design Process
 The whole system is seen as how data flows in the system by means of data flow diagram.
 DFD depicts how functions change data and state of the entire system.
 The entire system is logically broken down into smaller units known as functions on the basis of their
operation in the system.
 Each function is then described at large.

2. Object Oriented Design

Object Oriented Design (OOD) works around the entities and their characteristics instead of functions
involved in the software system. This design strategy focuses on entities and its characteristics. The whole
concept of software solution revolves around the engaged entities. Let us see the important concepts of Object
Oriented Design:
 Objects - All entities involved in the solution design are known as objects. For example, person, banks,
company, and customers are treated as objects. Every entity has some attributes associated to it and
has some methods to perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an instance of a class. Class
defines all the attributes, which an object can have and methods, which defines the functionality of the
object. In the solution design, attributes are stored as variables and functionalities are defined by means
of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are bundled
together is called encapsulation. Encapsulation not only bundles important information of an object
together, but also restricts access of the data and methods from the outside world. This is called
information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-
classes can import, implement and re-use allowed variables and methods from their immediate super
classes. This property of OOD is known as inheritance. This makes it easier to define specific class
and to create generalized classes from specific ones.
  Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but
vary in arguments, can be assigned same name. This is called polymorphism, which allows a single
interface performing tasks for different types. Depending upon how the function is invoked, respective
portion of the code gets executed.
Design Process: Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the following steps
involved:
 A solution design is created from requirement or previous used system and/or system sequence
diagram.
 Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.

3. Top Down Design

We know that a system is composed of more than one sub-systems and it contains a number of components.
Further, these sub-systems and components may have their own set of sub-systems and components, and
creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to achieve more than
one sub-system or component based on some characteristics. Each sub-system or component is then treated
as a system and decomposed further. This process keeps on running until the lowest level of system in the top-
down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the more specific part of it.
When all the components are composed the whole system comes into existence.
Top-down design is more suitable when the software solution needs to be designed from scratch and specific
details are unknown.

4. Bottom Up Design
The bottom up design model starts with most specific and basic components. It proceeds with composing
higher level of components by using basic or lower level components. It keeps creating higher level
components until the desired system is not evolved as one single component. With each higher level, the
amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the
basic primitives can be used in the newer system.

“Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of
both is used.”

SOFTWARE MEASUREMENT AND METRICS:

Software Measurement: A measurement is an manifestation of the size, quantity, amount or dimension of a
particular attributes of a product or process. Software measurement is a titrate impute of a characteristic of a
software product or the software process. It is an authority within software engineering. Software
measurement process is defined and governed by ISO Standard.

Need of Software Measurement: Software is measured to:

 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
  Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement: There are 2 types of software measurement:

 Direct Measurement: In direct measurement the product, process or thing is measured directly using
standard scale.
 Indirect Measurement: In indirect measurement the quantity or quality to be measured is measured
using related parameter i.e. by use of reference.

Metrics: A metrics is a measurement of the level that any impute belongs to a system product or process.
There are 4 functions related to software metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics:

 Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed in values.
 Understandable: Metric computation should be easily understood; the method of computing metric
should be clearly defined.
 Applicability: Metrics should be applicable in the initial phases of development of the software.
 Repeatable: The metric values should be same when measured repeatedly and consistent in nature.
 Economical: Computation of metric should be economical.
 Language Independent: Metrics should not depend on any programming language.

Classification of Software Metrics: There are 3 types of software metrics:

 Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and under
covering prospective problem areas. The ability of team to control quality is evaluated.
 Process Metrics: Process metrics pay particular attention on enhancing the long term process of the
team or organisation.
 Project Metrics: Project matrix is describes the project characteristic and execution process.
 Number of software developer
 Staffing pattern over the life cycle of software
 Cost and schedule
 Productivity

SIZE ORIENTED METRICS:

Size Oriented Metrics derived by normalizing quality and productivity Point Metrics measures by considering
size of the software that has been produced. The organization builds a simple record of size measure for the
software projects. It is built on past experiences of organizations. It is a direct measure of software. This
metrics is one of simplest and earliest metrics that is used for computer program to measure size. Size Oriented
Metrics are also used for measuring and comparing productivity of programmers. It is a direct measure of a
Software. The size measurement is based on lines of code computation. The lines of code are defined as one
line of text in a source file.
While counting lines of code, simplest standard is:
 Don’t count blank lines
 Don’t count comments
 Count everything else
 The size-oriented measure is not a universally accepted method.
Following are the points regarding LOC measures:

 In size-oriented metrics, LOC is considered to be the normalization value.

 It is an older method that was developed when FORTRAN and COBOL programming were very
popular.
 Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
 Size-oriented metrics depend on the programming language used.
 As productivity depends on KLOC, so assembly language code will have more productivity.
 LOC measure requires a level of detail which may not be practically achievable.
 The more expressive is the programming language, the lower is the productivity.
 LOC method of measurement does not apply to projects that deal with visual (GUI-based)
programming. As already explained, Graphical User Interfaces (GUIs) use forms basically. LOC
metric is not applicable here.
 It requires that all organizations must use the same method for counting LOC. This is so because some
organizations use only executable statements, some useful comments, and some do not. Thus, the
standard needs to be established.
 These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

 Errors/KLOC.
 $/ KLOC.
 Defects/KLOC.
 Pages of documentation/KLOC.
 Errors/PM.
 Productivity = KLOC/PM (effort is measured in person-months).
 $/ Page of documentation.

Advantages of LOC
 Simple to measure

Disadvantage of LOC
 It is defined on the code. For example, it cannot measure the size of the specification.
 It characterizes only one specific view of size, namely length, it takes no account of functionality or
complexity
 Bad software design may cause an excessive line of code
 It is language dependent
 Users cannot easily understand it

HALSTEAD’S SOFTWARE SCIENCE:

In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity. Halstead’s
metrics depends upon the actual implementation of program and its measures, which are computed directly
from the operators and operands from source code, in static manner. It allows to evaluate testing time,
vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.
According to Halstead, “A computer program is an implementation of an algorithm considered to be a
collection of tokens which can be classified as either operators or operands”. Halstead metrics think a program
as sequence of operators and their associated operands.
He defines various indicators to check complexity of module. Following table states the parameters and the
meanings:
 Parameter Meaning
n1 Number of unique operators
n2 Number of unique operands
N1 Number of total occurrence of operators
N2 Number of total occurrence of operands

When we select source file to view its complexity details in Metric Viewer, the following result is seen in
Metric Report:
Metric Meaning Mathematical
Representation
n Vocabulary n1 + n2
N Size N1 + N2
V Volume Length * Log2
Vocabulary
D Difficulty (n1/2) * (N1/n2)
E Efforts Difficulty * Volume
B Errors Volume / 3000
T Testing time Time = Efforts / S,
where S=18
seconds.

FUNCTION POINT BASED MEASURES:

It is widely used to measure the size of software. Function Point concentrates on functionality provided by the
system. Features and functionality of the system are used to measure the software complexity. Function point
counts on five parameters, named as External Input, External Output, Logical Internal Files, External Interface
Files, and External Inquiry. To consider the complexity of software each parameter is further categorized as
simple, average or complex.
1. External Input
Every unique input to the system, from outside, is considered as external input. Uniqueness of input is
measured, as no two inputs should have same formats. These inputs can either be data or control parameters.
 Simple - if input count is low and affects less internal files
 Complex - if input count is high and affects more internal files
 Average - in-between simple and complex.

2. External Output
All output types provided by the system are counted in this category. Output is considered unique if their
output format and/or processing are unique.
 Simple - if output count is low
 Complex - if output count is high
 Average - in between simple and complex.

3. Logical Internal Files

Every software system maintains internal files in order to maintain its functional information and to function
properly. These files hold logical data of the system. This logical data may contain both functional data and
control data.
 Simple - if number of record types are low
 Complex - if number of record types are high
 Average - in between simple and complex.
 4. External Interface Files
Software system may need to share its files with some external software or it may need to pass the file for
processing or as parameter to some function. All these files are counted as external interface files.
 Simple - if number of record types in shared file are low
 Complex - if number of record types in shared file are high
 Average - in between simple and complex.

5. External Inquiry
An inquiry is a combination of input and output, where user sends some data to inquire about as input and the
system responds to the user with the output of inquiry processed. The complexity of a query is more than
External Input and External Output. Query is said to be unique if its input and output are unique in terms of
format and data.
 Simple - if query needs low processing and yields small amount of output data
 Complex - if query needs high process and yields large amount of output data
 Average - in between simple and complex.

Each of these parameters in the system is given weightage according to their class and complexity. The table
below mentions the weightage given to each parameter:

Parameter Simple Average Complex

Inputs 3 4 6
Outputs 4 5 7
Enquiry 3 4 6
Files 7 10 15
Interfaces 5 7 10

The table above yields raw Function Points. These function points are adjusted according to the environment
complexity. System is described using fourteen different characteristics:
 Data communications
 Distributed processing
 Performance objectives
 Operation configuration load
 Transaction rate
 Online data entry,
 End user efficiency
 Online update
 Complex processing logic
 Re-usability
 Installation ease
 Operational ease
 Multiple sites
 Desire to facilitate changes
These characteristics factors are then rated from 0 to 5, as mentioned below:
 No influence
 Incidental
 Moderate
 Average
 Significant
 Essential
All ratings are then summed up as N. The value of N ranges from 0 to 70 (14 types of characteristics x 5 types
of ratings). It is used to calculate Complexity Adjustment Factors (CAF), using the following formula:
CAF = 0.65 + 0.01N
Then
Delivered Function Points (FP)= CAF x Raw FP

This FP can then be used in various metrics, such as:

 Cost = $ / FP
 Quality = Errors / FP
 Productivity = FP / person-month

Benefits of FPA:
 FPA is a tool to determine the size of a purchased application package by counting all the functions
included in the package.
 It is a tool to help users discover the benefit of an application package to their organization by counting
functions that specifically match their requirements.
 It is a tool to measure the units of a software product to support quality and productivity analysis.
 It is a vehicle to estimate cost and resources required for software development and maintenance.
 It is a normalization factor for software comparison.

CYCLOMATIC COMPLEXITY MEASURES:

Every program encompasses statements to execute in order to perform some task and other decision-making
statements that decide, what statements need to be executed. These decision-making constructs change the
flow of the program. If we compare two programs of same size, the one with more decision-making
statements will be more complex as the control of program jumps frequently.
McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of a given software. It
is graph driven model that is based on decision-making constructs of program such as if-else, do-while,
repeat-until, switch-case and goto statements.
Process to make flow control graph:
 Break program in smaller blocks, delimited by decision-making constructs.
 Create nodes representing each of these nodes.
 Connect nodes as follows:
o If control can branch from block i to block j
o Draw an arc
o From exit node to entry node
o Draw an arc.
To calculate Cyclomatic complexity of a program module, we use the formula -
V(G) = e – n + 2
Where: e is total number of edges
and n is total number of nodes
“According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed 10.”

Control flow graphs:

They are used to calculate the software complexity using cyclomatic complexity method.
The nodes in the graph indicate the smallest group of commands of a program, and a directed edge in it
connects the two nodes i.e. if second command might immediately follow the first command.
For example, if source code contains no control flow statement then its cyclomatic complexity will be 1 and
source code contains a single path in it. Similarly, if the source code contains one if condition then cyclomatic
complexity will be 2 because there will be two paths one for true and the other for false.
Mathematically, for a structured program, the directed graph inside control flow is the edge joining two basic
blocks of the program as control may pass from first to second.
So, cyclomatic complexity M would be defined as,
M = E – N + 2P
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components
Steps that should be followed in calculating cyclomatic
complexity and test cases design are:
 Construction of graph with nodes and edges from code.
 Identification of independent paths.
 Cyclomatic Complexity Calculation
 Design of Test Cases

Let a section of code as such:

A = 10
IF B > C THEN
A=B “Control flow of code”
ELSE
A=C
ENDIF
Print A
Print B
Print C

The cyclomatic complexity calculated for above code will be from control flow graph. The graph shows
seven shapes(nodes), seven lines(edges), hence cyclomatic complexity is 7-7+2 = 2.

Use of Cyclomatic Complexity:

 Determining the independent path executions thus proven to be very helpful for Developers and
Testers.
 It can make sure that every path has been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risk associated with program can be evaluated.
 These metrics being used earlier in the program helps in reducing the risks.

Advantages of Cyclomatic Complexity:

 It can be used as a quality metric, gives relative complexity of various designs.

 It is able to compute faster than the Halstead’s metrics.
 It is used to measure the minimum effort and best areas of concentration for testing.
 It is able to guide the testing process.
  It is easy to apply.

Disadvantages of Cyclomatic Complexity:

 It is the measure of the programs’s control complexity and not the data the data complexity.
 In this, nested conditional structures are harder to understand than non-nested structures.
 In case of simple comparisons and decision structures, it may give a misleading figure.