Unit 3 Software Design

What is Software Design?

Software Design is the process of defining the architecture, components, interfaces, and logic of
a software application to satisfy specified requirements.

It's like creating a blueprint for building software — just like an architect designs a building
before it's constructed.

Goals of Software Design:

●​ Convert requirements into a working solution.

●​ Ensure the system is efficient, maintainable, and scalable.
●​ Reduce complexity by organizing software into structured components.
●​ Make software easier to test, modify, and debug.

Key Elements of Software Design:

1. Architecture Design

●​ Focuses on the overall structure of the system.

●​ Defines how different components/modules interact.
●​ Example: Client-server architecture, layered architecture.

2. Component Design

●​ Each component (or module) is designed separately.

●​ Defines logic inside the component.
●​ Ensures that components are independent and reusable.

3. Interface Design

●​ Specifies how components will communicate with each other.

●​ Includes APIs, data formats, and protocols.​

4. Data Design

●​ Decides how data is organized, stored, and accessed.

 ●​ Defines data structures (arrays, linked lists, trees, etc.) and database schema.

Levels of Software Design:

Level Description

High-Level Design Describes the system architecture and major components.

(HLD)

Low-Level Design Describes internal logic of each module, functions, and class
(LLD) details.

Principles of Good Software Design:

Principle Meaning

Modularity Divide the system into manageable, independent parts (modules).

Abstraction Hide complex details and show only essential features.

Encapsulation Keep data and behavior bundled together in one unit (class/object).

Separation of Different parts of software handle different responsibilities.

Concerns

Cohesion Related functionalities should be grouped in the same module.

Coupling Modules should depend on each other as little as possible (low

coupling).

Common Software Design Approaches:

1. Structured Design

●​ Focuses on breaking down the system into functions and procedures.

●​ Uses tools like Data Flow Diagrams (DFD) and Flowcharts.

2. Object-Oriented Design (OOD)

●​ Models the system using objects (real-world entities).

●​ Based on classes, inheritance, polymorphism, and encapsulation.
●​ Example: Designing a "Banking System" with objects like Account, Customer,
Transaction.
Software Design Models and Tools:

●​ UML (Unified Modeling Language): Common language for design using diagrams like:​

○​ Class Diagram
○​ Sequence Diagram
○​ Use Case Diagram
○​ Activity Diagram
●​ ER Diagram: For designing databases.
●​ Flowcharts: For visualizing logic.

Advantages of Good Software Design:

●​ Makes software easy to understand and maintain.

●​ Reduces chances of errors.
●​ Enhances performance and reusability.
●​ Makes testing and debugging easier.
●​ Helps teams collaborate better.

Poor Design Can Lead To:

●​ Complicated code.
●​ High development and maintenance costs.
●​ Hard-to-find bugs.
●​ Poor performance and scalability issues.

Architectural Design
The software needs an architectural design to represent the design of the software. IEEE defines
architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a computer
system.” The software that is built for computer-based systems can exhibit one of these many
architectural styles.
System Category Consists of
●​ A set of components(eg: a database, computational modules) that will perform a
function required by the system.
●​ The set of connectors will help in coordination, communication, and cooperation
between the components.
●​ Conditions that defines how components can be integrated to form the system.
 ●​ Semantic models that help the designer to understand the overall properties of the
system.

The use of architectural styles is to establish a structure for all the components of the system.
Taxonomy of Architectural Styles

1] Data centered architectures:

●​ A data store will reside at the center of this architecture and is accessed frequently by
the other components that update, add, delete, or modify the data present within the
store.
●​ The figure illustrates a typical data-centered style. The client software accesses a
central repository. Variations of this approach are used to transform the repository
into a blackboard when data related to the client or data of interest for the client
change the notifications to client software.
●​ This data-centered architecture will promote integrability. This means that the
existing components can be changed and new client components can be added to the
architecture without the permission or concern of other clients.

Data centered architecture

2] Data flow architectures:

●​ This kind of architecture is used when input data is transformed into output data
through a series of computational manipulative components.
 ●​ The figure represents pipe-and-filter architecture since it uses both pipe and filter and
it has a set of components called filters connected by lines.
●​ Pipes are used to transmitting data from one component to the next.
●​ Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters don’t
require any knowledge of the working of neighboring filters.
●​ If the data flow degenerates into a single line of transforms, then it is termed as batch

