DELHI TECHNOLOGICAL UNIVERSITY

(Formely Delhi College of Engineering)

Shahbad Daulatpur, Bawana Road, Delhi – 110042

DEPARTMENT OF COMPUTER SCIENECE AND ENGINEERING

Software Engineering
Lab File(CO -301)

Submitted by: Submitted to:

Naveen
Niresh Kushwaha
Kumar Ms. Kainat Khan
2K21/EC/147
2K21/EC/150
 INDEX

S. No. Experiment Date Sign

1. Hands on experience on working of case tools like

meta edit+ staruml and rationale rose

2. Apply various elicitation techniques for different

domain like the library system banking system etc.

3. Draw use case diagram for different domains

4. Draw use case diagram along with use case

description

5. Draw the ER diagram for the above specified

problem

6. Draw different levels of DFD for different domains

7. Convert DFD to structure chart

8. Develop C code to calculate effort and time period

using different forms of COCOMO model

9. Develop test cases using boundary value analysis for

the area of a triangle factorial of a number N

10. Develop program to find cyclomatic complexity

using DD path for problems like root of quadratic
Equation
 Experiment - 1

Aim: Hands-on experience on working of CASE tools like MetaEdit+, StarUML, and
. Rational Rose.

Theory:
Case Tools
Computer-Aided Software Engineering (CASE) is the domain of the software tools used to
design and implement applications.
CASE Tools are used for developing high-quality, defect-free, and maintainable software.
CASE Tools support specific tasks in the software development life-cycle. They can be divided
into the following categories :
1. Business and Analytics modelling. Graphic Modeling tools. Eg : E/R Modeling,
Object Modeling, etc.
2. Development. Design and construction phases of the life-cycle. Debugging
environments. Eg : IISE LKO.
3. Verification and Validation. Analyse code specifications for correctness,
performance, etc.
4. Configuration management. Control the check-in and check-out of repository
objects and files. Eg : SCCS, IISE.
5. Measurement and metrics. Analyse code for complexity, modularity (Eg : no
“goto”s), performance, etc.
6. Project Management. Manage Project plans, task assignment, scheduling.

MetaEdit+
MetaEdit+ is an environment for creating and using Domain-Specific Modelling languages.
MetaEdit+ allows graphical metamodelling using Object-Property-Role-Relationship (OPPR)
data model, definition of the DSM language rotation with a graphical symbol editor, and the
definition of code generators using a Domain-Specific Language.
There are two mains versions of MetaEdit+ :
● MetaEdit+ Workbench - Includes tools for designing and using modelling languages.
● MetaEdit+ Modelers - Includes tools for using modelling languages.

Normally, MetaEdit+ Workbench is used by a few key developers to design a domain-specific

modelling language for their project. Then, this modelling language is used to develop final
products using MetaEdit+ Modeler.
StarUML
StarUML is a software engineering tool for system modelling using the Unified Modelling
Language, as well as Systems Modelling Language, and classical modelling notations.
StarUML offers object oriented modelling capabilities. It supports most of the diagram types
specified in UML 2.0 :
• Class Diagrams
• Composite Structure Diagrams
• Component Diagrams
• Object Diagrams
• Package Diagrams
• Use-Case Diagrams
• Activity Diagrams
• Sequence Diagrams
• Communication Diagrams
• Timing Diagrams
• State Diagrams
• Information Flow Diagrams
• Interaction overview Diagrams
• Profile Diagrams
StarUML also offers support for SysML :
• Requirement Diagrams
• Block Diagrams
• Internal Block Diagrams
StarUML supports legacy modelling notations, such as :
• Flowchart Diagrams
• Entity-Relationship Diagrams (ERD)
• Data-Flow Diagrams (DFD)

