[go: up one dir, main page]

0% found this document useful (0 votes)
19 views32 pages

SE Unit 3

Download as pdf or txt
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 32

Meerut Institute of Technology, Meerut

Software Engineering (KCS601)


Lecture Notes (UNIT-3)

UNIT - III SOFTWARE ENGINEERING

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 is the process to transform the user requirements into some suitable form, which
helps the programmer in software coding and implementation. During the software design phase, the
design document is produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into the design document.
The following items are designed and documented during the design phase:
 Different modules required.
 Control relationships among modules.
 Interface among different modules.
 Data structure among the different modules.
Objectives of Software Design:
1. Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of the
system.
2. Efficiency:
A good software design should address the resources, time, and cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be modular and all the
modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and external
interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a change request is
made from the customer side
The software design process can be divided into the following three levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

BY: SRISHTI AGARWAL (MIT) Page 1


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Interface Design:

Interface design is the specification of the interaction between a system and its environment. this phase
proceeds at a high level of abstraction with respect to the inner workings of the system i.e, during
interface design, the internal of the systems are completely ignored and the system is treated as a
black box. Attention is focused on the dialogue between the target system and the users, devices, and
other systems with which it interacts. The design problem statement produced during the problem
analysis step should identify the people, other systems, and devices which are collectively
called agents.
Interface design should include the following details:
 Precise description of events in the environment, or messages from agents to which the system
must respond.
 Precise description of the events or messages that the system must produce.
 Specification on the data, and the formats of the data coming into and going out of the system.
 Specification of the ordering and timing relationships between incoming events or messages, and
outgoing events or outputs.

Architectural Design:

Architectural design is the specification of the major components of a system, their responsibilities,
properties, interfaces, and the relationships and interactions between them. In architectural design, the
overall structure of the system is chosen, but the internal details of major components are ignored.
Issues in architectural design includes:
 Gross decomposition of the systems into major components.
 Allocation of functional responsibilities to components.
 Component Interfaces
 Component scaling and performance properties, resource consumption properties, reliability
properties, and so forth.
 Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.
Detailed Design:

Design is the specification of the internal elements of all major system components, their properties,
relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
 Decomposition of major system components into program units.
 Allocation of functional responsibilities to units.

BY: SRISHTI AGARWAL (MIT) Page 2


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

 User interfaces
 Unit states and state changes
 Data and control interaction between units
 Data packaging and implementation, including issues of scope and visibility of program elements
 Algorithms and data structures
Software Design Principles:

 Software design principles are concerned with providing means to handle the complexity of the
design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design:

Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant problem, divide the
problems and conquer the problem it means to divide the problem into smaller pieces so that each piece
can be captured separately. For software design, the goal is to divide the problem into manageable
pieces.

Benefits of Problem Partitioning


1. Software is easy to understand
2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They have
to cooperate and communicate to solve the problem. This communication adds complexity.

BY: SRISHTI AGARWAL (MIT) Page 3


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing element as
well as the component being designed. there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of the function.
Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

Structure Chart :

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.

1. Control Module
A control module branches to more than one sub module.
2. Sub Module
Sub Module is a module which is the part (Child) of another module.
3. 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.

BY: SRISHTI AGARWAL (MIT) Page 4


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module.


A curved arrow represents loop in the module. All the sub modules cover by the loop repeat execution of
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.

BY: SRISHTI AGARWAL (MIT) Page 5


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Physical Storage

Physical Storage is that where all the information are to be stored.

Example : Structure chart for an Email server

Pseudo code

Pseudo code is a term which is often used in programming and algorithm based fields. It is a
methodology that allows the programmer to represent the implementation of an algorithm. Pseudo
code: It’s simply an implementation of an algorithm in the form of annotations and informative text written
in plain English. It has no syntax like any of the programming language and thus can’t be compiled or
interpreted by the computer.

Advantages of Pseudocode

 Improves the readability of any approach. It’s one of the best approaches to start implementation
of an algorithm.

BY: SRISHTI AGARWAL (MIT) Page 6


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

 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.

Flowchart:
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.

BY: SRISHTI AGARWAL (MIT) Page 7


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

 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.

Advantages of Flowchart:

 Flowcharts are a better way of communicating the logic of the system.


 Flowcharts act as a guide for blueprint during program designed.
 Flowcharts help in debugging process.
 With the help of flowcharts programs can be easily analyzed.
 It provides better documentation.
 Flowcharts serve as a good proper documentation.
 Easy to trace errors in the software.
 Easy to understand.
 The flowchart can be reused for inconvenience in the future.
 It helps to provide correct logic.

Disadvantages of Flowchart:

 It is difficult to draw flowcharts for large and complex programs.


 There is no standard to determine the amount of detail.
 Difficult to reproduce the flowcharts.
 It is very difficult to modify the Flowchart.
 Making a flowchart is costly.
 Some developer thinks that it is waste of time.
 It makes software processes low.
 If changes are done in software, then the flowchart must be redrawn