sequential.

Data Flow architecture

3] Call and Return architectures

It is used to create a program that is easy to scale and modify. Many sub-styles exist within this
category. Two of them are explained below.
●​ Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
●​ Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components. ​
4] Object Oriented architecture

The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message passing.
Characteristics of Object Oriented architecture:
●​ Object protect the system’s integrity.
●​ An object is unaware of the depiction of other items.

5] Layered architecture

●​ A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
●​ At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Modularization

Modularization diagram

In this current age of software, you would be hard-pressed to find a program that isn't
continuously growing and evolving. Designing a program all at once, with all required functions,
would be difficult due to its size, complexity and constant changes. This is where modularization
comes in.

Modularization is the process of separating the functionality of a program into independent,

interchangeable modules, such that each contains everything necessary to execute only one aspect
of the desired functionality.
Monolith vs modular program

With modularization, we can easily work on adding separate and smaller modules to a program
without being hindered by the complexity of its other functions. In short, it’s about being flexible
and fast in adding more software functions to a program. In a software engineering team, we
could easily work independently on each module without affecting others’ work.

It is the backbone of the microservice architecture, whose basic idea is also the simplicity of
developing applications that are easier to extend and maintain when disassembled into small and
independent parts. On the other hand, in monolithic architecture, there’s always the risk of
bringing down the whole program with a simple update.

Microservices and modularity

Without modularization, this will lead to an increase in development time, the number of bugs
and the duration it takes to test and release a program.

Benefits of modularization

Why should we be decomposing our projects into modules? As shown in my experience with a
single-file program, programs without proper modularization would be a nightmare to maintain
and extend.
 In modularization, the modules have minimal dependency on other modules. So, we can easily
make changes in a module without affecting other parts of the program.

The following are just the gist of how modularization would improve the development process
for a program.

●​ Easier to add and maintain smaller components

●​ Easier to understand each module and their purpose

●​ Easier to reuse and refactor modules

●​ Better abstraction between modules

●​ Saves time needed to develop, debug, test and deploy a program

How should we decompose modules?

A module should have only a single responsibility, that is the Single Responsibility Principle.
Thus, it should depend minimally on other modules. The independence of a module can be
measured using coupling and cohesion.

Coupling: Coupling is the measure of the degree of interdependence between the modules. A good
software will have low coupling.

Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally
related. It is the degree to which all elements directed towards performing a single task are
contained in the component. Basically, cohesion is the internal glue that keeps the module together.
A good software design will have high cohesion.
Cohesion and coupling

Module coupling, with (c) being what we want to avoid

Each module should have a clear and focused purpose, such that its developers have a clear idea
of the requirement for each function. Its interface should be easy to understand and use, even
without understanding its implementation details. Thus, leading into our next point, is that its
implementation details, while not only correct, should be encapsulated and private, and that it
should be changeable without affecting another module. Furthermore, the dependency between
modules should be minimised.
Structure Chart
Structure Chart represents the hierarchical structure of modules. It breaks down the
entire system into the lowest functional modules and describes the functions and
sub-functions of each module of a system in greater detail. This article focuses on
discussing Structure Charts in detail.

What is a Structure Chart?

Structure Chart partitions the system into black boxes (functionality of the system is
known to the users, but inner details are unknown).

1.​ Inputs are given to the black boxes and appropriate outputs are generated.

2.​ Modules at the top level are called modules at low level.

3.​ Components are read from top to bottom and left to right.

4.​ When a module calls another, it views the called module as a black box,

passing the required parameters and receiving results.

Symbols in Structured Chart

1. Module
It represents the process or task of the system. It is of three types:

●​ Control Module: A control module branches to more than one submodule.

●​ Sub Module: Sub Module is a module which is the part (Child) of another

module.

●​ Library Module: Library Module are reusable and invokable from any

module.

2. Conditional Call

It represents that control module can select any of the sub module on the basis of

some condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module. A curved arrow
represents a loop in the [Link] the submodules cover by the loop repeat execution

of module.
4. Data Flow

It represents the flow of data between the modules. It is represented by a directed

arrow with an empty circle at the end.

5. Control Flow

It represents the flow of control between the modules. It is represented by a directed

arrow with a filled circle at the end.

6. Physical Storage:It is where all the information is to be stored.

Example
Structure chart for an Email server

