Software Engineering lab KHIT –R20

Software Engineering
Virtual Lab
www.vlabs.iitkgp.ac.in

II B.Tech, I Semester (KH- Regulations20)

Department of Computer Science and Engineering

KALLAM HARANADHREDDY INSTITUTE OF
TECHNOLOGY
Permanently Affiliated to JNTUK Kakinada, Accredited by NBA, Accredited by NAAC with A Grade
CHOWDAVARAM (POST), GUNTUR, ANDHRAPRADESH – 522 019.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 1

Software Engineering lab KHIT –R20

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 2

Software Engineering lab KHIT –R20

INDEX
Experiment Page
Experiments
Number Number

Experiment-1 Identifying the requirements from problem statements

Experiment-2 Estimation of Project Metrics

Experiment-3 Modeling UML Use Case Diagrams and Capturing Use Case Scenarios

Experiment-4 E-R Modeling from the Problem Statements

Experiment-5 Identifying Domain Classes from the Problem Statements

Experiment-6 State chart and Activity Modeling

Experiment-7 Modeling UML Class Diagrams and Sequence diagrams

Experiment-8 Modeling Data Flow Diagrams

Experiment-9 Estimation of Test Coverage Metrics and Structural Complexity

Experiment-10 Designing Test Suites

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 3

 Software Engineering lab KHIT –R20

1. Identifying the requirements from problem statements

Requirements identification is the first step of any software development project. Until the requirements of a client
have been clearly identified, and verified, no other task (design, coding, testing) could begin.
Usually business analysts having domain knowledge on the subject matter discuss with clients and decide what
features are to be implemented.
In this experiment we will learn how to identify functional and non-functional requirements from a given problem
statement. Functional and non-functional requirements are the primary components of a Software Requirements
Specification.

Objectives

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

Requirements

Somerville defines "requirement” 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 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 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:
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 4
 Software Engineering lab KHIT –R20
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.
For example, in a digital library a user might use the "Search Book" functionality to obtain information about the
books of his interest.

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 gets the book details and location as the
output.

Any high-level requirement identified could have different sub-requirements. For example, "Issue Book" module
could behave differently for different class of users, or for a particular user who has issued the book thrice
consecutively.
Preparing Software Requirements Specifications
Once all possible FRs and non-FRs have been identified, which are complete, consistent, and non-ambiguous, the
Software Requirements Specification (SRS) is to be prepared. IEEE provides a template also available here, which
could be used for this purpose.
The SRS is prepared by the service provider, and verified by its client. This document serves as a legal agreement
between the client and the service provider.
Once the concerned system has been developed and deployed, and a proposed feature was not found to be present
in the system, the client can point this out from the SRS.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 5
 Software Engineering lab KHIT –R20
Also, if after delivery, the client says a new feature is required, which was not mentioned in the SRS, the service
provider can again point to the SRS. The scope of the current experiment, however, doesn't cover writing a SRS.

Case Study

Identification of functional requirements

The above problem statement gives a brief description of the proposed system. From the above, even without doing any deep
analysis, we might easily identify some of the basic functionality of the system:

New user registration: Any member of the institute who wishes to avail the facilities of the library has to register himself with
the Library Information System. On successful registration, a user ID and password would be provided to the member. He has
to use this credential for any future transaction in LIS.
Search book: Any member of LIS can avail this facility to check whether any particular book is present in the institute's
library. A book could be searched by its:

Title

Author’s name
Publisher's name

User login: A registered user of LIS can login to the system by providing his employee ID and password as set by him while
registering. After successful login, "Home" page for the user is shown from where he can access the different functionalities
of LIS: search book, issue book, return book, reissue book. Any employee ID not registered with LIS cannot access the
"Home" page -- a login failure message would be shown to him, and the login dialog would appear again. This same thing
happens when any registered user types in his password wrong. However, if incorrect password has been provided for three
time consecutively, the security question for the user (specified while registering) with an input box to answer it are also
shown. If the user can answer the security question correctly, a new password would be sent to his email address. In case the
user fails to answer the security question correctly, his LIS account would be blocked. He needs to contact with the
administrator to make it active again.

Issue book: Any member of LIS can issue a book against his account provided that:
The book is available in the library i.e. could be found by searching for it in LIS
No other member has currently issued the book
Current user has not issued the maximum number of books that can
If the above conditions are met, the book is issued to the member.
Note that this FR would remain incomplete if the "maximum number of books that can be issued to a member" is not defined.
We assume that this number has been set to four for students and research scholars, and to ten for professors.
Once a book has been successfully issued, the user account is updated to reflect the same.
Return book: A book is issued for a finite time, which we assume to be a period of 20 days. That is, a book once issued
should be returned within the next 20 days by the corresponding member of LIS. After successful return of a book, the user
account is updated to reflect the same.

Reissue book: Any member who has issued a book might find that his requirement is not over by 20 days. In that case, he
might choose to reissue the book, and get the permission to keep it for another 20 days. However, a member can reissue any
book at most twice, after which he has to return it. Once a book has been successfully reissued, the user account is updated to
reflect the information.

In a similar way we can list other functionality offered by the system as well. However, certain features might not be evident
directly from the problem system, but which, nevertheless, are required. One such functionality is "User Verification". The
LIS should be able to judge between a registered and non-registered member. Most of the functionality would be available to
a registered member. The "New User Registration" would, however, be available to non-members. Moreover, an already
registered user shouldn't be allowed to register himself once again.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 6

 Software Engineering lab KHIT –R20
Having identified the (major) functional requirements, we assign an identifier to each of them [v] for future reference and
verification. Following table shows the list:

Table 01: Identifier and priority for software

requirements
# Requirement Priority
R1 New user registration High

R2 User Login High

R3 Search book High

R4 Issue book High

R5 Return book High

R6 Reissue book Low

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 LIS has to be developed as a web application, which should work with Firefox 5, Internet Explorer 8, Google Chrome 12,

Opera 10
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
Steps for conducting the experiment
General Instructions
Follow are the steps to be followed in general to perform the experiments in Software Engineering Virtual Lab.
Read the theory about the experiment
View the simulation provided for a chosen, related problem
Take the self-evaluation to judge your understanding (optional, but recommended)
Solve the given list of exercises
Experiment Specific Instructions
Following are the instructions specifically for this experiment:
From the given problem statement, try to figure out if there's any inconsistency with the requirement specification
Also, try to determine what are the functional and non-functional requirements are
Select the check boxes accordingly, and then click on the 'Submit' butto

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 7

Software Engineering lab KHIT –R20
Following books and websites have been consulted for this experiment.
You are suggested to go through them for further details.
Bibliography
Requirements Engineering: A Good Practice Guide, Ian Sommerville, Pete Sawyer, Wiley India Pvt Ltd, 2009
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
Webliography
Lecture on "System Analysis and Design", NPTEL
When Telepathy Won’t Do: Requirements Engineering Key Practices
Requirements Analysis: Process of requirements gathering and requirement definition
IEEE Recommended Practice for Software Requirements Specifications
Requirements Trace-ability and Use Cases

System Requirements: -
You need a modern web browser with JavaScript enabled to access the complete set of features of
Software Engineering Virtual Lab. In particular, this lab has been tested and found to work successfully
with
Firefox 3.6, 5.0
Google Chrome 13.0
Opera 11.0
Internet Explorer 7
Any higher version of the above mentioned four web browsers would also work fine. Moreover, any web
browser using modern versions of Gecko, Web Kit rendering engines should be able to display properly
and access all the features.

Note:- The above Requirements common to all Experiments

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 8

 Software Engineering lab KHIT –R20
Experiment – 2: Estimation of project metrics: -
Introduction
After gathering the entire requirements specific to software project usually we need to think about different
solution strategy for the project. Expert business analysts are analyzing their benefits and as well as their
shortcomings by means of cost, time and resources require to develop it.

In this experiment, we will learn how to estimate cost, effort and duration for a software project, and then select
one solution approach which will be found suitable to fulfill the organizational go

Objectives
After completing this experiment, you will be able to:

Categorize projects using COCOMO, and estimate effort and development time required for a project
Estimate the program complexity and effort required to recreate it using Halstead's metrics.

Project Estimation Techniques

