DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

LABORATORY MANUAL

Software Engineering Lab

(6KS07)

MAULI GROUP OF INSTITUTION’S

COLLEGE OF ENGINEERING &
TECHNOLOGY, SHEGAON

1
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 Late Purushottam Hari (Ganesh) Patil Shikshan Sanstha’s
Mauli Group of Institution’s, College of Engineering & Technology,
Shegaon.

Department of Computer Science & Engineering

LABORATORY : OS Subject: SE SEMESTER : VI

MASTER LIST OF EXPERIMENT

EXPT.
NO.
EXPERIMENT DESCRIPTION

1 To identify requirements from problem statements.

2 To study Estimation of project metrics using COCOMO Model.

3 To Model UML Use Case Diagrams and Capturing Use Case Scenarios.

4 E-R Modeling from Problem Statements.

5 Identitying Domain Classes from the Problem Statements.

6 State chart and Activity Modeling.

7 Modeling UML Class Diagrams and Sequence diagrams.

8 Modeling Data Flow Diagrams.

9 Estimation of Test Coverage Metrics and Structural Complexity.

10 Designing Test Suites.

PREPARED BY: Prof. [Link] APPROVED BY: H.O.D.: A. S. Kakad

2
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 01
Title: Identifying the Requirements from Problem Statements

Aim: To Identify the Requirements from Problem Statements

Learning Outcome: After completing this experiment, you will be able to:
 Identify ambiguities, inconsistencies and incompleteness from a requirements
specification
 Identify and state functional requirements
 Identify and state non-functional requirements

Resources:
Software Required: Operating System
Hardware Required: Computer System

Theory:
Requirements
Requirements can be defined as a specification of what should be implemented. Requirements
specify how the target system should behave. It specifies what to do, but not how to do.
Requirements engineering refers to the process of understanding what a customer expects from
the system to be developed, and to document them in a standard and easily readable and
understandable format. This documentation will serve as reference for the subsequent design,
implementation and verification of the system.
It is necessary and important that before we start planning, design and implementation of the
software system for our client, we are clear about it's requirements. If we don't have a clear
vision of what is to be developed and what all features are expected, there would be serious
problems, and customer dissatisfaction as well.
Characteristics of Requirements:
Requirements gathered for any new system to be developed should exhibit the following three
properties:
Unambiguity: There should not be any ambiguity what a system to be developed should do.
For example, consider you are developing a web application for your client. The client requires
that enough number of people should be able to access the application simultaneously. What's
the "enough number of people"? That could mean 10 to you, but, perhaps, 100 to the client.
There's an ambiguity.
Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one of the
clients say that it the radiation level inside the plant exceeds R1, all reactors should be shut

3
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
down. However, another person from the client side suggests that the threshold radiation level
should be R2. Thus, there is an inconsistency between the two end users regarding what they
consider as threshold level of radiation.
Completeness: A particular requirement for a system should specify what the system should
do and also what it should not. For example, consider a software to be developed for ATM. If
a customer enters an amount greater than the maximum permissible withdrawal amount, the
ATM should display an error message, and it should not dispense any cash.
Categorization of Requirements
Based on the target audience or subject matter, requirements can be classified into different
types, as stated below:
User requirements: They are written in natural language so that both customers can verify
their requirements have been correctly identified
System requirements: They are written involving technical terms and/or specifications, and
are meant for the development or testing teams.
Requirements can be classified into two groups based on what they describe:
Functional requirements (FRs): These describe the functionality of a system -- how a system
should react to a particular set of inputs and what should be the corresponding output.
Non-functional requirements (NFRs): They are not directly related what functionalities are
expected from the system. However, NFRs could typically define how the system should
behave under certain situations. For example, a NFR could say that the system should work
with 128MB RAM. Under such condition, a NFR could be more critical than a FR.
Non-functional requirements could be further classified into different types like:
Product requirements: For example, a specification that the web application should use only
plain HTML, and no frames
Performance requirements: For example, the system should remain available 24x7
Organizational requirements: The development process should comply to SEI CMM level 4
Functional Requirements
Identifying Functional Requirements:
Given a problem statement, the functional requirements could be identified by focusing on the
following points:
Identify the high level functional requirements simply from the conceptual understanding of
the problem. For example, a Library Management System, apart from anything else, should be
able to issue and return books.
Identify the cases where an end user gets some meaningful work done by using the system
If we consider the system as a black box, there would be some inputs to it, and some output in
return. This black box defines the functionalities of the system. For example, to search for a
book, user gives title of the book as input and get the book details and location as the output.

4
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Any high level requirement identified could have different sub-requirements.
Identification of non-functional requirements
Having talked about functional requirements, let's try to identify a few non-functional
requirements.
 Performance Requirements:
 This system should remain accessible 24x7
 At least 50 users should be able to access the system altogether at any given
time
 Security Requirements:
 This system should be accessible only within the institute LAN
 The database of LIS should not store any password in plain text -- a hashed
value has to be stored
 Software Quality Attributes
 Database Requirements
 Design Constraints:
 The system should be developed using HTML 5
Once all the functional and non-functional requirements have been identified, they are
documented formally in SRS, which then serves as a legal agreement.

Conclusion: Thus, we have identified requirements from problem statement.

References and further reading
Bibliography
Requirements Engineering: A Good Practice Guide, Ian Sommerville, Pete Sawyer, Wiley
India Pvt Ltd, 2009
Lecture on "System Analysis and Design", NPTEL
Requirements Analysis: Process of requirements gathering and requirement definition
Suggested Questions:
1. When is feasibility study done?
2. A good requirement specification is one, which is?
3. Requirement specification is done?
4. Functional requirements of a system are related to?
5. SRS refers to?

5
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 02
Title: Estimation of Project Metrics

Aim: To Estimate Project Metrics

Learning Outcome: In this experiment, we will learn how to estimate cost, effort and
duration for a software project .

Resources:
Software Required: Operating System
Hardware Required: Computer System

Theory:
A software project is not just about writing a few hundred lines of source code to achieve a
particular objective. One of the major activities of the project planning phase, is to estimate
various project parameters in order to take proper decisions. Some important project parameters
that are estimated include:
Project size: What would be the size of the code written say, in number of lines, files, modules?
Cost: How much would it cost to develop a software?
Duration: How long would it be before the software is delivered to the clients?
Effort: How much effort from the team members would be required to create the software?
In this experiment we will focus on two methods for estimating project metrics: COCOMO
and Halstead's method.