BY: SRISHTI AGARWAL (MIT) Page 8


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Modularity

Modularity specifies to the division of software into separate modules which are differently named and
addressed and are integrated later on in to obtain the completely functional software. It is the only
property that allows a program to be intellectually manageable. Single large programs are difficult to
understand and read due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

Advantages of Modularity: There are several advantages of Modularity

o It allows large programs to be written by several or different people


o It encourages the creation of commonly used routines to be placed in the library and used by
other programs.
o It simplifies the overlay procedure of loading a large program into main storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

Disadvantages of Modularity: There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer


o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o More linkage required, run-time may be longer, more source lines must be written, and more
documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system. We discuss a different section of modular
design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that perform


only one kind of task and do not excessively interact with other modules. Independence is important

BY: SRISHTI AGARWAL (MIT) Page 9


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

because it makes implementation more accessible and faster. The independent modules are easier to
maintain, test, and reduce error propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.


o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules should be
specified that data include within a module is inaccessible to other modules that do not need for such
information.

The use of information hiding as design criteria for modular system provides the most significant benefits
when modifications are required during testing's and later during software maintenance. This is because
as most data and procedures are hidden from other parts of the software, inadvertent errors introduced
during modifications are less likely to propagate to different locations within the software.

Strategy of Design

A good system design strategy is to organize the program modules in such a method that are easy to
develop and latter too, change. Structured design methods help developers to deal with the size and
complexity of programs. Analysts generate instructions for the developers about how code should be
composed and how pieces of code should fit together to form a program. To design a system, there are
two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components and then
decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards up the hierarchy,
as shown in fig. This approach is suitable in case of an existing system.

BY: SRISHTI AGARWAL (MIT) Page 10


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Effective Modular Design :

The role of effective modular design in software engineering:

Any software comprises of many systems which contains several sub-systems and those sub-systems
further contains their sub-systems. So, designing a complete system in one go comprising of each and
every required functionality is a hectic work and the process can have many errors because of its vast
size.
Thus in order to solve this problem the developing team breakdown the complete software into various
modules. A module is defined as the unique and addressable components of the software which can be
solved and modified independently without disturbing ( or affecting in very small amount ) other
modules of the software. Thus every software design should follow modularity.
The process of breaking down a software into multiple independent modules where each module is
developed separately is called Modularization.

Effective modular design can be achieved if the partitioned modules are separately solvable, modifiable
as well as compilable. Here separate compilable modules means that after making changes in a
module there is no need of recompiling the whole software system.

In order to build a software with effective modular design there is a factor “Functional
Independence” which comes into play. The meaning of Functional Independence is that a function is
atomic in nature so that it performs only a single task of the software without or with least interaction
with other modules. Functional Independence is considered as a sign of growth in modularity i.e.,
presence of larger functional independence results in a software system of good design and design
further affects the quality of the software.

Benefits of Independent modules/functions in a software design:

Since the functionality of the software have been broken down into atomic levels, thus developers get a
clear requirement of each and every functions and hence designing of the software becomes easy and
error free.
As the modules are independent they have limited or almost no dependency on other modules. So,
making changes in a module without affecting the whole system is possible in this approach.
Error propagation from one module to another and further in whole system can be neglected and it
saves time during testing and debugging.
Independence of modules of a software system can be measured using 2 criteria : Cohesion, and
Coupling.

BY: SRISHTI AGARWAL (MIT) Page 11


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

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

BY: SRISHTI AGARWAL (MIT) Page 12


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

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.

BY: SRISHTI AGARWAL (MIT) Page 13


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

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 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

BY: SRISHTI AGARWAL (MIT) Page 14


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

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.

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 Cohesion shows the relationship within the
between modules. module.

Coupling shows the Cohesion shows the module's


relative independence between the relative functional strength.
modules.

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

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

Function Oriented Design

Function Oriented design is a method to 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.

BY: SRISHTI AGARWAL (MIT) Page 15


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Object-Oriented Design

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, person,
banks, company, 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 superclasses.This property of OOD is called an inheritance. This makes it easier to
define a specific class and to create generalized classes from specific ones.

BY: SRISHTI AGARWAL (MIT) Page 16


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

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.

User Interface Design

The visual part of a computer application or operating system through which a client interacts with a
computer or software. It determines how commands are given to the computer or the program and how
data is displayed on the screen.

Types of User Interface: There are two main types of User Interface:

o Text-Based User Interface or Command Line Interface


o Graphical User Interface (GUI)

Text-Based User Interface: This method relies primarily on the keyboard. A typical example of this is
UNIX.

Advantages
o Many and easier to customizations options.
o Typically capable of more important tasks.