PSEUDOCODE
A Pseudocode is defined as a step-by-step description of an algorithm. Pseudocode does not use
any programming language in its representation, instead it uses the simple English language text
as it is intended for human understanding rather than machine reading.​
Pseudocode is the intermediate state between an idea and its implementation(code) in a
high-level language.

What is the need for Pseudocode

Pseudocode is an important part of designing an algorithm, it helps the programmer in planning

the solution to the problem as well as the reader in understanding the approach to the problem.
Pseudocode is an intermediate state between algorithm and program that plays supports the
transition of the algorithm into the program.

Pseudocode is an intermediate state between algorithm and program

How to write Pseudocode?

Before writing the pseudocode of any algorithm the following points must be kept in mind.
●​ Organize the sequence of tasks and write the pseudocode accordingly.
●​ First, establish the main goal or the aim. Example:

This program will print the first N numbers of Fibonacci series.

●​ Use standard programming structures such as if-else, for, while, and cases the way
we use them in programming. Indent the statements if-else, for, while loops as they
are indented in a program, it helps to comprehend the decision control and execution
mechanism. It also improves readability to a great extent. Example:

IF “1”​
print response​
 “I AM CASE 1”​

IF “2”​
print response​
“I AM CASE 2”
●​ Use appropriate naming conventions. The human tendency follows the approach of
following what we see. If a programmer goes through a pseudo code, his approach
will be the same as per that, so the naming must be simple and distinct.
●​ Reserved commands or keywords must be represented in capital letters. Example: if
you are writing IF…ELSE statements then make sure IF and ELSE be in capital
letters.
●​ Check whether all the sections of a pseudo code are complete, finite, and clear to
understand and comprehend. Also, explain everything that is going to happen in the
actual code.
●​ Don’t write the pseudocode in a programming language. It is necessary that the
pseudocode is simple and easy to understand even for a layman or client, minimizing
the use of technical terms.

Good vs Bad ways of writing Pseudocode:

Good Vs Bad way of writing Pseudocode

Pseudocode Examples:

1. Binary search Pseudocode:

Binary search is a searching algorithm that works only for sorted search space. It repeatedly
divides the search space into half by using the fact that the search space is sorted and checking if
the desired search result will be found in the left or right half.

Example: Given a sorted array Arr[] and a value X, The task is to find the index at which X is
present in Arr[].
Below is the pseudocode for Binary search.
BinarySearch(ARR, X, LOW, HIGH)​
repeat till LOW = HIGH​
MID = (LOW + HIGH)/2​
if (X == ARR[mid])​
return MID​
​
else if (x > ARR[MID]) ​
LOW = MID + 1​
​
else ​
HIGH = MID – 1

2. Quick sort Pseudocode:

QuickSort is a Divide and Conquer algorithm. It picks an element as a pivot and partitions the
given array around the picked pivot.

Say last element of array is picked as pivot then all elements smaller than pivot element are
shifted on the left side of pivot and elements greater than pivot are shifted towards the right of
pivot by swapping, the same algorithm is repeatedly followed for the left and right side of pivot
until the whole array is sorted.

Below is the pseudocode for Quick sort

QUICKSORT(Arr[], LOW, HIGH) {​
if (LOW < HIGH) {​
PIVOT = PARTITION(Arr, LOW, HIGH);​
QUICKSORT(ARR, LOW, PIVOT – 1); ​
QUICKSORT(ARR, PIVOT + 1, HIGH); ​
 }​
}

Here, LOW is the starting index and HIGH is the ending index.
Difference between Algorithm and Pseudocode

Algorithm Pseudocode

An Algorithm is used to provide a A Pseudocode is a step-by-step

solution to a particular problem in form description of an algorithm in code-like
of a well-defined step-based form. structure using plain English text.

An algorithm only uses simple English Pseudocode also uses reserved keywords
words like if-else, for, while, etc.

These are fake codes as the word pseudo

These are a sequence of steps of a
means fake, using code like structure and
solution to a problem
plain English text

There are certain rules for writing

There are no rules to writing algorithms
pseudocode
 Algorithms can be considered Pseudocode cannot be considered an
pseudocode algorithm

It is difficult to understand and interpret It is easy to understand and interpret

Difference between Flowchart and Pseudocode

Flowchart Pseudocode