COCOMO
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there
could be three categories of software projects: organic, semidetached, and embedded.
Organic: A development project is said to be of organic type, if
The project deals with developing a well understood application.
Semidetached: A development project can be categorized as semidetached type, if the team
consists of some experienced as well as inexperienced staff
Embedded: Embedded type of development project are those, which
aims to develop a software strongly related to machine hardware.

6
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Boehm suggested that estimation of project parameters should be done through three stages:
Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.
Basic COCOMO Model
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:
Effort = a * (KDSI)b PM
Tdev = 2.5 * (Effort)c Months
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)
Intermediate COCOMO Model
The basic COCOMO model considers that effort and development time depends only on the
size of the software. However, in real life there are many other project parameters that
influence the development process. The intermediate COCOMO take those other factors into
consideration by defining a set of 15 cost drivers (multipliers). Thus, any project that makes
use of modern programming practices would have lower estimates in terms of effort and cost.
Each of the 15 such attributes can be rated on a six-point scale ranging from "very low" to
"extra high" in their relative order of importance. Each attribute has an effort multiplier fixed
as per the rating. The product of effort multipliers of all the 15 attributes gives the Effort
Adjustment Factor (EAF).
Complete COCOMO Model
Both the basic and intermediate COCOMO models consider a software to be a single
homogeneous entity -- an assumption, which is rarely true. In fact, many real life applications
are made up of several smaller sub-systems. The complete COCOMO model takes these factors
into account to provide a far more accurate estimate of project metrics.

Advantages of COCOMO
COCOMO is a simple model, and should help one to understand the concept of project metrics
estimation.
Drawbacks of COCOMO
 COCOMO uses KDSI, which is not a proper measure of a program's size.
 Indeed, estimating the size of a software is a difficult task, and any slight miscalculation
could cause a large deviation in subsequent project estimates.
 COCOMO II was proposed later in 2000 to many of address these issues.

7
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Conclusion:Thus,we have studied to estimate the project metrics using cocomo model.

References For Further Reading:

Bibliography
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
Software Engineering, Ian Sommerville, Addison Wesley Longman, 9th Edition, March 2010
Webliography

COCOMO

Halstead complexity measures

COCOMO (Constructive Cost Model), Seminar on Software Cost Estimation WS 2002 / 2003,
presented by Nancy Merlo – Schett

The Halstead metrics

Software Engineering, National Program on Technology Enhanced Learning

Halstead Metrics, Verifysoft Technology

Suggested Question
[Link] to the COCOMO model, a project can be categorized into how many types?

Q2. Project metrics are estimated during which phase?

[Link] COCOMO considers a software as a
 Homogeneous system
 Heterogeneous system ?

8
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 03
Title: Modelling UML Use Case Diagrams and Capturing Use Case
Scenarios

Aim: To Model UML Use Case Diagrams and Capturing Use Case Scenarios

Learning Outcome: After completing this experiment, you will be able to:
[Link] identify different actors and use cases from a given problem statement
[Link] associate use cases with different types of relationships
[Link] draw a use-case diagram

Resources:

Software Required: Star UML

Hardware Required: Computer System

Theory:
Introduction
Use case diagram is a platform that can provide a common understanding for the end-users,
developers and the domain experts. It is used to capture the basic functionality i.e. use cases,
and the users of those available functionality, i.e. actors, from a given problem statement.
In this experiment, we will learn how use cases and actors can be captured and how different
use cases are related in a system.

Use case diagrams

Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use case
diagrams aim to present a graphical overview of the functionality provided by the system. It
consists of a set of actions (referred to as use cases) that the concerned system can perform,
one or more actors, and dependencies among them.
Actor
An actor can be defined as an object or set of objects, external to the system, which interacts
with the system to get some meaningful work done. Actors could be human, devices, or even
other systems.
For example, consider the case where a customer withdraws cash from an ATM. Here,
customer is a human actor.

9
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Use Case
Use cases include both successful and unsuccessful scenarios of user interactions with the
system. For example, authentication of a customer by the ATM would fail if he enters wrong
PIN. In such case, an error message is displayed on the screen of the ATM.
Subject
Subject is simply the system under consideration. Use cases apply to a subject. For example,
an ATM is a subject, having multiple use cases, and multiple actors interact with it.
Graphical Representation
An actor is represented by a stick figure and name of the actor is written below it. A use case
is depicted by an ellipse and name of the use case is written inside it. The subject is shown by
drawing a rectangle. Label for the system could be put inside it. Use cases are drawn inside the
rectangle, and actors are drawn outside the rectangle, as shown in figure - 01.

Figure - 01: A use case diagram for a book store

Association between Actors and Use Cases
A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.
An actor must be associated with at least one use case. Similarly, a given use case must be
associated with at least one actor. Association among the actors are usually not shown.
Use Case Relationships
Three types of relationships exist among use cases:
Include relationship
Extend relationship
Use case generalization

10
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Include Relationship
Include relationships are used to depict common behaviour that are shared by multiple use
cases. This could be considered analogous to writing functions in a program in order to avoid
repetition of writing the same code..

Figure - 02: Include relationship between use cases

Extend Relationship
Use case extensions are used used to depict any variation to an existing use case. They are used
to the specify the changes required when any assumption made by the existing use case
becomes false.

Figure - 03: Extend relationship between use cases

Generalization Relationship
Generalization relationship are used to represent the inheritance between use cases. A derived
use case specializes some functionality it has already inherited from the base use case.

11
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Figure - 04: Generalization relationship among use cases
Identifying Actors
Given a problem statement, the actors could be identified by asking the following questions.
Who gets most of the benefits from the system? (The answer would lead to the identification
of the primary actor)
Who keeps the system working? (This will help to identify a list of potential users)
What other software / hardware does the system interact with?
Identifying Use cases
Any use case name should start with a verb like, "Check balance".

Conclusion: Thus, we have learned UML Model and drawn Use Case diagrams.

References for Further Reading:

Bibliography
Object-Oriented Modeling and Design with UML, Michael Blaha, James Rumbaugh,
Prentice-Hall of India, 2nd Edition
Object-Oriented Analysis and Design using UML, Mahesh P. Matha, Prentice-Hall of India,

Webliography
Use Case Diagrams
Use case diagram -- Wikipedia
Unified Modeling Language, Superstructure, V2.1.2

