Practical 1: Preparing Software Requirements

Specifications
Objectives

 Identify ambiguities, inconsistencies and incompleteness from a requirements

specification
 Identify and state functional requirements
 Identify and state non-functional requirements

Requirements

Sommerville 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 a software
to be developed for ATM. If a customer enters an amount greater than the
maximum permissible withdrawal amount, the ATM should display an error
message, and it should not dispense any cash.
Categorization of Requirements

Based on the target audience or subject matter, requirements can be classified into
different types, as stated below:

 User requirements: They are written in natural language so that both customers can
verify their requirements have been correctly identified
 System requirements: They are written involving technical terms and/or
specifications, and are meant for the development or testing teams

Requirements can be classified into two groups based on what they describe:

 Functional requirements (FRs): These describe the functionality of a system -- how a

system should react to a particular set of inputs and what should be the corresponding
output.
 Non-functional requirements (NFRs): They are not directly related what
functionalities are expected from the system. However, NFRs could typically define how
the system should behave under certain situations. For example, a NFR could say that
the system should work with 128MB RAM. Under such condition, a NFR could be more
critical than a FR.

Non-functional requirements could be further classified into different types like:

 Product requirements: For example, a specification that the web application should
use only plain HTML, and no frames
 Performance requirements: For example, the system should remain available 24x7
 Organizational requirements: The development process should comply to SEI CMM
level 4

Functional Requirements
Identifying Functional Requirements

Given a problem statement, the functional requirements could be identified by focusing

on the following points:

 Identify the high level functional requirements simply from the conceptual
understanding of the problem. For example, a Library Management System, apart from
anything else, should be able to issue and return books.
 Identify the cases where an end user gets some meaningful work done by using the
system. 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 get 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(SRS)

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 , 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. 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: A Library Information System for SE VLabs Institute

The SE VLabs 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.

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 credentials 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:
 o Title
o Authors name
o 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:
o The book is available in the library i.e. could be found by searching for it in LIS
o No other member has currently issued the book
o 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.

Having identified the (major) functional requirements, we assign an identifier to each of

them 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:
o This system should remain accessible 24x7
o At least 50 users should be able to access the system altogether at any given time
 Security Requirements:
o This system should be accessible only within the institute LAN
o 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:
o The LIS has to be developed as a web application, which should work with
Firefox 5, Internet Explorer 8, Google Chrome 12, Opera 10
o 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.
Practical 2:
Identifying Domain Classes from the
ProblemStatements

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. As stated in, domain classes are used for representing business
activities during the analysis phase.

Below we discuss some techniques that can be used to identify the domain classes.

Traditional Techniques for Identification of Classes

Grammatical Approach Using Nouns

This object identification technique was proposed by Russell J. Abbot, and Grady Booch
made the technique popular. This technique involves grammatical analysis of the
problem statement to identify list of potential classes. The logical steps are:

1. Obtain the user requirements (problem statement) as a simple, descriptive English text.
This basically corresponds to the use-case diagram for the problem statement.
2. Identify and mark the nouns, pronouns and noun phrases from the above problem
statements
3. 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 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.

1. Make a list of potential objects by finding out the nouns and noun phrases from
narrative problem statement
2. Apply subject matter expertise (or domain knowledge) to identify additional classes
3. Filter out the redundant or irrelevant classes
4. Classify all potential objects based on categories. We follow the category table as
described by Ross.

Categories Explanation

People Humans who carry out some function

Places Areas set aside for people or things

Things Physical objects

Collection of people, resources, facilities and capabilities having a defined

Organizations
mission

Concepts Principles or Ideas not tangible

Things that happen (usually at a given date and time), or as a steps in an

Events
ordered sequence

5. Group the objects based on similar attributes. While grouping we should remember that
 o Different nouns (or noun phrases) can actually refer to the same thing
(examples: house, home, abode)
o 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)
6. Give related names to each group to generate the final list of top level classes
7. Iterate over to refine the list of classes

Advanced Concepts

Identification of domain classes might not be a simple task for novices. It requires
expertise and domain knowledge to identify business classes from plain English text.
The concepts presented here have been kept simple in order to make a student
familiarize with the subject. A lot of work has been done in this area, and various
techniques have been proposed to identify domain classes. Interested readers may look
at the following paper for an advanced treatment on this subject matter.

Case Study: A Library Information System for SE VLabs Institute

From the given problem statement we can identify the following nouns and noun
phrases:

 The SE VLabs Institute  System

 Software Engineering  Library staff
 Research scholars  Librarian
 Students  Transactions
 Professors  Record
 Employees  Shelf
 Projects  Non-member
 Institution  Web application
 Library Information System  LAN
 Members  Software
 Book  Information
 Desk  Passwords
 Chamber