Rational Rose
Rational Rose is an object-oriented Unified Modelling Language (UML) software design tool
intended for visual modelling and component construction of enterprise-level software
applications.
A software designer uses Rational Rose to visually create (model) the framework for an
application by blocking out classes with actors (Stick figures), use-case elements (ovals),
objects (rectangles) and messages/ relationships (arrows) in a sequence diagram using drag-
and-drop symbols. Rational Rose documents the diagram as it is being constructed and then
generates code in the designer;s choice of C++, Visual Basic, Java, Oracle8, Corbe or Data
Definition Language.
 Two popular features of Rational Rose are its ability to provide iterative development and
round-trip engineering. Rational Rose allows designers to take advantage of iterative
development (sometimes called evolutionary development) because the new application can
be created in stages with the output of one iteration becoming the input to the next. Then, as
the developer begins to understand how the components interact and makes modifications in
the design, Rational Rose can perform what is called “round-trip engineering” by going back
and updating the rest of the model to ensure the code remains consistent.

Discussion:
CASE tools which stand for Computer-Aided-Software-Engineering tool are really important
tools in Software Engineering. They provide support for the design and implementation of
information systems. It can document a database design and provide invaluable help in
maintaining the consistency of design.

Findings and Learnings:

We learnt about different CASE tools such as StarUML, MetaEdit+, Rational Rose. We also
learnt how to use them. We learnt their importance in the software engineering field. We also
designed a few models for hands-on experience in StarUML software.
 Experiment – 2

Aim: To apply various elicitation techniques for different domains, like the library
. system, banking systems, hospital management system and hotel management
. systems.

Theory:
Requirement elicitation
Requirement gathering or requirement elicitation is key to success for any software
development. Whoever wears the hat of a business analyst goes through this process and
practices, to analyse and research the system requirements based on the information collected
from the users, stakeholders and customers of any app.

Importance of requirement elicitation

A software is bound to fail if there is any gap in understanding the system’s requirements
whether it is functional or non-functional.
A project can fail for the following reasons:
Poorly designed requirements
From the project management perspective most of the project fails when they do not meet the
following criteria:
1. Deadline
2. Cost
The reason behind software failure may be poor requirement elicitation. If the functionality is
poorly specified its implementation would either lead to creation of certain functionalities that
are not needed or will lead to complete absence of the others. As a result, it would lead to lost
development time, missed project timelines, loss of revenue, increased frustration amongst
team members, poor quality of documentation and the list of impacts can go on and on.

Lack of communication
Lack of communication or ineffective communication especially with stakeholders can lead to
software failure. Less involvement of stakeholders in communication will ultimately lead to
loss of trust.
A bad relationship
Within a team, it is a well-known fact that a bad leader could be one of the most important
factors for project failure. A bad leader not only changes the project development life cycle but
also damages the reputation of the team and company.
For successful development of a project the leader should orchestrate the best team to get the
best performance and end results. The leader should be fully dedicated to the success of the
project, supportive to teammates and must work such that they are not able to manage the team
people's work, relationship, clients and partners. Lacking any skills will lead to the failure of
the project.

A bad team
For the success of any software development, performance of the selected team is very
important because this whole process requires team effort. Any team which lacks coordination,
communication skills and discipline can never help to achieve the end results in the best
possible ways.

Requirement elicitation techniques Task analysis

Task analysis is a way of carefully examining how a software will behave in each phase. It
involves breaking down the activity into a series of tasks which are observable action or
behaviour.
After decomposing the task into subtasks the purpose of task analysis is to focus on identifying
the problems/backlogs, decision making, judgements and resource allocation.
In short the purpose of task analysis is to know-
1. What are the stakeholders' goals?
2. What they want to achieve
3. How the task will be initiated and completed

Asking questions
Asking the right questions can help fill the gap between developers’ understanding of the
business process and real requirements of the clients. In general questionnaires are techniques
of asking the right questions.
Let's understand it with the case, suppose a school approaches a software development agency
with the requirement of a learning management system or a software for schools but they do
not know how it will be done, what technique will be used and how it will fulfil and map their
requirements. To ask the right questions one should have an understanding of the required
business model like in case of performance of students, how teachers get appointed and way of
evaluating teaching skills, etc.
Following are a few popular methods of questionnaires:
1. Telephonic
2. Survey
3. Email questionnaires
4. Interviewing the stakeholders