12
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Suggested Questions:
[Link] does a use case diagram represent?
2. In a use case diagram, relationships between different actors are normally shown
 True
 False
[Link] cases can be used for testing, which includes
1. Validation
2. Verification
3. Both
4. None

13
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 04
Title: E-R Modeling from the Problem Statements

Aim: To Model E-R Models from the Problem Statement.

Learning Outcome: In this experiment we will learn how to
 Identify entity sets, their attributes, and various relationships
 Represent the data model through ER diagram.

Resources:

Software Required: Star UML

Hardware Required: Computer System

Theory
Entity Relationship Model
Entity-Relationship model is used to represent a logical design of a database to be created. In
ER model, real world objects (or concepts) are abstracted as entities, and different possible
associations among them are modeled as relationships.
For example, student and school -- they are two entities. Students study in school. So, these
two entities are associated with a relationship "Studies in".
Entity Set and Relationship Set
An entity set is a collection of all similar entities. For example, "Student" is an entity set that
abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a
"Relationship" set is a set of similar relationships.
Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any entity in
a set can be described by zero or more attributes.
For example, any student has got a name, age, an address
These data are the attributes of the entity set Student.
Keys
One or more attribute(s) of an entity set can be used to define the following keys:
Super key: One or more attributes, which when taken together, helps to uniquely identify an
entity in an entity set.

14
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Candidate key: It is a minimal subset of a super key. In other words, a super key might contain
extraneous attributes, which do not help in identifying an object uniquely. When such attributes
are removed, the key formed so is called a candidate key.
Primary key: A database might have more than one candidate key. Any candidate key chosen
for a particular implementation of the database is called a primary key.
Prime attribute: Any attribute taking part in a super key.
Weak Entity
An entity set is said to be weak if it is dependent upon another entity set.
Entity Generalization and Specialization
Once we have identified the entity sets, we might find some similarities among them. For
example, multiple person interacts with a banking system. Most of them are customers, and
rest employees or other service providers. Here, customers, employees are persons, but with
certain specializations. Or in other way, person is the generalized form of customer and
employee entity sets.
ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).
Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two
entity sets E1 and E2 associated by a relationship set R. Based on the number of entities in E1
and E2 are associated with, we can have the following four type of mappings:
One to one: An entity in E1 is related to at most a single entity in E2, and vice versa.
One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in E2
could be related to at most a single entity in E1.
Many to one: Zero or more number of entities in E1 could be associated to a single entity in
E2. However, an entity in E2 could be related to at most one entity in E1.
Many to many: Any number of entities could be related to any number of entities in E2,
including zero, and vice versa.
ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have this information, we represent them
pictorially, called an entity-relationship (ER) diagram.
Graphical Notations for ER Diagram

Term Notation Remarks

Name of the set is written

Entity set
inside the rectangle

15
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 Term Notation Remarks

Name of the attribute is

Attribute
written inside the ellipse

Roll is the primary key;

Entity with attributes
denoted with an underline

Weak entity set

Name of the relationship is

Relationship set
written inside the diamond

Related enity sets

A person can own zero or

Relationship more cars but no two

cardinality persons can own the
same car

Relationship with
weak entity set

Importance of ER modelling

Figure - 01 shows the different steps involved in implementation of a (relational) database.

Figure - 01: Steps to implement a RDBMS

Given a problem statement, the first step is to identify the entities, attributes and relationships.
We represent them using an ER diagram. Using this ER diagram, table structures are created,
along with required constraints. Finally, these tables are normalized in order to remove

16
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
redundancy and maintain data integrity. Thus, to have data stored efficiently, the ER diagram
is to be drawn as much detailed and accurate as possible.
Conclusion:
In this way, we have learned E-R modelling from problem statement and how to find the
entities, its attributes and how the relationships between the entities can be established for a
system.
References for Further Reading:
Bibliography

1. Database System Concepts, Henry F. Korth , Abraham Silberschatz, McGraw Hills, 5th Edition

Webliography

Entity-relationship modelling

Entity Relationship Modelling - 2

Suggested Questions:
Q1. Entity Relationship model is used to represent the database at a

Logical level

Physical level
[Link] ER model an entity is usually related to another entity. The relationship is indicated by
a

1. Rectangle [Link] 3. Diamond [Link]

Q 3. An entity set could be related to itself

True

False
Q 4. Students study in schools -- this is a
1. 1:1 mapping 2. 1: N mapping
3 .M:1 mapping 4. M:M mapping

17
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 05
Title: Identifying Domain Classes from the Problem Statements

Aim: To Identify Domain Classes from the Problem Statements

Learning Outcome: In this experiment we will learn how to
o Understand the concept of domain classes.
o To Identify a list of potential domain classes from a given problem statement

Resources:
Software Required: Star UML
Hardware Required: Computer System

Theory:
Introduction:
Same types of objects are typically implemented by class in object oriented programming. As
the structural unit of the system can be represented through the classes, so, it is very important
to identify the classes before start implementing all the logical flows of the system.
In this experiment we will learn how to identify the classes from a given problem statement.
Domain Class
In Object Oriented Paradigm Domain Object Model has become subject of interest for its
excellent problem comprehending capabilities towards the goal of designing a good software
system. Domain Model, as a conceptual model gives proper understanding of problem
description through its highly effective component – the Domain Classes. Domain classes are
the abstraction of key entities, concepts or ideas presented in the problem statement. Domain
classes are used for representing business activities during the analysis phase.
Below we discuss some techniques that can be used to identify the domain classes.
Traditional Techniques for Identification of Classes
Grammatical Approach Using Nouns
This object identification technique was proposed by Russell J. Abbot, and Grady Booch made
the technique popular . This technique involves grammatical analysis of the problem statement
to identify list of potential classes. The logical steps are:

 Obtain the user requirements (problem statement) as a simple, descriptive English text.
This basically corresponds to the use-case diagram for the problem statement.

18
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
  Identify and mark the nouns, pronouns and noun phrases from the above problem
statements
 List of potential classes is obtained based on the category of the nouns. For example,
