Department of Computer Science Engineering Software Engineering Lab

SHADAN COLLEGE OF ENGINEERING AND TECHNOLOGY

PEERANCHERU, HYDERABAD

SOFTWARE ENGINEERING LAB

(III- B. Tech. – I– Semester)

(R18 REGULATION)

DEPARTMENT OF COMPUTER SCIENCE& ENGINEERING

By

[Link]
(Professor, Dept. of CSE)

Page No: 1
Department of Computer Science Engineering Software Engineering Lab

CS505PC: SOFTWARE ENGINEERING LAB

III Year [Link]. CSE I-Sem TP C

0 0 3 1.5
Prerequisites
1. A course on “Programming for Problem Solving”
1) Co-requisite
1. A Course on “Software Engineering”

2) Course Objectives
1. To have hands on experience in developing a software project by using
various software engineering principles and methods in each of the
phases of software development.

3) Course Outcomes
1. Ability to translate end-user requirements into system and software requirements
2. Ability to generate a high-level design of the system from the software
requirements
3. Will have experience and/or awareness of testing problems and will be able to
develop a simple testing report

4) List of Experiments
Do the following 8 exercises for any two projects given in the list of sample projects or
any other projects:
1) Development of problem statement.
2) Preparation of Software Requirement Specification Document, Design
Documents and Testing Phase related documents.
3) Preparation of Software Configuration Management and Risk Management related
documents.
4) Study and usage of any Design phase CASE tool
5) Performing the Design by using any Design phase CASE tools.
6) Develop test cases for unit testing and integration testing
7) Develop test cases for various white box and black box testing techniques.

5) Sample Projects:
1. Passport automation System
2. Book Bank
3. Online Exam Registration
4. Stock Maintenance System
5. Online course reservation system
6. E-ticketing
7. Software Personnel Management System

Page No: 6
Department of Computer Science Engineering Software Engineering Lab

8. Credit Card Processing

9. E-book management System.
10. Recruitment system

6) TEXT BOOKS:
1. Software Engineering, A practitioner’s Approach- Roger S. Pressman, 6th
edition, Mc Graw Hill International Edition.
2. Software Engineering- Sommerville, 7th edition, Pearson Education.
3. The unified modeling language user guide Grady Booch, James Rambaugh,
Ivar Jacobson, Pearson Education.

Page No: 7
 LIST OF EXPERIMENTS

EXP NO EXPERIMENT NAME

1 Passport Automation System

2 Book Bank

3 Exam Registration

4 Stock Maintenance System

5 Online Course Reservation System

6 E- Ticketing

7 Software Personnel Management System

8 Credit Card Processing

9 E-Book Management System

10 Recruitment System

8
Ex no: 1 PASSPORT AUTOMATION SYSTEM

AIM:
To create an automated system to perform the Passport Process

(I) PROBLEM STATEMENT:

Passport Automation System is used in the effective dispatch of passport to all of the
applicants. This system adopts a comprehensive approach to minimize the manual work and
schedule resources, time in a cogent manner. The core of the system is to get the online
registration form (with details such as name, address etc.,) filled by the applicant whose testament
is verified for its genuineness by the Passport Automation System with respect to the already
existing information in the database. This forms the first and foremost step in the processing of
passport application. After the first round of verification done by the system, the information is in
turn forwarded to the regional administrator's (Ministry of External Affairs) office. The
application is then processed manually based on the report given by the system, and any forfeiting
identified can make the applicant liable to penalty as per the law. The system also provides the
applicant the list of available dates for appointment to 'document verification' in the
administrator's office, from which they can select one. The system forwards the necessary details
to the police for its separate verification whose report is then presented to the administrator. The
administrator will be provided with an option to display the current status of application to the
applicant, which they can view in their online interface. After all the necessary criteria have been
met, the original information is added to the database and the passport is sent to the applicant.

(II) SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION

Passport Automation System is an interface between the Applicant and the Authority
responsible for the Issue of Passport. It aims at improving the efficiency in the Issue of Passport
and reduces the complexities involved in it to the maximum possible extent.

9
1.1 PURPOSE
If the entire process of 'Issue of Passport' is done in a manual manner then it would takes
several months for the passport to reach the applicant. Considering the fact that the number of
applicants for passport is increasing every year, an Automated System becomes essential to meet
the demand. So this system uses several programming and database techniques to elucidate the
work involved in this process. As this is a matter of National Security, the system has been
carefully verified and validated in order to satisfy it.

1.2 SCOPE
▪ The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning).

▪ The authority concerned with the issue of passport can use this system to reduce his
workload and process the application in a speedy manner.

▪ Provide a communication platform between the applicant and the administrator.

▪ Transfer of data between the Passport Issuing Authority and the Local Police for
verification of applicant's information.

▪ Users/Applicants will come to know their status of application and the date in which they
must subject themselves for manual document verification.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

▪ Administrator
Refers to the super user who is the Central Authority with the privilege to manage the entire
system. It can be any higher official in the Regional Passport Office of Ministry of External
Affairs.

▪ Applicant
One who wishes to obtain the Passport.
▪ PAS
Refers to this Passport Automation System.
▪ HTML
Markup Language used for creating web pages.

10
▪ J2EE
Java 2 Enterprise Edition is a programming platform java platform for developing and
running distributed java applications.

▪ HTTP
Hyper Text Transfer Protocol.
▪ TCP/IP
Transmission Control Protocol/Internet Protocol is the communication protocol used to
connect hosts on the Internet.

1.4 REFERENCES

IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java

1.6 TOOLS TO BE USED

• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and interconnections.

Specific Requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The PAS acts as an interface between the 'applicant' and the 'administrator'. This system
tries to make the interface as simple as possible and at the same time not risking the security of
data stored in. This minimizes the time duration in which the user receives the passport.

11
2.2 SOFTWARE INTERFACE
• Front End Client - The applicant and Administrator online interface is built using JSP
and HTML. The Administrator’s local interface is built using Java.

• Web Server – Apache Tomcat application server (Oracle Corporation).

• Back End – Oracle11g database.

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

▪ Secure Registration of information by the Applicants.
▪ Schedule the applicants an appointment for manual verification of original documents.

▪ Panel for Passport Application Status Display by the Administrator.

▪ SMS and Mail updates to the applicants by the administrator.
▪ Administrator can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

▪ Applicant
These are the person who desires to obtain the passport and submit the information to the
database.

▪ Administrator
He has the certain privileges to add the passport status and to approve the issue of
passport. He may contain a group of persons under him to verify the documents and give
suggestion whether or not to approve the dispatch of passport.

▪ Police
He is the person who upon receiving intimation from the PAS, perform a personal
verification of the applicant and see if he has any criminal case against him before or at
present. He has been vetoed with the power to decline an application by suggesting it to
the Administrator if he finds any discrepancy with the applicant. He communicates via
this PAS.

12
2.6 CONSTRAINTS
▪ The applicants require a computer to submit their information.
▪ Although the security is given high importance, there is always a chance of intrusion in
the web world which requires constant monitoring.

▪ The user has to be careful while submitting the information. Much care is required.
2.7 ASSUMPTIONS AND DEPENDENCIES
▪ The Applicants and Administrator must have basic knowledge of computers and English
Language.

▪ The applicants may be required to scan the documents and send.

( III )USECASE DIAGRAM:
The Passport Automation system use cases are:
1. Login
2. Registration
3. Verification
4. Check status
5. Enquiry
6. Dispatch Passport

ACTORS INVOLVED:
1. Applicant
2. Passport Officer
3. Police

USE-CASE NAME: LOGIN

The applicant login to the system to obtain a passport

USE-CASE NAME: REGISTRATION

The Applicant enters his name and details for applying a Passport .The applicant initially give his/
her details for registration.

USE-CASE NAME: VERIFICATION

The system verifies the applicant mandatory information given by him/her.

13
USE-CASE NAME: CHECK STATUS
The Applicant tries to check the status in which category applied. The system displays the
message to the applicant.

USE-CASE NAME: ENQUIRY

The police receive intimation from the PAS, perform a personal verification of the applicant and
see if he has any criminal case against him before or at present. He has been vetoed with the
power to decline an application by suggesting it to the Administrator if he finds any discrepancy
with the applicant. He communicates via this PAS.

USE-CASE NAME: DISPATCH PASSPORT

The administrator check or process the application which are submitted by applicant .Process the
application means the data which are given by the applicant is processed to create a passport for
the applicant and finally dispatches the passport to the applicant

14
 login

applicant

registration
passport officer

verification

check status

enquiry

police

dispatch passport

Fig.3. USECASE DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

15
(IV) ACTIVITY DIAGRAM:
The activity diagram represents the series of activities that are ocurring between the
[Link] is activity diagram which represents the Software personnel managemnet
system process .

Fig.4. ACTIVITY DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

(V) CLASS DIAGRAM:

16
The class diagram is referred as object modeling in the static analysis diagram. The main task of
object modeling is to graphically show what each object will do in the problem domain.

The problem domain describes the structure and the relationships among objects. The
Passport Automation system class diagram consists of five classes

1. Login class
2. Appointment class
3. Registration class
4. Authority class
5. Verification class

7) LOGIN CLASS:
It consists of two attributes and two operations. The attributes are user name, and password. The
operations of this class are creating login ( ), sign in ( ).

8) APPOINMENT CLASS:

The attributes of this class are appointment id, applicant id, date, time, and description. The
operation of this class are get appointment ( ), get appointment status ( ), Modify ( ), cancel ( ).

9) REGISTRATION CLASS:

The attributes are applicant id, name, dob, gender, birthplace, father name, addr1, addr2, district,
state, country, pin code, mobile, email id, qualification. The operation are add ( ), modify ( ),
view ( ).

10) AUTHORITY CLASS:

The attributes of this class are officered, name, designation, and password. The operations are
search ( ).

11) VERIFICATION CLASS:

The attributes of this class are verification id, appointment id, applicant id, officer id,
status id, description. The operation are verify ( ).

17
 [Link] DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

(VI) INTERACTION DIAGRAM:

▪ A sequence diagram represents the sequence and interactions of a given USE-CASE or

scenario. Sequence diagrams can capture most of the information about the system.

▪ Most object to object interactions and operations are considered events and events include
signals, inputs, decisions, interrupts, transitions and actions to or from users or external
devices.

▪ An event also is considered to be any action by an object that sends information.

▪ The event line represents a message sent from one object to another, in which the
“form” object is requesting an operation be performed by the “to” object. The “to” object
performs the operation using a method that the class contains.

▪ It is also represented by the order in which things occur and how the objects in the system
send message to one another.

18
▪ The sequence diagram for each USE-CASE that exists when a user administrator, check
status and new registration about passport automation system are given.

UI LoginClass RegistrationClass AppointmentClass

: applicant

Create Login

Enter Username/Pwd

Check username/Pwd

save username/pwd

Signin

get username/pwd

Check username/Pwd

show Registration Form

Enter applicant information

check applicant information

save applicant information

get date and time

save date and time

shows applicant ID, Date & time

19
 Database

[Link] DIAGRAM FOR LOGIN AND VERIFICATION

5: Check username/Pwd
12: Check username/Pwd

1: Create Login
3: Enter Username/Pwd
9: Signin 4:
14: Enter applicant information LoginCla
UI
ss

2:
8:
: applicant 13: show Registration Form
10: get username/pwd
24: shows applicant ID, Date & time
6: save username/pwd
23:
7:
11:

15:

16: check applicant information

Databas
17: save applicant information e

20: save date and time

Registratio 18:
nClass 19: get date and time
21:

22: Appointme
ntClass

[Link] DIAGRAM FOR LOGIN AND VERIFICATION

▪ The diagrams show the process done by the Passport Authority to the Passport
Automation system. The applicant has to enter his details.

▪ The details entered are verified by the Passport Authority and the applicant is approved if
the details match then the passport is dispatch, otherwise an appropriate error message is
displayed.

(VII) STATE CHART DIAGRAM:

▪ Every object undergoes through some state and on receiving some event the state gets
changed. This transition of the state can be represented by the state transition diagram.

20
 [Link] CHART DIAGRAM FOR PASSPORT AUTOMATION SYSTEM