Let us put the above into different categories.

People
 Research scholars  Members
 Students  Library staff
 Professors  Librarian
 Employees  Non-member
Places
 Chamber
Things
 Projects  System
 Book  Shelf
 Desk  LAN
Organizations
 The SE VLabs Institute  Institution
Concepts
 Software Engineering  Software
 Library Information System  Information
 Record  Password
 Web application
Events
 Transactions
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  Librarian
 Book  Employee
 Transaction (of books)

Although not explicitly mentioned in the problem statement, based on knowledge in

related area one may point out few other potential classes:

 Book Inventory  Order Line Item

 Distributor  Payment
 Order  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.
Practical 3: Modeling UML Class Diagrams and
Sequence diagrams
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 Behavioural 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
 Attributes
 Operations

Relationships

Existing relationships in a system describe legitimate connections between the classes

in that system.
  Association

Figure-03:

 Aggregation

Figur
e-04:

Figure-05:

 Multiplicity
 One vehicle may have two or more wheels


Figure-07:

Sequence diagram

It represents the behavioral aspects of a system. Sequence diagram shows the

interactions between the objects by means of passing messages from one object to
another with respect to time in a system.

Elements in sequence diagram

Sequence diagram contains the objects of a system and their life-line bar and the
messages passing between them.
Object

Objects appear at the top portion of sequence diagram. Object is shown in a rectangle
box. Name of object precedes a colon ‘:’ and the class name, from which the object is
instantiated. The whole string is underlined and appears in a rectangle box. Also, we
may use only class name or only instance name.

Objects which are created at the time of execution of use case and are involved in
message passing , are appear in diagram, at the point of their creation.

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 labelled with the message name. Chronological order of the messages passing
throughout the objects’ life-line show the sequence in which they occur . There may exist some
different types of messages:

 Synchronous messages: Receiver start processing the message after receiving it and
sender needs to wait until it is made. A straight arrow with close and fill arrow-head
from sender life-line bar to receiver end, represent a synchronous message.
 Asynchronous messages: For asynchronous message sender needs not to wait for the
receiver to process the message. A function call that creates thread can be represented
as an asynchronous message in sequence diagram. A straight arrow with open arrow-
head from sender life-line bar to receiver end, represent an asynchronous message.
 Return message: For a function call when we need to return a value to the object, from
which it was called, then we use return message. But, it is optional, and we are using it
when we are going to model our system in much detail. A dashed arrow with open
arrow-head from sender life-line bar to receiver end, represent that message.
 Response message: One object can send a message to self. We use this message when
we need to show the interaction between the same object.
Case Study: A Library Information System for SE VLabs Institute

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 "issueBook(bookID)" call from "Member" to "IssueManager" objects. At this point
the system checks whether that particular user can issue another book (based on the
maximum number of books that he can issue) by invoking the "canIssue()" method on
the "Member". As a result of this call, a response ("status") is sent back to the
"IssueManager" 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.

Figure 1: Sequence diagram for "Issue Book"

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 "IssueManager" 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, "PurchaseManager" 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.

Figure 2: Sequence diagram for "Purchase Books"

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.
"placeOrder(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 suffereing could await during the development phase.
However, unlike waterfall model, the life cycle in object oriented development is
iterative. One builds a model, analyzeit'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  Distributor
 Transaction (of books)  Order
 Librarian  Order Line Item
 Employee  Payment
 Book Inventory  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.
The "LIS" class consists of several modules: "RegistrationManager", "IssueManager"
"ReturnManager", and "PurchaseManager". Their "composition" relationship with "LIS"
indicates that any of these individual modules wouldn't exist without the existence of
"LIS". The "IssueManager" class is responsible for issue and reissue of books while

The relation between "IssueManager" class and "Book" class is shown as "weak
dependency". This is due to the reason that the "IssueManager" class do not require a
"Book" as it's member variable. Rather, when an user has issued a book, the concerned
method in "IssueManager" just needs to update the status of the corresponding book.
No instance of "Book" needs to be created. The arrow from "IssueManager" to "Book"
indicates that only the former knows about the "Book" class. The relationship between
"PurchaseManager" and "Distributor" is, however, not a weak dependency. The
"PurchaseManager" class has a member variable of type "Distributor", which keeps
track of the distributor selected for the current purchase.
Practical 4: Modeling UML Use Case Diagrams and
Capturing Use Case Scenarios
Objectives

After completing this experiment you will be able to:

 How to identify different actors and use cases from a given problem statement
 How to associate use cases with different types of relationships
 How to draw a use-case diagram