nouns that direct refer to any person, place, or entity in general, correspond to different
objects. And so does singular proper nouns. On the other hand, plural nouns and
common nouns are candidates that usually map into classes.
Advantages
1. This is one of the simplest approaches that could be easily understood and applied by a
larger section of the user base.
2. The problem statement does not necessarily be in English, but in any other language.
Disadvantages
1. The problem statement always may not help towards correct identification of a class.
At times it could give us redundant classes.
2. When the problem statement may use abbreviations for large systems or concepts, and
therefore, the identified class may actually point to an aggregate of classes. In other
words, it may not find all the objects.
Using Generalization
In this approach, all potential objects are classified into different groups based on some
common behaviour. Classes are derived from these groups.
Using Subclasses
Here, instead of identifying objects one goes for identification of classes based on some similar
characteristics. These are the specialized classes. Common characteristics are taken from them
to form the higher-level generalized classes.
Steps to Identify Domain Classes from Problem Statement
We now present the steps to identify domain classes from a given problem statement. This
approach is mostly based on the “Grammatical approach using nouns” discussed above, with
some insights from.
Make a list of potential objects by finding out the nouns and noun phrases from narrative
problem statement
Apply subject matter expertise (or domain knowledge) to identify additional classes
Filter out the redundant or irrelevant classes
Classify all potential objects based on categories. We follow the category table as described by
Ross

Categories Explanation

People Humans who carry out some function

Places Areas set aside for people or things

19
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 Categories Explanation

Things Physical objects

Collection of people, resources, facilities and

Organizations
capabilities having a defined mission

Concepts Principles or Ideas not tangible

Things that happen (usually at a given date and

Events
time), or as a step in an ordered sequence

Group the objects based on similar attributes. While grouping we should remember that
Different nouns (or noun phrases) can actually refer to the same thing (examples: house, home,
abode)
Same nouns (or noun phrases) could refer to different things or concepts (example: I go to
school every day / This school of thought agrees with the theory)
Give related names to each group to generate the final list of top-level classes
Iterate over to refine the list of classes
Advanced Concepts
Identification of domain classes might not be a simple task for novices. It requires expertise
and domain knowledge to identify business classes from plain English text. A lot of work has
been done in this area, and various techniques have been proposed to identify domain classes.
Conclusion: Thus, we have understood the concept of domain classes and learned identifying
the domain classes from problem statements.
References for further reading:
1. UML and C++ A Practical Guide To Object-Oriented Development, Richard C. Lee,
William M. Tepfenhart, Prentice-Hall of India, 2nd Edition, 2005
2. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition,
2009

Suggested Questions:

Q.1. Domain Object Model is used to

1. Build concept 2. Build the databases 3. Construct the logical operations

Q 2. Classes contain the same type objects – here the same type means
1. Coming from the same sources 2. They are of same data type

3. They are using the same attributes and methods

20
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 06

Title: Statechart and Activity Modeling

Aim: To Study Statechart and Activity Modeling.
Learning Outcome: After completing this experiment, you will be able to:

 Identify the distinct states a system has

 Identify the events causing transitions from one state to another
 Identify activities representing basic units of work, and represent their flow

Resources:

Software Required: Star UML

Hardware Required: Computer System
Introduction
Capturing the dynamic view of a system is very important for a developer to develop the logic
for a system. State chart diagrams and activity diagrams are two popular UML diagram to
visualize the dynamic behaviour of an information system.

Statechart Diagrams
A statechart diagram is a pictorial representation of such a system, with all it's states, and
different events that lead transition from one state to another.
To illustrate this, consider a computer. Some possible states that it could have are: running,
shutdown, hibernate. A transition from running state to shutdown state occur when user presses
the "Power off" switch, or clicks on the "Shut down" button as displayed by the OS. Here,
clicking on the shutdown button, or pressing the power off switch act as external events causing
the transition.
Statechart diagrams are normally drawn to model the behaviour of a complex system. For
simple systems this is optional.
Building Blocks of a Statechart Diagram
State
A state is any "distinct" stage that an object (system) passes through in it's lifetime. An object
remains in a given state for finite time until "something" happens, which makes it to move to
another state. All such states can be broadly categorized into following three types:
Initial: The state in which an object remain when created
Final: The state from which an object do not move to any other state.

21
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Intermediate: Any state, which is neither initial, nor final
As shown in figure-01, an initial state is represented by a circle filled with black. An
intermediate state is depicted by a rectangle with rounded corners. A final state is represented
by a unfilled circle with an inner black-filled circle.

Figure-01: Representation of initial,

intermediate, and final states of a statechart
diagram
Intermediate states usually have two compartments, separated by a horizontal line, called the
name compartment and internal transitions compartment. They are described below:
Name compartment: Contains the name of the state, which is a short, simple, descriptive string
Internal transitions compartment: Contains a list of internal activities performed as long as the
system is in this state
Action labels could be any condition indicator. There are, however, four special action labels:
Entry: Indicates activity performed when the system enters this state
Exit: Indicates activity performed when the system exits this state
Do: indicate any activity that is performed while the system remains in this state or until the
action expression results in a completed computation
Include: Indicates invocation of a sub-machine
Any other action label identify the event (internal transition) as a result of which the
corresponding action is triggered. Figure-02 shows the syntax for representing a typical

(intermediate) state
Figure-02: A typical state in a statechart diagram

Transition
Transition is movement from one state to another state in response to an external stimulus (or
any internal event). A transition is represented by a solid arrow from the current state to the
next state. It is labelled by: event [guard-condition]/[action-expression], where
Event is the what is causing the concerned transition (mandatory)
Guard-condition is (are) precondition(s), which must be true for the transition to happen
[optional]
Action-expression indicate action(s) to be performed as a result of the transition [optional]

22
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
It may be noted that if a transition is triggered with one or more guard-condition(s), which
evaluate to false, the system will continue to stay in the present state. Also, not all transitions
do result in a state change.
Action
As mentioned in actions represents behaviour of the system. The order in which different
actions are executed, is given below:
[Link] actions of the present state
[Link] specified for the transition
[Link] actions of the next state
Figure-03 shows a typical state chart diagram with all its syntaxes.

Figure-03: A statechart diagram showing transition from state A to B

Guidelines for drawing Statechart Diagrams
Following steps could be followed, to draw a statechart diagram:
 For the system to developed, identify the distinct states that it passes through
 Identify the events (and any precondition) that cause the state transitions.
 Identify what activities are performed while the system remains in a given state

Activity Diagrams
Activity diagrams fall under the category of behavioural diagrams in Unified Modeling
Language. It is a high level diagram used to visually represent the flow of control in a system.
However, it is more powerful than a simple flow chart since it can represent various other
concepts like concurrent activities, their joining, and so on.
These diagrams are typically used when the business logic is complex.
Components of an Activity Diagram
Below we describe the building blocks of an activity diagram.
Activity
An activity denotes a particular action taken in the logical flow of control. An activity is
represented with a rounded rectangle, as shown in table-01. A label inside the rectangle
identifies the corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a filled
circle, and a filled in circle with a border respectively.