Observation
The idea behind this technique is to know how stakeholders work/perform the day-to-day tasks
in their existing work process. This technique helps the development agency to recognise the
real problem with the process while observing their work.

Brainstorming
It is a group activity where the team finds new ideas and solutions for any specific problem.
Team members feel connected with the project but few things need to be considered while
performing brainstorming:
1. Time limit
2. Evaluation criteria
3. Avoid criticism and office politics
Domain analysis
In the process of requirement elicitation, domain analysis is the technique of analysing the
related systems of same business domains to find out the common and variable features.
This practice also helps developers and stakeholders to find the edge over competitors and get
better solutions on existing systems.

Prototyping
Prototyping is a method of replicating the business ideas into tangible forms. This is the most
liked method of requirement elicitation, stakeholders love it! This tells how the application will
look. It is very helpful to non-technical stakeholders to visualise the application before
approving the development. It also helps to validate the requirement, user flow and use cases
to the development team. There are specific tools for creating wireframes but paper and pencil
can also help easily.

Findings and Learnings:

Objective, precise and understandable requirements play a crucial role when starting software
development, especially when one wants to achieve the desirable results in a given time frame.
It is well said that “precaution is better than cure”. Although it applies on each step of software
development, it is especially important during the requirement elicitation process. In short the
output of the requirement elicitation process should be correct, precise, comprehensive, testable
and well-structured covering functional and non-functional requirements of the system.
 Experiment – 3
Aim: To draw a use case diagram for smart home management system.

Theory:
Use case diagram
A use case diagram is used to represent the dynamic behaviour of a system. It encapsulates the
system's functionality by incorporating use cases, actors and their relationships. It models the
tasks, services and functions required by the system/subsystem of an application. It depicts the
high-end functionality of a system and also tells how the user handles the system.

Purpose of use case diagrams

The main purpose of a use case diagram is used to portray the dynamic aspect of a system. It
accumulates the system requirements, which include both internal as well as external
influences. It invokes persons, use cases and several things that involve the actors and elements
accountable for the implementation of use case diagrams. It represents how an entity from the
external environment can interact with a part of the system.

Following are the purposes of a use case diagram

1. It gathers systems needs
2. It depicts the external view of the system
3. It recognises the internal as well as external factors that influence the system
4. It represents the interaction between the actors
Discussion:
Use case diagrams help to model use cases and actor behaviours in a graphically representable
way. This helps developers to code better and designers to design better.

Findings and Learnings:

We are successfully able to prepare use case diagrams for a given system. Use case diagrams
are the best to represent actors and use case relationships.
 Experiment – 4
Aim: To draw a use case diagram along with a use case description.

Theory:
Use case diagram
A use case diagram is used to represent the dynamic behaviour of a system. It encapsulates the
system's functionality by incorporating use cases, actors and their relationships. It models the
tasks, services and functions required by the system/subsystem of an application. It depicts the
high-end functionality of a system and also tells how the user handles the system.

Purpose of use case diagrams

The main purpose of a use case diagram is used to portray the dynamic aspect of a system. It
accumulates the system requirements, which include both internal as well as external
influences. It invokes persons, use cases and several things that involve the actors and elements
accountable for the implementation of use case diagrams. It represents how an entity from the
external environment can interact with a part of the system.
Following are the purposes of a use case diagram
1. It gathers systems needs
2. It depicts the external view of the system
3. It recognises the internal as well as external factors that influence the system
4. It represents the interaction between the actors

Components of use case diagram actor

The users that interact with the system are called actors. An actor can be a person, an
organisation or an outside system that interacts with your application or system. They must be
external objects that produce or consume data.