Use case diagrams

Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use
case diagrams aim to present a graphical overview of the functionality provided by the
system. It consists of a set of actions (referred to as use cases) that the concerned
system can perform, one or more actors, and dependencies among them.

Actor

An actor can be defined as an object or set of objects, external to the system, which
interacts with the system to get some meaningful work done. Actors could be human,
devices, or even other systems.

For example, consider the case where a customer withdraws cash from an ATM. Here,
customer is a human actor.

Actors can be classified as below.

 Primary actor: They are principal users of the system, who fulfil 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 actors are usually drawn on the top left side of the
diagram.

Use Case

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

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 fig

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

Association between Actors and Use Cases

A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.

An actor must be associated with at least one use case. Similarly, a given use case must
be associated with at least one actor. Association among the actors are usually not
shown. 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 behaviour that are shared by multiple
use cases. This could be considered analogous to writing functions in a program in
order to avoid repetition of writing the same code. 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 - 02: Include relationship between use cases

Notation

Include relationship is depicted by a dashed arrow with a «include» stereotype from the
including use case to the included use case.

Extend Relationship

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

Example

Let's consider an online bookstore. The system allows an authenticated user to buy
selected book(s). While the order is being placed, the system also allows to specify any
special shipping instructions vii], for example, call the customer before delivery. This
Shipping Instructions step is optional, and not a part of the main Place Order use case.
Figure - 03 depicts such relationship.
 Figure - 03: Extend relationship between use cases

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.

Figure - 04: Generalization relationship among use cases

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:

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

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:

 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 behaviour among use cases , if any

Case Study: A Library Information System for SE VLabs Institute

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 2: List of use cases
# Use Case Description
Allows to register with the LIS and create an account for all
UC1 Register
transactions
UC2 User login LIS authenticates a member to let him avail the facilities
UC3 Search book A member can can search for a book
UC4 Issue book Allows a member to issue a specified book against his account
UC5 Return book To return a book, which has been issued earlier by a member
UC6 Reissue book To reissue a book
UC7 User logout User logs out from the system

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

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.

Table 4: UC2 -- User login

Use Case UC2. User login
Description Allows a member to login to the system using his user ID and password
Assumptions
 Member
Actors
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 pageELSE display error

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

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 is 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 login
Description
failures, and he attempts to login again
3a. IF consecutive failure count is 3 THEN invoke "Answer security
Steps
question"

The details of the "Issue book" use case is shown in table 6.

Table 6: UC5 -- Issue book

Use Case UC5. Issue book
Description Allows a member to issue a specified book against his 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

Steps 1. User logs in

 2. User searches for a book
3. User clicks on "Issue" button to issue the book
4. User's account is updated
5. Library staff delivers the book

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.

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.
Practical 5: E-R modelling
Objectives

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

Importance of ER Modeling

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

database.

Figure - 01: Steps to implement a RDBMS

Given a problem statement, the first step is to identify the entities, attributes and
relationships. We represent them using an ER diagram. Using this ER diagram, table
structures are created, along with required constraints. Finally, these tables are
normalized in order to remove 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 Library Information System for SE VLabs Institute

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

Figure 1 represents Member Entity Set and the primary key.

Figure 1: "Member" entity set

Let us now focus on the "Book" entity set. A graphical representation of the "Book"
entity set is shown in figure 2.

Figure 2: "Book" entity set

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.
 Figure 3: Relationships among different entity sets

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.
Practical 6: Statechart and Activity Modeling
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

Statechart Diagrams

In case of Object Oriented Analysis and Design, a system is often abstracted by one or
more classes with some well-defined behaviour and states. A statechart diagram is a
pictorial representation of such a system, with all it's states, and different events that
lead transition from one state to another.

To illustrate this, consider a computer. Some possible states that it could have are:
running, shutdown, hibernate. A transition from running state to shutdown state occur
when user presses the "Power off" switch, or clicks on the "Shut down" button as
displayed by the OS. Here, clicking on the shutdown button, or pressing the power off
switch act as external events causing the transition.

Statechart diagrams are normally drawn to model the behaviour of a complex system.
For simple systems this is optional.

Building Blocks of a Statechart Diagram

State

A state is any "distinct" stage that an object (system) passes through in it's lifetime. An
object remains in a given state for finite time until "something" happens, which makes it
to move to another state. All such states can be broadly categorized into following three
types:

 Initial: The state in which an object remain when created

 Final: The state from which an object do not move to any other state 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.
Figure-01: Representation of initial, intermediate, and final states of a statechart
diagram Intermediate states usually have two compartments, separated by a horizontal
line, called the name compartment and internal transitions compartment. They are
described below:

 Name compartment: Contains the name of the state, which is a short, simple,
descriptive string
 Internal transitions compartment: Contains a list of internal activities performed as