23
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Flow
A flow (also termed as edge, or transition) is represented with a directed arrow. This is used to
depict transfer of control from one activity to another, .A flow is often accompanied with a
label, called the guard condition, indicating the necessary condition for the transition to happen.
Decision
A decision node, represented with a diamond, is a point where a single flow enters and two or
more flows leave. The control flow can follow only one of the outgoing paths. The outgoing
edges often have guard conditions indicating true-false or if-then-else conditions.
Merge
This is represented with a diamond shape, with two or more flows entering, and a single flow
leaving out.
Fork
Fork is a point where parallel activities begin. A fork is graphically depicted with a black bar,
with a single flow entering and multiple flows leaving out.
Join
A join is depicted with a black bar, with multiple input flows, but a single output flow.
Physically it represents the synchronization of all concurrent activities.
Note
UML allows attaching a note to different components of a diagram to present some textual
information.
Partition
Different components of an activity diagram can be logically grouped into different areas,
called partitions or swimlanes. They often correspond to different units of an organization or
different actors.
The following table shows commonly used components with a typical activity diagram.

Component Graphical Notation

Activity

Flow

24
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Component Graphical Notation

Decision

Merge

Fork

Join

Note

Table-01: Typical components used in an activity diagram

A Simple Example

25
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Figure-04 shows a simple activity diagram with two activities. The figure depicts two stages
of a form submission. At first a form is filled up with relevant and correct information. Once it
is verified that there is no error in the form, it is then submitted. The two other symbols shown
in the figure are the initial node (dark filled circle), and final node (outer hollow circle with
inner filled circle). It may be noted that there could be zero or more final node(s) in an activity
diagram.

Figure-04: A simple activity diagram.

Guidelines for drawing an Activity Diagram
The following general guidelines could be followed to pictorially represent a complex logic.
 Identify tiny pieces of work being performed by the system
 Identify the next logical activity that should be performed
 Think about all those conditions that should be made, and all those constraints that
should be satisfied, before one can move to the next activity
 Put non-trivial guard conditions on the edges to avoid confusion

Conclusion: Thus, we have studied the statechart and activity modelling.

References for Further Reading:

Webliography
PlantUML : State Diagram
Activity Diagram
UML Activity Diagram

26
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Suggested Questions
1. What does an entry action of a state indicate?
[Link] does the guard condition depicted over the transition between any two states indicate?
3. A state can contain one or more sub-state(s) within it
4. What does forking of several activities from a synchronization point indicate?
5. A decision point in an activity diagram is a control where

27
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 07

Title: Modeling UML Class Diagrams and Sequence diagrams

Aim: To Model UML Class Diagrams and Sequence diagrams.

Learning Outcome: After completing this experiment you will be able to:
 Graphically represent a class, and associations among different classes
 Identify the logical sequence of activities undergoing in a system, and represent them
pictorially
 Structural and Behavioural aspects

Resources:

Software Required: Star UML

Hardware Required: Computer System
Theory:
Introduction
All objects in a system are also interacting to each other by means of passing messages from
one object to another. Sequence diagram shows these interactions with time ordering of the
messages.
From the experiment of sequence diagram, we will learn about different types of messages
passing in between the objects and time ordering of those messages, in a system.

Class diagram
It is a graphical representation for describing a system in context of its static construction.
Elements in class diagram
Class diagram contains the system classes with its data members, operations and relationships
between classes.
Class
A set of objects containing similar data members and member functions is described by a class.
In UML syntax, class is identified by solid outline rectangle with three compartments which
contain

 Class name

28
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 A class is uniquely identified in a system by its name. A textual string is taken as class
name. It lies in the first compartment in class rectangle.

 Attributes
Property shared by all instances of a class. It lies in the second compartment in class
rectangle.

 Operations
An execution of an action can be performed for any object of a class. It lies in the last
compartment in class rectangle.
Example
To build a structural model for an Educational Organization, ‘Course’ can be treated as a class
which contains attributes ‘courseName’ & ‘courseID’ with the operations ‘addCourse()’ &
‘removeCourse()’ allowed to be performed for any object to that class.

Figure-01:

 Generalization/Specialization
It describes how one class is derived from another class. Derived class inherits the
properties of its parent class.

Example

Figure-02:

29
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Geometric_Shapes is the class that describes how many sides a particular shape has. Triangle,
Quadrilateral and Pentagon are the classes that inherit the property of the Geometric_Shapes class. So,
the relations among these classes are generalization. Now Equilateral_Triangle, Isosceles_Triangle and
Scalene_Triangle, all these three classes inherit the properties of Triangle class as each one of them has
three sides. So, these are specialization of Triangle class.
Relationships
Existing relationships in a system describe legitimate connections between the classes in that system.
Association
It is an instance level relationship that allows exchanging messages among the objects of both ends of
association. A simple straight line connecting two class boxes represent an association. Association
may be uni-directional.
Example
In structure model for a system of an organization an employee (instance of ‘Employee’ class) is always
assigned to a particular department (instance of ‘Department’ class) and the association can be shown
by a line connecting the respective classes.

Figure-03:

Aggregation
In a relationship, when a class holds some instances of related class, then that relationship can be
designed as an aggregation.
Example
For a supermarket in a city, each branch runs some of the departments they have. So, the relation among
the classes ‘Branch’ and ‘Department’ can be designed as an aggregation. In UML, it can be shown as
in the fig. below

Figure-04:
Composition
It is a strong from of aggregation which describes that whole is completely owns its part. Life cycle of
the part depends on the whole.

Example

30
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Let consider a shopping mall has several branches in different locations in a city. The existence of
branches completely depends on the shopping mall as if it is not existing any branch of it will no longer
exists in the city. This relation can be described as composition and can be shown as below

Figure-05:
Multiplicity
It describes how many numbers of instances of one class is related to the number of instances of another
class in an association.
Notation for different types of multiplicity:

Figure-06:
Example
One vehicle may have two or more wheels

Figure-07:

Sequence diagram
It represents the behavioral aspects of a system Sequence diagram shows the interactions between the
objects by means of passing messages from one object to another with respect to time in a system.
Elements in sequence diagram
Sequence diagram contains the objects of a system and their life-line bar and the messages passing
between them.