Use case
Use case represents the functionality of the system that can be invoked by an actor in order to
use the system. It is a visual representation of distinct business functionalities of the system.

System boundary
A system boundary defines the scope of the system. A system cannot have infinite functionality
so it follows that use cases also need to have finite limits defined. A system boundary of a use
case diagram defines the limits of a system. This system boundary is shown as a rectangle
spanning all the use cases in the system.
Procedure to draw use case diagrams
It is essential to analyse the whole system before starting with drawing a use case diagram; and
then system functionalities are found and once every single functionality is defined and
identified they are then transformed into the use cases to be used in the use case diagram.
After that we will enlist actors that will interact with the system. The actors are the person or
the thing that involves the functionality of a system. It may be a system or a private entity such
that it requires an entity to be persistent to the functionalities of the system with which it is
going to interact.
Once both the actors and use cases are enlisted, the relation between actor and use case is
inspected. It identifies the number of times an actor communicates with the system. Basically
an actor can interact multiple times with the use case or system at a particular instance of time.
Following are some of the rules that must be followed while drawing a use case diagram:
1. A persistent and meaningful name should be assigned to the actor and or use case
of a system.
2. The communication of an actor with the use case must be defined in an
understandable way.
3. Specified notations to be used as and when required.
4. The most significant interaction should be represented among the multiple number
of interactions between the use case and the actors.
Use case description
Actors
Hub
Hub is the main system which controls every appliance and sub module
Database
Database stores the useful information required later on by processes and other actors.
Owner
Owner is the person in command. They give commands to execute several functions.
Police receive alarms and respond in case of emergency.

Use cases
CCTV system

It uses a database to store video footage and monitors it to trigger an alert function which in
turn alerts the police.
Music player
It also uses a database to store music and then plays on request of the user. Its function is
controlled via the hub but can also be manually controlled by the user.
Climate control
Fans, lighting and other such appliances are used to control airflow and lighting etc of the
house.

Discussion:
Use case diagrams help to model use cases and actor behaviours in a graphically representable
way. This helps developers to code better and designers to design better.

Findings and Learnings:

We are successfully able to prepare use case diagrams for a given system. Use case diagrams
are the best to represent actors and use case relationships.
 Experiment – 5
Aim: To draw the ER Diagram for the above specified problem.

Theory:
Entity Relationship Model
An Entity-Relationship Model (ERM) is an abstract and conceptual representation of data.
ERM is a database modelling method, used to produce a type of conceptual schema or semantic
data model of a system, often a relational database, and its requirements in a top-down fashion.
The diagrams created by this process are called entity relationship (ER) diagrams. An entity
may be defined as a thing which is recognised as being capable of an independent existence
and can be uniquely identified.

ER Diagram

Entity

An entity may be a physical object such as a house or car, an event such as a house sale or car
service or a concept such as customer transaction or order. Entities can be thought of as nouns.
For example : a computer, an employee, a song, a mathematical theorem. Entities are drawn as
rectangles.
Relationship
A relationship captures how entities are related to one another. Relationship sets are drawn as
diamonds. If an entity set participates in a relationship set, they are connected with a line. For
example: A performs a relationship between an artist and a song, a proved relationship between
a mathematician and a theorem. Relationships illustrate how two entities share information in
the database structure.

Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a
relationship, ordinality describes the relationship as either mandatory or optional. Cardinality
basically specifies the maximum number of relationships while ordinality specifies the absolute
minimum number of relationships.

Discussion:
In software engineering, an ER model is useful and commonly made to represent things a
business needs to remember in order to perform business processes. ER model basically
becomes an abstract data model that defines a data or information structure which can be
implemented in a database.

Findings and Learnings:

We learnt what an Entity Relationship Model is. We also learnt the importance of an ER model.
We then found out how to develop an ER model from scratch. We also learnt about the different
components involved in ER models such as Entity, Relationship, Cardinality, Ordinality.
 Experiment – 6