long as the system is in this state

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 enter this state
 Exit: Indicates activity performed when the system exits this state
 Do: indicate any activity that is performed while the system remain in this state or until
the action expression results in a completed computation
 Include: Indicates invocation of a sub-machine

Any other action label identify the event (internal transition) as a result of which the
corresponding action is triggered. 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 statechart 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

As mentioned in, actions represents behaviour 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:

1. Exit actions of the present state

2. Actions specified for the transition
3. Entry actions of the next state

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

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

Guidelines for drawing Statechart Diagrams

Following steps could be followed, as suggested in to draw a statechart diagram:

 For the system to developed, identify the distinct states that it passes through
 Identify the events (and any precondition) that cause the state transitions. Often these
would be the methods of a class as identified in a class diagram.
 Identify what activities are performed while the system remains in a given state

Activity Diagrams

Activity diagrams fall under the category of behavioural diagrams in Unified Modeling
Language. It is a high level diagram used to visually represent the flow of control in a
system. It has similarities with traditional flow charts. However, it is more powerful
than a simple flow chart since it can represent various other concepts like concurrent
activities, their joining, and so on.

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.

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

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.

Component Graphical Notation Component Graphical Notation

Activity Note

Merge Decision

Fork Join
Component Graphical Notation Component Graphical Notation

Flow

Table-01: Typical components used in an activity diagram

Apart from the above stated components, there are few other components as well
(representing events, sending of signals, nested activity diagrams), which won't be
discussed here. The reader is suggested to go through for further knowledge.

A Simple Example

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

Figure-04: A simple activity diagram.

Guidelines for drawing an Activity Diagram

The following general guidelines could be followed to pictorially represent a complex

logic.

 Identify tiny pieces of work being performed by the system

 Identify the next logical activity that should be performed
 Think about all those conditions that should be made, and all those constraints that
should be satisfied, before one can move to the next activity
 Put non-trivial guard conditions on the edges to avoid confusion
Case Study: A Library Information System for SE VLabs Institute

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.

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.

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.

Figure-03: Activity diagram for updating inventory

Addition of new books and removing records of books taken off from the shelves could
be done parallely. 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.
Practical 7: Modeling Data Flow Diagrams
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

Term Remarks

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

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
Data store
written inside the shape

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

Explanation of Symbols used in DFD

 Process: Processes are represented by circle. The name of the process is written
into the circle. The name of the process is usually given in such a way that
represents the functionality of the process. More detailed functionalities can be
shown in the next Level if it is required. Usually it is better to keep the number of
processes less than 7 . If we see that the number of processes becomes more than
7 then we should combine some the processes to a single one to reduce the
number of processes and further decompose it to the next level.
 External entity: External entities are only appear in context diagram. 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 process is split into in the next level. 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 :

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

2. Keep number of processes at each level less than 7.
3. Data flow is not possible in between two external entities and in between two
data stores.
4. Data cannot flow from an External entity to a data store and vice-versa.

Case Study: A Library Information System for SE VLabs Institute

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 databases 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" identify 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 is provided to the member.

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.

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.
Figure 1: Context-level DFD for Library Information System
Figure 2: Level 1 DFD for Library Information System
Practical 8:Estimation of Project Metrics
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

o The project deals with developing a well understood application
o The development team is small
o The team members have prior experience in working with similar types
of projects
 Semidetached: A development project can be categorized as semidetached type,
if
o The team consists of some experienced as well as inexperienced staff
o Team members may have some experience on the type of system to be
developed
 Embedded: Embedded type of development project are those, which
o Aims to develop a software strongly related to machine hardware
o 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) PM
b

Tdev = 2.5 * (Effort)c Months where

o KDSI is the estimated size of the software expressed in Kilo Delivered

Source Instructions
o a, b, c are constants determined by the category of software project
o Effort denotes the total effort required for the software development,
expressed in person months (PMs)
 o 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

Advantages of COCOMO

COCOMO is a simple model, and should help one to understand the concept of project
metrics estimation.

Drawbacks of COCOMO

COCOMO uses KDSI, which is not a proper measure of a program's size. Indeed,
estimating the size of a software is a difficult task, and any slight miscalculation could
cause a large deviation in subsequent project estimates. Moreover, COCOMO was
proposed in 1981 keeping the waterfall model of project life cycle in mind . 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.

Case Study: A Library Information System for SE VLabs Institute

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

So, around 27 person-months are required to complete this project. With this calculated
value for effort we can also approximate the development time required:

Tdev = 2.5 * (27)0.38 Months

= 8.7 Months (approx)