Object
Objects appear at the top portion of sequence diagram. Object is shown in a rectangle box. Name of
object precedes a colon ‘:’ and the class name, from which the object is instantiated. The whole string
is underlined and appears in a rectangle box. Also, we may use only class name or only instance name.
Objects which are created at the time of execution of use case and are involved in message passing , are
appear in diagram, at the point of their creation.

31
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Life-line bar
A down-ward vertical line from object-box is shown as the life-line of the object. A rectangle bar on
life-line indicates that it is active at that point of time.
Messages
Messages are shown as an arrow from the life-line of sender object to the life-line of receiver object
and labeled with the message name. Chronological order of the messages passing throughout the
objects’ life-line show the sequence in which they occur. There may exist some different types of
messages:
Synchronous messages:Receiver start processing the message after receiving it and sender needs to
wait until it is made. A straight arrow with close and fill arrow-head from sender life-line bar to receiver
end, represent a synchronous message.
Asynchronous messages:For asynchronous message sender needs not to wait for the receiver to
process the message. A function call that creates thread can be represented as an asynchronous message
in sequence diagram.A straight arrow with open arrow-head from sender life-line bar to receiver end,
represent an asynchronous message.
Return message:For a function call when we need to return a value to the object, from which it was
called, then we use return message. But it is optional, and we are using it when we are going to model
our system in much detail. A dashed arrow with open arrow-head from sender life-line bar to receiver
end, represent that message.

Response message:One object can send a message to self. We use this message when we need
to show the interaction between the same object.

Conclusion: In this way, we have learned to model UML class diagrams and sequence
diagrams.
References for Further Reading:
Bibliography
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009

THE UNIFIED MODELING LANGUAGE USER GUIDE, GRADY BOOCH, JAMES RUMBAUGH, IVAR
JACOBSON, ADDISON-WESLEY, Low Priced Edition, 2000

Webliography
Class diagram

UML Tutorial: Part 1 -- Class Diagrams

Synchronous messages The UML

32
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Asynchronous message , UML sequence diagram

Suggested Questions:
Q1.A class is a
[Link] 2. Specific instance of an object
3. Category of user requirement 4. None of the above

Q2. In class diagrams, a class is represented with a

1. Rectangle 2. Human stick figure
3. Ellipse 4. Diamond

Q3. What does a sequence diagram represent?

1. Workflow in the system 2. How classes are related to each other
3. Sequence of events flow to achieve a target
4. Sequence of activities to be performed before moving to next state

Q4. From a class diagram it is evident that

1. All classes work in isolation
2. Each class is related with every other class
3. Most of the classes are related
4. Class diagram show object interactions

33
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 08

Title: Modeling Data Flow Diagrams

Aim: To Model Data Flow Diagram
Learning Outcome: After completing this experiment you will be able to:
 Identify external entities and functionalities of any system
 Identify the flow of data across the system
 Represent the flow with Data Flow Diagrams flow

Resources:

Software Required: Star UML

Hardware Required: Computer System
Theory
Data Flow Diagram
DFD provides the functional overview of a system. The graphical representation easily
overcomes any gap between ’user and system analyst’ and ‘analyst and system designer’ in
understanding a system. Starting from an overview of the system it explores detailed design of
a system through a hierarchy. DFD shows the external entities from which data flows into the
process and also the other flows of data within a system. It also includes the transformations of
data flow by the process and the data stores to read or write a data.
Graphical notations for Data Flow Diagram

Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; name of th

Data store
written inside the shape

34
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Term Notation Remarks

Data flow Data flow is represented by a directed arc with its data name

Explanation of Symbols used in DFD

Process: Processes are represented by circle. The name of the process is written into the circle.
The name of the process is usually given in such a way that represents the functionality of the
process. More detailed functionalities can be shown in the next Level if it is required. Usually
it is better to keep the number of processes less than 7. If we see that the number of processes
becomes more than 7 then we should combine some the processes to a single one to reduce the
number of processes and further decompose it to the next level .
External entity: External entities are only appeared in context [Link] send data to be
processed and again receive the processed data.
Data store: Name of the data store is written in between two horizontal lines of the open
rectangle. Data stores are used as repositories from which data can be flown in or flown out to
or from a process.
Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two
processes and vice-versa.
Context diagram and leveling DFD
We start with a broad overview of a system represented in level 0 diagram. It is known as
context diagram of the system. The entire system is shown as single process and also the
interactions of external entities with the system are represented in context diagram.
Further we split the process in next levels into several numbers of processes to represent the
detailed functionalities performed by the system. Data stores may appear in higher level DFDs.
Numbering of processes: If process ‘p’ in context diagram is split into 3 processes ‘p1’, ‘p2’and
‘p3’ in next level then these are labeled as 0.1, 0.2 and 0.3 in level 1 respectively. Let the
process ‘p3’ is again split into three processes ‘p31’, ‘p32’ and ‘p33’ in level 2, so, these are
labeled as 0.3.1, 0.3.2 and 0.3.3 respectively and so on.
Balancing DFD: The data that flow into the process and the data that flow out to the process
need to be match when the process is split into in the next level. This is known as balancing a
DFD.

Note:
External entities only appear in context diagram i.e, only at level 0.
Keep number of processes at each level less than 7.
Data flow is not possible in between two external entities and in between two data stores.
Data cannot flow from an External entity to a data store and vice-versa.
Conclusion:
35
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
In this way we have learned to model data flow diagrams.
References for Further Reading:
Bibliography
Software Engineering, Ian Sommerville, Addison Wesley Longman, 9th Edition, March 2010
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
Webliography
NPTEL course material - System Analysis and Design
Software Engineering Virtual Lab - Simulation
Software Engineering Virtual Lab - Case Study
Suggested Questions:
Q1. A DFD represents
Flow of control
Flow of data
Both the above
Neither one
[Link] is not a component of a DFD?
Data flow
Decision
Process
Data store

[Link] flow in a DFD is not possible in between

Two processes

Data store and process

External entity and data store
Process and external entity

36
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 09

Title: Estimation of Test Coverage Metrics and Structural

Complexity

Aim: Estimation of Test Coverage Metrics and Structural Complexity

Learning Outcome: After completing this experiment, you will be able to:
 Identify basic blocks in a program module, and draw its control flow graph (CFG)
 Identify the linearly independent paths from a CFG
 Determine Cyclomatic complexity of a module in a program