Aim: To draw different levels of DFD for smart home management system.
Theory:
Data Flow Diagram
A data flow diagram is a traditional visual representation of the information flows within a
system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated or a combination of both.
It shows how data enters and leaves the system, what changes the information and where data
is stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in
order to act as a starting point for redesigning the system. The DFD is also called a data flow
graph or a bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows in a flowchart represent the order of
events whereas arrows in DFD represent flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If you ever have the urge to draw a diamond shaped box in
a DFD, suppress that urge. A diamond shaped box is used in flow charts to represent
decision points with multiple exit parts of which only one is taken, this implies an
ordering of events which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Symbols used in data flow diagram

Circle
A circle shows a process that transforms data inputs into data outputs.
Data flow
A curved line shows the flow of data into or out of a process or data store.

Data store
A set of parallel lines shows a place for the collection of data items. A data store indicates that
data is stored and can be retrieved at a later stage or by other processes in a different order. The
data store can have an element or a group of elements.
Source or sink
Source or sink is an external entity and acts as a source of system inputs or sink of system
outputs.

Levels in Data Flow Diagram

The data flow diagram may be used to perform a system or software at any level of abstraction.
In fact data flow diagrams may be partitioned into levels that represent increasing information
flow and functional details. Levels in DFD are numbered 0, 1, 2 or beyond. Here we will see
primarily three levels in the data flow diagram which are level-0 DFD, level-1 DFD and level-
2 DFD.
Level – 0 DFD
It is also known as the fundamental system model aur context diagram. It represents the entire
software requirement in a single bubble with input and output data denoted by incoming and
outgoing arrows then the system is decomposed and described as a DFD with multiple bubbles.
Part of the system represented by each of these Bubbles are then decomposed and documented
as more and more detailed DFDs.
This process may be repeated at as many levels as necessary until the program at hand is well
understood. It is essential to preserve the number of inputs and outputs between levels.Thus, if
bubble “A” has two inputs “X1” and “X2” and one output “Y” then the expanded DFD that
represents “A” should have exactly two external inputs and one external output.

Level – 1 DFD
In level-1 DFD, a context diagram is decomposed into multiple bubbles. In this level we
highlight the main objective of the system and break down the high-level process of level-0
DFD into subprocesses.
Level – 2 DFD
Level-2 DFD goes one process deeper into parts of level-1 DFD. It can be used to project or
record the specific details about the system functioning.
DFDs for smart home management system
Level – 0 DFD
Level – 1 DFD

Level – 2 DFD
Security System
Music System

Discussion:
The purpose of a data flow diagram is to graphically represent the flow of data from data stores
to processes, processes to entities and from one process to another.

Findings and Learning:

We are successfully able to make data flow diagrams of a given system. We also learnt and
understood different levels of data flow diagrams and how to draw them progressively.
 Experiment – 7
Aim: To convert DFD to a structure chart.

Theory:
Data Flow Diagram
Data Flow Diagram is a graphical representation of flow of data in an information system. It is
capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does
not mention anything about how data flows through the system. There is a prominent difference
between DFD and a Flowchart. The flowchart depicts flow of control in program modules.
DFDs depict flow of data in the system at various levels. DFD does not contain any control or
branch elements.

Types of DFD
Data Flow Diagrams are classified as follows:
Logical DFD
This type of DFD concentrates on the system process, and flow of data in the system.
Physical DFD
This type of DFD shows how the data flow is actually implemented in the system. It is more
specific and close to the implementation.

Structure Chart
Structure Chart is a chart derived from a Data Flow Diagram. It represents the system in more
detail than DFD. It breaks down the entire system into the lowest functional modules, describes
functions and sub-functions of each module of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.
Here are the symbols used in construction of Structure Chart:
Module
H represents process or subroutine or task. A control module branches to more than one sub-
module. Library Modules are reusable and invokable from any module.
Condition
It is represented by a small diamond at the base of the module. It depicts that the control module
can select any subroutine based on some condition.