So, the project is supposed to be complete by nine months. However, estimations using
basic COCOMO are largely idealistic. Let us refine them using intermediate COCOMO.
Before doing so we determine the Effort Adjustment Factor (EAF) by assigning
approprite weight to each of the following attributes.

Ratings
Very Very Extra
Cost Drivers Low LowNominalHigh High 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 environment 0.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 methods 1.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.
Practical 9: Estimation of Test Coverage Metrics and
Structural Complexity
Objectives

After completing this experiment you will be able to:

 Identify basic blocks in a program module, and draw it's 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.

1 intx = 10, x_2 = 0;

2 x_2 = x * x;

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

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

01 sum = 0;

02 i = 1;

03 while(i ≤ n) {

04 sum += i;

05 ++i;

06 }

07 printf("%d", sum);

08 if(sum > 0) {

09 printf("Positive");

10 }

The CFG with basic blocks is shown for the above code in figure 3.

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. 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:
01 sum = 0;
02 i = 1;
03 while(i ≤ n) {
04 sum += i;
05 ++i;
06 }
07 returnsum;
08 if(sum < 0) {
09 return0;
10 }

Figure 4 shows the corresponding CFG. The sub-graph containing line #s 8, 9, 10 is

disconnected from the graph containing the entry block. The code in the disconnected
sub-graph would never get executed, and, therefore, could be discarded. Figure 4: CFG
with unreachable blocks

Terminologies

Path
A path in a CFG is a sequence of nodes and edges that starts from the initial node (or
entry block) and ends at the terminal node. The CFG of a program could have more than
one terminal nodes.

Linearly Independent Path

A linearly independent path is any path in the CFG of a program such that it includes at
least one new edge not present in any other linearly independent path. A set of linearly
independent paths give a clear picture of all possible paths that a program can take
during 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 . Cyclomatic complexity metric, as proposed by McCabe, provides an upper
bound for the number of linearly independent paths that could exist through a given
program module. Complexity of a module increases as the number of such paths in the
module increase. Thus, if Cyclomatic complexity of any program module is 7, there
could be up to seven linearly independent paths in the module. For a complete testing,
each of those possible paths should be tested.

Computing Cyclomatic Complexity

Let G be aa 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 . 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. Once the complexities of individual modules of a program are known,
complexity of the program (or class) could be determined by: V(G) = SUM( V(Gi) ) -
COUNT( V(Gi) ) + 1 where COUNT( V(Gi) ) gives the total number of procedures
(methods) in the program (class).

Optimum Value of Cyclomatic Complexity

A set of threshold values for Cyclomatic complexity has been presented in, which we
reproduce below.

V(G) Module Category Risk

1-10 Simple Low

 V(G) Module Category Risk

11-20 More complex Moderate

21-50 Complex High

> 50 Unstable Very high

It has been suggested that the Cyclomatic complexity of any module should not exceed
10 . Doing so would make a module difficult to understand for humans. If any module is
found to have Cyclomatic complexity greater than 10, the module should be considered
for redesign. Note that, a high value of V(G) is possible for a given module if it contains
multiple cases in C like switch-case statements. McCabe had exempted such modules
from the limit of V(G) as 10.

Merits

McCabe's Cyclomatic complexity has certain advantages:

 Independent of programming language

 Helps in risk analysis during development or maintenance phase
 Gives an idea about the maximum number of test cases to be executed (hence, the
required effort) for a given module

Demerits

Cyclomatic complexity doesn't reflect on cohesion and coupling of modules.

McCabe's Cyclomatic complexity was originally proposed for procedural languages. One
may look in to get an idea of how the complexity calculation could be modified for
object-oriented languages. In fact, one may also wish to make use of Chidamber-
Kemerermetrics (or any other similar metric), which has been designed for object-
oriented programming.
Practical 10: Designing Test Suites
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.

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 improves 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
2. Integration Testing
3. System Testing

Unit Testing

Unit testing is done at the lowest level. It tests the basic unit of software, that is the
smallest testable piece of software. The individual component or unit of a program are
tested in unit testing. Unit testing are of two types.

 Black box testing: This is also known as functional testing , where the test cases are
designed based on input output values only. There are many types of Black Box Testing
but following are the prominent ones.

- Equivalence class partitioning: In this approach, the domain of input values to a

program is divided into a set of equivalence classes. e.g. Consider a software program
that computes whether an integer number is even or not that is in the range of 0 to 10.
Determine the equivalence class test suite. There are three equivalence classes for this
program. - The set of negative integer - The integers in the range 0 to 10 - The integer
larger than 10

- Boundary value analysis : In this approach, while designing the test cases, the values
at boundaries of different equivalence classes are taken into consideration. e.g. In the
above given example as in equivalence class partitioning, a boundary values based test
suite is { 0, -1, 10, 11 }

 White box testing: It is also known as structural testing. In this testing, test cases are