A Pseudocode is a step-by-step
A Flowchart is a pictorial representation
description of an algorithm in code like
of flow of an algorithm.
structure using plain English text.

A Flowchart uses standard symbols for

input, output decisions and start stop Pseudocode uses reserved keywords
statements. Only uses different shapes like if-else, for, while, etc.
like box, circle and arrow.

This is a way of visually representing These are fake codes as the word
data, these are nothing but the graphical pseudo means fake, using code like
 representation of the algorithm for a structure but plain English text instead
better understanding of the code of programming language

Pseudocode is better suited for the

Flowcharts are good for documentation
purpose of understanding

Coupling and Cohesion Measures

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.

The various types of coupling techniques are shown in fig:

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

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.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.

3. 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 entire
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.

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

5. 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.
6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. 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 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 forms 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 a 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.

Differentiate between Coupling and Cohesion

Coupling Cohesion
 Coupling is also called Inter-Module Cohesion is also called Intra-Module
Binding. Binding.

Coupling shows the relationships between Cohesion shows the relationship within the
modules. module.

Coupling shows the relative independence Cohesion shows the module's relative
between the modules. functional strength.

While creating, you should aim for low While creating you should aim for high
coupling, i.e., dependency among modules cohesion, i.e., a cohesive component/
should be less. module focuses on a single function (i.e.,
single-mindedness) with little interaction
with other modules of the system.

In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.

Function Oriented Design

Function Oriented design is a method of software design where the model is decomposed into a
set of interacting units or modules where each unit or module has a clearly defined function.
Thus, the system is designed from a functional viewpoint.

Design Notations
Design Notations are primarily meant to be used during the process of design and are used to
represent design or design decisions. For a function-oriented design, the design can be
represented graphically or mathematically by the following:
 Data Flow Diagram
Data-flow design is concerned with designing a series of functional transformations that convert
system inputs into the required outputs. The design is described as data-flow diagrams. These
diagrams show how data flows through a system and how the output is derived from the input
through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They
show end-to-end processing. That is the flow of processing from when data enters the system to
where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a data-flow
diagram. The user inputs the name of the design represented by the diagram. The report
generator then finds all the names used in the data-flow diagram. It looks up a data dictionary
and retrieves information about each name. This is then collated into a report which is output by
the system.

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data items
listed contain all data flows and the contents of all data stores looking on the DFDs in the DFD
model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

○​ A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential since,
in large projects, different engineers of the project tend to use different terms to refer to
the same data, which unnecessarily causes confusion.
 ○​ The data dictionary provides the analyst with a means to determine the definition of
various data structures in terms of their component elements.

Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to the
user without the knowledge of internal design.

Structured Chart is a graphical representation which shows:

○​ System partitions into modules

○​ Hierarchy of component modules
○​ The relation between processing modules
○​ Interaction between modules
○​ Information passed between modules

The following notations are used in structured chart:

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design phases. Using
pseudo-code, the designer describes system characteristics using short, concise, English
Language phases that are structured by keywords such as If-Then-Else, While-Do, and End.

Object-Oriented Design in Software Engineering

In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities). The state is distributed among the objects, and each object handles its state data. For
example, in a Library Automation Software, each library representative may be a separate object
with its data and functions to operate on these data. The tasks defined for one purpose cannot
refer or change data of other objects. Objects have their internal data which represent their state.
Similar objects create a class. In other words, each object is a member of some class. Classes
may inherit features from the superclass.

The different terms related to object design are:

1.​ Objects: All entities involved in the solution design are known as objects. For example,
people, banks, companies, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.
2.​ Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3.​ Messages: Objects communicate by message passing. Messages consist of the integrity of
the target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.
4.​ Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5.​ Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential
 information of an object together but also restricts access to the data and methods from
the outside world.
6.​ Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions
from their immediate [Link] property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific
ones.
7.​ Polymorphism: OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
types. Depending upon how the service is invoked, the respective portion of the code gets
executed.

Top-Down and Bottom-Up Design

What is the Top-Down Design Model?

In the top-down model, an overview of the system is formulated without going into detail for any
part of it. Each part of it then refined into more details, defining it in yet more details until the
entire specification is detailed enough to validate the model. if we glance at a haul as a full, it’s
going to appear not possible as a result of it’s so complicated For example: Writing a University
system program, writing a word processor.

How Does Top-Down Approach Work?

The Top-Down approach works by:

1.​ Breaking the problem into major components,