Disadvantages
o Relies heavily on recall rather than recognition.
o Navigation is often more difficult.

Graphical User Interface (GUI): GUI relies much more heavily on the mouse. A typical example of this
type of interface is any versions of the Windows operating systems.

GUI Characteristics
Characteristics Descriptions

Windows Multiple windows allow different information to be displayed


simultaneously on the user's screen.

Icons Icons different types of information. On some systems, icons represent


files. On other icons describes processes.

Menus Commands are selected from a menu rather than typed in a command
language.

BY: SRISHTI AGARWAL (MIT) Page 17


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Pointing A pointing device such as a mouse is used for selecting choices from a
menu or indicating items of interests in a window.

Graphics Graphics elements can be mixed with text or the same display.

Advantages
o Less expert knowledge is required to use it.
o Easier to Navigate and can look through folders quickly in a guess and check manner.
o The user may switch quickly from one task to another and can interact with several different
applications.

Disadvantages
o Typically decreased options.
o Usually less customizable. Not easy to use one button for tons of different variations.

UI Design Principles

Structure: Design should organize the user interface purposefully, in the meaningful and usual based on
precise, consistent models that are apparent and recognizable to users, putting related things together
and separating unrelated things, differentiating dissimilar things and making similar things resemble one
another. The structure principle is concerned with overall user interface architecture.

Simplicity: The design should make the simple, common task easy, communicating clearly and directly
in the user's language, and providing good shortcuts that are meaningfully related to longer procedures.

Visibility: The design should make all required options and materials for a given function visible without
distracting the user with extraneous or redundant data.

Feedback: The design should keep users informed of actions or interpretation, changes of state or
condition, and bugs or exceptions that are relevant and of interest to the user through clear, concise, and
unambiguous language familiar to users.

BY: SRISHTI AGARWAL (MIT) Page 18


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse by
allowing undoing and redoing while also preventing bugs wherever possible by tolerating varied inputs
and sequences and by interpreting all reasonable actions.

Software Measurement & Metric:

Software Measurement: A measurement is a manifestation of the size, quantity, amount, or dimension


of a particular attribute 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. The software measurement process is defined and governed by ISO Standard.

Need for 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:


1. Direct Measurement: In direct measurement, the product, process, or thing is measured directly
using a standard scale.

2. Indirect Measurement: In indirect measurement, the quantity or quality to be measured is


measured using related parameters i.e. by use of reference.

Metrics:

A metric is a measurement of the level at which any impute belongs to a system product or process.
Software metrics will be useful only if they are characterized effectively and validated so that their worth
is proven. There are 4 functions related to software metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving

Classification of Software Metrics:

There are 3 types of software metrics:


1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and
undercover prospective problem areas. The ability of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term process of
the team or organization.
3. Project Metrics: The project matrix describes the project characteristic and execution process.
 Number of software developer
 Staffing patterns over the life cycle of software

BY: SRISHTI AGARWAL (MIT) Page 19


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

 Cost and schedule


 Productivity
Halstead’s software science metrics

According to Halstead’s software metrics, a program is the implementation of an algorithm. These steps
are considered as a number of tokens, and tokens are classified as operators and operands. All software
science measures are functions of the counts of these tokens.
Token count
1. Operator –Any symbol or keyword in a program that specifies an algorithm is considered an
operator. For example, arithmetic symbols like (+. -. /,*), punctuation marks, common names
(while, for, print f), special symbols (=, :) and function names.
2. Operand– In an algorithm or program, a symbol is used to represent data, constants, variables,
labels, etc. is considered as an operand.

measures of Halstead's software science are:

 Size of vocabulary ղ ( known as Ita)

The size of the vocabulary of a program is defined as a number of unique tokens in a program used to
build a program.
ղ =ղ1 + ղ2
where,
ղ = number of vocabulary in a program
ղ1 = number of unique operators
ղ2 = number of unique operands
By using this formula, we can find the total number of vocabulary in a given source code.

 Length of program N

The total number of tokens in a program is termed as the Length of the program.
N = N1 + N2
Where,
N = Length of program
N1= Total occurrences of operators
N2 = Total occurrences of operators
Additional metrics are defined using these basic terms- the size of vocabulary and Length of the program.
Another measure for the size of the program is known as:
Program Volume (V)
V= N x log2ղ
Program volume is proportional to program size, represents the size of space necessary for sorting a
program.
Unit of volume = Common unit of size “bits” {it is the actual size of the program if a uniform binary
encoding for the vocabulary is used}

 Potential Volume

V* = represents a program having a minimal size.


V* = (2+n2 *) log2(2+n2*)
Program Level
L = V* / V
Program level L = Ranges between 0 to 1

BY: SRISHTI AGARWAL (MIT) Page 20


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

L =1 states that the program is written with minimum size.