Resources:
Software Required: Star UML
Hardware Required: Computer System
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 it's CFG. For
simplicity, each node in the CFG has been labeled 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.
int x = 10, x_2 = 0;
x_2 = x * x;
return x_2;

37
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Figure 1: A simple program and it's CFG
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 how a CFG would look like if
there are sequential, selection and iteration kind of statements in order.

Figure 2: CFG for different

types of statements
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 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
The size of a CFG could be reduced by representing each basic block with a node. To illustrate
this, let's consider the following example.
sum = 0;
i = 1;
while (i ≤ n) {

38
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 sum += i;
++i;
}
printf("%d", sum);
if (sum > 0) {
printf("Positive");
}
The CFG with basic blocks is shown for the above code in figure 3.

Figure 3: Basic blocks in a CFG

The first statement of a basic block is termed as leader. Any node x in a CFG is said to dominate
another node y (written as x dom y) if all possible execution paths that goes through node y must
pass through node x. The node x is said to be a dominator [ii]. In the above example, line #s 1, 3, 4, 6,
7, 9, 10 are leaders. The node containing lines 7, 8 dominate the node containing line # 10. The block
containing line #s 1, 2 is said to be the entry block; the block containing line # 10 is said to be the exit
block.

If any block (or sub-graph) in a CFG is not connected with the sub-graph containing the entry block,
that signifies the concerned block contains code, which is unreachable while the program is
executed. Such unreachable code can be safely removed from the program. To illustrate this, let's
consider a modified version of our previous code:

sum = 0;

39
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 i = 1;