2.​ Refining each component into smaller subcomponents

3.​ We Continue this process until every part is simple enough to implement.

This approach is particularly useful for solving complex problems, like developing a University
System Program or a Word Processor. By starting with a high-level design and gradually
focusing on smaller details, the complexity of the system becomes more manageable.

Advantages of the Top-Down Design Model

 ●​ Simplifies Complex Problems: Breaking problems into smaller parts help us to identify
what needs to be done.
●​ Easy to Identify Requirements: At each step of refinement, new parts will become less
complex and therefore easier to solve.
●​ Promotes Reusability: Parts of the solution may turn out to be reusable.
●​ Collaboration-Friendly: Breaking problems into parts allows more than one person to
solve the problem. ​

What is Bottom-Up Design Model?

In contrast, the Bottom-Up Design Model is started by defining the system’s individual parts
first. Once the individual components are detailed, they are integrated into larger modules. This
process is continued till the system is fully integrated. The Bottom-Up approach is often used in
Object-Oriented Programming (OOP) languages like C++, Java, and Python, where individual
objects are identified and developed first.

How Does Bottom-Up Approach Work?

The Bottom-Up approach works by:

1. Identifying and specifying the smaller components (or objects).

2. Linking these smaller parts together to form larger components.

3. Continuously integrating them to complete the system.

This method focuses on creating well-defined and reusable low-level components before
deciding how to integrate them into higher-level systems.

Advantages of the Bottom-Up Design Model

●​ Reusability of Low-Level Components: Decisions about reusable low-level utilities are

made early in the design.
●​ Focused Problem-Solving: Developers can focus on solving smaller and more isolated
problems first.
●​ Increased Modularity: The modular approach makes it easier to update individual
components without affecting the entire system.

Key Differences Between Top-Down and Bottom-Up Design Models

S.
No. TOP DOWN APPROACH BOTTOM UP APPROACH

1. focus on breaking the problem Solves smaller problems and integrates them
into smaller, more manageable into a complete system.
parts.

2. Mainly used in Structured Mainly used in Object Oriented

programming languages like Programming languages like C++, C#,
COBOL, Fortran, C, etc. Python.

3. Each part is programmed Redundancy is minimized by using data

separately therefore contains encapsulation and data hiding.
redundancy.

4. communication is less among Modules must communicate to integrate the

modules. system.

5. It is used for debugging and It is basically used in testing.

module documentation

6. Decomposition of the system Composition of the system happens by

occurs, breaking it into smaller combining low-level components into a
components. higher-level structure.
7. The top function of system In this sometimes we can not build a program
might be hard to identify. from the piece we have started.

8. implementation details can Building a program can be difficult if

vary throughout the process modules are not assembled in a logical order

9. Pros Pros

●​ Easier isolation of ●​ Easy to create test conditions

interface errors ●​ Test results are easy to observe
●​ It benefits in the case ●​ It is suited if defects occur at the
error occurs towards the bottom of the program.
top of the program.
●​ Defects in design get
detected early and can
be corrected as an early
working module of the
program is available.
 10. Cons- Cons-

●​ Difficulty in observing ●​ There is no representation of the

the output of test case. working model once several modules
●​ Stub writing is quite have been constructed.
crucial as it leads to ●​ There is no existence of the program as
setting of output an entity without the addition of the
parameters. last module.
●​ When stubs are located ●​ From a partially integrated system,
far from the top level test engineers cannot observe
module, choosing test system-level functions. It can be
cases and designing possible only with the installation of
stubs become more the top-level test driver.
challenging.

When to Use the Top-Down vs. Bottom-Up Design Models?

Use Top-Down Design Model When:

●​ We need to develop large and complex systems where high-level architecture is defined
early.
●​ The overall system’s structure is crucial before dealing with individual components.
●​ You are working in a more procedural or structured programming environment.

Use Bottom-Up Design Model When:

●​ You want to focus on individual components and gradually build them into a complete
system.
●​ You are working with Object-Oriented Programming (OOP) languages and want to take
advantage of modularity and object reusability.

Software Measurement and Metrics

What is Software Measurement?

Software measurement is the process of collecting, analyzing, and interpreting data related to
software development. It helps in evaluating software quality, performance, and progress.
Think of it like measuring speed, fuel efficiency, and mileage in a car. These numbers help us
understand how well the car is performing. Similarly, in software engineering, software
measurement helps in improving software development and maintenance.