Jump
An arrow is shown pointing inside the module to depict that the control will jump in the middle
of the submodule.

Loop
A curved arrow represents a loop in the module. All sub-modules covered by loop repeat
execution of module.
Data Flow
A directed arrow with an empty circle at the end represents data flow.

Control Flow
A directed arrow with a filled circle at the end represents control flow.

Discussion:
Structure charts are charts which show breakdown of a system to its lowest manageable levels.
They are useful in structured programming to arrange program modules into a tree.

Findings and Learnings:

We learnt about what structure charts are, and we also learned why they are useful. Next, we
learnt and converted a DFD into a structure chart. Each module is represented by a box which
contains the module’s name. The tree structure visualises the relationships between modules.
 Experiment – 8
Aim: To develop c code to calculate effort and time period using different forms of COCOMO model.
Theory:
COCOMO Model
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there could
be three categories of software projects: organic, semi detached, and embedded. The
classification is done considering the characteristics of the software, the development team and
environment. These product classes typically correspond to application, utility and system
programs, respectively. Data processing programs could be considered as application
programs. Compilers, linkers, are examples of utility programs. Operating systems, real-time
system programs are examples of system programs. One could easily apprehend that it would
take much more time and effort to develop an OS than an attendance management system.
The concept of organic, semi detached, and embedded systems are described below.
Organic
A development project is said to be of organic type, if
1. The project deals with developing a well understood application.
2. The development team is small.
3. The team members have prior experience in working with similar types of projects.

Semi detached
A development project can be categorised as semi detached type, if
1. The team consists of some experienced as well as inexperienced staff.
2. Team members may have some experience on the type of system to be developed.

Embedded
Embedded type of development project are those, which
1. Aim to develop software strongly related to machine hardware.
2. Team size is usually large.
The basic COCOMO model helps to obtain a rough estimate of the project parameters. It
estimates effort and time required for development in the following way:
Where,

• KDSI is the estimated size of the software expressed in Kilo Delivered Source
instructions.
• a, b, c are constants determined by the category of software project.
• Effort denotes the total effort required for the software development, expressed in
person months (PMs).
• Tdev denotes the estimated time required to develop the software (expressed in
months).

Code:
#include <iostream> #include<bits/stdc++.h> using namespace std;
int fround(float x)
{
int a; x=x+0.5;
a=x; return(a);
}
void calculate(float table[][4], int n,char mode[][15], int size)
{
float effort,time; int model;
if(size>=2 && size<=50) model=0; //organic
else if(size>50 && size<=300) model=1; //semi-detached
else if(size>300)
model=2; //embedded cout<<"The mode is "<<mode[model];
effort = table[model][0]*pow(size,table[model][1]); time =
table[model][2]*pow(effort,table[model][3]); cout<<"\nEffort = "<<effort<<" Person-
Month";
cout<<"\nDevelopment Time = "<<time<<" Months";
}
int main()
{
float table[3][4]={2.4,1.05,2.5,0.38,3.0,1.12,2.5,0.35,3.6,1.20,2.5,0.32};
char mode[][15]={"Organic","Semi-Detached","Embedded"}; int size = 110;
calculate(table,3,mode,size);
return 0;
}

Output:

Discussion:
The purpose of this code is to find effort and development time required beforehand so that
one knows what resources they have to gather.

Findings and Learning:

We learnt how to use the COCOMO model and its advantages. We also learnt to calculate
effort and development time using the COCOMO model.
 Experiment – 9
Aim: To develop test cases using boundary value analysis for the identification of a triangle.

Theory:
Boundary Value Analysis
Boundary Value Analysis (BVA) is a software testing technique where test cases are designed
using boundary values. BVA is based on the single fault assumption (aka critical fault
assumption) which states that failures are rarely the product of two or more simultaneous faults.
Hence, while designing test cases for BVA we keep all but one variable to the nominal value
and allow the remaining variable to take the extreme value.

Test Case Design for BVA