(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM
Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

Fig.8.1 DEPLOYMENT DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

COMPONENT DIAGRAM
Component diagrams are used to visualize the organization and relationships among components
in a system.

21
 [Link] DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER
//Source file: [Link]

public class authorityClass

{ private int offcierId;
private string name; private
string description;
private string password;

/**
* @roseuid 5142EF4002BF
*/
public authorityClass()
{

/**
* @roseuid 5142ED5F01E4
*/
public void search()
{

}
}
//void [Link](){
//
// }

22
//Source file: [Link]

public class appointmentClass

{
private int appointmentId;
private int applicantId; private
date sate; private int time;
private string description;
public verificationClass theVerificationClass;

/**
@roseuid 50F8E90000BB
*/
public appointmentClass()
{

/**
@roseuid 50F8E4BA0271
*/
public void getappointment()
{

/**
@roseuid 50F8E4C503D8
*/
public void getappointmentStatus()
{

/**
@roseuid 50F8E4D20167
*/
public void modify()
{

/**
@roseuid 50F8E4D8032C
*/

23
 public void cancel()
{

}
}

(XI) IMPLEMENTATION OF USER INTERFACE LAYER

Fig.11.1. Login Form

24
 Fig.11.2. Registration Form

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the test
case format. It has all the information like preconditions, input data, output data, post
conditions, etc. It has a defined set of inputs which will provide the expected output.
• Informal test cases: Informal test cases are authored for such requirements where the exact
input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

25
Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for passport automation system has been successfully executed and
codes are generated.

26
Ex no: 2 BOOK BANK SYSTEM

AIM:
To create a system to perform book bank operation

(I) PROBLEM STATEMENT:

A Book Bank lends books and magazines to member, who is registered in the system. Also it
handles the purchase of new titles for the Book Bank. Popular titles are brought into multiple
copies. Old books and magazines are removed when they are out or date or poor in condition. A
member can reserve a book or magazine that is not currently available in the book bank, so that
when it is returned or purchased by the book bank, that person is notified. The book bank can
easily create, replace and delete information about the tiles, members, loans and reservations from
the system.

(II) SOFTWARE REQUIREMENTS SPECIFICATION:

1.0 INTRODUCTION

Book Bank is the interface between the students and Librarian. It aims at improving the
efficiency in the Issue of books or magazines and reduce the complexities involved in it to the
maximum possible extent.

1.1 PURPOSE

If the entire process of 'Issue of Books or Magazines' is done in a manual manner then it
would take several months for the books or magazines to reach the applicant. Considering the fact
that the number of students for Book Bank is increasing every year, an Automated System
becomes essential to meet the demand. So this system uses several programming and database
techniques to elucidate the work involved in this process. The system has been carefully verified
and validated in order to satisfy it.

1.2 SCOPE

The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning). The authority concerned with
the issue of books can use this system to reduce his workload and process the application in a
speedy manner.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

• Librarian - Refers to the super user who is the Central Authority who has been
vested with the privilege to manage the entire system.
• Student - One who wishes to obtain the Books or Magazines.

27
 • HTML - Markup Language used for creating web pages.

• J2EE - Java 2 Enterprise Edition is a programming platform and it is the part of

the java platform for developing and running distributed java applications.
• HTTP -Hyper Text Transfer Protocol
• TCP/IP - Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on the Internet.

1.4 REFERENCES

IEEE Software Requirement Specification format

1.5 TECHNOLOGIES TO BE USED

• Visual Basic
• Oracle 11g

1.6 TOOLS TO BE USED

• Visual Basic Tools

• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW

SRS includes two sections overall description and specific requirements.

Overall description will describe major role of the system components and
interconnections.

Specific requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION:

It will describe major role of the system components and inter-connections.

2.1 PRODUCT PERSPECTIVE

The SRS acts as an interface between the 'Students' and the 'Librarian'. This system tries
to make the interface as simple as possible and at the same time not risking the security of
data stored in. This minimizes the time duration in which the user receives the books or
magazines.

2.2 SOFTWARE INTERFACE

28
 • Front End Client - The Student and Librarian online interface is built using
Visual studio.
• Back End - Oracle 11 g database

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

• Secure Registration of information by the Students.

• Librarian can generate reports from the information and is the only authorized personnel
to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

• Student - They are the people who desire to obtain the books and submit the information
to the database.
• Librarian - He has the certain privileges to add the books and to approval of the
reservation of books.

2.6 CONSTRAINTS

• The Students require a computer to submit their information.

• Although the security is given high importance, there is always a chance of intrusion in
the web world which requires constant monitoring.
• The Students has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES

• The Student and Librarian must have basic knowledge of computers and English
Language.
• The Students may be required to scan the documents and send.

(III)USE-CASE DIAGRAM:
The book bank use cases are:
1. book_issue
2. book_return
3. book_order
4. book_entry

29
 5. search book_details

ACTORS INVOLVED:

1. Student
2. Librarian
3. Vendor

USECASE NAME : SEARCH BOOK_DETAILS

The librarian initiates this use case when any member returns or request the book and checking if
the book is available.

Precondition: The librarian should enter all Book details.

Normal Flow: Build message for librarian who search the book.
Post Condition: Send message to respective member who reserved the book.

USECASE NAME: BOOK_ISSUE

Initiated by librarian when any member wants to borrow the desired book. If the book is
available, the book is issued.

Precondition: Member should be valid member of library.

Normal Flow: Selected book will be issued to the member.
Alternative Flow: If book is not available then reserved book use case should be initiate.
Post Condition: Update the catalogue.

USECASE NAME: BOOK_ORDER

Initiated by librarian when the requested book is not available in the library at that moment.
The book is reserved for the future and issued to the person when it is available.
Precondition: Initiated only when book is not available.
Normal Flow: It reserved the book if requested.
Post Condition: Mention the entry in catalogue for reservation.

USECASE NAME: BOOK_RETURN

Invoked by the librarian when a member returns the book.

30
Precondition: Member should be valid member of library.
Normal Flow: Librarian enters bookid and system checks for return date of the book.
Alternative Flow: System checks for return date and if it returned late fine message will be
displayed.

Post Condition: Check the status of reservation.

USECASE NAME: BOOK_ENTRY

The purchase book use-case when new books invoke it or magazines are added to the library.
Precondition: Not available or more copies are required.
Normal Flow: Enter bookid,author information, publication information, purchased date, prize
and number of copies.

Post Condition: Update the information in catalogue.

31
 book_issue

student
librarian

book_return

book_entry

vendor
search book_details

book_order

Fig 3.1 USE-CASE DIAGRAM FOR BOOK BANK SYSTEM

32
(IV) ACTIVITY DIAGRAM:
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams can be used to describe the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control.

An activity is shown as an rounded box containing the name of the operation.

This activity diagram describes the behaviour of the system.

shows id
card

request for
specific book

is book
available? no enquires for
alternative book

yes
if satisfied?
borrows
book yes

no

librarian approves transaction

transaction cancelled

33
Fig4.1 ACTIVITY DIAGRAM [BORROW BOOK]

collects quotation
from vendors

no

if satisfied with
norms?

yes

place order

discount & mode of

payment finalised

takes delivery

bill amt paid

34
 Fig.4.2 ACTIVITY DIAGRAM [ ORDER BOOK]

shows id and
library card

librarian
makes entry

on or before
return date? no

pays fine

yes

librarian approves
transaction

Fig.4. 3 ACTIVITY DIAGRAM [RETURN BOOK]

(V) CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis diagram. The
main task of object modeling is to graphically show what each object will do in the problem
domain. The problem domain describes the structure and the relationships among objects.

35
 The ATM system class diagram consists of four classes:
1. Student
2. Book
3. Issue
4. Return
5. Vendor
6. Details

1) STUDENT:

It consists of twelve attributes and three operations. The attributes are enrollno, name, DOB,
fathername, address, dept name, batch and book limits. The operations of this class are
addStInfo(), deleteStInfo(), modifyStInfo().

2) BOOK:
It consists of ten attributes and four operations. This class is used to keep book
information such as author, title, vendor, price, etc

3) ISSUE:
It consists of eight attributes and two operations to maintain issue details such as, issue date,
accno of issued book, name of the student who borrowed book.

4) RETURN:
It consists of eight attributes and two operations to maintain issue details such as, issue
date, accno of issued book, name of the student who borrowed book.

5) STUDENTS:
The attributes of this class are name, dept ,year ,bcode no The operation is display
students().

6) DETAIL:
The attributes of this class are book name, author, bcode no The operations are delete
details().

36
Fig.5. CLASS DIAGRAM FOR BOOK BANK SYSTEM

37
(VI) SEQUENCE DIAGRAM:

A sequence diagram represents the sequence and interactions of a given USE-CASE or scenario.
Sequence diagrams can capture most of the information about the system. Most object to object
interactions and operations are considered events and events include signals, inputs, decisions,
interrupts, transitions and actions to or from users or external devices.

An event also is considered to be any action by an object that sends information. The event line
represents a message sent from one object to another, in which the “form” object is requesting an
operation be performed by the “to” object. The “to” object performs the operation using a method
that the class contains.

It is also represented by the order in which things occur and how the objects in the system send
message to one another.

38
 : issue : return search DB

Fig. 6.1. SEQUENCE DIAGRAM FOR BOOK ISSUE & RETURN

39
 1: request book
7: request for another book 14:enter issue data
13:provide student details
19:request toreturn book : issue
: librarian 17:updated successfully

6: not available
12:avilable 15:update issue status
18:issue book
: student 24:book returned 16:issue status updated

2: check available book DB

8: check availability
23:updated successfully

20:enter the book details 5: not avilable

11:avilable
3: check available book
21:update return status
9: check availabilty

4: not avilable
22:return status updated
10:available

: return
search

Fig. 6.2. COLLABORATION DIAGRAM FOR BOOK ISSUE & RETURN

(VII) STATE CHART DIAGRAM

It consists of state, events and activities. State diagrams are a familiar technique to describe
the behavior of a system. They describe all of the possible states that a particular object can get
into and how the object's state changes as a result of events that reach the object

40
 star book book

vendor supplies book student takes student returns book to

the from pays fine if

Fig. 7.1 STATE CHART DIAGRAM