A software project is not just about writing a few hundred lines of source code to achieve a particular objective.
The scope of a software project is comparatively quite large, and such a project could take several years to
complete. However, the phrase "quite large" could only give some (possibly vague) qualitative information. As in
any other science and engineering discipline, one would be interested to measure how complex a project is. One of
the major activities of the project planning phase, therefore, 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? A software may be just pieces of code, but one has to pay to
the managers, developers, and other project personnel.
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. 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, semidetached, and embedded systems are described below.

Organic: A development project is said to be of organic type, if

The project deals with developing a well understood application
The development team is small
The team members have prior experience in working with similar types of projects
Semidetached: A development project can be categorized as semidetached type, if
The team consists of some experienced as well as inexperienced staff
Team members may have some experience on the type of system to be developed
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 9
 Software Engineering lab KHIT –R20
Embedded: Embedded type of development project are those, which
Aims to develop a software strongly related to machine hardware
Team size is usually large
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

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)
The value of the constants a, b, c are given below:

Software project a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32

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) as shown in the table below [i].
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)

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 10

 Software Engineering lab KHIT –R20

Cost drivers for Intermediate COCOMO (Source: http://en.wikipedia.org/wiki/COCOMO)

Cost Drivers Ratings
Very Low Low Nominal High Very High Extra High
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance constraints 1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environment0.87 1.00 1.15 1.30
Required turnabout time 0.87 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project attributes
Application of software engineering methods1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10

EAF is used to refine the estimates obtained by basic COCOMO as follows:

Effort corrected = Effort * EAF
Tdev|corrected = 2.5 * (Effort| corrected) c

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.
(One might not even develop all the sub-systems -- just use the available services). The complete COCOMO model
takes these factors into account to provide a far more accurate estimate of project metrics.

To illustrate this, consider a very popular distributed application: the ticket booking system of the Indian Railways.
There are computerized ticket counters in most of the railway stations of our country. Tickets can be booked /
cancelled from any such counter. Reservations for future tickets, cancellation of reserved tickets could also be
performed. On a high level, the ticket booking system has three main components:

Database

Graphical User Interface (GUI)

Networking facilities
Among these, development of the GUI is considered as an organic project type; the database module could be
considered as a semi-detached software. The networking module can be considered as an embedded software. To
obtain a realistic cost, one should estimate the costs for each component separately, and then add it up.

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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 11
 Software Engineering lab KHIT –R20
is a difficult task, and any slight miscalculation could cause a large deviation in subsequent project estimates.
Moreover, COCOMO was proposed in 1981 keeping the waterfall model of project life cycle in mind [2]. It fails to
address other popular approaches like prototype, incremental, spiral, agile models. Moreover, in present day a
software project may not necessarily consist of coding of every bit of functionality. Rather, existing software
components are often used and glued together towards the development of a new software. COCOMO is not
suitable in such cases.

COCOMO II was proposed later in 2000 to many of address these issues.

Halstead's Complexity Metrics

Halstead took a linguistic approach to determine the complexity of a program. According to him, a computer
program consists of a collection of different operands and operators. The definition of operands and operators
could, however, vary from one person to another and one programming language to other. Operands are usually the
implementation variables or constants -- something upon which an operation could be performed. Operators are
those symbols that affects the value of operands. Halstead's metrics are computed based on the operators and
operands used in a computer program. Any given program has the following four parameters:

n1: Number of unique operators used in the program

n2: Number of unique operands used in the program
N1: Total number of operators used in the program
N2: Total number of operands used in the program
Using the above parameters one compute the following metrics:

Program Length: N = N1 + N2
Program Vocabulary: n = n1 + n2
Volume: V = N * lg n
Difficulty: D = (n1 * N2) / (2 * n2)
Effort: E = D * V
Time to Implement: T = E / 18 (in seconds)

The program volume V is the minimum number of bits needed to encode the program. It represents the size of the
program while taking into account the programming language.

The difficulty metric indicates how difficult a program is to write or understand.

Effort denotes the "mental effort" required to develop the software, or to recreate the same in another programming
language.

CASE STUDY

The SE VLabs Institute has a IT management team of it's own. This team has been given the task to execute the
Library Information System project. The team consists of a few experts from industry, and a batch of highly
qualified engineers experienced with design and implementation of information systems. It is planned that the
current project will be undertaken by a small team consisting of one expert and few engineers. Actual team
composition would be determined in a later stage.

Using COCOMO and based on the team size (small) and experience (high), the concerned project could be
categorized as "organic". The experts, based on their prior experience, suggested that the project size could roughly
be around 10 KLOC. This would serve as the basis for estimation of different project parameters using basic
COCOMO, as shown below:

Effort = a * (KLOC)b PM
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 12
 Software Engineering lab KHIT –R20
Tdev = 2.5 * (Effort)c Months
For organic category of project the values of a, b, c are 2.4, 1.05, 0.38 respectively. So, the projected effort required
for this project becomes

Effort = 2.4 * (10)1.05 PM

= 27 PM (approx)

Cost Drivers Ratings

very low low Normal High Very High Extra High
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance constraints1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environment0.87 1.00 1.15 1.30
Required turnabout time 0.87 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project attributes
Application of software engineering method1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10

The cells with yellow backgrounds highlight our choice of weight for each of the cost drivers. EAF is determined
by multiplying all the chosen weights. So, we get

EAF = 0.53 (approx)

Using this EAF value we refine our estimates from basic COCOMO as shown below

Effort|corrected = Effort * EAF

= 27 * 0.53
= 15 PM (approx)
Tdev|corrected = 2.5 * (Effort|corrected)c
= 2.5 * (15)0.38
= 7 months (approx)
After refining our estimates it seems that seven months would likely be sufficient for completion of this project.
This is still a rough estimate since we have not taken the underlying components of the software into consideration.
Complete COCOMO model considers such parameters to give a more realistic estimate.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 13

 Software Engineering lab KHIT –R20

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 14

 Software Engineering lab KHIT –R20
Experiment – 3:

Modeling UML Use Case Diagrams and Capturing Use Case Scenarios:-

Actor
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 behavioral 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.

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.
Actors can be classified as below
Primary actor: They are principal users of the system, who fulfill their goal by availing some service from the
system. For example, a customer uses an ATM to withdraw cash when he needs it. A customer is the primary actor
here.
Supporting actor: They render some kind of service to the system. "Bank representatives", who replenishes the
stock of cash, is such an example. It may be noted that replenishing stock of cash in an ATM is not the prime
functionality of an ATM.
In a use case diagram primary actor are usually drawn on the top left side of the diagram.
A use case is simply a functionality provided by a system.
Continuing with the example of the ATM, withdraw cash is a functionality that the ATM provides. Therefore, this
is a use case. Other possible use cases include, check balance, change PIN, and so on.

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 [iii] 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. However, one should be careful of external
systems interacting with the subject as actor

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.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 15

 Software Engineering lab KHIT –R20

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 is usually not shown. However, one can depict the class hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:
Include relationship
Extend relationship
Use case generalization
Include Relationship
Include relationships are used to depict common behavior 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. Such a function would be
called from different points within the program.
Example
For example, consider an email application. A user can send a new mail, reply to an email he has received, or forward an
email. However, in each of these three cases, the user must be logged in to perform those actions. Thus, we could have a login
use case, which is included by compose mail, reply, and forward email use cases. The relationship is shown in figure - 02.

Figure - 03: Extend relationship between use cases

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 16

 Software Engineering lab KHIT –R20

Notation
Extend relationship is depicted by a dashed arrow with a «extend» stereotype from the extending use case to the
extended use case.
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.
Example
To illustrate this, consider a graphical application that allows users to draw polygons. We could have a use case
draw polygon. Now, rectangle is a particular instance of polygon having four sides at right angles to each other. So,
the use case draw rectangle inherits the properties of the use case draw polygon and overrides it's drawing method.
This is an example of generalization relationship. Similarly, a generalization relationship exists between draw
rectangle and draw square use cases. The relationship has been illustrated in figure - 04.

Notation

Generalization relationship is depicted by a solid arrow from the specialized (derived) use case to the more
generalized (base) use case.
Identifying Actors
Given a problem statement, the actors could be identified by asking the following questions [2]:
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?
Any interface (interaction) between the concerned system and any other system?

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 17

 Software Engineering lab KHIT –R20

Identifying Use cases

Once the primary and secondary actors have been identified, we have to find out their goals i.e. what are the
functionality they can obtain from the system. Any use case name should start with a verb like, "Check balance".

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram [1]:
Determine the system boundary

Ensure that individual actors have well-defined purpose

Use cases identified should let some meaningful work done by the actors
Associate the actors and use cases -- there shouldn't be any actor or use case floating without any connection
Use include relationship to encapsulate common behavior among use cases , if any
Case Study

A Library Information System for SE Labs Institute

The SE Labs Institute has been recently setup to provide state-of-the-art research facilities in the field of Software
Engineering. Apart from research scholars (students) and professors, it also includes quite a large number of
employees who work on different projects undertaken by the institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to develop a Library
Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the members to
borrow a book (or return it) with ease while sitting at his desk/chamber.
The system also enables a member to extend the date of his borrowing if no other booking for that particular book
has been made.
For the library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into the system when a new
book has been purchased, or remove a record in case any book is taken off the shelf.
Any non-member is free to use this system to browse/search books online. However, issuing or returning books is
restricted to valid users (members) of LIS only.
The final deliverable would a web application (using the recent HTML 5), which should run only within the
institute LAN. Although this reduces security risk of the software to a large extent, care should be taken no
confidential information (eg., passwords) is stored in plain text.
From the given problem statement, we can identify a list of actors and use cases as shown in tables 1 & 2
respectively. We assign an identifier to each use case, which we would be using to map from the software
requirements identified earlier.

Table 1: List of actors

Actor Description
Member Can avail LIS facilities; could be student, professor, researcher

Non-member Need to register to avail LIS facilities

Librarian Update inventory and other administrative tasks

Library staff Handle day-to-day activities with the LIS

Table 1: List of actors

Actor Description
Member Can avail LIS facilities; could be student, professor, researcher

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 18

 Software Engineering lab KHIT –R20
Table 1: List of actors
Actor Description
Non-member Need to register to avail LIS facilities

Librarian Update inventory and other administrative tasks

Library staff Handle day-to-day activities with the LIS

Before presenting the details of individual use cases, let us do a mapping from requirements specifications to use cases. A list
of functional requirements can be found in the table 1. For each such requirements, we identify the use case(s) that helps to
achieve the requirement. This mapping is shown in table 3. Please note that we would be mapping only functional
requirements into use cases. A method to deal with non-functional requirements could be found in [vi]

Table 3: Mapping functional requirements

to use cases
FR # FR Description Use Case(s)
R1 New user registration UC1

R2 User login UC2

R3 Search book UC3

R4 Issue book UC4

R5 Return book UC5

R6 Reissue book UC6

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 19

 Software Engineering lab KHIT –R20

Now let us deal with the inner details of a few use cases and the actors with whom they are associated.
Table 4 shows the details of the "User login" use case using a template presented in table 1 in [v].
Table 4: UC2 -- User login

Table 4: UC2 -- User

login

Use Case UC2. User login

Allows a member to login to the system using his user

Description
ID and password

Assumptions

Actors  Member
1. User types in user ID
2. User types in password
Steps 3. User clicks on the 'Login' button
4. IF successful THEN show home page
ELSE display error
Variations

Non-functional

Issues

The above use case lets an already registered member of the LIS to login to the system and possible use it's various
features. If the user provides a correct pair of (<user_id>, <password>) then he can access his home page.
However, if login credentials are incorrect, an error message is displayed to him. Figure 1 shows its pictorial
representation.

Figure 1: Use case diagram showing "New user registration" use case
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 20
 Software Engineering lab KHIT –R20
The above figure also depicts extension of a use case. "Answer security question" is not a use case by itself, and is
not invoked in a "normal" flow. However, when a member is trying to login, and provides incorrect (<user_id>,
<password>) for three consecutive times, he is asked the security question that was set during registration. If user
can answer the question correctly, the password is send to his email address. However, if the user fails to answer
the security question correctly, his account is temporarily blocked. Details of the concerned use case extension are
shown in table 5.

Table 5: Extension for use case New user

registration
Use Case
Answer security question extends UC2. User login
Extension

Deals with the condition when a user has three consecutive

Description
login failures, and he attempts to login again

3a. IF consecutive failure count is 3 THEN invoke "Answer

Steps
security question"

The details of the “Issue book” use case are shown in table 6
Table 6: UC5 --
Issue book

Use Case UC5. Issue book

Allows a member to issue a specified book against his

Description
account

1. User is logged in
2. The book is available
Assumptions
3. User's account has not exceeded the limit
of maximum books that can be issued
 Member (primary)
Actors
 Library staff
1. User logs in
2. User searches for a book
3. User clicks on "Issue" button to issue the
Steps
book
4. User's account is updated
5. Library staff delivers the book
Variations

Non-functional

Issues

In order to issue a book, the availability of the book has to be checked. Also, the system needs to verify whether
another book could be issued to the current user. These are shown in figure 2 by the «include» relationship among
the use cases. The maximum # of books that can be issued to a user depends on whether he is a student or a
professor. So, "Verify issue count" is a general use case, which has been specialized by "Verify student issue
count" and "Verify professor issue count" use cases. These have been represented by the "generalization"
relationship in figure 2.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 21

Software Engineering lab KHIT –R20

Figure 2: Use case diagram showing "Issue book" use case

In the above scenario "Member" is the primary actor who triggers the "Issue book" use case. "Library staff" is a
secondary actor here.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 22

 Software Engineering lab KHIT –R20

Experiment – 4:- E-R Modeling from the Problem Statements

After completing this experiment, you will be able to:

Identify entity sets, their attributes, and various relationships

Represent the data model through ER diagram

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

As another example, consider a system where some job runs every night, which updates the database. Here,
job and database could be two entities. They are associated with the relationship "Updates".

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. At any given time a student can study only at one school.
In the school he would have a roll number, and of course a grade in which he studies. 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.
For example, a school can have any number of students. However, if we know grade and roll number, then we can
uniquely identify a student in that school.
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. A weak entity can't be uniquely identified

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 23

 Software Engineering lab KHIT –R20
only by it's attributes. In other words, it doesn't have a super key.

For example, consider a company that allows employees to have travel allowance for their immediate family. So,
here we have two entity sets: employee and family, related by "Can claim for". However, family doesn't have a
super key. Existence of a family is entirely dependent on the concerned employee. So, it is meaningful only with
reference to employee.

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.

Graphical Notations for ER Diagram

Entity set Name of the set is written inside the rectangle

Attribute Name of the attribute is written inside the ellipse

Importance of ER modeling

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

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,
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 24
 Software Engineering lab KHIT –R20
these tables are normalized in order to remove 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.

Case Study

A robust database backend is essential for a high-quality information system. Database schema should be
efficiently modeled, refined, and normalized. In this section we would develop a simple ER model for the Library
Information System.

The first step towards ER modeling is to identify the set of relevant entities from the given problem statement. The
two primary, and obvious, entity sets in this context are "Member" and "Book". The entity set "Member" represents
all students, professors, or employees who have registered themselves with the LIS. While registering with the LIS
one has to furnish a lot of personal and professional information. This typically includes name (well, that is trivial),
employee ID (roll # for students), email address, phone #, age, date of joining in this institute. The system may
store some not-so-important information as well like, blood group, marital status, and so on. All these pieces of
information that an user has to provide are sufficient to describe a particular member. These characteristics are the
attributes of the entities belonging to the entity set "Member".

It is essential for an entity to have one or more attributes that help us to distinguish it from another entity. 'Name'
can't help that -- two persons could have exactly the same name. However, ('Name', 'Phone #') combination seems
to be okay. No two persons can have the same phone number. 'Employee ID', 'Email address' are other potential
candidates. Here, 'Employee ID', 'Email address' and ('Name', 'Phone #') are super keys. We choose 'Employee ID'
to uniquely identify an user in our implementation. So, 'Employee ID' becomes our primary key (PK) for the
"Member" entity set. Figure 1 represents this set along with it's attributes and the primary key.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 25

 Software Engineering lab KHIT –R20

Let us now focus on the "Book" entity set. Typical attributes of a book are it's title, name of author(s), publisher,
date of publication, edition, language, ISBN-10, ISBN-13, price (of course!), date of purchase. The set of listed
attributes for a book doesn't give a straight forward choice of primary key. For instance, several books could have
the same title. Again, ISBN numbers for a book are specific to it's edition -- it can't distinguish between two books
of the same edition. One might be tempted to use a combination of ('Title', 'Authors') as a primary key.

This has some shortcomings. It is advisable not to use texts as a PK. Moreover, the number of authors that a book
could have is not fixed, although it is a small, finite number. The rules of normalization (not covered here) would
dictate to have a separate field for each author like 'Author1', 'Author2', and so on. Therefore, we assign an extra
attribute, 'ID', to each book as it's PK. Different databases available in the market provide mechanisms to generate
such an unique ID, and automatically increment it whenever a new new entity is added. In fact, we could assign
such an ID to the "Member" entity set as well. However, because of availability of the unique 'Employee ID' field,
we skipped that. A graphical representation of the "Book" entity set is shown in figure 2.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 26

 Software Engineering lab KHIT –R20

One point to note here is that a book is likely to have multiple copies in the library. Therefore, one might wish to
have a '# of copies' attribute for the "Book" entity set. However, that won't allow us to differentiate among the
different copies of book bearing same title by same author(s), edition, and publisher. The approach that we have
taken is to uniquely identify each book even though they are copies of the same title.

To buy any new book an order is to be placed to the distributor. This task is done by the librarian. Therefore,
"Librarian" and "Distributor" are two other entities playing roles in this system.

Having identified the key entities, we could now relate them with each other. Let us consider the entity sets
"Member" and "Book". A member can issue books. In fact, he can issue multiple books up to a finite number say,
N. A particular book, however, could be issued by a single member only. Therefore, we have a one-to-many
mapping from "Member" to "Book" entity sets. This relationship between "Member" and "Book" entity sets is
pictorially depicted in figure 3.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 27

 Software Engineering lab KHIT –R20

Figure 3 also shows that the librarian can "place order" for books to the distributor. This is a many-to-many
mapping since a librarian can purchase books from multiple distributors. Also, if the institute has more than one
librarians (or any other staff having such authority), then each of them could place order to the same distributor. An
order is termed as complete when distributor supplies the book(s) and invoice

The design in figure 3 has a flaw. Librarian himself could be a member of the LIS. However, he is a "special" kind
of member since he can place order for books. Our ER diagram doesn't reflect this scenario. Such special roles of
an entity set could be represented using "ISA" relationship, which is not discussed here.
Any kind of designing couldn't be possibly done at one go. Therefore, the baseline ER model so prepared should be
revised by considering the business model yet again to ensure that all necessary information could be captured.
Once this has been finalized, the next logical step would be to create table structures for each identified entity set
(and relationships in some cases) and normalize the relations.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 28

 Software Engineering lab KHIT –R20

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 29

 Software Engineering lab KHIT –R20
Experiment – 5: Identifying Domain Classes from the Problem Statements
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.

Objectives
After completing this experiment you will be able to:

Understand the concept of domain classes

Identify a list of potential domain 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
[iv]. As stated in [v], 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 [1]. 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.
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 (details given later). 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

This is one of the simplest approaches that could be easily understood and applied by a larger section of the user
base. The problem statement does not necessarily be in English, but in any other language.

Disadvantages

The problem statement always may not help towards correct identification of a class. At times it could give us
redundant classes. At times 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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 30
 Software Engineering lab KHIT –R20
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 [i].

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 (table 5-3, pg
88, [1]

Categories Explanation
People Humans who carry out some function
Places Areas set aside for people or things
Things Physical objects
Organizations Collection of people, resources, facilities and capabilities having a defined mission
Concepts Principles or Ideas not tangible
Events Things that happen (usually at a given date and time), or as a steps 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

Case Study

From the given problem statement, we can identify the following nouns and noun phrases:
 The SE VLabs Institute
 Software Engineering
 Research scholars
 Students
 Professors
 Employees
 Projects

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 31

 Software Engineering lab KHIT –R20
 Institution
 Library Information System
 Members
 Book
 Desk
 Chamber
 System
 Library staff
 Librarian
 Transactions
 Record
 Shelf
 Non-member
 Web application
 LAN
 Software
 Information
 Passwords
Let us put the above into different categories.

People
 Research scholars
 Students
 Professors
 Employees
 Members
 Library staff
 Librarian
 Non-member
Places
 Chamber
Things
 Projects
 Book
 Desk
 System
 Shelf
 LAN
Organizations
 The SE Labs Institute
 Institution
Concepts
 Software Engineering
 Library Information System
 Record
 Web application
The nouns and noun phrases in the problem statement gives us a list of 25 potential classes. However, all of them may not be
relevant. For example, 'Chamber' is not something related to the Library Information System. And so are 'Projects', 'Desk',
'Shelf'. In a similar way, 'Software Engineering', 'Web application', 'Software' doesn't seem to be potential classes in this
context. If we filter these entries, we might find that the follwong set of classes directly relate to the business activities of LIS:
Member
Book
Transaction (of books)
Librarian
Employee
Although not explicitly mentioned in the problem statement, based on knowledge in related area one may point out few other
potential classes:
Book Inventory
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 32
 Software Engineering lab KHIT –R20
Distributor
Order
Order Line Item
Payment
Invoice
Among the classes listed above, 'Member', 'Librarian', 'Employee' share some common characteristics. For instance, everyone
has a name, each has got an unique ID in the institution. In fact, 'Librarian' and 'Member' are some specialized category of the
class 'Employee'. (This considers a student is also an "employee".) The above identified conceptual classes pave the way for
modeling of design and implementation classes.

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 33

Software Engineering lab KHIT –R20
Experiment – 6: State chart and Activity Modeling

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 behavior of an information system.
In this experiment, we will learn about the different components of activity diagram and state chart diagram and how these
can be used to represent the dynamic nature of an information system.

Objectives
After completing this experiment, you will be able to:
Identify the distinct states a system have
Identify the events causing transitions from one state to another
Represent the above information pictorially using simple states
Identify activities representing basic units of work, and represent their flow

State chart Diagrams

In case of Object-Oriented Analysis and Design, a system is often abstracted by one or more classes with some well-
defined behavior and states. A state chart 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.

State chart diagrams are normally drawn to model the behavior of a complex system. For simple systems this is optional.

Building Blocks of a State chart 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 remains when created

Final: The state from which an object do not move to any other state [optional]
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.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 34

 Software Engineering lab KHIT –R20

Figure-01: Representation of initial, intermediate, and final states of a state chart diagram

Intermediate states usually have two compartments, separated by a horizontal line, called the name compartment
and internal transitions compartment [iv]. 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
The internal activities are indicated using the following syntax: action-label / action-expression. 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 identifies the event (internal transition) as a result of which the corresponding action is
triggered. Internal transition is almost similar to self-transition, except that the former doesn't result in execution of
entry and exit actions. That is, system doesn't exit or re-enter that state. Figure-02 shows the syntax for representing
a typical (intermediate) state.

Figure-02: A typical state in a state chart diagram

States could again be either simple or composite (a state congaing other states). Here, however, we will deal only
with simple states.

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 labeled by: event [guard-
condition]/[action-expression], where

Event is the what is causing the concerned transition (mandatory) -- Written in past tense
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]
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. For example, if
a queue is full, any further attempt to append will fail until the delete method is invoked at least once. Thus, state of
the queue doesn't change in this duration.

Action
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 35
 Software Engineering lab KHIT –R20
As mentioned in [ii], actions represent behavior of the system. While the system is performing any action for the
current event, it doesn't accept or process any new event. The order in which different actions are executed, is given below:

Exit actions of the present state

Actions specified for the transition
Entry actions of the next state

Figure-03 shows a typical state chart diagram with all it's syntaxes.

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

Activity diagrams, however, cannot depict the message passing among related objects. As such, it can't be directly translated
into code. These kind of diagrams are suitable for confirming the logic to be implemented with the business users. These
diagrams are typically used when the business logic is complex. In simple scenarios it can be avoided entirely [ix].

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. This could simply be invocation of a mathematical
function, alter an object's properties and so on [x]. 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 (table-01). Initial node represents the starting point of a flow in an activity diagram. There could be
multiple initial nodes, which means that invoking that particular activity diagram would initiate multiple flows.

A final node represents the end point of all activities. Like an initial node, there could be multiple final nodes. Any transition
reaching a final node would stop all activities.

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, or to other types of components, as we will see below. A flow is often accompanied with a label,
called the guard condition, indicating the necessary condition for the transition to happen. The syntax to depict it is [guard
condition].

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. However, they can be omitted in obvious cases. The input edge could also have guard conditions.
Alternately, a note can be attached to the decision node indicating the condition to be tested.

Merge

This is represented with a diamond shape, with two or more flows entering, and a single flow leaving out. A merge node
represents the point where at least a single control should reach before further processing could continue.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 36
 Software Engineering lab KHIT –R20

Fork
Fork is a point where parallel activities begin. For example, when a student has been registered with a college, he can in
parallel apply for student ID card and library card. 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. Unlike a merge, in case of a join all of the incoming controls must be completed
before any further progress could be made. For example, a sales order is closed only when the customer has receive the
product, and the sales company has received it's payment.

Note
UML allows attaching a note to different components of a diagram to present some textual information. The information
could simply be a comment or may be some constraint. A note can be attached to a decision point, for example, to indicate
the branching criteria.

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 drawing area can be partitioned into
multiple compartments using vertical (or horizontal) parallel lines. Partitions in an activity diagram are not mandatory.

The following table shows commonly used components with a typical activity diagram.

Initial node is a control node at which flow starts when the activity is invoked.
A control token is placed at the initial node when the activity starts, but not in initial nodes in structured nodes
contained by the activity. Tokens in an initial node are offered to all outgoing edges. For convenience, initial nodes
are an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream, for
example, by guards.
Activities may have more than one initial node. In this case, invoking the activity starts multiple flows, one at each
initial node.
Note that flows can also start at other nodes, so initial nodes are not required for an activity to start execution.
Initial nodes are shown as a small solid circle.

Flow final node is a control final node that terminates a flow. It destroys all tokens that arrive at it but has no effect
on other flows in the activity. Flow final was introduced in UML 2.0.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 37
 Software Engineering lab KHIT –R20
The notation for flow final node is small circle with X inside.

Flow final node.

Activity final node is a control final node that stops all flows in an activity. Activity final was introduced in UML
2.0.
An activity may have more than one activity final node. The first one reached stops all flows in the activity. A
token reaching an activity final node terminates the activity. In particular, it stops all executing actions in the
activity, and destroys all tokens in object nodes, except in the output activity parameter nodes. Terminating the
execution of synchronous invocation actions also terminates whatever behaviors they are waiting on for return.
Any behaviors invoked asynchronously by the activity are not affected. If it is not desired to abort all flows in the
activity, use flow final instead.

Activity final nodes are shown as a solid circle with a hollow circle inside. It can be thought of as a goal notated as
"bull’s eye," or target.

Activity final node.

Decision node is a control node that accepts tokens on one or two incoming edges and selects one outgoing
edge from one or more outgoing flows. Decision nodes were introduced in UML to support conditionals in
activities.
The edges coming into and out of a decision node, other than the decision input flow (if any), must be either
all object flows or all control flows.

Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each token
offered by the incoming edge is offered to the outgoing edges.
Which of the edges is actually traversed depends on the evaluation of the guards on the outgoing edges. The order
in which guards are evaluated is not defined, i.e. we should not rely on any visual or text description order.
The notation for a decision node is a diamond-shaped symbol.

Decision node with two outgoing edges with guards.

The modeler should arrange that each token only be chosen to traverse one outgoing edge. For decision points, a
predefined guard "else" may be define
The modeler should arrange that each token only be chosen to traverse one outgoing edge. For decision points, a
predefined guard "else" may be defined for at most one outgoing edge.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 38

 Software Engineering lab KHIT –R20

Decision node with three outgoing edges and [else] guard.

Decision can have decision input behavior specified. Decision input behaviors were introduced in UML to avoid
redundant recalculations in guards.
In this case each data token is passed to the behavior before guards are evaluated on the outgoing edges. The
behavior is invoked without input for control tokens. The output of the behavior is available to each guard. Because
the behavior is used during the process of offering tokens to outgoing edges, it may be run many times on the same
token before the token is accepted by those edges. This means the behavior cannot have side effects.

Decision input behavior is specified by the keyword «decision Input» and some decision behavior or condition
placed in a note symbol, and attached to the appropriate decision node.

Decision node with decision input behavior.

Decision may also have decision input flow. In this case the tokens offered on the decision input flow that are made
available to the guard on each outgoing edge determine whether the offer on the regular incoming edge is passed
along that outgoing edge.
A decision input flow is specified by the keyword «decisionInputFlow» annotating that flow.

Decision node with decision input flow.

If there are both a decision input behavior as well as decision input flow, the token offered on the decision input
flow is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second
argument if it is an object flow). Decision nodes with the additional decision input flow offer tokens to outgoing
edges only when one token is offered on each incoming edge.

Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing
flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows.
For example, if a decision is used after a fork, the two flows coming out of the decision need to be merged into one
before going to a join; otherwise, the join will wait for both flows, only one of which will arrive.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 39
 Software Engineering lab KHIT –R20
The notation for a merge node is a diamond-shaped symbol with two or more edges entering it and a single activity
edge leaving it.

Merge node with three incoming edges and a single outgoing edge
The functionality of merge node and decision node can be combined by using the same node symbol, as
illustrated below. This case maps to a model containing a merge node with all the incoming edges shown in the
diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the diagram.

Merge node and decision node combined using the same symbol
Fork node is a control node that has one incoming edge and multiple outgoing edges and is used to split incoming
flow into multiple concurrent flows. Fork nodes are introduced to support parallelism in activities. As compared
to UML 1.5, UML 2.0 activity forks model unrestricted parallelism.
Tokens arriving at a fork are duplicated across the outgoing edges. If at least one outgoing edge accepts the token,
duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that
did not accept the token due to failure of their targets to accept it, keep their copy in an implicit FIFO queue until it
can be accepted by the target. The rest of the outgoing edges do not receive a token.
The notation for a fork node is a line segment with a single activity edge entering it, and two or more edges leaving
it.

Fork node with a single activity edge entering it, and three edges leaving it.
The functionality of join node and fork node can be combined by using the same node symbol. This case maps to a
model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork
node that has all the outgoing edges shown in the diagram.

Combined join node and fork node.

If guards are used on edges outgoing from forks, the modelers should ensure that no downstream joins depend on
the arrival of tokens passing through the guarded edge. If that cannot be avoided, then a decision node should be
introduced to have the guard, and shunt the token to the downstream join if the guard fails.

Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize
incoming concurrent flows. Join nodes are introduced to support parallelism in activities.
The notation for a join node is a line segment with several activity edges entering it, and only one edge leaving it.

Join node with three activity edges entering it, and a single edge leaving it.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 40
 Software Engineering lab KHIT –R20
The functionality of join node and fork node can be combined by using the same node symbol. This case maps to a
model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork
node that has all the outgoing edges shown in the diagram.

Combined join node and fork node.

Join nodes have a join specification which is Boolean value specification using the names of the incoming
edges to specify the conditions under which the join will emit a token.

The join specification is evaluated whenever a new token is offered on any incoming edge. The evaluation is not
interrupted by any new tokens offered during the evaluation, nor are concurrent evaluations started when new
tokens are offered during an evaluation.
The default join specification is the reserved string "and". It is equivalent to a specification that requires at least
one token offered on each incoming edge.
Join specifications are shown in curly braces near the join node as joinSpec=....

Join node with join specification shown in curly braces.

Case Study
From the given problem we can identify at least four different functionality offered by the system:

Register a new member

Issue book
Reissue book
Update inventory
To begin with, let's consider the activity diagram for user registration, as shown in figure - 01.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 41

 Software Engineering lab KHIT –R20

Figure-01: Activity diagram for new user registration

A new user fills up the registration form for library membership (either online or in paper), and submits to the
librarian. Of course, an already registered user can't create another account for himself (or, herself). For users' who
don't have an account already and have submitted their registration forms, the librarian verifies the information
provided, possibly against the central database used by the institution. If all information have been provided
correctly, librarian goes on with creating a new account for the user. Otherwise, the user is asked to provide all and
correct information in his (her) registration form. Once a new account has been created for the user, he (she) is
being issued an ID card, which is to be provided for any future transaction in the library.

Note that in the above diagram two swim lanes haven been shown indicated by the labels User and Librarian. The
activities have been placed in swim lanes that correspond to the relevant role.

One of the major events that occur in any library is issue of books to it's members. Figure-02 tries to depict the
workflow involved while issuing books.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 42

 Software Engineering lab KHIT –R20

Figure-02: Activity diagram for issuing books

Now let's focus on figure-03, which shows the typical workflow of inventory update by the librarian. Note that
since these are the tasks performed only by the librarian (and no one else plays a role), we skip the swim lanes.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 43

 Software Engineering lab KHIT –R20

Figure-03: Activity diagram for updating inventory

Addition of new books and removing records of books taken off from the shelves could be done parallelly. This
means, one doesn't have to complete the task of addition of all new books before doing any removal. Merging of
these two activities and the subsequent Update inventory activity indicates that it is not required to complete all
addition and removals before proceeding to update the database. That is, a few books could be added, then update
the database, then again continue with the tasks.

Finally, the workflow terminates when all addition and removal tasks have been completed.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 44

Software Engineering lab KHIT –R20

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 45

 Software Engineering lab KHIT –R20
Experiment – 7: Modeling UML Class Diagrams and Sequence diagrams
Introduction
Classes are the structural units in object-oriented system design approach, so it is essential to know all the
relationships that exist between the classes, in a system. 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.

In this Experiment, we will learn about the representation of class diagram and sequence diagram. We also learn
about different relationships that exist among the classes, in a system.

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.

Objectives
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 Behavioral aspects

Developing a software system in object-oriented approach is very much dependent on understanding the problem.
Some aspects and the respective models are used to describe problems and in context of those aspects the
respective models give a clear idea regarding the problem to a designer. For developer, structural and behavioral
aspects are two key aspects to see through a problem to design a solution for the same.

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
A class is uniquely identified in a system by its name. A textual string [2]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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 46
 Software Engineering lab KHIT –R20
attributes ‘course Name’ & ‘coursed’ with the operations ‘add Course()’ & ‘remove Course()’ allowed to be
performed for any object to that class.

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

Example

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[i] that allows exchanging messages among the objects of both ends of association. A simple
straight line connecting two class boxes represent an association. We can give a name to association and also at the both end
we may indicate role names and multiplicity of the adjacent classes. 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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 47
 Software Engineering lab KHIT –R20
the respective classes.

Aggregation

It is a special form of association which describes a part-whole[i] relationship between a pair of classes. It means,
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

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

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 exist any branch of it will no longer exists in the city. This
relation can be described as composition and can be shown as below

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:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 48

 Software Engineering lab KHIT –R20

Example

One vehicle may have two or more wheels

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

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 :

Case Study
Let us consider the "Issue Book" use case and represent the involved steps in a sequence diagram as shown in
figure 1. We assume that the book to be issued is available. An user makes a request to issue a book against his
account. This is shown by the "issue Book(booked)" call from "Member" to "Issue Manager" objects.

At this point the system checks whether that particular user can issue another book (based on the maximum
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 49
 Software Engineering lab KHIT –R20
number of books that he can issue) by invoking the "can Issue()" method on the "Member". As a result of this call,
a response ("status") is sent back to the "Issue Manager" class. If the "status" is "true" (as indicated in the note),
status of the concerned book is set to "issued". A new transaction is saved corresponding to the current issue of
book by the user. Finally, a success message is sent back to "Member" indicating that the book was successfully
issued.

Few points could be noted here. Notes can be used almost anywhere within an UML diagram for whatever purpose.
In figure 1 we use a note to specify the condition when status of a book is set to 'issued'. UML 1.0 had used guard
conditions to specify such kind of Boolean logic. UML 2.0 provide components to specify the alternate scenarios
within a sequence diagram (not discussed here). One can definitely make use of these components. However, if the
number of IF-THEN-ELSE conditions in a sequence diagram becomes high, the diagram gets complicated. In such
cases one can draw multiple sequence diagrams for alternate conditions.
One key component in figure 1 is the "Issue Manager" class. This class doesn't represent the actual Library
Information System (LIS). Rather, this is a part of LIS -- a specific module to handle issuing of books to the
members.
Also, note that the life cycle of the "Transactions" has been shown as self-destroyed. To understand this, consider
how a transaction is actually implemented in code. One creates an object from "Transactions" class, fills it up with
all necessary information, and then saves the transaction. Thereafter, the transaction object is not required to be in
memory.
Figure 2 shows the order of steps involved in the process of purchasing of a new book. In this case also, "Purchase
Manager" is a part of LIS, which manages all books that are being purchased. The activation bars indicate the
different instances when a particular object is active in their corresponding life cycles.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 50

 Software Engineering lab KHIT –R20

One may have doubts over the inclusion of "Distributor" class. "Distributor" is not a constituent of the LIS;
however, it interacts with LIS. Here "Distributor" is meant to represent the "interface" between LIS and the actual,
physical book sellers and distributors. For instance, LIS can store details of distributor XYZ, including it's email
address, bank account number, into it's records. Whenever the librarian places a new order to XYZ, the order is
being sent electronically to XYZ, processed (possibly with a delay), a corresponding invoice is generated, and sent
back to LIS. "place Order (orderID)" has been indicated as asynchronous calls since the calling object can continue
with other tasks. The books would be dispatched by XYZ physically, which lies outside the boundary of LIS. Once
the ordered books have been received, the librarian opts to make payment for his orders, which, too, could happen
electronically through Net Banking. Technology has, indeed, made a huge progress!
Finally, at his leisure time, the librarian might consider updating the inventory according to the corresponding
order.

Classes are the fundamental components of any object-oriented design and development. Unless individual class,
it's attributes and associated operations have been modeled well, a lot of suffering could await during the
development phase. However, unlike waterfall model, the life cycle in object oriented development is iterative.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 51

 Software Engineering lab KHIT –R20
One builds a model, analyze it's efficiency, and refines it thereafter, if required. Therefore, an analyst, designer, or
developer doesn't have the tight constraints to create a perfect art at one go.
Based on conceptual modeling and domain knowledge we already had identified a list of classes. We present them
here once again
 Member
 Book
 Transaction (of books)
 Librarian
 Employee
 Book Inventory
 Distributor
 Order
 Order Line Item
 Payment
 Invoice
Let's focus on the "Member", "Librarian" and "Employee" classes. The "Employee" class could be considered as a
parent class, some of whose properties are inherited by the "Member" class. Again, "Librarian" is just a special
type of "Member" with certain extra privileges. However, it may be noted here that LIS in no way would be
interested to know about employees who are not members of LIS. Moreover, to distinguish between a normal
member and a librarian, one could define a set of roles, and assign them appropriately to the members.

This approach provides a flexible approach to manage users. For example, if the librarian goes on a leave, another
member could be assigned the librarian role temporarily. Therefore, we decide to have a single "Member" class,
whose instances could have one or more roles. This is shown in figure 3 with the "association" relationship
between "Member" and "Role" classes. The "Role" class could consist of a list of available roles. A list could be
maintained in the "Member" class to indicate which roles are associated with a particular instance of it.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 52

 Software Engineering lab KHIT –R20

The "LIS" class consists of several modules: "Registration Manager", "Issue Manager" "Return Manager", and
"Purchase Manager". Their "composition" relationship with "LIS" indicates that any of these individual modules
wouldn't exist without the existence of "LIS". The "Issue Manager" class is responsible for issue and reissue of
books while considering the two-times reissue constraint placed on a book.
The relation between "Issue Manager" class and "Book" class is shown as "weak dependency". This is due to the
reason that the "Issue Manager" class do not require a "Book" as it's member variable. Rather, when an user has
issued a book, the concerned method in "Issue Manager" just needs to update the status of the corresponding book.
No instance of "Book" needs to be created. The arrow from "Issue Manager" to "Book" indicates that only the
former knows about the "Book" class. The relationship between "Purchase Manager" and "Distributor" is, however,
not a weak dependency. The "Purchase Manager" class has a member variable of type "Distributor", which keeps
track of the distributor selected for the current purchase.
With the classes so identified, the code for issue book could look as follows:
public ID IssueBook(ID userID, ID bookID) {
Member user = Member.GetMember(userID);
ID transactionID = null;
if ( user.canIssueNow() && Book.IsAvailable(bookID) ) {
Book.SetStatusIssued(bookID);
user.incrementIssueCount(bookID);
BookTransaction transaction = new Book Transaction(userID, bookID);
transaction.save();
transactionID = transaction.getID();
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 53
 Software Engineering lab KHIT –R20
}
return transactionID;
}
The code for reissuing a book to an user could look like the following.
public ID ReissueBook(ID userID, ID bookID) {
Member user = Member.GetMember(userID);
ID transactionID = null;
if ( user.canIssueNow() && Book.IsAvailable(bookID) ) {
Integer count = user.getReissueCountFor(bookID); // # of times this books has been reissued after it's recent
issue by the user
if ( count < REISSUE_LIMIT ) {
user.incrementReissueCount(bookID);
BookTransaction transaction = new BookTransaction(userID, bookID);
transaction.save();
transactionID = transaction.getID();
}
}
return transactionID;
}
_

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 54

Software Engineering lab KHIT –R20
Experiment – 8: Modeling Data Flow Diagrams
Introduction
Information Systems (IS) help in managing and updating the vast business-related information. Before designing such
an IS, it is helpful to identify the various stakeholders, and the information that they would be exchanging with the
system. An IS, however, is a large software comprised of several modules, which, in turn, share the process the available
data. These data are often stored in databases for further references. A Data Flow Diagram (DFD) is used to pictorially
represent the functionalities of the ISs by focusing on the sources and destinations of the data flowing in the system.

Objectives
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

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
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 [i]. 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 [2] .
External entity: External entities are only appear in context diagram[2]. External entities are represented by a rectangle and the
name of the external entity is written into the shape. These send data to be processed and again receive the processed data.

Data store: Data stares are represented by a left-right open rectangle. 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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 55
 Software Engineering lab KHIT –R20
process is split into in the next level[2]. This is known as balancing a DFD.

See simulation[ and case study of the experiment to understand data flow diagram in more real context.
Note :

External entities only appear in context diagram i.e, only at level 0.

Keep number of processes at each level less than
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
Term Notation Remarks

ternal
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 the data store is written
re
inside the shape

ta flow Data flow is represented by a directed arc wi

Case Study

Figure 1 shows the context-level DFD for LIS. The entire system is represented with a single circle (process). The
external entities interacting with this system are members of LIS, library staff, librarian, and non-members of LIS.
Two database are used to keep track of member information and details of books in the library.

Let us focus on the external entity, Member. In order to issue or return books a member has to login to the system.
The data flow labeled with “Login credentials” indicates the step when a member authenticates himself by
providing required information (user ID, password). The system in turn verifies the user credentials using
information stored in the members database. If all information are not provided correctly, the user is shown a login
failure message. Otherwise, the user can continue with his operation. Note that a DFD does not show conditional
flows. It can only summarize the information flowing in and out of the system.

The data flow with the label “Requested book details” identifies the information that the user has to provide in
order to issue a book. LIS checks with the books database whether the given book is available. After a book has
been issued, the transaction details are provided to the member.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 56

Software Engineering lab KHIT –R20

Figure 1: Context-level DFD for Library Information System

The level-1 DFD is shown in figure 2. Here, we split the top-level view of the system into multiple logical
components. Each process has a name, and a dotted-decimal number in the form 1.x. For example, the process
"Issue book" has the number 1.2, which indicates that in the level 1 DFD the concerned process is numbered 2.
Other processes are numbered in a similar way.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 57

 Software Engineering lab KHIT –R20

Figure 2: Level 1 DFD for Library Information System

Comparing figures 1 and 2 one might observe that the information flow in and out of LIS has been preserved. We
observe in figure 2 that the sub-processes themselves exchange information among themselves. These information
flows would be, in turn, preserved if we decompose the system into a level 2 DFD.
Finally, in order to eliminate intersecting lines and make the DFD complex, the Member external entity has been
duplicated in figure 2. This is indicated by a * mark near the right-bottom corner of the entity box.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 58

Software Engineering lab KHIT –R20

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 59

Software Engineering lab KHIT –R20
Experiment – 9: Estimation of Test Coverage Metrics and Complexity

Introduction
A visual representation of flow of control within a program may help the developer to perform static analysis of his
code. One could break down his program into multiple basic blocks, and connect them with directed edges to draw a
Control Flow Graph (CFG). A CFG of a program helps in identifying how complex a program is. It also helps to
estimate the maximum number of test cases one might require to test the code.

In this experiment, we will learn about basic blocks and how to draw a CFG using them. We would look into paths and
linearly independent paths in context of a CFG. Finally, we would learn about McCabe's cyclomatic complexity, and
classify a given program based on that.

Objectives 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

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

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.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 60

Software Engineering lab KHIT –R20

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 thousand 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
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) {
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

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 61

Software Engineering lab KHIT –R20

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;
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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 62
Software Engineering lab KHIT –R20
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 it's execution. Therefore, path-coverage testing of a program would suffice by considering only
the linearly independent paths.
In figure 3 we can find four linearly independent paths:

1 - 3 - 6 - (7, 8) - 10
1 - 3 - 6 - (7, 8) - 9 - 10
1 - 3 - (4, 5) - 6 - (7, 8) - 10
1 - 3 - (4, 5) - 6 - (7, 8) - 9 - 10
Note that 1 - 3 - (4, 5) - 3 - (4, 5) - 6 - (7, 8) - 10, for instance, won't qualify as a linearly independent path because there
is no new edge not already present in any of the above four linearly independent paths.
McCabe's Cyclomatic Complexity
McCabe had applied graph-theoretic analysis to determine the complexity of a program module [vi]. 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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 63
Software Engineering lab KHIT –R20
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.

Computing Cyclomatic Complexity

Let G be a 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:

Method #1:
V(G) = E - N + 2
Method #2: V(G) could be directly computed by a visual inspection of the CFG:
V(G) = Total number of bounded areas + 1
It may be noted here that structured programming would always lead to a planar CFG.
Method #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 [viii]. Also, the value of V(G)
so 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 [ix]. Once the complexities of individual modules of a program are known,
complexity of the program (or class) could be determined by [4], [ix]:
V(G) = SUM( V(Gi) ) - COUNT( V(Gi) ) + 1
where COUNT( V(Gi) ) gives the total number of procedures (methods) in the program (class).

Optimum Value of Cyclomatic Complexity

A set of threshold values for Cyclomatic complexity has been presented in [vii], 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 [vi], [4]. 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 [vi].

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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 64
Software Engineering lab KHIT –R20
Demerits
Cyclomatic complexity doesn't reflect on cohesion and coupling of modules.

McCabe's Cyclomatic complexity was originally proposed for procedural languages. One may look in [xi] to get an idea
of how the complexity calculation could be modified for object-oriented languages. In fact, one may also wish to make
use of Chidamber-Kemerer metrics [x] (or any other similar metric), which has been designed for object-oriented
programming.
Case Study
Let us determine the Cyclomatic complexity for the "Reissue Book" method as shown below:

public ID Reissue Book(ID userID, ID bookID) {

Member user = Member.GetMember(userID);
ID transactionID = null;
if ( user.canIssueNow() && Book.IsAvailable(bookID) ) {
Integer count = user.getReissueCountFor(bookID); // # of times this books has been reissued after it's recent issue
by the user
if ( count < REISSUE_LIMIT ) {
user.incrementReissueCount(bookID);
BookTransaction transaction = new BookTransaction(userID, bookID);
transaction.save();
transactionID = transaction.getID();
}
}
return transactionID;
}
The Control Flow Graph for the above module is shown in figure 1. The CFG has six nodes and seven edges. So, the
Cyclomatic complexity is V(G) = 7 - 6 + 2 = 3. It can be verified with the other two formulae as well: # of regions + 1 =
2 + 1 = 3. Also, # of decision points = 2. So, V(G) = 2 + 1 = 3. However, as mentioned in the theory section, for
methods of classes we add an extra 1 to the V(G). So, the Cyclomatic complexity of this method becomes 4, which is
good.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 65

Software Engineering lab KHIT –R20

Figure 1. CFG for "ReissueBook" method

Note that in line # 3 two decisions have been short-circuited. Taking this into account, V(G) for the module would
become 5, which is OK. This implies that the method could have upto five linearly independent paths. By looking at
figure 1 we can easily identify three such paths. However, as mentioned that line # 3 consists of two decision points, that
results in another "implicit" path. Based on these, we can design four test cases that would result in Boolean values for
this sequence { user.canIssueNow, Book.IsAvailable, count < REISSUE_LIMIT }. The four such cases are shown
below:

{ true, true, true } : Output should be a valid ID

{ false, true, true } : Output would be null
{ true, false, true } : Output would be null
{ true, true, false } : Output would be null
Now let us focus on the "IssueManager" class. For simplicity, let's assume it has only two methods: IssueBook and
ReissueBook, as shown below.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 66

Software Engineering lab KHIT –R20
public Class IssueManager {
public ID IssueBook(ID userID, ID bookID) {
Member user = Member.GetMember(userID);
ID transactionID = null;
if ( user.canIssueNow() && Book.IsAvailable(bookID) ) {
Book.SetStatusIssued(bookID);
user.incrementIssueCount(bookID);
BookTransaction transaction = new BookTransaction(userID, bookID);
transaction.save();
transactionID = transaction.getID();
}
return transactionID;
}

public ID ReissueBook(ID userID, ID bookID) {

Member user = Member.GetMember(userID);
ID transactionID = null;
if ( user.canIssueNow() && Book.IsAvailable(bookID) ) {
Integer count = user.getReissueCountFor(bookID); // # of times this books has been reissued after it's recent
issue by the user
if ( count < REISSUE_LIMIT ) {
user.incrementReissueCount(bookID);
BookTransaction transaction = new BookTransaction(userID, bookID);
transaction.save();
transactionID = transaction.getID();
}
}
return transactionID;
}
}
"IssueBook" has two decision points (if and &&). So, V(GIssueBook) = (2 + 1) + 1 = 4. We have already determined
V(GReissueBook) to be 5. So, the total Cyclomatic complexity of this class (having two methods) becomes
V(G) = (4 + 5) - 2 + 1 = 8.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 67

Software Engineering lab KHIT –R20

OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 68

Software Engineering lab KHIT –R20
Experiment – 10: Designing Test Suites

Introduction
Development of a new software, like any other product, remains incomplete until it subjected to exhaustive tests. The primary
objective of testing is not to verify that all desired features have been implemented correctly. However, it also includes verification
of the software behavior in case of "bad inputs".
In this experiment we discuss in brief about different types of testing, and provide mechanisms to have hands-on experience on unit
testing.

Objectives
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

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 analyzing 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 [i]. 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
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
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 69
Software Engineering lab KHIT –R20
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:

J Unit - 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 analyzing 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 the different legal requirements.
In order to meet industry specific standards such as the Aerospace, Missile and Railway Signaling 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, compatibility testing, recovery testing, maintenance testing, documentation testing, and usability testing.
Software testing are mainlyof following types [1]

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.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 70

Software Engineering lab KHIT –R20
- 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 analyzing 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
vulnerabilities. This 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 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 does not belong to either unit testing, integration testing, or system
testing, instead, it is a separate dimension to these three forms of testing.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 71

Software Engineering lab KHIT –R20

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.

Example
Write a program to calculate the square of a number in the range 1-100

#include <stdio.h>

int
main()
{
int n, res;
printf("Enter a number: ");
scanf("%d", &n);
if (n >= 1 && n <= 100)
{
res = n * n;
printf("\n Square of %d is %d\n", n, res);
}
else if (n<= 0 || n > 100)
printf("Beyond the range");

return 0;
}
Output

Inputs Outputs
I1 : -2 O1 : Beyond the range
I2 : 0 O2 : Beyond the range
I3 : 1 O3 : Square of 1 is 1
I4 : 100 O4 : Square of 100 is 10000
I5 : 101 O5 : Beyond the range
I6 : 4 O6 : Square of 4 is 16
I7 : 62 O7 : Square of 62 is 3844
Test Cases
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 72
 Software Engineering lab KHIT –R20

T1 : {I1 ,O1}
T2 : {I2 ,O2}
T3 : {I3, O3}
T4 : {I4, O4}
T5 : {I5, O5}
T6 : {I6, O6}
T7 : {I7, O7}
Some Remarks
A prevalent misconception among the beginners is that one should be concerned with testing only after coding ends.
Testing is, in fact, not a phase towards the end. It is rather a continuous process. The efforts for testing should begin in
the form of preparation of test cases after the requirements have been finalized. The Software Requirements
Specification (SRS) document captures all features to be expected from the system. The requirements so identified here
should serve as a basis towards preparation of the test cases. Test cases should be designed in such a way that all target
features could be verified. However, testing a software is not only about proving that it works correctly. Successful
testing should also point out the bugs present in the system, if any.

Case Study
As already discussed under the theory section, test case preparation could begin right after requirements identification
stage. It is desirable (and advisable) to create a Requirements Traceability Matrix (RTM) showing a mapping from
individual requirement to test case(s). A simplified form of the RTM is shown in table 1 (the numbers shown in this
table are arbitrary; not specific to LIS).
Table 1: A simplified mapping from requirements to
test cases
Requirement # Test Case #
R1 TC1
R2 TC2, TC3, TC4
R3 TC5
R4 TC6

Table 1 states which test case should help us to verify that a specified feature has been implemented and working
correctly. For instance, if test case # TC6 fails, that would indicate requirement # R4 has not fully realized yet.
Note that it is possible that a particular requirement might need multiple test cases to verify whether it has been
implemented correctly.
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 73
 Software Engineering lab KHIT –R20
To be specific to our problem, let us see how we can design test cases to verify the "User Login" feature. The
simplest scenario is when both user name and password have been typed in correctly. The outcome will be that the
user could then avail all features of LIS. However, there could be multiple unsuccessful conditions:
 User ID is wrong
 Password is wrong
 User ID & password are wrong
 Wrong password given twice consecutively
 Wrong password given thrice consecutively
 Wrong password given thrice consecutively, and security question answered correctly
 Wrong password given thrice consecutively, and security question answered incorrectly
We would create test case for the above stated login scenarios. These test cases together would constitute a test
suite to verify the concerned requirement. Table 2 shows the details of this test suite.

Table 2: A test suite to verify the "User Login" feature

# TS1
Title Verify "User Login" functionality
Description To test the different scenarios that might arise while an user is trying to login
Post-
# Summary Dependency Pre-condition Execution Steps Expected Output
condition

Verify that user 1. Type in employee ID

already Employee as 149405
registered with ID 149405 is a 2. Type in
User is "Home" page for the user
TC1 the LIS is able registered user of
logged in
password this_is_pass is displayed
to login with LIS; user's password word
correct user ID is this_is_password 3. Click on the 'Login'
and password button
1. Type in employee ID
Verify that an as 149405xx The "Login" dialog is
Employee
unregistered User is not 2. Type in shown with a "Login
TC2 ID 149405xx is not a
user of LIS is logged in password whatever failed! Check your user ID
registered user of LIS
unable to login 3. Click on the 'Login' and password" message
button
Verify that user 1. Type in employee ID
already Employee as 149405 The "Login" dialog is
registered with ID 149405 is a shown with a "Login
User is not 2. Type in
TC3 the LIS is registered user of failed! Check your user
logged in password whatever
unable to login LIS; user's password ID and
with incorrect is this_is_password 3. Click on the 'Login' password" message
password button
Verify that user
already 1. Type in employee ID
registered with This test case is as 149405 The "Login" dialog is
the LIS is executed after
User is not 2. Type in shown with a "Login
TC4 unable to login TC3 execution of TC3
logged in password whatever2 failed! Check your user ID
with incorrect before executing any
3. Click on the 'Login' and password" message
password given other test case
twice button
consecutively
Verify that user
The "Login" dialog is
already 1. Type in employee ID shown with a "Login
registered with This test case is as 149405 failed! Check your user
the LIS is executed after
User is not 2. Type in ID and
TC5 unable to login TC4 execution of TC4
logged in password whatever3 password" message; the
with incorrect before executing any
3. Click on the 'Login' security question and
password other test case
button input box for the answer
given thrice
are displayed
consecutively
TC6 Verify that a TC5 This test case is Email sent 1. Type in the answer Login dialog is displayed;
registered user executed after containing as my_answer an email containing the
can login after execution of TC6 new 2. Click on the 'Email new password is received
three before executing any password.
Password' button
IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 74
Software Engineering lab KHIT –R20
Table 2: A test suite to verify the "User Login" feature
# TS1
Title Verify "User Login" functionality
Description To test the different scenarios that might arise while an user is trying to login
Post-
# Summary Dependency Pre-condition Execution Steps Expected Output
condition
consecutive
The email is
failures by other test case.
expected to
correctly Answer to the security
be received
answering the question
within 2
security is my_answer.
minute.
question
Verify that a
registered
user's account
Execute the test
is blocked after 1. Type in the answer The message "Your
cases TC3, TC4, and User
three account has been
TC5 once again (in account has as not_my_answer
TC7 consecutive blocked! Please contact
order) before been 2. Click on the 'Email
failures and the
executing this test blocked Password' button
answering the administrator." appears
case
security
question
incorrectly

In a similar way, test suites corresponding to other user requirements could be created as well. A good test plan can
reduce the burden of testing team by specifying what exactly they should focus on.

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 75

Software Engineering lab KHIT –R20
OUTPUT:

IIB.Tech, I Semester, Dept.of CSE, KHIT, Guntur. Page 76