designed on the basis of examination of the code.This testing is performed based on the
knowledge of how the system is implemented. It includes 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.
White Box Testing
The box testing approach of software testing consists of black box testing and white box testing. We are
discussing here white box testing which also known as glass box is testing, structural testing, clear box
testing, open box testing and transparent box testing. It tests internal coding and infrastructure of a
software focus on checking of predefined inputs against expected and desired outputs. It is based on inner
workings of an application and revolves around internal structure testing. In this type of testing programming
skills are required to design test cases. The primary goal of white box testing is to focus on the flow of inputs
and outputs through the software and strengthening the security of the software.

The term 'white box' is used because of the internal perspective of the system. The clear box or white box or
transparent box name denote the ability to see through the software's outer shell into its inner workings.

Developers do white box testing. In this, the developer will test every line of the code of the program. The
developers perform the White-box testing and then send the application or the software to the testing team,
where they will perform the black box testing and verify the application along with the requirements and
identify the bugs and sends it to the developer.

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

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

Black Box Testing

Boundary Value Analysis (BVA) – A Black Box Testing Technique

This Black Box testing technique believes and extends the concept that the density of
defect is more towards the boundaries. This is done due to the following reasons

a) Usually the programmers are not able to decide whether they have to use <=
operator or < operator when trying to make comparisons.

b) Different terminating conditions of For-loops, While loops and Repeat loops may
cause defects to move around the boundary conditions.

c) The requirements themselves may not be clearly understood, especially around the
boundaries, thus causing even the correctly coded program to not perform the correct
way.

The basic idea of BVA is to use input variable values at their minimum, just above the
minimum, a nominal value, just below their maximum and at their maximum. Meaning
thereby (min, min+, nom, max-, max), as shown in the following figure.

BVA is based upon a critical assumption that is

known as “Single fault assumption theory”.
According to this assumption, we derive the
test cases on the basis of the fact that failures
are not due to simultaneous occurrence of two
(or more) faults. So, we derive test cases by
holding the values of all but one variable at
their nominal values and allowing that variable
assume its extreme values.

If we have a function of n-variables, we hold all

but one at the nominal values and let the
remaining variable assume the min, min+,
nom, max-and max values, repeating this for
each variable. Thus, for a function of n
variables, BVA yields (4n + 1) test cases.

Limitations of BVA:

1) Boolean and logical variables present a problem for Boundary Value Analysis.

2) BVA assumes the variables to be truly independent which is not always possible.

3) BVA test cases have been found to be rudimentary because they are obtained with
very little insight and imagination.
Robustness Testing:

Robustness Testing is another variant of BVA

In BVA, we remain within the legitimate boundary of our range i.e. for testing we
consider values like (min, min+, nom, max-, max) whereas in Robustness testing, we try
to cross these legitimate boundaries as well.

Thus for testing here we consider the values like (min-, min, min+, nom, max-, max,
max+)

Again, with robustness testing, we can focus on exception handling. With strongly typed
languages, robustness testing may be very awkward. For example, in PASCAL, if a
variable is defined to be within a certain range, values outside that range result in run-
time errors thereby aborting the normal execution.For a program with n-variables,
robustness testing will yield (6n + 1) test-cases. Thus we can draw the following
Robustness Test Cases graph.

Each dot represents a test value at which the program is

to be tested. In Robustness testing, we cross the
legitimate boundaries of input domain. In the above
graph, we show this by dots that are outside the range
[a, b] of variable x1. Similarly, for variable x2, we have
crossed its legitimate boundary of [c, d] of variable x2.

This type of testing is quite common in electric and

electronic circuits. Furthermore, this type of testing also
works on 'single fault assumption theory'.

Worst Case Testing:

If we reject our basic assumption of single fault

assumption theory and focus on what happens
when we reject this theory-it simply means that
we want to see that what happens when more
than one variable has an extreme value. In
electronic circuit analysis, this is called as
"worst-case analysis". We use this idea here to
generate worst-case test cases.

For each variable, we start with the five-element

set that contains the min, min+, nom, max-, and
max values. We then take the Cartesian product
of these sets to generate test cases. This is shown
in following graph

For a program with n-variables, 5n test cases

are generated.
Guidelines for BVA:

1) The normal versus robust values and the single fault versus the multiple-fault
assumption theory result in better tuning. These methods can be applied to both input
and output domain of any program.

2) Robustness testing is a good choice for testing internal variables.

3) We must bear in mind that we can create extreme boundary results from non-
extreme input values.

Aim: Generate BVA Test Cases For the Triangle Problem

Before we generate the test cases, firstly we need to define the problem domain as
described below.