(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

[Link] DIAGRAM

41
(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER

//Source file: E:\\sruthi\\[Link]

public class book1

{
private integer accno; private
string author; private string title;
private string edition; private
integer publicationid; private
double price; private date
purchaseDate; private integer
vendorId; private string
vendorName; private integer
isReference; public return1
theReturn1;
public vendor1 theVendor1;

/**
@roseuid 51187CA503B2
*/
public book()
{

/**
@roseuid 510F44A7007E
*/
public void viewBookDetails()
{

/**
@roseuid 510F44B50217
*/
public void addbookinfo()
{

/**
@roseuid 510F44BD0063
*/

42
 public void deletebookinfo()
{

/**
@roseuid 510F44C60045
*/
public void modifybookinfo()
{

}
}
/**

void [Link](){

void [Link](){
}
void [Link](){
}
void [Link](){
}
void [Link](){
}
void [Link](){

*/

12) //Source file: D:\\vaish\\[Link]

public class issue {

private date iisDate;
private integer issId;
private integer acno;
private string title; private
integer enNo; private
string name; private
integer deptId; private
integer batId;
public books theBooks;

43
 /**
@roseuid 5100DE750281
*/ public
issue()
{

}
}
//void [Link](){
//
// }
//void [Link](){
//
// }

13) //Source file: F:\\VAISH\\[Link]

public class return1

{ public integer returnid;
public date returndate;
public integer accno;
public string titlle; public
integer enrollno; public
string name; public string
dept; public integer batch;
public book theBook;

/**
@roseuid 50F92E4D0177
*/ public
return1()
{

/**
@roseuid 50F91C69005D
*/
public void bookreturn()
{

/**
@roseuid 50F91C6C0000

44
 */
public void modify()
{

}
}

14) //Source file: F:\\VAISH\\[Link]

public class student

{ public integer enrollno;
public string name; public
date DOB; public string
fathername; public string
address; public string
address2; public string
address3; public string
district; public string state;
public long pincode; public
integer deptid; public string
depname; public integer
batchid;
public integer booklimit; public
issue theIssue;
public return1 theReturn1;

/**
@roseuid 50F92E4D00FA
*/ public
student()
{

/**
@roseuid 50F918E6000F
*/
public void add()
{

/**
@roseuid 50F918EB03A9

45
 */ public void
delete()
{

/**
@roseuid 50F918EE029F
*/
public void modify()
{

}
}

15) //Source file: F:\\VAISH\\[Link]

public class vendor1

{ private integer vendorid;
private string name; private
string address1; private
string address2; private
string address3;

/**
@roseuid 5118C814009C
*/
public vendor1()
{

/**
@roseuid 5118B75100AB
*/
public void bookOrder()
{

/**
@roseuid 5118B75702BF
*/
public void modify()
{

46
 }
}
//void [Link](){
//
// }

(X) IMPLEMENTATION OF USER INTERFACE LAYER

47
TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the test
case format. It has all the information like preconditions, input data, output data, post
conditions, etc. It has a defined set of inputs which will provide the expected output.
• Informal test cases: Informal test cases are authored for such requirements where the exact
input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

48
Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for Book Bank System has been successfully executed and codes are
generated.

49
Ex no: 3 EXAM REGISTRATION SYSTEM

AIM:
To create a system to perform the Exam Registration system

PROBLEM STATEMENT:

Exam Registration [Link] used in the effective dispatch of registration form to all of the
students. This system adopts a comprehensive approach to minimize the manual work and
schedule resources, time in a cogent manner. The core of the system is to get the online
registration form (with details such as name, [Link] etc.,) filled by the student whose testament is
verified for its genuineness by the Exam Registration System with respect to the already existing
information in the database. This forms the first and foremost step in the processing of exam
application. After the first round of verification done by the system, the information is in turn
forwarded to the Exam Controller. The application is then processed manually based on the report
given by the system. The system also provides the student the list of exam [Link] controller
will be provided with fees details to display the current status of application to the student, which
they can view in their online interface. After all the necessary criteria has been met, the original
information is added to the database and the hall ticket is sent to the student.

(I)SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION
Exam Registration System is an interface between the Student and the Exam Controller
responsible for the Issue of Hall Ticket. It aims at improving the efficiency in the Issue of Hall
ticket and reduces the complexities involved in it to the maximum possible extent.

1.1 PURPOSE
If the entire process of 'Issue of Hall ticket' is done in a manual manner then it would
takes several days for the hall ticket to reach the student. Considering the fact that the number of
students for hall ticket is increasing every year, an Automated System becomes essential to meet
the demand. So this system uses several programming and database techniques to elucidate the
work involved in this process. As this is a matter of National Security, the system has been
carefully verified and validated in order to satisfy it.

1.2 SCOPE
• The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning).
• The controller concerned with the issue of hall ticket can use this system to reduce his
workload and process the application in a speedy manner.
• Provide a communication platform between the student and the controller.

• Students will come to know their status of application and the date in which they must
subject themselves for manual document verification.

50
1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS
• Exam Controller - Refers to the super user who is the Central Authority who has been
vested with the privilege to manage the entire system.
• Student - One who wishes to obtain the Hall Ticket.
• ERS - Refers to this Examination Registration System.
• HTML - Markup Language used for creating web pages.
• J2EE – Java 2 Enterprise Edition is a programming platform java platform for
developing and running distributed java applications.
• HTTP - Hyper Text Transfer Protocol.
• TCP/IP – Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java
1.6 TOOLS TO BE USED
• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements - Overall
Description will describe major role of the system components and inter-connections. Specific
Requirements will describe roles & functions of the actors.

2. [Link] DESCRIPTION
2.1 PRODUCT PERSPECTIVE
The ERS acts as an interface between the 'student' and the 'exam controller'. This system
tries to make the interface as simple as possible and at the same time not risking the security of
data stored in. This minimizes the time duration in which the user receives the hall ticket.

2.2 SOFTWARE INTERFACE

• Front End Client - The exporter online interface is built using JSP and
HTML.
• Web Server – Apache Tomcat Server (Oracle Corporation)
• Back End - Oracle 11g database

51
 2.3 HARDWARE INTERFACE
The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

• Secure Registration of information by the Students.
• SMS and Mail updates to the students by the controller.
• Controller can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

• Student - They are the people who desire to obtain the hall ticket and submit the
information to the database.
• Exam controller - He has the certain privileges to add the registration status and
to approve the issue of hall ticket. He may contain a group of persons under him to verify
the documents and give suggestion whether or not to approve the dispatch of hall ticket.

2.6 CONSTRAINTS
• The applicants require a computer to submit their information.
• Although the security is given high importance, there is always a chance of intrusion in
the web world which requires constant monitoring.
• The user has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES

• The Students and Exam Controller must have basic knowledge of computers and English
Language.
• The student may be required to scan the documents and send.

(III)USECASE DIAGRAM:

The Exam Registration use cases in our system are:

1. Login
2. View exam details
3. Register
4. Acknowledgement
5. Fee Processing

ACTORS INVOLVED:
1. Student
2. System DB

USE-CASE NAME: LOGIN

The student enters his username and password to login and retrieve the information’.

52
USE-CASE NAME: VIEW EXAM DETAILS
The student view the details about the exam schedule which contains Date,time,etc...

USE-CASE NAME: REGISTER

The student should notify the fee details that only the student can pay the correct amount

USE-CASE NAME: ACKNOWLEDGEMENT

The exam fees should be paid by the student to get the hall ticket from the exam
controller.

USE-CASE NAME: FEE PROCESSING

All the details should be viewed by both the student and the controller to verify whether
all the entered details are correct.

Login

View exam details

System DB
Student
<<include>>
Register
Fee processing

Acknowledgement

Fig. 3. 1. USECASE DIAGRAM FOR EXAM REGISTRATION SYSTEM

(IV) ACTIVITY DIAGRAM:

53
(V)CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis diagram. The
main task of object modeling is to graphically show what each object will do in the problem
domain. The problem domain describes the structure and the relationships among objects.

54
 The Exam Registration System class diagram consists of four two classes of registration
system.

1. Student_details
2. Exam_details
3. Register

1) STUDENT_DETAILS

It consists of six attributes and six operations. The attributes id, password, name, age, sex,
course. The operations of this class are login(), logout(), conformation(), register(),
newfeesdetails().

2) EXAM_DETAILS

It consists of four attributes and six methods. The attributes are userid, password,
examfees, fees due. The methods are login(),logout(), feesdetails(), displayfees(), conformation(),
examcontroller().

3) REGISTER
This class is used to maintain the registered student information such as, subject registered, date
of registration and etc,.

55
 Fig.5.1 CLASS DIAGRAM FOR EXAM REGISTRATION SYSTEM
(VI)INTERACTION DIAGRAM:

A sequence diagram represents the sequence and interactions of a given USE-CASE or scenario.
Sequence diagrams can capture most of the information about the system. Most object to object
interactions and operations are considered events and events include signals, inputs, decisions,
interrupts, transitions and actions to or from users or external devices.

An event also is considered to be any action by an object that sends information. The event line
represents a message sent from one object to another, in which the “form” object is requesting an
operation be performed by the “to” object. The “to” object performs the operation using a method
that the class contains.

It is also represented by the order in which things occur and how the objects in the system
send message to one another.

56
 Fig. 6.1. SEQUENCE DIAGRAM FOR REGISTRATION SYSTEM

The sequence and collaboration diagram represents that the student enter the information to get
the hall ticket and the exam controller issues the hall ticket after verifying the necessary items and
this data are stored in the database.

57
 : Exam _details

: System DB

1: enter(uid,pwd)4: Successfully stored 8:

: Student
6: View exam details
10: Get reg form
12: Fill registration form 7: Get exam details
16: Store student details 3: Store uid,pwd
17: return regid
2: Check validation
5: 13: Check given data
9:
11:
15: Verify cri
teria 19: Acknowledgement & display reg id

18: UI: Internet

Explorer
: Register
14: register

Fig. 6.2. COLLABORATION DIAGRAM FOR REGISTRATION SYSTEM

(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

58
 [Link] DIAGRAM

COMPONENT DIAGRAM

Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM

59
(VIII) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER
//Source file: D:\\uma\\[Link]

public class examDetails

{
private string examCode;
private string examName;
private string subjectId;
private string subjectName;
private time duration;
private date dateOfExam;
private double fee; private
integer ageLimit;
private string criteria; private string
examCentreName; private string
examCentreCode; public studentDetails
theStudentDetails; public register
theRegister;

/**
* @roseuid 515AA57101B5
*/
public examDetails()
{

/**
* @roseuid 515AA448037A
*/
public void addExam()
{

/**
* @roseuid 515AA44F00BB
*/
public void updateExam()
{

/**

60
* @roseuid 515AA4570280
*/
public void delExam()
{

}
}
//void [Link](){
//
// }

//Source file: F:\\Vaish\\[Link]

public class Register

{ private int studid;
private String ExamCode;
private String subid;
private int [Link];
private double fees;
private string regid;
private String ExamCenterCode;

/**
@roseuid 51342F76033C
*/ public
Register() {

/**
@roseuid 51342C88004E
*/
public void getRegister()
{

/**
@roseuid 51342C8E0271
*/
public void cancelRegister()
{

/**

61
 @roseuid 51342CA20109
*/
public void verifyIngormation()
{

}
}
//[Link]()
//[Link](){
// return null;
// }
//[Link](){
//
// }
//[Link](){
//
// }

//Source file: F:\\Vaish\\[Link]

public class StudentDetails

{ private string
Studname; private
integer Studid; private
Date DOB;
private String gender;
private String qualification;
private string Address;
private integer mobileno;
private string emailid;
private string username;
private string password;

/**
@roseuid 51342F7602CE
*/
public StudentDetails()
{

/**
@roseuid 51342B4901E4
*/
public void addStudent()
{

62
 }

/**
@roseuid 51342B4F03A9
*/
public void updateStudent()
{

/**
@roseuid 51342B58029F
*/
public void getLogic()
{

}
} /** void
[Link](){

}
[Link]()

63
void [Link](){
}
void [Link](){

*/

(IX) IMPLEMENTATION OF USER INTERFACE LAYER

Fig.9.1. REGISTRATION FORM

64
 Fig.9.2 LOGIN FORM

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the test
case format. It has all the information like preconditions, input data, output data, post
conditions, etc. It has a defined set of inputs which will provide the expected output.
• Informal test cases: Informal test cases are authored for such requirements where the exact
input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login

65
 ▪ File Name: [Link]

Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for Exam Registration system has been successfully executed and codes
are generated.

66
Ex no: 4 STOCK MAINTENANCE

AIM:
To create a system to perform the Stock maintenance
(I)PROBLEM STATEMENT
The stock maintenance system must take care of sales information of the company and must
analyze the potential of the trade. It maintains the number of items that are added or removed.
The sales person initiates this Use case. The sales person is allowed to update information and
view the database.

(II) SOFTWARE REQUIREMENT SPECIFICATION

1.0 INTRODUCTION
Stock maintenance is an interface between the customer and the sales person. It aims at
improving the efficiency in maintaining the stocks.

1.1 PURPOSE
The entire process of Stock maintenance is done in a manual manner Considering the fact
that the number of customers for purchase is increasing every year, a maintenance system is
essential to meet the demand. So this system uses several programming and database techniques
to elucidate the work involved in this process.

1.2 SCOPE
• The System provides an interface to the customer where they can fill in
orders for the item needed.

• The sales person is concerned with the issue of items and can use this
system.
• Provide a communication platform between the customer and the sales
person.
1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS
• Market Data provider: One who analyze the product and distribute the news.
• Customer: One who takes order of product
• Sales person: One who maintains the stock details

67
 1.4 REFERENCES
IEEE Software Requirement Specification format

1.5 TECHNOLOGIES TO BE USED

• Visual Studio
• VB Script

1.6 TOOLS TO BE USED

• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and inter-
Connections
Specific Requirements will describe roles & functions of the actors.
2.0 OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
The Stock maintenance acts as an interface between the 'customer' and the 'sales person'.
This system tries to make the interface as simple as possible and at the same time not risking the
work of data stored in

2.2 SYSTEM FUNCTIONS

• Secure order of information by the customer
• Schedule the customer an appointment for manual delivery of the product.

2.3 USER CHARACTERISTICS

1. Customer: The person who orders for the item.
2. Validate customer: The items ordered by the customer are validated.
3. Sales Detail: Maintains the stock details after delivering the items to the customer.
2.4 CONSTRAINTS

68
 1. The customer should wait until the trade contractor and other to analyze the product.
2. After the distribution of the news about the product. The customer can take order and
request of sales person to fill it.

3. Finally the sales person delivers the order.

(III) USE CASE DIAGRAM
The functionality of a system can be described in a number of different use-cases, each of
which represents a specific flow of events in a system. It is a graph of actors, a set of use-cases
enclosed in a boundary, communication, associations between the actors and the use-cases, and
generalization among the use-cases.

The use cases used in this system are

1. Product details: Used for placing an order.
2. Purchase details: Used for tracking items that have been ordered.
3. sales details: Used for give the sales particulars about a item.
4. stock details: Used for give the stock detail in a shop.
5. Purchase the product: Used to provide bills for the customer.
6. supply the product: Used to give the order product to customer.
ACTORS
The actors used in this system are
1. Customer: The person who orders for the item.
2. Shopkeeper: The items ordered by the customer are validated.
3. Company: Maintains the stock details after delivering the items to the customer.

69
 product details

purchase details

shopkeeper customer
sales details

stock details

purchase the product

company

supply the product

Fig.3. USE CASE DIAGRAM

(IV) ACTIVITY DIAGRAM

It shows organization and their dependence among the set of components. These diagrams
are particularly useful in connection with workflow and in describing behavior that has a lot of
parallel processing. An activity is a state of doing something: either a real-world process, or the
execution of a software routine.

70
 login

order check
product availability

product stock
details

if available if not available

do
payment

cancle
order

get
payment

recive the
stock

logout

Fig.4. ACTIVITY DIAGRAM

(V) CLASS DIAGRAM

Description:
• A class diagram describes the type of objects in system and various kinds of
relationships that exists among them.

• Class diagrams and collaboration diagrams are alternate representations of object

models.

71
The Stock maintenance system class diagram consists of seven classes:
1. PurchaseDetails: One who takes orders for the product?
2. SalesDetails: The customer make an order for the required products.
3. Product Details: The items that are stored as stock.

Fig.5. CLASS DIAGRAM

(VI)UML INTERACTION DIAGRAMS

It is the combination of sequence and collaboration diagram. It is used to depict the flow
of events in the system over a timeline. The interaction diagram is a dynamic model which shows
how the system behaves during dynamic execution.

1. SEQUENCE DIAGRAM
A sequence diagram represents the sequence and interactions of a given
USECASE or scenario. Sequence diagrams can capture most of the
information about the system. Most object to object interactions and operations
are

72
 considered events and events include signals, inputs, decisions, interrupts,
transitions and actions to or from users or external devices.

o An event also is considered to be any action by an object that sends

information. The event line represents a message from one object to another,
in which the

“from” object is requesting an operation be performed by the “to” object. The

“to” object performs the operation using a method that the class contains.

o It is also represented by the order in which things occur and how the objects in
the system send message to one another.

customer shopekeeper dealer database

1. request for item

2. enter the details

[Link] for item

[Link] for product availability

[Link] product details

. 6. product available

7. send for quation

[Link] for delivery

[Link] item

[Link] delivery details

[Link] delivery

73
 Fig.6.1 SEQUENCE DIAGRAM

2. COLLABORATION DIAGRAM
Collaboration diagram and sequence diagrams are alternate representations of an
interaction. A collaboration diagram is an interaction diagram that shows the order of
messages that implement an operation or a transaction. Collaboration diagram is an
interaction diagram that shows the order of messages that implement an operation or a
transaction. Collaboration diagram shows object s, their links and their messages. They can
also contain simple class instances and class utility instances.

During, analysis indicates the semantics of the primary and secondary interactions.
Design, shows the semantics of mechanisms in the logical design of system.

1 request for
8 request for
shopek
custom epe
r
enter the
11 product
2

7 send for update delivery

9
10 recording

send for
order
3
5 update product

4 check for
deale databa
e
6 product

Fig.6.2 COLLABORATION DIAGRAM

74
(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

[Link] DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components
of a system where the software components are deployed.

(VIII) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER

//Source file: E:\\10764\\[Link]

public class productDetails

{
private integer prodCode;
private string prodName;
private integer prodQty;
private float prodPrice;

/**
@roseuid 5167CD420232
*/
public productDetails()
{

/**
@roseuid 512702DE0128
*/
public void prodAdd()

75
 {

/**
@roseuid 512702E4003E
*/
public void prodDelete()
{

/**
@roseuid 512702EF003E
*/
public void prodUpdate()
{

}
/**
@roseuid 512B3FAC007F
*/
public void prodDetails()
{

}
}//Source file: E:\\10764\\[Link]

public class purchaseDetails

{ private integer
purcCode; private
date purcDate; private
integer subid; private
string subname;
private integer purcQty;
private float purcPrice;

/**
@roseuid 5167CD4201D4
*/
public purchaseDetails()
{

/**
@roseuid 5127049302DE
*/
public void save()
{

76
 }

/**
@roseuid 512704970232
*/ public void
delete()
{

/**
@roseuid 5127049F00FA
*/
public void purchasedit()
{

/**
@roseuid 512B3FC102C1
*/
public void purchaseDetials()
{

}
}
//Source file: E:\\10764\\[Link]

public class salesDetails

{ private integer
salId; private date
salDate; private
integer custCode;
private string
custName; private
integer prodCode;
private integer price;
private integer qty;

/**
@roseuid 512840E5009C
*/
public salesDetails()
{

/**

77
 @roseuid 512705AD030D
*/
public void sale()
{

}
}

(IX) IMPLEMENTATION OF USER INTERFACE LAYER

78
TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly. The process of
developing test cases can also help find problems in the requirements or design of an
application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.
• Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are
not authored but the activities done and the outcomes are reported once the tests are
run.

Test Cases Examples:

▪ Module: User Login

79
 ▪ File Name: [Link]

Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for stock maintenance system has been successfully executed and
codes are generated.

80
Ex. No: 5 ONLINE COURSE RESERVATION SYSTEM

AIM:

To create a system through which students can register to the courses desired by them.

(I)PROBLEM STATEMENT

The system is built to be used by students and managed by an administrator. The

student and employee have to login to the system before any processing can be done. The
student can see the courses available to him/her and register to the course he/she wants. The
administrator can maintain the course details and view all the students who have registered to
any course.

(II) SOFTWARE REQUIREMENT SPECIFICATION

1.0. INTRODUCTION

Course Reservation System is an interface between the Student and the Registrar
responsible for the issue of Course. It aims at improving the efficiency in the issue of Course
and reduces the complexities involved in it to the maximum possible extent.

1.1 PURPOSE
If the entire process of 'Issue of Course' is done in a manual manner then it would
takes several months for the course to reach the applicant. Considering the fact that the
number of applicants for course is increasing every year, an Automated System becomes
essential to meet the demand. So this system uses several programming and database
techniques to elucidate the work involved in this process.

1.2 SCOPE
▪ The System provides an online interface to the user where they can fill in their
personal details and submit the necessary documents (may be by scanning).

▪ The Registrar concerned with the issue of course can use this system to reduce his
workload and process the application in a speedy manner.

▪ Provide a communication platform between the Student and the Registrar.

81
1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

▪ Registrar
Refers to the super user with the privilege to manage the entire system.
▪ Applicant
One who wishes to register the Course
▪ OCRS
Refers to online Course Reservation System.
▪ HTML
Markup Language used for creating web pages.
▪ J2EE
Java 2 Enterprise Edition is a programming platform java platform for developing and
running distributed java applications.

▪ HTTP
Hyper Text Transfer Protocol.
▪ TCP/IP
Transmission Control Protocol/Internet Protocol is the communication protocol used
to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java

1.6 TOOLS TO BE USED

• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and interconnections.

Specific Requirements will describe roles & functions of the actors.

82
2.0 OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
The OCRS acts as an interface between the 'Student' and the 'Registrar'. This system
tries to make the interface as simple as possible and at the same time not risking the security
of data stored in. This minimizes the time duration in which the user receives the course.

2.2 SOFTWARE INTERFACE

• Front End Client - The Student and Registrar online interface is built using JSP and
HTML. The Administrators's local interface is built using Java.

• Web Server – Tomcat Apache application server (Oracle Corporation).

• Back End – Oracle 11g database.

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access
to the database in the server.

2.4 SYSTEM FUNCTIONS

• Secure Reservation of information by the Students.
• SMS and Mail updates to the students by the Registrar
• Registrar can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

• Applicant - They are the person who desires to obtain the course and submit
the information to the database.

• Administrator - He has the certain privileges to add the course status and to
approve the issue of course. He may contain a group of persons under him to verify
the documents and give suggestion whether or not to approve the dispatch of course.

2.6 CONSTRAINTS
• The applicants require a computer to submit their information.
• Although the security is given high importance, there is always a chance of intrusion
in the web world which requires constant monitoring.

• The user has to be careful while submitting the information. Much care is required.

83
2.7 ASSUMPTIONS AND DEPENDENCIES
• The Applicants and Administrator must have basic knowledge of computers and
English Language.

• The applicants may be required to scan the documents and send

(III)USE-CASE DIAGRAM:

The course registration system has the following use-cases

1. Login
2. View course details
3. Reserve for course
4. Pay fee
5. Check status

ACTORS INVOLVED:
1. Student
2. Registrar
USE-CASE NAME: LOGIN
The user enters the username and password and chooses if the user is student or Registrar. If
entered details are valid, the user’s account becomes available. If it is invalid, an appropriate
message is displayed to the user.

USE-CASE NAME: VIEW COURSE DETAILS

In this use case, a student can search all the courses available to him and choose the best
course he wants. The student can view the course duration, faculty and department of the
courses he may choose.

USE-CASE NAME: RESERVE FOR COURSE

When a student has successfully chosen a course, he can register to that course. Upon
registration, the student’s details are stored in the database.

USE-CASE NAME: PAY FEE

After registration to any course, the student may see the details of his current course. He may
wish to know details about fees and other information.

USE-CASE NAME: CHECK STATUS

The student tries to check the status in which category applied. The system displays the status
information to the student.

84
 view course details

Registrar

Student
login

<<include>>
pay fee
reserve for course

check status

[Link]-CASE DIAGRAM

85
(IV) ACTIVITY DIAGRAM:

Fig.4. ACTIVITY DIAGRAM

86
(V) CLASS DIAGRAM:
The class diagram is a graphical representation of all the classes used in the system and
their operations, attributes and relationships.
The course registration system makes use of the following classes:
1. Student
2. Course Catalog
3. Reserve Course

1) STUDENT:
It consists of the details of all the students present in the database. The attributes
present in this class are student id, student name, student qualification, student address1,
student address2, student address3, student mobile no, student emailed,, student dob,
student sex. The object of this class is created as soon as the student registers to a
course. The operations available to this class are add details (), modify details (), del
details (), reserve course().

2) COURSE CATALOG:
The course catalog class consist of course id, course name, course duration
course fee, course eligibility, total no of seat, course avail seat. The operations are add
course(), update course(), del course().

3) RESERVE COURSE:
The reserve catalog class consists of student id, course id, date, amt paid, reg id,
DD no. the operation are get course details(), check eligibility(), confirm registration().

87
Fig.5. CLASS DIAGRAM

88
(VI) INTERACTION DIAGRAM:
• A sequence diagram represents the sequence and interactions of a given USE-CASE or
scenario. Sequence diagrams can capture most of the information about the system.
Most object to object interactions and operations are considered events and events
include signals, inputs, decisions, interrupts, transitions and actions to or from users or
external devices.

• An event also is considered to be any action by an object that sends information. The
event line represents a message sent from one object to another, in which the “form”
object is requesting an operation be performed by the “to” object. The “to” object
performs the operation using a method that the class contains.

• It is also represented by the order in which things occur and how the objects in the
system send message to one another.

• The sequence diagram for each USE-CASE that exists when a user administrator, check
status and new registration about course registration system are given.

• Users have to first login to the system before performing any operation. The user has to
provide the necessary details to the system for login.

89
: Student UI : ReserveCourse : Course Catalog

Login(username,pwd)

Check Data

View course details

getCoursedetails

Reserve course

View reservation form

Fills up the reservation form

confirmReservation

getCourseDetails

ckeckEligibilityCriteria

Eligible&Seat available

Registers for the course

[Link] DIAGRAM

90
 :
Cata

: 1 )
4 View course
1
8 Reserve
1 Fills up the

5
1 6
3
7
1 9 View
1 Registers for 2 Check

1 Eligible&Seat
:
U
1

[Link] DIAGRAM

• After login, the student has to register to a course of his choice. The student can view all
the courses available to him and register to a course suitable to him. The student may
view the course details before registration.

• A student may wish to view course details before registration. For this, the student has to
first login and select the course details he wishes to see.

91
(VII) STATE CHART DIAGRAM:
Every object undergoes through some state and on receiving some event the state gets changed.
This transition of the state can be represented by the state transition diagram.

Login to course registration View get list of courses Select Enter data Fill form
course course

after clicking

Pay fees Gets Submit

Confirmation form
Eligible sending form to registrar

Gets receipt
not eligible

Reserves
seat

Fig.7. STATE CHART DIAGRAM

92
(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM
Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

[Link] DIAGRAM

COMPONENT DIAGRAM:
Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM

93
(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER

//Source file: [Link]

public class coursecatalog

{ private integer courseid; private
integer coursename; private integer
courseduration; private double
coursefees; private string
courseeligibilitycritiria; private string
totalnoofseats; private integer
courseavailable;
public reservecourse theReservecourse;

/**
@roseuid 512350660128
*/
public coursecatalog()
{

/**
@roseuid 51234FBD005D
*/
public void addcourse()
{

/**
@roseuid 51234FC80138
*/
public void updatecourse()
{

/**
@roseuid 51234FD20251
*/
public void deletecourse()
{

}
}

//Source file: [Link]

94
public class reservecourse
{ private integer studentid;
private integer courseid;
private date date; private
double amountpaid; private
integer registerid;
private string DDno;

/**
@roseuid 512350660167
*/
public reservecourse()
{

/**
@roseuid 51234EE5007D
*/
public void getcoursedetails()
{

/**
@roseuid 51234EF3003E
*/
public void checkeligibility()
{

/**
@roseuid 51234F0102AF
*/
public void confirmreg()
{

}}

(X) IMPLEMENTATION OF USER INTERFACE LAYER

95
16) Home Page

Login Page

96
 Course Catalog

Registration Form

ThanU Page

97
TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.
• Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

98
 Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for Course Reservation system has been successfully executed and
codes are generated.

99
Ex. No.: 6 E-TICKETING
AIM:
To create an automated system to perform E-ticketing.

(I) PROBLEM STATEMENT

Our project is carried out to develop software for online Railway Reservation System. This
system has various options like reservation, cancellation and to view details about available
seats. Our project mainly simulates the role of a Railway ticket booking officer, in a
computerized way.
The reservation option enables a person to reserve for a ticket at their home itself. All he/ she
has to do is to just login and enter the required details. After this the reservation database is
updated with the person details, train name and also the source and destination place.
The cancellation option enables the passenger to cancel the tickets that has been already booked
by him/her.
The availability option prompts the person to enter train number, train name and date of travel.
After this the availability database is accessed and available positions are produced.

(II) SOFTWARE REQUIREMENT SPECIFICATION

1.0 INTRODUCTION

The manual system of ticket reservation takes more time and the number of reservations per
day is limited. To increase the efficiency of the process, we go for online ticket reservation
system. This system supports online ticket booking.

1.1 PURPOSE

If the entire process of reservation is done in a manual manner then it would takes
several months for reservation to reach the applicant. Considering the fact that the number of
passenger is increasing every year, an Automated System becomes essential to meet the
demand. So this system uses several programming and database techniques to elucidate the
work involved in this process. As this is a matter of National Security, the system has been
carefully verified and validated in order to satisfy it.

1.2 SCOPE
• The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning).

• The authority concerned with the issue of railway can use this system to reduce his
workload and process the application in a speedy manner.

• Provide a communication platform between the passenger and the administrator.

100
1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

• Passenger – The person that who wishes to obtain the railway ticket.
• PNR – Passenger Name Records
• HTML - Markup Language used for creating web pages.
• J2EE – Java 2 Enterprise Edition is a programming platform java platform for
developing and running distributed java applications.

• HTTP - Hyper Text Transfer Protocol.

•TCP/IP – Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java

1.6 TOOLS TO BE USED

• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)
1.7 OVERVIEW
SRS includes two sections overall description and specific requirements –
Overall Description will describe major role of the system components and
interconnections.
Specific Requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE
This system tries to make the interface as simple as possible and at the same time not
risking the security of data stored in. This minimizes the time duration in which the user
receives the ticket.

2.2 SOFTWARE INTERFACE

• Front End Client - The passenger and System online interface is built using JSP and
HTML. The Administrators's local interface is built using Java.

101
 • Web Server – Apache Tomcat Server (Oracle Corporation)
• Back End - Oracle 11g database

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

• Secure Registration of information by the Passengers.
• System can generate reports from the information and is the only authorized personnel
to add the eligible application information to the database.

• Display the requested pages to the user.

• Update the database after every successful process.

2.5 USER CHARACTERISTICS

• Passenger - They are the people who desire to obtain the ticket and submit the
information to the database.

2.6 CONSTRAINTS
• The passengers require a computer to submit their information.
• Although the security is given high importance, there is always a chance of intrusion in
the web world which requires constant monitoring.

• The user has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES

• The Passengers must have basic knowledge of computers and English Language.

• The passengers may be required to scan the documents and send.

(III) USE-CASE DIAGRAM

The online ticket reservation system uses the following use cases:
1. Request for seat availability
2. makeReservation
3. Cancellation
4. Check status
5. Print ticket

ACTORS INVOLVED:

102
 1) System
2) Passenger

USE-CASE NAME: REQUEST FOR SEAT AVAILABILITY

The passenger can view the train available in the database for deciding which train ticket he
wishes to reserve. The passenger can search the train information based on journey date, train
type and reservation type. The passenger can view the details of flights such as, train number,
source station, destination station, arrival time, departure time, fare and number of seats
available.

USE-CASE NAME: MAKERESERVATION

The user is allowed to reserve a ticket on train as he/she requires on the particular date and
time. The user has to provide details such as name, train number, date of travel, source station,
destination station, proof name and money transaction details.

USE-CASE NAME: PRINT TICKET

The user after booking a ticket can print a copy of the ticket reserved. The user has to
provide the details about ticket number for searching in the database and passenger name for
confirming passenger identity.

USE-CASE NAME: CANCEL TICKET

A passenger can decide to cancel a ticket after the ticket is booked. The passenger has to
provide details about ticket for searching and details about him for confirmation of identity.

USE-CASE NAME: CHECK STATUS

The passenger can view the status of the reserved tickets. So the passenger can confirm his/her
travel.

103
 request for seat availability

<<includ>>

print
makeReservation
Passenger System

cancellation

check status

Fig.3.1 USE-CASE DIAGRAM FOR AIRLINE RESERVATION

104
(IV) ACTIVITY DIAGRAM
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams can be used to describe the business and operational step-bystep workflows of
components in a system. An activity diagram shows the overall flow of control. An activity is
shown as an rounded box containing the name of the operation.

This activity diagram describes the behaviour of the system.

• First state is login where the passenger login to the E-Ticketing system.
• The next state is filling details the passenger are used to fill the form.
• Then passenger used to selecting the flight.
• The passenger appears for book ticket and search details from E-Ticketing DataBase.

Check seat availablity based on

date/ train/reservation type

Yes
Is it valid
No data?

Show the Display the required

error page train information

Fig.4.1 ACTIVITY DIAGRAM [Check Availability]

105
Fig.4.2 ACTIVITY DIAGRAM [Ticket Reservation]

106
 request to check
pnr status

Enter the PNR

number

Is valid PNR Yes

No no?
Display
Invalid PNR the status
number

Fig.4. 3ACTIVITY DIAGRAM [Check Status]

107
 Fig.4. 4ACTIVITY DIAGRAM [Ticket Cancellation] (V) CLASS
DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis diagram. The
main task of object modeling is to graphically show what each object will do in the problem
domain. The problem domain describes the structure and the relationships among objects.

108
.
The online ticket reservation system makes use of the following classes:

1. ticketReservation
2. trainInfo
3. passengerInfo
4. seatAvailStatus

1. TICKETRESERVATION
It consists of twelve attributes and two operations. It records the details of every ticket
booked such as ticket number, passenger ID, source and destination station and etc.

2. TRAININFO
It stores the details of all the trains such as train number, train name, speed, source and
destination stations, etc.

3. PASSENGERINFO
It consists of seven attributes and three operations. This class is used to store passenger
details such as, passenger name, age, address and etc.

4. SEATAVAILSTATUS
This class is used to update the number of seats available for a particular train by using
updateStatus() operation.

109
Fig.5.1 CLASS DIAGRAM FOR E-TICKETING

110
(VI) INTERACTION DIAGRAM:

A sequence diagram represents the sequence and interactions of a given USECASE or

scenario. Sequence diagrams can capture most of the information about the system. Most object
to object interactions and operations are considered events and events include signals, inputs,
decisions, interrupts, transitions and actions to or from users or external devices.

An event also is considered to be any action by an object that sends information.

The event line represents a message sent from one object to another, in which the “form” object
is requesting an operation be performed by the “to” object. The “to” object performs the
operation using a method that the class contains.

This sequence diagram describes the sequence of steps to show

• Passenger are used to login the form. And then its verify the username and password.

• If the password and username are correct then applicants are used to login the filling
details.

• Passenger are used to selecting the train and book the tickets.
• Now the E-Ticketing DataBase verify the filling Details.
• And then the E-Ticketing DataBase displays the ticket information.
• Incase of any sudden change of the plan, the applicant can cancel the ticket.

111
Fig.6.1. SEQUENCE DIAGRAM

112
 7: Verify given details
1: Login(username,password)
5: Enter the passenger details
6: Perform money transaction
13: Print the ticket reserveTicket :
ticketReservation

4: Display the reservation page 2: Check given data

12: Confirm & Display the ticket
: Passenger
3: Registered user

System
14: request to cancel ticket 8: Update status

16: Select the passenger details 11:

9: Store the details

15: Display the cancellation page
19: Store the details
22: Ticket cancelled

17: Verify given details

10: Updated successfully

20: Updated successfully

18: Update status

cancelTicket :
ticketReservation : seatAvailStatus

21:

Fig.6.2 COLLABORATION DIAGRAM

113
(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

[Link] DIAGRAM

(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER

//Source file: E:\\sugan\\[Link]

public class passengerInfo
{
private integer passId; private
String PassName; private
integer age; private string sex;
private integer phoneno; private
String emailid;

/**
@roseuid 5121D2AB01D4
*/

114
 public passengerInfo()
{
}

/**
@roseuid 51188FBF0203
*/
public void addPassenger()
{
}

/**
@roseuid 51188FD00148
*/
public void updatePassenger()
{
}

/**
@roseuid 51188FD900FA
*/
public void delPassenger()
{
}
} /**
void [Link](){
}
void [Link](){
}
void [Link](){
}
[Link]() */

//Source file: E:\\SUGAN\\[Link]

public class setavailStatus

{ private integer transacid;
private date journeydate;
private integer availableseat;
private string resclass;

/**
@roseuid 51133F790138
*/
public setavailStatus()
{
}

/**

115
 @roseuid 51133CE3002E
*/
public void updatestatus()
{
}
}

//Source file: E:\\saras\\[Link]

public class reserve

{ private int passid; private int
trainid; private string source;
private string destina; private string
tclass; private int proofid; private
string proofname; private date date;
private int [Link];
private double spare; private int pnr;
private int reserveid;
public seatAvailableStatus theSeatAvailableStatus; public
trainInfor theTrainInfor;

/**
@roseuid 5110DA9C0232
*/ public reserve()
{
}

/**
@roseuid 5110D2CF0203
*/
public void reserveticket()
{
}

/**
@roseuid 5110D562007D
*/
public void cancelticket()
{
}
}

116
//Source file: E:\\sugan\\[Link] public
class trainInfo
{ private integer trainid; private string trainname;
private string sourcestn; private string desstn;
private time depatime; private time arrivaltime;
private stirng traintype; private integer distance;
private string speed; private double fare; private
Integer noOfSeats; public ticketReservation
theTicketReservation;
public seatAvailStatus theSeatAvailStatus;

/**
@roseuid 5121D2AB0186
*/ public trainInfo()
{
}

/**
@roseuid 511896750186
*/
public void addTrainInfo()
{

/**
@roseuid 5118967F0000
*/
public void updateTrainInfo()
{
}

/**
@roseuid 511896880186
*/
public void deleteTrainInfo()
{
}
} /** void [Link](){
}
void [Link](){
}
void [Link](){

*/

117
(X) IMPLEMENTATION OF USER INTERFACE LAYER

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.

118
 • Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for airline reservation system has been successfully executed and
codes are generated.

119
Ex no: 7 SOFTWARE PERSONNEL MANAGEMENT SYSTEM

AIM:
To implement a software for software personnel management system

(I) PROBLEM STATEMENT:

Software personnel management system allows employees to record time card

electronically and automatically generates pay slips based on number of hours worked and
total amount of sales. The system will run on individual employee desktops where the
employee can access and edit only their personal details. The system will maintain
information on the employee in the company in order to calculate the payroll. The employees
will also be able to know from the system, the number of hours worked per day and total of all
hours spent on a project and total pay received year-to-date etc. Payroll administrators keep
track of all the information including adding new employees, deleting employees, and edit
information and run reports. The system will generate records and performance report of the
employees.

( II )SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION

The Software Personnel Management system is an interface between Employee and

the Administrator responsible for generation of payment slip. It aims at improving the
efficiency in the generation of Pay slip and reduces the complexities involved in it to the
maximum possible extent.

1.1 PURPOSE
If the entire process of Software personnel management is done in a manual manner
then it would more time for pay slip generation process. Considering the fact that the number
of employee is increasing every year, a maintenance system is essential to meet the demand.
So this system uses several programming and database techniques to elucidate the work
involved in this process.

120
1.2 SCOPE
▪ Software system allows Administrator to manage its employee in a better way.
▪ When needed, it will take just a few second to find out the background of an employee
and his/her contribution to the organization, it will also facilitate keeping all the records
of employee.

▪ So all the information about an employee will be available in a few seconds, it will also
make it very easy to generate statistical data or custom data, line finding a certain set of
employee.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

▪ ADMINISTRATOR
Refers to the super user who is maintaining the employee
details. ▪ Employee
One who works for a software company.
▪ SPMS
Refers to this Software personnel management system.
▪ HTML
Markup Language used for creating web pages.
▪ J2EE
Java 2 Enterprise Edition is a programming platform java platform for developing and
running distributed java applications.

▪ HTTP
Hyper Text Transfer Protocol.

1.4 REFERENCES

IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java
• XML
• AJAX

121
1.6 TOOLS TO BE USED
• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and inter-connections.
Specific Requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The SPMS acts as an interface between the 'ADMINISTRATOR' and the 'employee'.
This system tries to make the interface as simple as possible and at the same time not risking
the security of data stored in. This minimizes the time duration in which to manage the
software personnel.

2.2 SOFTWARE INTERFACE

• Front End Client - The applicant and Administrator online interface is built using
JSP and HTML. The ADMINISTRATOR's local interface is built using Java.

• Web Server – Apache Tomcat application server(Oracle Corporation).

• Back End – Oracle 11g database.

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

Payment Slip
The payment module greatly reduces the workload of the ADMINISTRATOR
department by automating the payroll process, allowing ADMINISTRATOR to ensure
the payroll functions are completed on time and without errors. The payroll class

122
 automatically calculates payment amounts and various deductions such as income tax
before generating pay checks and employee tax reports.

View Salary
The employee views the salary details efficiently from the SPMS. The employees will
also be able to know from the system, the number of hours worked per day and total of
all hours spent on a project and total pay received year-to-date etc.

2.5 USER CHARACTERISTICS

▪ Employee
These are the person who desires to view the salary details.
▪ Administrator
Administrator has the certain privileges to generate pay slip for the employee.
▪ Database manager
DB manager stores all the data related to Employee and Administrator.

2.6 CONSTRAINTS

▪ The administrator requires a system to monitor information of the employee.

2.7 ASSUMPTIONS AND DEPENDENCIES

▪ The employee and Administrator must have basic knowledge of computers and English
Language.

(III) USECASE DIAGRAM:

The Software personnel management system use cases are:
1. Login
2. Job Assigned
3. View Salary
4. View Employee details
5. Generate payment slip
6. Create DB
7. Update DB
8. Delete DB

ACTORS INVOLVED:
1. Employee
2. Administrator

123
 3. Database Manager
USE-CASE NAME: LOGIN
The Employee login to the system to view the salary details

USE-CASE NAME: JOB ASSIGNED

The employee views the job assigned to him/ her by the Administrator.

USE-CASE NAME: VIEW SALARY

The employee views the salary details efficiently from the SPMS. The employees will also be
able to know the number of hours worked per day and total of all hours spent on a project and
total pay received year-to-date etc.

.
USE-CASE NAME: VIEW EMPLOYEE DETAILS
The Administrator views the details of the employee for the payroll process

USE-CASE NAME: GENERATE PAYMENT SLIP

The Administrator generates the pay slip based on the details of the no of hours/ no of days
worked by the employee.

USE-CASE NAME: CREATE DB

The database manager creates individual database tables for the employees

USE-CASE NAME: UPDATE DB

When an employee information changes the database manager updates individual database
tables for the employees.

USE-CASE NAME: DELETE DB

When an employee relieves/terminated the database manager deletes individual database tables
for the employees.

124
 Login

Job Assigned

Administrator

Employee View Salary

View Employee details

Generate Payment Slip

Create DB

Update DB

Delete DB
Database
Manager

Fig.3. USE CASE DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

125
(IV) ACTIVITY DIAGRAM:

The activity diagram notation is an action, partition, fork join and object node. Most of
the notation is self explanatory, two subtle points. Once an action finished, there is an
automatic outgoing transaction. The diagram can show both control flow and data flow.

Employee Administrator

Login

Login
view employee
Details

Do Work

Generate
Payroll

View Salary
Details
ViewPayroll

Logout

Fig.4. ACTIVITY DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

126
(V) CLASS DIAGRAM:

The class diagram is referred as object modeling in the static analysis diagram. The main task
of object modeling is to graphically show what each object will do in the problem domain.
The problem domain describes the structure and the relationships among objects. The
Software Personnel Management system class diagram consists of four classes

1. Employee class
2. Administrator class
3. Database Manager class
4. Payment class

1)EMPLOYEE CLASS
It consists of seven attributes and two operations. The attributes are empid, empname,
emppassword, address, mobile number, date, Hours Worked. The operations of this class are
Login( ) and viewsalary( ).

2)ADMINISTRATOR CLASS
It consists of attributes Adminid, Adminname and Adminpassword. The operations are login ( ),
Generate payroll ( ), view payroll ( ) and viewemployeedetail ( ).

3)DATABASE MANAGER CLASS

The attributes of this class are DBmanagerid, DBmanagername( ) and DBmanagerpassword.
The operation are create( ), update( ),delete( ) and display payroll( ).

4)PAYMENT CLASS
The attributes of this class are paymentid, empid, date, Basic pay, HRA, DA, PF, Netpay and
Gross pay. The operation are calculatesalary( ) and GenerateSlip( ).

127
Fig.5. CLASS DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

128
5)INTERACTION DIAGRAM:
▪ A sequence diagram represents the sequence and interactions of a given USE-CASE or
scenario. Sequence diagrams can capture most of the information about the system.

▪ Most object to object interactions and operations are considered events and events
include signals, inputs, decisions, interrupts, transitions and actions to or from users or
external devices.

▪ An event also is considered to be any action by an object that sends information.

▪ The event line represents a message sent from one object to another, in which the “form”
object is requesting an operation be performed by the “to” object.

▪ The “to” object performs the operation using a method that the class contains.
▪ It is also represented by the order in which things occur and how the objects in the
system send message to one another.

▪ The sequence diagram for each USE-CASE that exists when a user administrator, check
status and new registration about passport automation system are given.

EMPLOYEE:

DBManager
UI
employee :
Employee

Seek login

Request Job

Allot job

View Salary details

display payroll

Fig.6. [Link] DIAGRAM FOR EMPLOYEE

129
 1: seek login
3: request job
5: view salary details
employee UI

2:
4: allot job
8: display payroll

7:

6:

DB manager

Fig.6. [Link] DIAGRAM FOR EMPLOYEE

UI Payment Database Manager

: Administrator

Seek Login

View Employee Details

Display Employee Detail

Generate Payslip

Calculate Salary

return salary

Display Payroll

Fig.6. [Link] DIAGRAM FOR ADMINISTRATOR

1: seek login

130
 3: view employee details
7: generate payslip
administrator UI

2:
6: display employee details
12: display payroll
5:
11:
4:
8:

10: return salary

payment
DB manager

9: calculate salary

Fig.6. [Link] DIAGRAM FOR EMPLOYEE

(6) STATE TRANSITION DIAGRAM

▪ States of object are represented as rectangle with round corner, the transaction between
the different states.

▪ A transition is a relationship between two state that indicates that when an event occur
the object moves from the prior state to the subsequent.

Login View Employee Generate calculate

Detail Payroll Salary

Display
Payroll

[Link] TRANSITION DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

131
(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed

[Link] DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

COMPONENT DIAGRAM

Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM FOR SOFTWARE PERSONNEL MANAGEMENT SYSTEM

132
(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER

//Source file: [Link]

public class employee

{ private int emp_id;
private string
emp_name; private
string adrr1; private
string addr2; private
string addr3;
public administrator1 theAdministrator1;

/**
@roseuid 515D15470203
*/
public employee()
{

/**
@roseuid 515D1509029F
*/
public void login()
{

/**
@roseuid 515D150D031C
*/
public void view()
{

}
}
//Source file: [Link]
public class administrator1
{
private int admin_id;
private string
admin_name; private
string admin_pwd;
public employee theEmployee;

133
 /**
@roseuid 515D154701A5
*/
public administrator1()
{

/**
@roseuid 515D130F030D
*/ public void
login()
{

/**
@roseuid 515D13140271
*/
public void generatePayroll()
{

/**
@roseuid 515D131F0251
*/
public void viewPayroll()
{

}
}

134
(IX) IMPLEMENTATION OF USER INTERFACE LAYER

Fig.11. Generate Payroll

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.

135
 • Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for software personnel management system has been successfully
executed and codes are generated.

136
Ex no: 8 CREDIT CARD PROCESSING

AIM:
To create a system to perform the credit card processing

(I) PROBLEM STATEMENT:

Credit card processing through offline involves the merchant collecting order
information (including credit card numbers), storing this in a database on your site, and
entering it using their on-site merchant credit card processing system. Takes time to
manually enter credit card information for each order. This solution creates following
cons:

· Insecure – there is a possibility that a skilled hacker could break into the
database and steal an entire list of credit card numbers, thereby damaging the
merchant’s reputation with current client.

· There is a higher risk of customer charge backs with no signature

· Higher risk of fraud for using stolen credit cards
· Many discerning online shoppers will not give their credit card to an
“untrusted” online merchant (you may want to consider being part of the Better
Business Bureau or similar organization to add credibility).

So there is a need of online and trusted credit card processing.

(II) SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION

A credit card is a small plastic card issued to users as a system of payment. It

allows its holder to buy goods and services based on the holder's promise to pay for
these goods and services. The issuer of the card creates a revolving account and grants
a line of credit to the consumer (or the user) from which the user can borrow money for
payment to a merchant or as a cash advance to the user.

When a purchase is made the merchant swipes the card. The information
goes to a gateway processor, which either accepts or rejects the transaction. If it is

137
 accepted, the transaction is held until the end of the business day. The merchant
then reenters the transaction via the gateway processor, the data is logged, and the
debt is transferred to the account. The use of an ATM for cash advance is a similar
process.

If you are selling to consumers, merchant services will allow you to expand
your customer base and provide a more convenient method of payment than cash or
checks. And if you are interested in selling over the Internet, accepting credit card
processing is a must. Accepting credit cards allows funds to be transferred to your
bank account in less than a week. This can be a welcome relief for businesses that
experience a tight cash flow.

The two purchase options for Credit Card Processing

facility are: Validation only

• Credit card processing (which secures deposits at the time of booking)

With either option, credit card accounts entered during booking are
validated to assure that the account is active and in good standing. The credit card
processing option also allows properties to process credit card deposits.

1.1 PURPOSE
When customers complete their shopping cart, their credit card is preauthorized
and the order is entered into Sales Order. Credit Card Processing dials out and obtains a
credit card payment. Within five minutes the customer receives an e-mail receipt.

1.2 SCOPE
• Automatically connects to your financial network for credit card authorizations and
settlements

• Integrates with Sales Order, Accounts Receivable, and e-Business Manager

• Support for dial-up (modem) connections or secure Internet connections through TCP/IP
and SSL

• Compliant with Visa and MasterCard Electronic Commerce Indicator (ECI) regulations
• Multiple address verification options available

138
1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

• Authorization service - The issuer of the card creates a revolving

account and grants a line of credit to the consumer (or the user) from which the user can
borrow money for payment to a merchant or as a cash advance to the user.

•User- One who wishes to uses the credit card.

• CCP - Refers to this Credit Card Processing.

• HTML - Markup Language used for creating web pages.

•J2EE – Java 2 Enterprise Edition is a programming platform java platform for
developing and running distributed java applications.
• HTTP - Hyper Text Transfer Protocol.
•TCP/IP – Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java
1.6 TOOLS TO BE USED
• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)
1.7 OVERVIEW
SRS includes two sections overall description and specific requirements –
Overall Description will describe major role of the system components and
interconnections.

Specific Requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

This solution involves signing up for a free Business Account. Once this is
done and the e-commerce site is properly configured, you can accept payments from
Visa, MasterCard, Amex, and Discover cards payments.

2.2 SOFTWARE INTERFACE

• Front End Client - The applicant and Administrator online interface is built using JSP
and HTML. The Administrators's local interface is built using Java.

139
 • Web Server - Glassfish application server(SQL Corporation).
• Back End - SQL database.

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have
access to the database in the server.

2.4 SYSTEM FUNCTIONS

1. Accept credit card numbers on the web, store them in a database, then process them
offline

2. Credit card processing with CCP

3. Credit card processing with a third-party credit card processing company

2.5 USER CHARACTERISTICS

1) User/Customer - They are the people who desires to purchase the goods using credit
card.
2) Authorization Service
• Validate the credit card payments to ensure that the card number is valid and the card has
not expired
• Deposit processing to apply the deposit payment to the card
• Prepare Credit card transaction reports that show authorization codes, amounts, and
error/success messages

2.6 CONSTRAINTS
• Trusted if using a well known third-party processor
• Must suite for higher-volume sites
• Cheaper transaction rates
• Getting money transferred may be very fast
• Must provide fraud prevention measures and fraud protection programs

2.7 ASSUMPTIONS AND DEPENDENCIES

• The Applicants and Administrator must have basic knowledge of computers and English
Language.
• The applicants may be required to scan the documents and send.
( III )USECASE DIAGRAM:
The Passport Automation system use cases are:
Creating Account: Used to create a account.
Credit card request: Used to send the request to credit card.

140
Bank Enquiry: Used to get the bank enquiry like pin code to verify your user account.
Issuing card: Used to issuing the card to machine.
Purchase the item: Used to list out the purchase details in shop.
Prepare the bill: Used to issuing the bill for the purchased
item. paying bill: Used to transaction of money to paying the
bill.

ACTORS INVOLVED
Customer/user: The person who order for the item.
Banker: The person to check the account details.
Retailer: The person to preparing the bills.
USE-CASE NAME: PURCHASE PRODUCT
Customer purchases items from ecommerce site then proceeds to the site’s
secure checkout area.
.
USE-CASE NAME: AUTHORIZATION REQUEST
Credit card processor collects billing information from the customer via a secure
connection.

USE-CASE NAME: AUTHORIZATION RESPONSE

Billing information is verified and the transaction is completed by the credit card
issuer.

USE-CASE NAME: PAYMENT APPROVAL

The transaction details are recorded by the credit card processor and results are
securely relayed to the merchant. Merchant’s site receives transaction result and does
appropriate actions (e.g. saves the order & shows message).

141
 creating account

credit card request

bankenquiry

banker
issuing card
customer

purchase the item

prepare the bill

retailer

paying bill

Fig.3. USECASE DIAGRAM FOR PASSPORT AUTOMATION SYSTEM

142
(IV) CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis
diagram. The main task of object modeling is to graphically show what each object
will do in the problem domain. The problem domain describes the structure and the
relationships among objects.

The Credit Card Processing system class diagram consists of three classes.
They are

1. Banker
2. Customer
3. Retailer

[Link] DIAGRAM

(V) INTERACTION DIAGRAM:

▪ A sequence diagram represents the sequence and interactions of a given USE-CASE

or scenario. Sequence diagrams can capture most of the information about the system.

▪ Most object to object interactions and operations are considered events and events
include signals, inputs, decisions, interrupts, transitions and actions to or from users
or external devices.

▪ An event also is considered to be any action by an object that sends information.

143
▪ The event line represents a message sent from one object to another, in which the
“form” object is requesting an operation be performed by the “to” object.

▪ The “to” object performs the operation using a method that the class contains.
▪ It is also represented by the order in which things occur and how the objects in the
system send message to one another.

▪ The sequence diagram for each USE-CASE that exists when a user administrator,
check status and new registration about passport automation system are given.

C:Customer B:Banker

1: Select Bank

2: Creating Account

3: Requesting Card

4: Enquiry

5: Issuind Card

R:Retailer

6: select shop

7: Purchase Item

8: producing item for billing

9: preparing bills

10: Swipe the card

11: validate card

12: Paying the bills

13: returning amount

14: checking account details

[Link] DIAGRAM

144
 6: select shop
7: Purchase Item 9: preparing bills
8: producing item for billing
10: Swip e t he card
C:Custo R:Retail
mer er

12: Paying the bills

5: Issuind Card

1: Select Bank
2: Creating Account
3: Requesting Card
13: returning amount
14: checking account details

4: Enquiry

11: validate card

B:Banke
r

[Link] DIAGRAM

145
 (VI) State chart Diagram:
▪ States of object are represented as rectangle with round corner, the transaction
between the different states.

▪ A transition is a relationship between two state that indicates that when an event
occur the object moves from the prior state to the subsequent.

Start

[ new account
]
creating account
customer
do/ creating account

Exiting account
Request To Bank
[ Customer Enquiry
]

requesting for credit card Bank Processing enquiry from bank

do/ requesting credit card do/ bank enquiry

[ Satisfied Customer
]

issuing card
abort
do/ card delivery

End

Fig.6. STATE CHART DIAGRAM

146
DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of
a system where the software components are deployed.

[Link] DIAGRAM

COMPONENT DIAGRAM

Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM

147
(VII) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER
//Source file: E:\\10764\\[Link]

public class banker

{ private
integer BId;
private string
Bname;
private string Branch;

/**
@roseuid 5167CE2902EE
*/
public banker()
{

/**
@roseuid 512848F00127
*/
public void credit()
{

/**
@roseuid 512848FD031A
*/ public
void
verify()
{

/**
@roseuid 512849060098
*/
public void update()
{

}
}
//Source file: E:\\10764\\[Link]

148
public class
customer {
private integer CId;
private string
Cname; private
date Cdob; private
integer
CaccountNo;
private string
CAddress; private
integer CCardNo;
private integer
CPhoneNo;
private string CEmailId;

/**
@roseuid 5167CE29036B
*/
public customer()
{

/**
@roseuid 512849FA0212
*/
public void requestForward()
{

/**
@roseuid 51284A15033B
*/ public void
purchaseThings()
{

}
}
//Source file: E:\\10764\\[Link]

public class
retailer {
private integer
SId; private
string Sname;
private string
Saddress;

149
private integer
Sphoneno;
private integer SemailId;

/**
@roseuid 5167CE29031C
*/
public
retailer(
)
{

/**
@roseuid 51284A9A0366
*/
public void Accept()
{

/**
@roseuid 51284AA2002A
*/ public
void
validate()
{

/**
@roseuid 51284AA602AA
*/
public void
billing()
{

}
}

150
(IX) IMPLEMENTATION OF USER INTERFACE LAYER

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.
• Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

151
Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT
Thus the mini project for credit card processing system has been successfully
executed and codes are generated.

152
Ex no: 9 E-BOOK MANAGEMENT SYSTEM

AIM:
To create a system to perform E- book Management System.

(I) PROBLEM STATEMENT:

EBook process is well organized online buying and selling of books. This
system is well developed in various resources, for example Amazon site deals more
about e-booking concept. This process has various issues in the basics of
maintenance of database and updating in sites, and virus problem in pdf books, so
we have many issues in this process. The process of e-books is fully based on
online, and the process for this mainly interaction between buyer and seller, buyer
who enter the site for purchase of book will use search engine for book to
purchase, the search engine will mainly focused on the database process, it used to
search book for the buyer who mentioned the book name, author name, edition,
publication details in the site, so that the search engine will show many books.
There will be a payment option and option for pdf file or hardcopy delivery to
home, the user should decide whether he want which one. Whether he choice
hardcopy means, full detail address, driving license no, and then he should login
with his username and password, and then payment through atm debit or credit
card applicable.

(II) SOFTWARE RESOURCE SPECIFICATION:

1.0 INTRODUCTION
E-Book is the interface between the students and Librarian. It aims at
improving the efficiency in the Issue of books or magazines and reduces the
complexities involved in it to the maximum possible extent.

1.1 PURPOSE
If the entire process of 'Issue of Books or Magazines' is done in a manual
manner then it would take several months for the books or magazines to reach the
applicant. Considering the fact that the number of students for Book Bank is
increasing every year, an Automated System becomes essential to meet the
demand. So this system uses several programming and database techniques to
elucidate the work involved in this process. The system has been carefully verified
and validated in order to satisfy it.

153
1.2 SCOPE
The System provides an online interface to the user where they can fill in
their personal details and submit the necessary documents (may be by scanning).
The authority concerned with the issue of books can use this system to reduce his
workload.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

E-book manager
Refers to the super user who is the Central Authority who has been vested with
the privilege to manage the entire system.

User
One who wishes to obtain the Books or Magazines.

Visitor
One who visits to obtain Books or Magazines.

Administrator
One who manages and maintain Books or Magazines.

1.4 REFERENCES
IEEE Software Requirement Specification format

1.5 TECHNOLOGIES TO BE USED

HTML - Markup Language used for creating web pages.

J2EE - Java 2 Enterprise Edition is a programming platform and it is the

part of the java platform for developing and running distributed java
applications.

HTTP -Hyper Text Transfer Protocol

TCP/IP - Transmission Control Protocol/Internet Protocol is the

communication protocol used to connect hosts on the Internet.

1.6 TOOLS TO BE USED

Eclipse IDE (Integrated Development Environment

Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements.

154
 Overall description will describe major role of the system components and
interconnections.

Specific requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

It will describe major role of the system components and inter-connections.

2.1 PRODUCT PERSPECTIVE

The ORS acts as an interface between the user and the 'e-book manager'.
This system tries to make the interface as simple as possible and at the same time
not risking the security of data stored in. This minimizes the time duration in which
the user receives the books or magazines.

2.2 SOFTWARE INTERFACE

Front End Client

The Student and Librarian online interface is built using JSP and HTML. The Librarians
local interface is built using Java.

Web Server
Apache Tomcat application server (Oracle Corporation).

Back End
Oracle 11g database

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

Secure Registration of information by the Students.

Librarian can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

User
They are the people who desire to obtain the books and submit the information to
the database.

Visitor
They are the person who visits the E-book system

155
 Administrator
He has the certain privileges to add the books and to approval of the
reservation of books.

2.6 CONSTRAINTS
The Students require a computer to submit their information.

Although the security is given high importance, there is always a chance of

intrusion in the web world which requires constant monitoring.

The user has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES

The user and e-book manager must have basic knowledge of computers and
English Language. The user may be required to scan the documents and send.

(III)USE-CASE DIAGRAM:

The E-book use cases in our system are:

1. Login
2. Register
3. Search book
4. Download
5. Payment
6. Publisher
7. Update

Actors involved:

1. Register User
2. Visitor
3. Administrator

1. Add: a student record. Each student should have following attributes.

-> Student id
->Name
-
>Address
->Phone no

2. Update:
The record would be selected using the student id.

156
 The updates can be made on full items only.
->name
->address
->phone no

3. Add to book item:

Each book should have following attribute
->call no
->title
->ISBN
->Author name

4. Query the book database:

The product shall let librarian query tools books detail information by their
ISBN number (or) author (or) title.

The search result would produce a list of books, which match the search parameters.

5. Check out a book:

Librarians and member of the library can check out can be initialized from a
previous search operation where user has selected a set of books.

6. Check in a book:
Librarians and member of the library can check in a book using its call no.

157
 Regist

Visito

Logi

Administrat

Search

Downlo

Register
Payme

Publish

Updat

[Link]-CASE DIAGRAM

(IV) ACTIVITY DIAGRAM:

The activity diagram shows the activity of the process here first login is
done when the user is valid then the welcome page appears .Here fork is used
where two transaction line may be got search book and online reading .search book
can be used to search book and online reading can allow user to learn online and
when any of these two process is selected a join is used where download occurs, in
this download of book is done then finally cost of book is paid online.

158
 Login

Welcome
page

Search Online
book Reading

Download

Payment

[Link] DIAGRAM

159
(V)CLASS DIAGRAM
The class diagram, also referred to as object modeling is the main static analysis
diagram. The main task of object modeling is to graphically show what each object
will do in the problem domain. The problem domain describes the structure and the
relationships among objects.
The E-book Management system class diagram consists of five classes:

1. Login
2. Registered User
3. Administrator
4. Book
5. Visitor
6. download
7. Logout

1) Login: Login to the system

2) Registered User: It consists of six attributes and four operations. The attributes
are user id, name, password, email id, phone no, security question. The
operations of this class are download(), login(),search(),register().

3) Administrator: It consists of four attributes and two operations. The attributes

are name, password, email id, admin id. The operations of this class are
update(), record().

4) Book: It consists of four attributes and two operations. The attributes are book
id, book name, author, and price. The operations of this class are update(), add().

5) Visitor: It consists of two attributes and two operations. The attributes are user
name, email id. The operations of this class are search book(), read book().

6) Download: It consists of two attributes and two operations. The attributes are
user id, book id, date, and amount. The operations of this class are search
download ().

7) Logout:
Logout from the system.

160
Fig.5. CLASS DIAGRAM

161
(VI) INTERACTION DIAGRAM:

• A sequence diagram represents the sequence and interactions of a given

USE-CASE or scenario. Sequence diagrams can capture most of the
information about the system. Most object to object interactions and
operations are considered events and events include signals, inputs,
decisions, interrupts, transitions and actions to or from users or external
devices.
• An event also is considered to be any action by an object that sends
information. The event line represents a message sent from one object to
another, in which the “form” object is requesting an operation be performed
by the “to” object. The “to” object performs the operation using a method
that the class contains.

• It is also represented by the order in which things occur and how the
objects in the system send message to one another.
• The two sequence diagram and two collaboration diagram one for
Registered user and another for visitor are given below

[Link] DIAGRAM FOR REGISTERED USER

162
 Book
: Visitor

seek for register

Registered is granted

Search book

Check availablity of book

Display Book

[Link] DIAGRAM FOR VISITOR

1: seek login
register user UI

2: login agreed

6: request download book

8: payment transaction submitted

7: display payment
5: 3: search book
9: downloading

4: check availabillity of book

Download

Book

[Link] DIAGRAM FOR REGISTERED USER

163
 4: check availability of book

1: seek for register

3: search book
visitor Book

2: registered is granted
5: display book

[Link] DIAGRAM FOR VISITOR

The diagrams show first login to the system and the pin no is entered and
check the pin .Get no and validate password check the condition based on
condition book issue and return are done. Pay the online and renewed .Finally
logout from the system.

VII) STATE CHART DIAGRAM:

The diagrams show first login to the system and view the books and search
for required book is done and then required book is downloaded and amount paid
in online .Finally logout from the system.

Login View Search Download Payment

boo

[Link] CHART DIAGRAM

164
(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM
Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.

Fig.8.1 DEPLOYMENT DIAGRAM

COMPONENT DIAGRAM
Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM

165
(X) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER

//Source file:
[Link] public
class administrator
{ private
int adminId;
private string
name;
private string
emailId;
private string
pwd;
public visitors theVisitors;

public administrator()
{
}

/**
@roseuid 515D119D004E
*/
public void update()
{ }
public void
record()
{
}
} //Source file:
[Link]
public class
book {
private string
bookid;
private string
bookname;
private string
author; private
int prize;
public visitors theVisitors;

/**
@roseuid 515D12350203
*/
public book()
{

166
 }

/**
@roseuid 515D11E5005D
*/
public void add()
{

/**
@roseuid 515D11E800CB
*/
public void update()
{

}
}

(XI) IMPLEMENTATION OF USER INTERFACE LAYER

Fig.11. Downloading book

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

167
Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.
• Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

Test Case Input ExpOutput ActOutput Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for E-Book System has been successfully executed and
codes are generated.

168
Ex no: 10 RECRUITMENT SYSTEM

AIM:
To create an automated system to perform the Recruitment System Process.

(I) PROBLEM STATEMENT:

The recruitment system allows the job seekers to view the job opportunity through
Advertisement and helps to apply for the job. The organization shortlist the applicants for the
interview. The shortlisted applicants undergo through a process of Test and Interview. The HR
department selects the Applicant based on the performance in the Test and Interview. Finally the
recruited applicants are informed. This system makes the task of the job seeker easier rather
than waiting in queue for enrollment. This also reduces the time consumption for both for the
job seeker and organization.

(II)SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION
Recruitment System is an interface between the Applicant and the Organization
responsible for the Recruitment. It aims at improving the efficiency in the Recruitment process
and reduces the complexities involved in it to the maximum possible extent.

1.1 PURPOSE
If the entire process of ‘Recruitment' is done in a manual manner then it would takes
several days for the recruitment. Considering the fact that the number of applicants for
recruitment is increasing every year, an Automated System becomes essential to meet the
demand. So this system uses several programming and database techniques to elucidate the
work involved in this process.

1.2 SCOPE

▪ The System provides an online interface to the user where they can fill in their personal
details and apply for the job.

169
 ▪ The Organization (HR-Department) concerned with the recruitment process can make
use of this system to reduce their workload and process the application in a speedy
manner.

▪ Provide a communication platform between the Applicant and the Organization.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

▪ Organization
Refers to the super user who is the Central Authority with the privilege to manage the
entire system. It can be any higher official in the HR department.
▪ Applicant
One who wishes to apply for the job.
▪ RS
Refers to this Recruitment System.
▪ HTML
Markup Language used for creating web pages.
▪ J2EE
Java 2 Enterprise Edition is a programming platform java platform for developing and
running distributed java applications.
▪ HTTP
Hyper Text Transfer Protocol.
▪ TCP/IP
Transmission Control Protocol/Internet Protocol is the communication protocol used to
connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED

• HTML
• JSP
• Javascript
• Java

1.6 TOOLS TO BE USED

• Eclipse IDE (Integrated Development Environment)

170
 • Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements

Overall Description will describe major role of the system components and inter-connections.

Specific Requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The RS acts as an interface between the ''Applicant and the 'Organization'. This system
tries to make the interface as simple as possible and at the same time not risking the security of
data stored in. This minimizes the time duration for recruitment process.

2.2 SOFTWARE INTERFACE

• Front End Client –The Applicants and Organization online interface is built using
JSP and HTML. The Administrators’ local interface is built using Java.

• Web Server - Glassfish application server (SQL Corporation).

• Back End - SQL database.

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS

▪ The applicant views the jobs through Advertisement.

▪ Applicants apply for the job.

▪ Test and Interview are conducted.

▪ Recruited Applicants are informed.

▪ HR Manager can generate reports from the information and he/she is the only authorized
personnel to add the eligible application information to the database.

171
2.5 USER CHARACTERISTICS
▪ Applicant
These are the persons who desire to apply for the job.
▪ Organization
These are the person with certain privileges to announce recruitment depending upon the
organization need. He/ She may contain a group of persons under him/her to publish
advertisement and give suggestion whether or not to approve the recruitment.
▪ HR
He/ She is the person who upon receiving intimation from the RS, perform a personal
verification of the applicants and see if he/she has eligibility for the advertised job
through a process of Test and Interview.

2.6 CONSTRAINTS
▪ The Applicants require a computer to submit their information.

2.7 ASSUMPTIONS AND DEPENDENCIES

▪ The Applicants and HR must have basic knowledge of computers and English Language.

17) ( III )USECASE DIAGRAM:

The Recruitment system use cases are:

1. Advertisement
2. Apply for job
3. Test
4. Interview
5. Recruit Applicants
18) ACTORS INVOLVED:
Actors are as follows:

1. Applicant
2. Organization
3. HR

172
19) ACTORS DOCUMENTATION:
▪ Applicant
Applicant is an actor who applies for the job vacancy. If he/she gets selected then HR
department sends the Interview call letter.

▪ HR
HR is an actor who informs about the vacancy to their Organization. HR recruits the
applicants based on the required skill for the vacant position and shortlist them. HR is
also responsible for Interview Scheduling.

▪ Organization
Organization is an actor who announces the Advertisement for vacancy.

USE-CASE NAME: ADVERTISEMENT

Description: This Use Case is initiated by Organization. Notifies about the required job
vacancies
Flow of Events:
1. HR informs about vacancy to Organization.
2. Organization announces the Advertisement.
Pre-Condition: Vacancy must exist.
Post-Condition: Details about the vacancy are informed.

USE CASE: APPLY FOR JOB

Description: This Use Case is initiated by Applicants. Online forms are filled by the Applicants
and submitted to the organization.
Flow of Events: 1. HR processes the filled forms.
2. HR selects the list of eligible Applicants.
Pre-Condition: Online form must exist.
Post-Condition: Forms filled are stored in an Information System for processing. The filled
forms are sent to the HR. The HR produces the list of eligible Applicants.

USE CASE: SELECT APPLICANTS FOR INTERVIEW

Description This Use Case is initiated by HR. The lists of selected Applicants are Informed
.The Test and Interviews are conducted by the HR of the region that has the vacancy.
Flow of Events: 1. HR schedules the interview process.
2. HR conducts test and interview for the applicant via online system.
3. Who clear the interview process are selected.
Pre-Condition: Applicants must meet eligibility criteria.
Post-Condition: Applicants clears interview process OR doesn’t clear interview process.

173
USE CASE: TEST.

Description: This Use Case is initiated by the HR. A test will be conducted by the HR
Flow of Events 1. The applicants undergo the Test process.
2. He/ She clear or not clear the Test.
Pre-Condition: Applicant is selected for the Test.
Post-Condition: Applicant clear or not clear the Test.

USE CASE: INTERVIEW

Description: This Use Case is initiated by the HR. An Interview will be conducted by the HR
Flow of Events 1. The applicants undergo the Interview process.
2. He/ She clear or not clear the Interview.
Pre-Condition: Applicant is selected for the Interview.
Post-Condition: Applicant clear or not clear the Interview.
USE CASE: RECRUITED APPLICANTS

Description: This Use Case is initiated by the HR. The selected applicants are recruited by HR.
Flow of Events 1. The applicants clear the Test.
2. The applicants clear the Interview.
Pre-Condition: Applicant is selected for the Test and Interview.
Post-Condition: Applicant clears Test and Interview.

174
Fig 3. USE CASE DIAGRAM FOR RECRUITMENT SYSTEM

175
(IV) ACTIVITY DIAGRAM:
The activity diagram represents the series of activities that are ocurring between the
[Link] is activity diagram which represents the recruitment process .

Applicant Knows the

organisation jobs

Advertisement Other Sources

Applicant apply for

organisation Jobs

Selected Applicant
called for Interview

Test Interview

Fix Salary

Recruited & Not Recruited

Applicants Informed

Fig.4 ACTIVITY DIAGRAM FOR RECRUITMENT SYSTEM

176
(V) CLASS DIAGRAM:

The UML class diagram illustrates class interfaces and their actions. They are used for static
object modeling. The problem domain describes the structure and the relationships among
objects.

The Recruitment system class diagram consists of five classes

1. Applicant class
2. Organization class
3. HR Department class
4. Advertisement class
20) 5. Recruitment class

1) APPLICANT CLASS:

It consists of eight attributes and two operations. The attributes are Appl-id, Appl-name,
Appl-DOB, Appl-Gender, Appl-Qualification, Appl-phone, Appl-emailid, [Link]
operation of this class are view jobs ( ) and Apply ( ).

2) ORGANIZATION CLASS
The attributes of this class are Org-name, Org-Ph-No, and Org-Addr. The operation of this class
are HR-Dept( ), Mkt-Dept( ) and Account-Dept( ).

3) HR DEPARTMENT CLASS
The attributes of this class are Emp-id, Emp-name, Emp-DOB, Emp-Gender, Emp-Phone,
Empemailid, Emp-addr. The operation are Planning( ), Policies( ),Strategies( )

4) ADVERTISEMENT CLASS
The attributes of this class are Adv-No, Adv-Name and Adv-description. The operation is
display( ).

5) RECRUITMENT CLASS
The attributes are Rec-Designation and Rec-Totalcandiate. The operation is recruit( ).

177
 Fig.5 .CLASS DIAGRAM FOR RECRUITMENT SYSTEM

(VI) INTERACTION DIAGRAM:

▪ A sequence diagram illustrates a kind of format in which each object interacts via
message. It is generalize between two or more specialized diagram.

178
 Advertisement Organisation
: Applicant Recruitment
Committee : HR
View Jobs

Apply for Jobs

Forward Applicants Resume

Analyse Applicants Resume

Send Interview call Letter/E-mail

Attend Test

Evaluate Test

Selected /Not Selected Informed

Attend Interview

Applicant passed Test and Interview Informed

Salary Fixed /Recruited

Fig 6.1 SEQUENCE DIAGRAM FOR RECRUITMENT SYSTEM

▪ Communication diagram illustrate that object interact on a graph or network format. In

collaboration diagram the object can be placed in anywhere on the diagram. The
collaboration comes from sequence diagram.

179
 1: view jobs
appilicant advertisement

6: attend interview
2: apply for jobs
5: send interview call letter/emil
7: applicant passed test & interview informed
8: salary fixed/received
4: analyse applicant resume

3: forward applicants
organisation recuitment
commited=HR

Fig 6.2 COLLOBORATION DIAGRAM FOR RECRUITMENT SYSTEM

(VII) STATE CHART DIAGRAM:

▪ Every object undergoes through some state and on receiving some event the state gets
changed. This transition of the state can be represented by the state transition diagram.

View Jobs Apply Job Select for Test

Interview

Interview

Salary

Recruit

Fig .7 STATE CHART DIAGRAM FOR RECRUITMENT SYSTEM

180
(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

[Link] DIAGRAM

Component diagrams are used to visualize the organization and relationships among
components in a system.

[Link] DIAGRAM

181
(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL
SERVICE LAYER
21) //Source file:
[Link] public class
recruitment
{ private string
rec_designation;
private int rec_totalcandidate;

/**
@roseuid 515D0EFE0290
*/
public recruitment()
{

/**
@roseuid 515D0DC4031C
*/
public void recruit()
{

}
}

//Source file: [Link]

public class HRDepartment

{ private int Emp_id;
private int emp_DOB;
private string emp_name;
private string emp_addr;
public organisation theOrganisation;

/**
@roseuid 515D0EFE02BF
*/
public HRDepartment()
{

/**
@roseuid 515D0D8F0261
*/
public void planning()
{

182
 /**
@roseuid 515D0D940242
*/ public void
policies()
{

/**
@roseuid 515D0D9702DE
*/ public void
strategies()
{

}
}

(X) IMPLEMENTATION OF USER INTERFACE LAYER

[Link] Form

183
TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.

Types of test cases

There are two types of test cases as mentioned below:

• Formal test cases: Formal test cases are those test cases which are authored as per the
test case format. It has all the information like preconditions, input data, output data,
post conditions, etc. It has a defined set of inputs which will provide the expected
output.
• Informal test cases: Informal test cases are authored for such requirements where the
exact input and output are not known. In order to test them the formal test cases are not
authored but the activities done and the outcomes are reported once the tests are run.

Test Cases Examples:

▪ Module: User Login
▪ File Name: [Link]

Test Case Input Exp Output Act Output Desc

Valid login username, Success Success Login

password, successful.
type

Invalid Login username, Failed Failed Login

password, unsuccessful.
type Try again.

RESULT:
Thus the mini project for recruitment system has been successfully executed and codes are
generated.

184