Else if L=0 states program has a maximum size.
V* = potential volume {different or equivalent programs may implement an algorithm. Therefore program
that is minimal in size will have potential volume}
Other different measures are:-

 Program difficulty D

D = ղ 1/2 x N2 / ղ2
D = 1/L
Difficulty measure is the difficulty of the program to read or write the program. If the program level
decreases, difficulty to handle that program increases.

 Effort –The amount of effort needed to translate an algorithm into implementation is specified
programming language.

E = V/L = D x V

V = Volume of program
L = Level of program
D =Program difficulty
V= Volume of program

 Time required to program

T = E/ 18 sec
T = Time
E = Effort

 Number of delivered bugs

B = E2/3/3000 {actually whole state delivered bugs is an estimated number of errors in the
implementation}
Recently V/3000 is accepted for delivered bugs B.

 Estimated program Length

The first hypothesis of software science is that the length of well structure software program is a function
of number of unique operators and operands.
N =ղ1log2ղ 1+ ղ2log2ղ2
ղ1 = number of unique operators
ղ2 = number of unique operands

 Purity Ratio

P= N/N

BY: SRISHTI AGARWAL (MIT) Page 21


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Cyclomatic complexity:

Cyclomatic complexity is a software metric used to measure the complexity of a program . Cyclomatic
complexity of a code section is the quantitative measure of the number of linearly independent paths in
it. It is a software metric used to indicate the complexity of a program. It is computed using the Control
Flow Graph of the program.

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 program’s control complexity and not 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 results.

BY: SRISHTI AGARWAL (MIT) Page 22


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

QUESTIONS ON CYCLOMATIC COMPLEXITY:

1. Calculate cyclomatic complexity for the given code-

IFA=354
THEN IF B>C
THEN A=B
ELSE A=C
END IF
END IF
PRINTA

Method-01:

Cyclomatic Complexity
=Total number of closed regions in the control flow graph +1
=2+1
=3

Method-02:

Cyclomatic Complexity
=E–N+2
=8–7+2
=3

Method-03:

Cyclomatic Complexity
=P+1
=2+1
=3

BY: SRISHTI AGARWAL (MIT) Page 1


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Problem-02:

Calculate cyclomatic complexity for the given code-

{ inti,j,k;

for(i=0;i<=N;i++)

p[i]=1;

for(i=2;i<=N;i++)

k=p[i];
j=1;

while

(a[p[j-1]]>a[k]{p[j]=p[j-

1];

j--;

p[j]=k;

BY: SRISHTI AGARWAL (MIT) Page 2


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Method-01:
Cyclomatic Complexity
= Total number of closed regions in the control flow graph + 1
=3+1
=4
Method-02:
Cyclomatic Complexity
=E–N+2
=16–14+2
=4
Method-03:
Cyclomatic Complexity
=P+1
=3+1
=4

Problem-03:

Calculate cyclomatic complexity for the given code-


beginintx,y,power;

floatz;

input(x,y);

if(y<0)

power=-y;

else power=y;

z=1;

while(power!=0)

{z=z*x;

power=power-1;

}if(y<0)z=1

/z;output(z);

end

BY: SRISHTI AGARWAL (MIT) Page 3


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

Method-01:

Cyclomatic Complexity
=Total number of closed regions in the control flow graph + 1
=3+1
=4

Method-02:

Cyclomatic Complexity
=E–N+2
=16–14+2
=4

Method-03:

Cyclomatic Complexity
=P+1
=3+1

BY: SRISHTI AGARWAL (MIT) Page 4


Meerut Institute of Technology, Meerut
Software Engineering (KCS601)
Lecture Notes (UNIT-3)

IMPORTANT QUESTIONS

1. What is cohesion ? Also explain its different types in detail? 2016-17, 2018-19 [CO3].

2. What is coupling? Explain with its different types? 2016-17,2018-19 [CO3].

3. What is function oriented design & object oriented design approach ? 2016-17, 2017-18, 2018-19
[CO3].

4. What do you understand by software design . Explain different design process ? 2016-17, 2017-
18 , 2018-19, 2018-19 , 2021-22 [CO1].

5. What is halstead's software science metrics. Explain in detail? 2017-18 [CO3].

6. Explain the concept of modularity ? 2018-19 [CO3].

7. What is a structure charts? Explain rules for drawing good structure charts diagrams with the
help of a suitable example. 2016-17,2017-18 [CO3].

8. Describe decomposition levels of abstraction and modularity concepts in software design.


2018-19

9. What are the characteristics of a good design? Describe different types of coupling and
cohesion. How design evaluation is performed? 2018-19

10. Explain about the various design concepts considered during design. 2018-19, 2017-18

11. What is Cyclomatic complexity? Write all methods, which are used to calculate the Cyclomatic
complexity of a control, flow graph.2017-18, 2021-22

BY: SRISHTI AGARWAL (MIT) Page 23

You might also like