🔹 What are Software Metrics?

Software Metrics are specific measurements that help in assessing software quality,
productivity, and efficiency. They are like performance indicators in a business that help
measure success.

For example, if you are developing software, you may want to measure:​
✔ How many lines of code (LOC) are written?​
✔ How many defects (bugs) were found?​
✔ How much time was spent on coding and testing?

Types of Software Metrics

Software metrics are classified into different categories based on what they measure:

1️ Process Metrics (Measures Development Process Efficiency)

These metrics help measure how efficiently the software development process is running.

🔹 Example Metrics:​
✔ Defect Rate: Number of bugs found per 1000 lines of code.​
✔ Development Time: How long it takes to develop a software module.​
✔ Team Productivity: Number of tasks completed per developer in a sprint.

Example: If a team completes a project in 6 months but has 200 defects, the process might need
improvement.

2️ Product Metrics (Measures Software Quality & Performance)

These metrics measure the quality and complexity of the software itself.

🔹 Example Metrics:​
✔ Lines of Code (LOC): Total number of lines in the program.​
✔ Cyclomatic Complexity: Measures how complex the software code is.​
✔ Code Maintainability Index: How easy it is to modify and maintain the software.

Project Metrics (Measures Project Progress & Success)

These metrics help in managing time, cost, and resources in a software project.
🔹 Example Metrics:​
✔ Budget Variance: Difference between planned and actual cost.​
✔ Schedule Variance: Difference between planned and actual completion time.​
✔ Resource Utilization: How efficiently human resources are used.

1. Lines of Code (LOC)

LOC is one of the simplest ways to measure software size. It counts the number of lines in a
program, including code but excluding comments and blank lines.

Advantages of LOC:

✔ Easy to measure​
✔ Helps in estimating project effort​
✔ Used for productivity comparison

Disadvantages of LOC:

Doesn’t measure software quality​

More lines don’t always mean better software​
Different programming languages have different LOC requirements

Example:​
A mobile banking app has 50,000 LOC, while a calculator app has only 2,000 LOC. The
banking app is more complex and requires more effort.

2. Function Points (FP)

Function Points (FP) measure the size of software based on its functionality rather than the
number of lines of code. It considers user inputs, outputs, files, and system interactions.

Advantages of FP:

✔ Independent of programming language​

✔ Focuses on what the system does rather than how many lines of code it has​
✔ Helps in estimating project size and effort

Disadvantages of FP:

More difficult to measure compared to LOC​

Requires detailed documentation
Example:​
An E-commerce website has:

● ​ 20 User Inputs (Login, Add to Cart, Checkout)

● ​ 15 Outputs (Invoice, Order Confirmation, Email Notification)

● ​ 10 Queries (Product Search, Order History)

5 Data Files (Product Database, Customer Data)

3. Number of Classes (For Object-Oriented Software)

In object-oriented programming, software is divided into classes. Measuring the number of
classes helps in understanding the size and complexity of the system.

Example:

● ​ A small mobile app may have 50 classes

● ​ A large e-commerce system may have 500+ classes

4. Number of Modules
A module is an independent unit in a software system that performs a specific function.
Counting modules helps in understanding how modular and maintainable a system is.

CYCLOMATIC COMPLEXITY MEASURE

Cyclomatic Complexity is a way to measure how complex a program is by counting how
many different paths exist through the code.

It tells you:

“How many different ways can someone go through this code?”

More paths = more complex = harder to test and maintain.

Why is it useful?

● ​ Helps you understand how difficult a program is to test.

● ​ Tells you how many test cases you need to cover all logic paths.

● ​ Useful for code quality analysis — lower is better!

The Formula:

Where:

● ​ E = number of edges (arrows)

● ​ N = number of nodes (boxes)

● ​ P = number of connected components (usually 1 for one function)

Example:

For the check(num) function above:

● ​ Nodes (N): 4 (Start, decision, two print statements)

● ​ Edges (E): 5 (Start→Decision, Decision→Yes, Decision→No, Yes→Print,

No→Print)

● ​ P: 1 (only one function)

Where:

● ​ M = Cyclomatic complexity

● ​ E = Number of edges (transitions or lines/arrows in flowchart)

● ​ N = Number of nodes (statements or blocks in flowchart)