Problem Domain: "The triangle program accepts three integers, a, b and c as input.
These are taken to be the sides of a triangle. The integers a, b and c must satisfy the
following conditions

C1: 1 ≤ a ≤ 200
C2: 1 ≤ b ≤ 200
C3: 1 ≤ c ≤ 200
C4: a <b+c
C5: b <a+c
C6: c <a+b

The output of the program may be either of: Equilateral Triangle, Isosceles Triangle,
Scalene or "Not a Triangle".

Objective:How to Generate BVA Test Cases for this problem?

We know that our range is [1, 200] where 1 is the lower bound and 200 being the upper
bound.

Also, we find that this program has three inputs like a, b and c.

Hence for our case number of inputs or n = 3

Since BVA yields (4n + 1) test cases according to single fault assumption theory, hence
we can say that the total number of test cases will be (4*3+1)=12+1=13.

Now we can draw the following Table indicating all the 13 test-cases.
 Test Side "a" Side "b" Side "c" Expected Output
Case ID

1 100 100 1 Isosceles Triangle

2 100 100 2 Isosceles Triangle

3 100 100 100 Equilateral Triangle

4 100 100 199 Isosceles Triangle

5 100 100 200 Not a Triangle

6 100 1 100 Isosceles Triangle

7 100 2 100 Isosceles Triangle

8 100 100 100 Equilateral Triangle

9 100 199 100 Isosceles Triangle

10 100 200 100 Not a Triangle

11 1 100 100 Isosceles Triangle

12 2 100 100 Isosceles Triangle

13 100 100 100 Equilateral Triangle

14 199 100 100 Isosceles Triangle

15 200 100 100 Not a Triangle

It may be noted that as explained above that we can have 13 test cases (4n + 1) for this
problem. But instead of 13, now we have 15 test cases.

Moreover we can see that the test cases vide ID number 8 and 13 are redundant. Hence
we can ignore them. However, we do not ignore test case ID number 3, as we must
consider at least one test case out of these three. Thus it is evident that it is a mechanical
activity.

Hence we can say that these 13 test cases are sufficient to test this program using BVA
technique.
Example: Generate BVA Test Cases for the Next Date Function

Before we generate the test cases for the Next Date Function problem, firstly we need to
define the problem domain as described below.

Problem Domain: "Next Date" is a function consisting of three variables like: month,
date and year. It returns the date of next day as output. It reads current date as input
date.

The conditions are

C1: 1 ≤ month ≤ 12

C2: 1 ≤ day ≤ 31

C3: 1900 ≤ year ≤ 2025.

If any one condition out of C1, C2 or C3 fails, then this function produces an output
"value of month not in the range 1...12".

Since many combinations of dates can exist, hence we can simply displays one message
for this function : "Invalid Input Date".

Complexities in Next Date Function

A very common and popular problem occurs if the year is a leap year. We have taken
into consideration that there are 31 days in a month. But what happens if a month has
30 days or even 29 or 28 days ?

A year is called as a leap year if it is divisible by 4, unless it is a century year. Century

years are leap years only if they are multiples of 400. So, 1992, 1996 and 2000 are leap
years while 1900 is not a leap year.

Furthermore, in this Next Date problem we find examples of Zipf's law also, which
states that "80% of the activity occurs in 20% of the space". Thus in this case also,
much of the source-code of Next Date function is devoted to the leap year
considerations.

Objective:How to Generate BVA Test Cases for this problem?

The Next Date program takes date as input and checks it for validity. If it is valid, it
returns the next date as its output.

Here we have three inputs for the program, hence n = 3.

Since BVA yields (4n + 1) test cases according to single fault assumption theory, hence
we can say that the total number of test cases will be (4*3+1)=12+1=13.
The boundary value test cases are

Test Month Day (dd) Year (yyyy) Expected Output

Case ID (mm)

1 6 15 1900 16 June, 1900

2 6 15 1901 16 June, 1901

3 6 15 1962 16 June, 1962

4 6 15 2024 16 June, 2024

5 6 15 2025 16 June, 2025

6 6 1 1962 2 June, 1962

7 6 2 1962 1 June, 1962

8 6 30 1962 1 July 1962

9 6 31 1962 Invalid Date as June has 30 Days

10 1 15 1962 16 January, 1962

11 2 15 1962 16 February, 1962

12 11 15 1962 16 November, 1962

13 12 15 1962 16 December, 1962

This is how we can apply BVA technique to create test cases for our Next Date Problem.

Example:Find out the Roots of a Quadratic Equation & Generate its Boundary
Value Test Cases

Inputs :A quadratic equation a(x2)+bx+c=0 with input as three positive integers a, b, c

having values ranging from an interval [0,100].