While designing the test cases for BVA first we determine the number of input variables in the
problem. For each input variable, we then determine the range of values it can take. Then we
determine the extreme values and nominal values for each input variable.
If an input variable ‘t’ takes values in range [l,r] then the extreme values for t will be t = l, t =
l+1, t = r-1, t = r. The nominal value can be any value in the range (l,r). In most BVA
implementations, it is taken as middle value of range i.e. (r+l)/2.
Under the single fault assumption, the total number of test cases in BVA for a problem with
‘n’ inputs is 4n+1. The 4n corresponds to the test cases with four extreme values of each
variable keeping the other n-1 variable at nominal value. The one additional case is where all
variables are held at a nominal value.

Boundary Value Analysis for Triangle

Triangle Problem accepts three integers a, b, c as three sides of the triangle. We also define a
range for the sides of the triangle as [l,r] where l > 0. It returns the type of triangle (Scalene,
Isosceles, Equilateral, Not a Triangle) formed by a, b, c. For three sides to form a triangle, the
sum of two sides should always be greater than the third side. If all sides are equal then it is an
Equilateral triangle. If two sides are equal then it is an Isosceles triangle. If none of the sides
are equal then it is a
Scalene triangle. Let's take the range for the side of the triangle to be [1,100] and thus nominal
value will be 50.
Now since the number of input variables is 3 (sides of triangle) therefore, total cases will be
4n+1 = 4*3+1 = 13 test cases.
Test Cases

Test Case No. a b c Expected Output

T1 1 50 50 Isosceles

T2 2 50 50 Isosceles

T3 99 50 50 Isosceles

T4 100 50 50 Not a Triangle

T5 50 50 50 Equilateral

T6 50 1 50 Isosceles

T7 50 2 50 Isosceles

T8 50 99 50 Isosceles

T9 50 100 50 Not a Triangle

T10 50 50 1 Isosceles

T11 50 50 2 Isosceles

T12 50 50 99 Isosceles

T13 50 50 100 Not a Triangle

Code:
#include<stdio.h> int main()
{
int a,b,c,result;
printf("Enter the values of a, b and c : "); scanf("%d %d %d", &a,&b,&c);
if( ( ( a + b ) > c ) && ( ( b + c ) > a ) && ( ( c + a ) > b ) )
{
if( ( a == b ) && ( b == c ) ) printf("\nEquilateral Triangle");
else
if( ( a == b ) || ( b == c ) || ( c == a ) ) printf("\nIsosceles Triangle");
else
printf("\nScalene Triangle");
}
else
printf("\nNot a Triangle"); return 0;
}

Output:

Discussion:
Boundary Value Analysis helps to test the software we have written. It checks for the input
values near the boundary that have a higher chance of error. Every partition has its maximum
and minimum values and these maximum and minimum values are the boundary values of a
partition.

Findings and Learnings:

We are successfully able to test the program we have written for classification of triangles by
generating test cases using BVA. We also learned that mostly error happens on the extreme
values of the input variables involved.
 Experiment – 10
Aim: To develop a program to find cyclomatic complexity using DD Path for the root of a quadratic
, equation.

Theory:
Control Flow Graph
A control flow graph (CFG) is a directed graph where the nodes represent different instructions
of a program, and the edges define the sequence of execution of such instructions. Figure 1
shows a small snippet of code (compute the square of an integer) along with its CFG. For
simplicity, each node in the CFG has been labelled with the line numbers of the program
containing the instructions. A directed edge from node #1 to node #2 in figure 1 implies that
after execution of the first statement, the control of execution is transferred to the second
instruction.

A program, however, doesn't always consist of only sequential statements. There could be
branching and looping involved in it as well. Figure 2 shows what a CFG would look like if
there are sequential, selection and iteration kind of statements in order.
A real life application seldom could be written in a few lines. In fact, it might consist of
thousands of lines. A CFG for such a program is likely to become very large, and it would
contain mostly straight-line connections. To simplify such a graph different sequential
statements could be grouped together to form a basic block. A basic block is a [ii, iii] maximal
sequence of program instructions I1, I2, ..., In such that for any two adjacent instructions Ik
and Ik+1, the following holds true
• Ik is executed immediately before Ik+1.
• Ik+1 is executed immediately after Ik.