● ​ P = Number of connected components (usually 1 for a single program)

Example:
How many paths?

Let’s think of all the ways this function can run:

1.​ If x > 0 → "Positive"

2.​ If x < 0 → "Negative"

3.​ If x == 0 → "Zero"

👉 So, there are 3 different paths through the code.

Cyclomatic Complexity = Number of independent paths

So here, Cyclomatic Complexity = 3

Which means:

● ​ You need 3 test cases to fully test this function.

○ ​ One with a positive number

○ ​ One with a negative number

One with zero

Question1.
A = 10​
IF B > C THEN​
A = B​
ELSE​
A = C​
ENDIF​
Print A​
Print B​
Print C

SOL. M=E-N+2P

​ E=7, N=7, P=1

​ M=7-7+2*1=2
 HALSTEAD’S SOFTWARE METRICS
Halstead’s Software metrics are a set of measures proposed by Maurice Halstead to evaluate the
complexity of a software program. These metrics are based on the number of distinct operators
and operands in the program and are used to estimate the effort required to develop and maintain
the program. These metrics provide a quantitative assessment of software complexity, aiding in
software development, maintenance, and quality assurance processes. They include measures
such as program length, vocabulary, volume, difficulty, and effort, calculated based on the
number of unique operators and operands in a program.

Token Count

In Halstead’s Software metrics, a computer program is defined as a collection of tokens that can
be described as operators or operands. These tokens are used to analyze the complexity and
volume of a program. Operators are symbols that represent actions, while operands are the
entities on which the operators act. All software science metrics can be specified using these
basic symbols. These symbols are referred to as tokens.

In Halstead’s Software Metrics:

n1 = Number of distinct operators.

n2 = Number of distinct operands.

N1 = Total number of occurrences of operators.

N2 = Total number of occurrences of operands.

Halstead's Formulas (in simple terms):

1. Program Vocabulary (n)​

n = n₁ + n₂​
→ Total unique elements used in the code.

2. Program Length (N)​

N = N₁ + N₂​
→ Total number of elements in the code (how many times stuff is written).

3. Volume (V)​
V = N * log₂(n)​
 → Represents the size of the program in bits. Think of it like how much “mental effort”
it takes to understand the code.

4. Difficulty (D)​
D = (n₁ / 2) * (N₂ / n₂)​
→ How hard it is to write or understand the program.

5. Effort (E)​
E = D * V​
→ The total effort needed to write or understand the program. Measured in mental
work units.

6. Time (T)​
T = E / 18​
→ Estimated time to code it, in seconds.

7. Bugs (B)​
B = E^(2/3) / 3000​
→ Estimated number of errors in the program

Question :

int sort (int x[ ], int n)​

​
{​
int i, j, save, im1;​
/*This function sorts array x in ascending order */​
If (n< 2) return 1;​
for (i=2; i< =n; i++)​
{​
im1=i-1;​
for (j=1; j< =im1; j++)​
if (x[i] < x[j])​
{​
Save = x[i];​
x[i] = x[j];​
x[j] = save;​
}​
}​
return 0;

Solution:

Operators Occurrences Operands Occurrences

Int 4 sort 1

() 5 x 7

, 4 n 3

[] 7 i 8

If 2 j 7

< 2 save 3

; 11 im1 3

For 2 2 2

= 6 1 3

– 1 0 1
<= 2 – –

++ 2 – –

Return 2 – –

{} 3 – –

n1=14 N1=53 n2=10 N2=38

n1​= number of distinct operators 14

N1= total occurrences of operators 53

n2 = number of distinct operands 10

N2 = total occurrences of operands 38

Formulas and Calculations:

1. Program Vocabulary (n)

n=n1+n2=14+10=24

2. Program Length (N)

N=N1+N2=53+38=91
3. Volume (V)

V=N×log2​(n)=91×log2​(24) ≈ 91×4.585=417.24

4. Difficulty (D)

D=n1/2​​×​N2/n2​​=214​×1038​=7×3.8=26.6​

5. Effort (E)

E=D×V=26.6×417.24=11100.58

6. Estimated Time to Implement (T) (in seconds)

​ T=E/18​=11100.58​/18≈616.7 seconds​≈10.28 minutes

7. Estimated Bugs (B)

B=E^2/3/3000​≈ (11100.58)2/3/3000​≈0.76​