Objective: There are two objectives of the tutorial like:

Objective –1: To write a Program in C++ for the determining the nature of roots of the
above quadratic equation. The program output may have one of the following words:

"Not a Quadratic Equation", "Real Roots", "Imaginary Roots" or "Roots are Equal"

Objective –2: Boundary Value Testing by designing Test Cases which would use input
variables at their Minimum Values, Just above Minimum Values, at Nominal Value, Just
below Maximum and Minimum Values.

Solution Part – 1: Program in C++

#include<iostream.h>
#include<conio.h>
void main( )
{
clrscr();
inta,b,c,d;
cout<<"The quadratic equation is of the type
a(x2)+bx+c=0";
cout<<"Enter the value of a:"<<enl1;
cin>>a;
cout<<"Enter the value of b:"<<endl;
cin>>b;
cout<<"Enter the value of c: "<<endl;
cin>>c;
d = (b*b)-4*a*c;
if((a<0)||(b<0)||(c<0)||(a>100)||(b>100)||(c>100))
cout«"Invalid input"«end1;
elseif(a==0)
cout<<"Not a quadratic equation"<<endl;
elseif(d==0)
cout<<"Roots are equal"<<endl;
else if(d<0)
cout<<"Imaginary roots"<<end1;
else
cout<<"Real roots"<<endl;
getch();
}

Solution Part – 2: Design Boundary Value Test Cases

In the above program, we consider the values as 0 (Minimum), 1 (Just above Minimum),
50 (Nominal), 99 (Just below Maximum) and 100 (Maximum)

Test a b c Expected Output

Case ID

1 50 50 0 Real Roots

2 50 50 1 Real Roots

3 50 50 50 Imaginary Roots

4 50 50 99 Imaginary Roots

5 50 50 100 Imaginary Roots

6 50 0 50 Imaginary Roots

7 50 1 50 Imaginary Roots

8 50 99 50 Imaginary Roots

9 50 100 50 Equal Roots

 10 0 50 50 Not a Quadratic Equation

11 1 50 50 Real Roots

12 99 50 50 Imaginary Roots

13 100 50 50 Imaginary Roots

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.

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.

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
1. Type in
employee
ID as
Verify that user 149405
Employee ID
already 2. Type in
149405 is a
registered with password "Home" page for
registered user of User is
TC1 the LIS is able this_is_pass the user is
LIS; user's logged in
to login with word displayed
password is
correct user ID 3. Click on the
this_is_password
and password 'Login'
button

1. Type in
employee
ID as
149405xx The "Login" dialog
Verify that an Employee ID 2. Type in is shown with a
unregistered 149405xx is not a User is not password "Login failed! Check
TC2
user of LIS is registered user of logged in whatever your user ID and
unable to login LIS 3. Click on the password" message
'Login'
button

1. Type in
employee
Verify that user ID as
Employee ID 149405
already The "Login" dialog
149405 is a 2. Type in is shown with a
registered with
registered user of User is not password "Login failed! Check
TC3 the LIS is
LIS; user's logged in whatever your user ID and
unable to login
password is 3. Click on the password" message
with incorrect
this_is_password 'Login'
password
button

TC4 Verify that user TC3 This test case is User is not 1. Type in The "Login" dialog
already executed after logged in employee is shown with a
registered with execution of TC3 ID as "Login failed! Check
the LIS is before executing 149405 your user ID and
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
2. Type in
unable to login password
with incorrect whatever2
any other test 3. Click on the password" message
password
case 'Login'
given twice
consecutively button

1. Type in
Verify that user employee The "Login" dialog
already ID as is shown with a
This test case is 149405 "Login failed! Check
registered with
executed after 2. Type in your user ID and
the LIS is
execution of TC4 User is not password password"
TC5 unable to login TC4
before executing logged in whatever3 message; the
with incorrect
any other test 3. Click on the security question
password
case 'Login' and input box for
given thrice
button the answer are
consecutively
displayed

Verify that a Email sent

This test case is 1. Type in the
registered user containing
executed after answer as
can login after new
execution of TC6 my_answer Login dialog is
three password.
before executing 2. Click on the displayed; an email
consecutive The email
TC6 TC5 any other test 'Email containing the new
failures by is expected
case. Answer to Password' password is
correctly to be
the security button received
answering the received
question is
security within 2
my_answer.
question minute.
Verify that a
registered 1. Type in the
user's account answer as
Execute the test not_my_ans The message "Your
is blocked after
cases TC3, TC4, User wer account has been
three
and TC5 once account 2. Click on the blocked! Please
TC7 consecutive
again (in order) has been 'Email contact the
failures and
before executing blocked Password' administrator."
answering the
this test case button appears
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.