Terminologies
DD Path
A decision-to-decision path, or DD-path, is a path of execution (usually through a flow graph
representing a program, such as a flow chart) between two decisions.
A DD-path is a set of nodes in a program graph such that one of the following holds (quoting
and keeping Jorgensen's numbering, with comments added in parenthesis)
1. It consists of a single node with in-degree = 0 (initial node)
2. It consists of a single node without-degree = 0 (terminal node)
3. It consists of a single node with in-degree ≥ 2 or out-degree ≥ 2 (decision/merge points)
4. It consists of a single node with in-degree = 1 and out-degree = 1
5. It is a maximal chain of length ≥ 1.
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. 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.

Computing Cyclomatic Complexity

Let G be a given CFG. Let E denote the number of edges, and N denote the number of nodes.
Let V(G) denote the Cyclomatic complexity for the CFG. V(G) can be obtained in either of the
following three ways.
1. V(G) = E - N + 2
1. 2.V(G) = Total number of bounded areas + 1
2. 3.If LN be the total number of loops and decision statements in a program, then V(G)
= LN + 1
In case of object-oriented programming, the above equations apply to methods of a class. Also,
the value of V(G) obtained is incremented by 1 considering the entry point of the method. A
quick summary of how different types of statements affect V(G) could be found in . Once the
complexities of individual modules of a program are known, complexity of the program (or
class) could be determined by
V(G) = SUM( V(Gi) ) - COUNT( V(Gi) ) + 1
where COUNT( V(Gi) ) gives the total number of procedures (methods) in the program (class).

Code:
#include <stdio.h> #include <conio.h> #include <math.h> int main()
{
int a, b, c, validInput = 0, d; double D;
printf("Enter the 'a' value: "); scanf("%d", &a); printf("Enter the 'b' value: "); scanf("%d", &b);
printf("Enter the 'c' value: "); scanf("%d", &c);
if ((a >= 0) && (a <= 100) && (b >= 0) && (b <= 100) && (c >= 0) && (c
<= 100)) {
validInput = 1; if (a == 0)
validInput = -1;
}
if (validInput = 1) { d = b * b - 4 * a * c; if (d == 0) {
printf("The roots are equal and are r1 = r2 = %f\n", -b / (2 * (float)a));
}
else if (d > 0) { D = sqrt(d);
printf("The roots are real and are r1 = %f and r2 = %f\n", (-b - D) / (2 * a), (-b + D) / (2
* a));
}
else {
D = sqrt((-d) / (2 * a));
printf("The roots are imaginary and are r1 = (%f, %f) and r2 = (%f,
%f)\n", 1.0*-b / (2 * a),
D, 1.0*-b / (2 * a), -D);
}
}
else if (validInput == -1) {
printf("The values do not constitute a Quadratic Equation.");
}
else {
printf("The input belongs to invalid range.");
}
getch(); return 1;
}

Output:

Control flow graph

DD path graph

Cyclomatic complexity

In the above DD Path Graph, we can find Number of Nodes (n) = 19

Number of Edges (e) = 24
Number of Connected Components (P) = 1
1. V(G) = e – n + 2P = 24 – 19 + 2 = 7
2. V(G) = Π + 1 = 6 + 1 = 7 (where Π is the number of predicate nodes contained in the
graph G)
3. V(G) = Number of Regions = 7

Discussion:
Cyclomatic complexity is a software metric used to determine the complexity of a program. It
is a count of the number of decisions in the source code. The higher the count, the more
complex the code.

Findings and Learning:

We learnt to compute cyclomatic complexity which gives us the approximate complexity of
the program and helps us write efficient program