while (i ≤ n) {

sum += i;

++i;

return sum;

if (sum < 0) {

return 0;

}
Figure 4 shows the corresponding CFG. The sub-graph containing line #s 8, 9, 10 is disconnected from
the graph containing the entry block. The code in the disconnected sub-graph would never get
executed, and, therefore, could be discarded.

Figure 4: CFG with

unreachable blocks
Terminologies
Path
A path in a CFG is a sequence of nodes and edges that starts from the initial node (or entry
block) and ends at the terminal node. The CFG of a program could have more than one terminal
nodes.
Linearly Independent Path
A linearly independent path is any path in the CFG of a program such that it includes at least
one new edge not present in any other linearly independent path. A set of linearly independent
paths give a clear picture of all possible paths that a program can take during its execution.
Therefore, path-coverage testing of a program would suffice by considering only the linearly

40
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
independent paths.

McCabe's Cyclomatic Complexity

McCabe had applied graph-theoretic analysis to determine the complexity of a program module
Cyclomatic complexity metric, as proposed by McCabe, provides an upper bound for the
number of linearly independent paths that could exist through a given program module.
Complexity of a module increases as the number of such paths in the module increase. Thus,
if Cyclomatic complexity of any program module is 7, there could be up to seven linearly
independent paths in the module. For a complete testing, each of those possible paths should
be tested.
Optimum Value of Cyclomatic Complexity
A set of threshold values for Cyclomatic complexity has been presented in which we
reproduce below.

V(G) Module Category Risk

1-10 Simple Low

11-20 More complex Moderate

21-50 Complex High

> 50 Unstable Very high

It has been suggested that the Cyclomatic complexity of any module should not exceed 10.
Doing so would make a module difficult to understand for humans. If any module is found to
have Cyclomatic complexity greater than 10, the module should be considered for redesign.
Note that, a high value of V(G) is possible for a given module if it contains multiple cases in
C like switch-case statements. McCabe had exempted such modules from the limit of V(G) as
10.
Merits
McCabe's Cyclomatic complexity has certain advantages:
Independent of programming language
Helps in risk analysis during development or maintenance phase
Gives an idea about the maximum number of test cases to be executed (hence, the required
effort) for a given module
Demerits
Cyclomatic complexity doesn't reflect on cohesion and coupling of modules.

41
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
McCabe's Cyclomatic complexity was originally proposed for procedural languages. One may
look in to get an idea of how the complexity calculation could be modified for object-oriented
languages.
Conclusion:
In this way, we have to Estimation of Test Coverage Metrics and Structural Complexity

References for Further Reading

Bibliography
1. Software Engineering: A Practioner's Approach, Roger S. Pressman, McGraw Hills,
7th Edition, 2009

Webliography
Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric
Control flow graphs and loop optimizations - Purdue Engineering
Control Flow Analysis

Suggested Questions:

Q1. What does CFG of a program describe?

Sequence of function calls

Sequence of statements executed

Contents of the stack
There's nothing called CFG!
Q2.A set of paths are said to be linearly independent if

Each of them is distinct

No paths have a common node
No two paths have a common node
All the paths are pairwise distinct

42
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 PRACTICAL NO: 10

Title: Designing Test Suites

Aim: To Design Test Suites.
Learning Outcome: After completing this experiment you will be able to:
 Learn about different techniques of testing a software
 Design unit test cases to verify the functionality and locate bugs, if any
Resources:
Software Required: Operating System
Hardware Required: Computer System
Theory:
Software Testing
Testing software is an important part of the development life cycle of a software. It is an
expensive activity. Hence, appropriate testing methods are necessary for ensuring the reliability
of a program. According to the ANSI/IEEE 1059 standard, the definition of testing is the
process of analysing a software item, to detect the differences between existing and required
conditions i.e. defects/errors/bugs and to evaluate the features of the software item.
The purpose of testing is to verify and validate a software and to find the defects present in a
software. The purpose of finding those problems is to get them fixed.
Verification is the checking or we can say the testing of software for consistency and
conformance by evaluating the results against pre-specified requirements.
Validation looks at the systems correctness, i.e. the process of checking that what has been
specified is what the user actually wanted.
Defect is a variance between the expected and actual result. The defect’s ultimate source may
be traced to a fault introduced in the specification, design, or development (coding) phases.
Standards for Software Test Documentation
IEEE 829-1998 is known as the 829 Standard for Software Test Documentation. It is an IEEE
standard that specifies the form of a set of documents for use in software testing . There are
other different standards discussed below.
IEEE 1008, a standard for unit testing
IEEE 1012, a standard for Software Verification and Validation
IEEE 1028, a standard for software inspections
IEEE 1044, a standard for the classification of software anomalies
IEEE 1044-1, a guide to the classification of software anomalies
43
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
IEEE 830, a guide for developing system requirements specifications
IEEE 730, a standard for software quality assurance plans
IEEE 1061, a standard for software quality metrics and methodology
IEEE 12207, a standard for software life cycle processes and life cycle data
BS 7925-1, a vocabulary of terms used in software testing
BS 7925-2, a standard for software component testing
Testing Frameworks
Following are the different testing frameworks:
jUnit - for Java unit test
Selenium - is a suite of tools for automating web applications for software testing purposes,
plugin for Firefox
HP QC - is the HP Web-based test management tool. It familiarizes with the process of
defining releases, specifying requirements, planning tests, executing tests, tracking defects,
alerting on changes, and analysing results. It also shows how to customize project.
IBM Rational - Rational software has a solution to support business sector for designing,
implementing and testing software.
Need for Software Testing
There are many reasons for why we should test software, such as:
Software testing identifies the software faults. The removal of faults helps reduce the number
of system failures. Reducing failures improves the reliability and the quality of the systems.
Software testing can also improve the other system qualities such as maintainability, usability,
and testability.
In order to meet the condition that the last few years of the 20th century systems had to be
shown to be free from the ‘millennium bug’.
In order to meet industry specific standards such as the Aerospace, Missile and Railway
Signalling standards.
Test Cases and Test Suite
A test case describes an input descriptions and an expected output descriptions. Input are of
two types: preconditions (circumstances that hold prior to test case execution) and the actual
inputs that are identified by some testing methods. The set of test cases is called a test suite.
We may have a test suite of all possible test cases.
Types of Software Testing
Testing is done in every stage of software development life cycle, but the testing done at each
level of software development is different in nature and has different objectives. There are
different types of testing, such as stress testing, volume testing, configuration testing,

44
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
compatibility testing, recovery testing, maintenance testing, documentation testing, and
usability testing. Software testing are mainly of following types
Unit Testing
Integration Testing
System Testing
Unit Testing
Unit testing is done at the lowest level. It tests the basic unit of software, that is the smallest
testable piece of software. The individual component or unit of a program are tested in unit
testing. Unit testing are of two types.
Black box testing: This is also known as functional testing , where the test cases are designed
based on input output values only. There are many types of Black Box Testing but following
are the prominent ones.
- Equivalence class partitioning: In this approach, the domain of input values to a program is
divided into a set of equivalence classes. e.g. Consider a software program that computes
whether an integer number is even or not that is in the range of 0 to 10. Determine the
equivalence class test suite. There are three equivalence classes for this program. - The set of
negative integer - The integers in the range 0 to 10 - The integer larger than 10
- Boundary value analysis : In this approach, while designing the test cases, the values at
boundaries of different equivalence classes are taken into consideration. e.g. In the above given
example as in equivalence class partitioning, a boundary values based test suite is { 0, -1, 10,
11 }
White box testing: It is also known as structural testing. In this testing, test cases are designed
on the basis of examination of the code. This testing is performed based on the knowledge of
how the system is implemented. It includes analysing data flow, control flow, information flow,
coding practices, exception and error handling within the system, to test the intended and
unintended software behavior. White box testing can be performed to validate whether code
implementation follows intended design, to validate implemented security functionality, and
to uncover exploitable [Link] testing requires access to the source code. Though
white box testing can be performed any time in the life cycle after the code is developed, but it
is a good practice to perform white box testing during the unit testing phase.
Integration Testing
Integration testing is performed when two or more tested units are combined into a larger
structure. The main objective of this testing is to check whether the different modules of a
program interface with each other properly or not. This testing is mainly of two types:
Top-down approach
Bottom-up approach
In bottom-up approach, each subsystem is tested separately and then the full system is tested.
But the top-down integration testing starts with the main routine and one or two subordinate

45
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
routines in the system. After the top-level ‘skeleton’ has been tested, the immediately
subroutines of the ‘skeleton’ are combined with it and tested.
System Testing
System testing tends to affirm the end-to-end quality of the entire system. System testing is
often based on the functional / requirement specification of the system. Non-functional quality
attributes, such as reliability, security, and maintainability are also checked. There are three
types of system testing
Alpha testing is done by the developers who develop the software. This testing is also done
by the client or an outsider with the presence of developer or we can say tester.
Beta testing is done by very few numbers of end users before the delivery, where the change
requests are fixed, if the user gives any feedback or reports any type of defect.
User Acceptance testing is also another level of the system testing process where the system
is tested for acceptability. This test evaluates the system's compliance with the client
requirements and assess whether it is acceptable for software delivery
An error correction may introduce new errors. Therefore, after every round of error-fixing,
another testing is carried out, i.e. called regression testing.
Regression Testing
The purpose of regression testing is to ensure that bug fixes and new functionality introduced
in a software do not adversely affect the unmodified parts of the program. Regression testing
is an important activity at both testing and maintenance phases. When a piece of software is
modified, it is necessary to ensure that the quality of the software is preserved. To this end,
regression testing is to retest the software using the test cases selected from the original test
suite.
Conclusion:In this way we have learned about designing test suites.
References fir Further Reading:
Bibliography
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
Software Engineering: A Practioner's Approach, Roger S. Pressman, McGraw Hills, 7th
Edition, 2009
Webliography
Standards for software test documentation
JUnit frameworks
Selenium frameworks
Developing Test Plans

46
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Suggested Questions.
[Link] testing is the process of

Demonstrating that errors are not present

Establishing confidence that a program does what it is supposed to do

Executing a program to show that it is working as per specifications

Executing a program with the intent of finding errors

[Link] testing is done by

Customer

Tester

Developer

All of the above

3. Test suite is

Set of test cases

Set of inputs

Set of outputs

None of the above

4. Regression testing is primarily related to

Functional testing

Data flow testing

Development testing

Maintenance testing
5. Acceptance testing is done by

Developers

Customers

47
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
 Testers

All of the above

6. Testing the software is basically

Verification

Validation

Verification and Validation

None of the above

7. Functionality of a software is tested by

White box testing

Black box testing

Regression testing

None of the above

8. Top down approach is used for

Development

Identification of faults

Validation

Functional testing
9. Testing of software with actual data and in the actual environment is called

Alpha testing

Beta testing

Regression testing

None of the above

10. During the development phase, which of the following testing approach is not adopted

Unit testing

48
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab
Bottom up testing

Integration testing

Acceptance testing

49
DEPT: Computer Science & Engineering/Sem VI/Software Engineering Lab