Ooad Record Full

PASSPORT
AUTOMATION
SYSTEM
Ex.no:1
PROBLEM STATEMENT
Date:
AIM
To develop the problem statement for the passport automation system.
PROBLEM STATEMENT
Passport Automation System is used to Apply renew, update the passport online.This Software is
developed to reduce the Manual work as well as the time. The first and foremost step is that the
Applicants will fill their personal details and submit the required documents. Then the personal
details and documents validated with the Database. Then the Verification is done by a Police
officer.
Then the System provides the List of Available data. The Current status of your Application is
updated after every process which can be seen in online interface. After adding your data in the
database, the Passport will be dispatched. The Existing Users can also renew for the Passport.
Table of Contents
Table of Contents ......................................................................................................................... iii
Revision History ........................................................................................................................... iii
1. Introduction ..............................................................................................................................4
1.1 Purpose ............................................................................................................................................. 4
1.2 Document Conventions .................................................................................................................... 4
1.3 Intended Audience and Reading Suggestions................................................................................... 4
1.4 Product Scope ................................................................................................................................... 4
1.5 References......................................................................................................................................... 5
2. Overall Description ..................................................................................................................5
2.1 Product Perspective .......................................................................................................................... 5
2.2 Product Functions ............................................................................................................................. 5
2.3 User Classes and Characteristics ...................................................................................................... 5
2.4 Operating Environment .................................................................................................................... 5
2.5 Design and Implementation Constraints ........................................................................................... 6
2.6 User Documentation ......................................................................................................................... 6
2.7 Assumptions and Dependencies ....................................................................................................... 6
3.External Interface Requirements ..............................................................................................6
3.1 User Interfaces .................................................................................................................................. 6
3.2 Hardware Interfaces.......................................................................................................................... 6
3.3 Software Interfaces ........................................................................................................................... 6
3.4 Communications Interfaces .............................................................................................................. 7
4. System Features .......................................................................................................................7
4.1 Registration ....................................................................................................................................... 7
4.2 Verification ....................................................................................................................................... 9
5. Other Nonfunctional Requirements .......................................................................................9
5.1 Performance Requirements............................................................................................................... 9
5.2 Safety Requirements ......................................................................................................................... 9
5.3 Security Requirements...................................................................................................................... 9
5.4 Software Quality Attributes ............................................................................................................ 10
5.5 Business Rules ................................................................................................................................ 10
Appendix A: Glossary..................................................................................................................10
Revision History
Name Date Reason For Changes Version
1. 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.
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 Document Conventions

Content Font Face Font Size Font Style
Heading Times New Roman 18 Bold
Sub heading Times New Roman 14 Bold
Paragraph Times New Roman 12 Normal
1.3 Intended Audience and Reading Suggestions

This Document is intended for readers such as developers, project managers, marketing staff, users,
testers, and documentation writers. The SRS contains Product Perspective, Product function, User
classes and characteristics, Operating environment, Design and Implementation Constrains,
Assumptions and Dependencies of the project under Overall Description. It also contains User
Interfaces, Hardware interfaces, Software interfaces, Communication interfaces under External
Interface Requirements and Functional and Non Functional Requirements in Software Features.
1.4 Product Scope

The System provides an online interface to the user where they can fill in their personal details and
submit the necessary documents. 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.5 References
IEEE Software Requirement Specification format
Book Reference: LARAMN CRAIG
https://www.academia.edu/6680982/1_Passport_Automation_System
https://www.vidyarthiplus.com/vp/attachment.php?aid=24303https://onlineengineering.wordpress.c
om/2011/03/07/ooad-lab-passport-automation-system/
2. 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.
2.2 Product 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.3 User Classes and Characteristics

➢ Applicant - They are the people 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
2.4 Operating Environment

➢ Windows 32-bit and 64-bit PC architectures
➢ HTML
➢ JSP
➢ JavaScript
➢ Java
➢ Argo UML
➢ XML
➢ AJAX
2.5 Design and Implementation 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.6 User Documentation

The product will include the user manual. This will include product overview, complete configuration
of the software’s to be used and hence the description of the overall product. The application will
allow users to access the offline and online help manual. This manual will be updated with each new
service pack.
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.
3. External Interface Requirements

The system uses the GUI – Graphical User Interface for easy interaction with the customer. The
system maintains a relationship with the Rational Rose Tool. According to the code generated by the
Rose tool, the system is developed. This gives more sequential access for the functions and the
functions can be coded easily
3.1 User Interfaces
➢ The user interface for the software shall be compatible to any browser such as Internet
Explorer, Mozilla or Netscape Navigator by which user can access to the system.
➢ The user interface shall be implemented using any tool or software package like Java Applet,
MS Front Page, EJBetc.
3.2 Hardware Interfaces
Since the application must run over the internet, all the hardware shall require to connect internet
will be hardware interface for the system. As for e.g. Modem, WAN – LAN, Ethernet Cross-
Cable.
➢ Needed: Computers
➢ Hard Disk: 100-150 GB
➢ RAM: 512-1 GB required
➢ Internet Connection required.
➢ Cables, wires, Network adapters are required
3.3 Software Interfaces
➢ 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
3.4 Communications Interfaces

The system shall use the HTTP protocol for communication over the internet and for the
intranet communication will be through TCP/IP protocol suite.
4. System Features
Secure Registration of information by the Applicants. Message box for Passport Application
Status display 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
4.1 Registration
4.1.1 Description and Priority

The applicant needs to fill their details properly verification is based on that. It has the highest
priority in the system. because the details of the user/applicant shouldn’t be misused at any cost.
4.1.2 Stimulus/Response Sequences

➢ The user enters all the details in the form.
➢ If all fields all filled then system returns the success message that details are entered
4.1.3 Functional Requirements

ACTORS INVOLVED:
1.Applicant
2. Passport Officer
3. Police
The Passport Automation system use cases are:
1. Login
2. Registration
3. Verification
4. Check Status
5. Enquiry
6. Dispatch Passport
USE-CASE NAME: LOGIN
Author –TEAM01
Purpose – To Obtain a Passport ID
Requirements Traceability – Online Interface
Preconditions – User account must be exists
Actors –Registered User
Flow of Events
➢ Basic Flow –New page with all the information regarding the user and account is shown by
the system.
➢ Exceptions – Error message regarding the issues and user is asked to provide valid log in
information
USE-CASE NAME: REGISTRATION
Purpose - To register a new user, user should be able to register himself with the application
Priority – FIFO(First-In-First-Out)
Preconditions – Fill the form with details.
Post conditions - The user is successfully registered with the system
Actors – User
Flow of Event
The user, if new, requests to registers himself with the system.
➢ The system asks for the personal Document details of the user.
➢ User enters the personal details including chosen credentials, i.e. Name, Age ,Phone Number
,Address, And Other documents and submit the registration form.
➢ System differentiates between different users, and accordingly saves them in the system
database and registration is successful.
USE-CASE NAME: VERIFICATION

Pre-function: Taking the applicant form.
Post-function: Verify the information and enquiry to applicant.
USE-CASE NAME: CHECK STATUS

Pre-function: Checking validity date.
Post-function: Renewal the old passport.
USE-CASE NAME: ENQUIRY
Pre-function: All the documents should be Properly attached and verified.
Post-function: If Documents filed are Valid, Then Passport is Prepared.
USE-CASE NAME: DISPATCH PASSPORT

Pre-function: Send the passport to applicant address.
Post-function: Receive the passport form the postman.
The requirements needed to be fulfilled are specified below:

REQ-1:Password for login and viewing the Applicant details.
4.2 Verification
4.2.1 Description and Priority:
➢ The verification is done by the regional administrator after the
information provided by theuser.It has the highest priority in the system.
4.2.2 Stimulus/Response Sequences:

➢ The verification is done on the administrator side and if valid then
➢ passport will be issued.
➢ If the verification respond as invalid then ask the user to reapply the
passport.
5. Other Nonfunctional Requirements

5.1 Performance Requirements
➢ The response time of the system should be less.The applicant under the criminal act are
not allowed to issue passport .
➢ Sometimes the workload will be high,that is in certain period the application will be high
and sometime it will be less,then it should be managed properly by employing more
staffs to process the system.
➢ Administrator warrants that this system shall be capable of supporting atleast 1000
customers per day.
• Safety
• Reliability
• Availability
• Maintainability
5.2 Safety Requirements

➢ It’s password protected. So it is safe and details are stored in private server for protect the
details from unwanted access.
➢ The UI provides easy access to the users.
➢ It is available 24/7.
5.3 Security Requirements

➢ Every user is provided with unique ID with their password. Every user is authenticated
before accessing their account.
➢ If authentication doesn’t provided then illegal usage of passport will occur.
5.4 Software Quality Attributes

➢ The system is highly reliable.
➢ The system is also adaptable under any conditions.
5.5 Business Rules

To get the passport the address proof and age proof should be provided and the applicant
should be free of criminal case.
Appendix A: Glossary
ADMINISTRATOR: Refers to the super user who is maintaining the Applicant details.
HTML: Mark-up 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.
SQL: Structured Query Language.
SRS: Software Requirements Specification.
GUI: Graphical User Interface.
EX.NO: 3 IDENTIFY USE CASES AND DEVELOP USE CASE MODEL
DATE:
USE CASE DIAGRAM

A use case diagram at its simplest is a representation of a user's interaction with the system that shows
the relationship between the user and the different usecases in which the user is involved. A use case
diagram can identify the different types of users of a system and the different use cases and will often
be accompanied by other types of diagrams as well. The use cases are represented by either circles or
ellipses.
PURPOSE OF USE CASE DIAGRAMS

The purpose of use case diagram is to capture the dynamic aspect of a system. However, this definition
is too generic to describe the purpose, as other four diagrams (activity, sequence, collaboration, and
State chart) also have the same purpose.
BASIC USE CASE DIAGRAM SYMBOLS AND NOTATIONS

SYSTEM
Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the
system's boundaries.
USECASE
Draw use cases using ovals. Label the ovals with verbs that represent the system's functions.
ACTORS
Actors are the users of a system. When one system is the actor of another system, label the actor
system with the actor stereotype.
RELATIONSHIPS
Illustrate relationships between an actor and a use case with a simple line. For relationships among
use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use
case is needed by another in order to perform a task. An "extends" relationship indicates alternative
options under a certain use case.
Figure 1.1
USE CASE MODELLING
LOGIN
BRIEF FORMAT:-
An Applicant/user , enters the username and password to enter into the webpage .After the
Authentication by the Admin (verification officer).the Next window of PAS webpage will be opened
.Further Process can be take place.
CASUAL FORMAT :-
SUCCESS SCENARIO
Login is the main use case in the PAS System. Its primary actors are Applicant /user (Existing
User).Applicant /user (Existing user),Enters the usernames and password to Enter into the Webpage.
After the Authentication by the Verification Officer, the Next windows of PAS webpage will be take
place.
Here ,there are some negative scenario such as some network issues and Invalid username and
password are not allowed.
ALTERNATE SCENARIO
If the password entered by the Applicant is invalid, the system cannot be opened and can’t perform
any actions. So he must re-enter the valid password. The system allows to enter the valid password
upto three attempts.
FULLY DRESSED FORMAT

Use case name Login
Goal To login successfully into the system.
Level Enter the login ID and password.
Primary actor Admin, Applicant /user
Secondary / Supporting actor Admin , Server.
Stake holders Admin
Precondition Enter the Username and Password to Login

into the Webpage.
Main success scenario Enter the Proper Username you have
registered Previously. Then , enter the Correct
Password . After Authentication , the Next
window of the webpage will be opened.
Exception Incorrect password.

Forget password.
Extension Proper maintenance of the system is needed.
Unauthorised person cannot login to the
system.
Special requirements Security is important.
Provide more authentication.
USE CASE MODELLING
REGISTRATION
BRIEF FORMAT
The System asks for the personal documents details of the user. User enters the personal Details
including chosen credentials , i.e. Name, Age ,Phone Number ,Address and Other Documents and
Submit the Registration form .System Differentials between Different Users and Accordingly Saves
them in the System Database and Registration is Successful.
CASUAL FORMAT
SUCCESS SCENARIO
Registration is used to attach the Files (or) Documents of the Applicant to the System for the Passport
Generation .Basic Actors are Applicant and System . The registration may be Classified into two
types. One is Passport Registration And Another is Passport Renewal.
In the Passport Registration , The System asks for the Personal Document Details of the Users .
Applicant enters the Personal Details of the User. Chosen Credentials i.e. Name ,Age, Phone Number,
Address and other Documents and Submit the Registration Form

Use case name Registration
Goal To Register a new user, user should be able to
register himself with the Application
Level To also Register the pre-user, user should be
able to register himself the renewal details.
Primary actor Applicant /user
Secondary / Supporting actor Admin , Server
Stake holders Applicant plays the important role in the
system. He login to the system and can view
or update or remove details about
His passport and personal details etc.,
Precondition The system login should be working.
Main success scenario The System asks for the Personal Document
details of the user.
User enters the details including chosen
Credentials i.e. Name, Age, Phone number,
Address and other Documents and Submit the
Registration form.
System differentiates between different users
and accordingly saves them in the system
database and registration is successful.
Exception Usage of Existing data
like (g-mail, Phone
number)
Extension Avoid Repeated Data and inform when
Repeated data are found .

Database Analysis is needed.
EX.NO:4 IDENTIFY CONCEPTUAL CLASSES AND DEVELOP THE
DOMAIN MODEL AND ALSO DERIVE A CLASS DIAGRAM
DATE: FROM THAT.
CLASSDIAGRAM:
Class diagram is a static diagram. It represents the static view of an application. Class diagram is
not only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on
the system. The class diagrams are widely used in the modelling of object oriented systems because
they are the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints.
It is also known as a structural diagram.
Purpose of Class Diagrams:
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
Members:
UML provides mechanisms to represent class members, such as attributes and methods, and
additional information about them.
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these notations must be
placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
Derived property is a property which value (or values) is produced or computed from other
information, for example, by using values of other properties.
Derived property is shown with its name preceded by a forward slash '/'.
Scope:
The UML specifies two types of scope for members: instance and classifier, and the latter is
represented by underlined names.
• Classifier members are commonly recognized as “static” in many programming languages. The
scope is the class itself.
o Attribute values are equal for all instances
o Method invocation does not affect the classifier’s state
• Instance members are scoped to a specific instance.
• Attribute values may vary between instances
• Method invocation may affect the instance’s state (i.e. change instance’s attributes)
To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance scope
is assumed by default.
Relationships
5.6 Class Notation:
UML class is represented by the following figure. The diagram is divided into four parts.
• The top section is used to name the class.

• The second one is used to show the attributes of the class.
• The third section is used to describe the operations performed by the class.
• The fourth section is optional to show any additional components.
Classes are used to represent objects. Objects can be anything having properties and responsibility.
Object Notation:
It is represented in the same way as the class. The only difference is the name which is underlined
as shown in the following figure.
DOMAIN MODEL:
Figure 1.2
As the object is an actual implementation of a class, which is known as the instance of a class. Hence,
it has the same usage as the class.
CLASS DIAGRAM:
The class diagram consists of Nine classes namely, Applicant, Passport, Passport office, Payment,
Passport Verification officer, Police, Passport Description ,Net-banking, Credit card. The associations
between the classes are as follows:
➢ One Applicant Applies for One Passport.
➢ One Applicant makes Many Payment.
➢ ManyPassport Verification Officer Works for One Passport Office.
➢ One Passport Described by One Passport Description.
➢ One Police Verifies One Passport.
➢ One Passport Verification Officer Approach One Police.
➢ One Passport Enquired by One Passport Verification Officer
EX.NO:5 USING IDENTIFIED SCENARIOS FIND INTERACTION
DATE:
BETWEEN OBJECTS AND REPRESENT THEM USING UML
SEQUENCE DIAGRAM
SEQUENCE DIAGRAM:
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order in
which these interactions take place. We can also use the terms event diagrams or event scenarios to
refer to a sequence diagram. Sequence diagrams describe how and in what order the objects in a
system function. These diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.
Sequence Diagram Notations

Actors
An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we aim to
model using the UML diagram.
1. We use actors to depict various roles including human users and other external subjects. We
represent an actor in a UML diagram using a stick person notation. We can have multiple
actors in a sequence diagram.
For example – Here the user in seat reservation system is shown as an actor where it exists
outside the system and is not a part of the system.
Figure 1.3– an actor interacting with a seat reservation system
2.Lifelines – A lifeline is a named element which depicts an individual participant in a sequence
diagram. So basically each instance in a sequence diagram is represented by a lifeline. Lifeline
elements are located at the top in a sequence diagram. The standard in UML for naming a lifeline
follows the following format – Instance Name : Class Name
Figure 1.4 – lifeline

We display a lifeline in a rectangle called head with its name and type. The head is located on top of
a vertical dashed line (referred to as the stem) as shown above. If we want to model an unnamed
instance, we follow the same pattern except now the portion of lifeline’s name is left blank.
Difference between a lifeline and an actor.
A lifeline always portrays an object internal to the system whereas actors are used to depict objects
external to the system. The following is an example of a sequence diagram:
Figure 1.5 – a sequence diagram

3.Messages – Communication between objects is depicted using messages. The messages appear in
a sequential order on the lifeline. We represent messages using arrows. Lifelines and messages form
the core of a sequence diagram.Messages can be broadly classified into the following categories :
Figure 1.6– a sequence diagram with different types of messages
Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The sender waits
until the receiver has completed the processing of the message. The caller continues only when it
knows that the receiver has processed the previous message i.e. it receives a reply message. A large
number of calls in object oriented programming are synchronous. We use a solid arrow head to
represent a synchronous message.
Figure 1.7– a sequence diagram using a synchronous message
Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction moves forward
irrespective of the receiver processing the previous message or not. We use a lined arrow head to
represent an asynchronous message.
Figure 1.8
Create message
We use a Create message to instantiate a new object in the sequence diagram. There are situations
when a particular message call requires the creation of an object. It is represented with a dotted arrow
and create word labelled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would require a new object of
Order class to be created.
Figure 1.9– a situation where create message is used

Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is destroyed
within the system we use the Delete Message symbol. It destroys the occurrence of the object in the
system. It is represented by an arrow terminating with a x.
For example :In the scenario below when the order is received by the user, the object of
order class can be destroyed.
Figure 1.10 – a scenario where delete message is used

Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such messages are
called Self Messages and are represented with a U shaped arrow.
Figure 1.11– self message
For example – Consider a scenario where the device wants to access its webcam. Such a
scenario is represented using a self message.
Figure 1.12– a scenario where a self message is used

Reply Message
Reply messages are used to show the message being sent from the receiver to the sender. We represent
a return/reply message using an open arrowhead with a dotted line. The interaction moves forward
only when a reply message is sent by the receiver.
Figure 1.13 – reply message

For example – Consider the scenario where the device requests a photo from the user. Here the
message which shows the photo being sent is a reply message.
Figure 1.14– a scenario where a reply message is used
Found Message
A Found message is used to represent a scenario where an unknown source sends the message. It is
represented using an arrow directed towards a lifeline from an end point. For example: Consider the
scenario of a hardware failure.
Figure 1.15 – found message
It can be due to multiple reasons and we are not certain as to what caused the hardware failure.
Figure 1.16 – a scenario where found message is used

Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the system. It is
represented using an arrow directed towards an end point from a lifeline. For example: Consider a
scenario where a warning is generated.
Figure 1.17 – lost message

The warning might be generated for the user or other software/object that the lifeline is
interacting with. Since the destination is not known before hand, we use the Lost Message symbol.
Guards
To model conditions we use guards in UML. They are used when we need to restrict the flow of
messages on the pretext of a condition being met. Guards play an important role in letting software
developers know the constraints attached to a system or a particular process.
For example: In order to be able to withdraw cash, having a balance greater than zero is a condition
that must be met as shown below.
Figure 1.18
Uses of sequence diagrams :
• Used to model and visualize the logic behind a sophisticated function, operation or
procedure.
• They are also used to show details of UML use case diagrams.
• Used to understand the detailed functionality of current or future systems.
• Visualize how messages and tasks move between objects or components in a system.
Figure 1.19
The Applicant/ User logins to the system by entering a valid ID and password. Then If he is new
user ,he register for new Passport and Existing user just can alter the details of their data. Once
The Registration is over ,then Payment should be done through Online either by Net-banking a
or Credit/ Debit card. After that We should for Acknowledgement from the Passport Officer. After
all the Verification Process the Police officer will makes an Enquire regrading Passport. Finally After
all the Process , Passport will be Dispatched and Receive within 30 days.
EX.NO:6 USING THE IDENTIFIED SCENARIOS,FIND THE INTERACTION
COLLABORATION DIAGRAM
DATE:
COLLABORATION DIAGRAM:
A collaboration diagram, also known as a communication diagram, is an illustration of the
relationships and interactions among software objects in the Unified Modeling Language (UML).
These diagrams can be used to portray the dynamic behavior of a particular use case and define the
role of each object.
Collaboration diagrams are created by first identifying the structural elements required to carry out
the functionality of an interaction. A model is then built using the relationships between those
elements. Several vendors offer software for creating and editing collaboration diagrams.
Notations of a collaboration diagram:

A collaboration diagram resembles a flowchart that portrays the roles, functionality and behaviour of
individual objects as well as the overall operation of the system in real time. The four major
components of a collaboration diagram are:
1. Objects- Objects are shown as rectangles with naming labels inside. The naming label follows the
convention of object name: class name. If an object has a property or state that specifically
influences the collaboration, this should also be noted.
2. Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a name and
a role, with one actor initiating the entire use case.
3. Links- Links connect objects with actors and are depicted using a solid line between two elements.
Each link is an instance where messages can be sent.
4. Messages- Messages between objects are shown as a labeled arrow placed near a link. These
messages are communications between objects that convey information about the activity and can
include the sequence number.
The most important objects are placed in the center of the diagram, with all other participating objects
branching off. After all objects are placed, links and messages should be added in between.
Figure 1.20
EX.NO : 7
DATE: DRAW STATE CHART DIAGRAM AND ACTIVITY
DIAGRAM
ACTIVITY DIAGRAM:
Activity diagram describe activities which involve concurrency and synchronization, which are a
variation of state diagrams that focuses on the flow of actions and events. They can be used for:
• To model a human task. (a business process, for instance)
• To describe a system function that is represented by a use case.
• In operation specifications, to describe the logic of an operation.
Figure 1.21
This Activity diagram consists of three swim-lanes namely, Applicant, Passport authority, Police. The
initial process is the Login done by the User. Then Apply the Given Details. Passport authority makes
an Appointment and Verifies the Filled Details and Documents. The Parallel behavior such as fork
and join operations are used for Enquiry and Reject the User application
.After completing all the enquiry ,if Positive Result, the Police officer will send an Report to the
Passport Authority and he Dispatch the Passport . if Negative Result , then Return/ Reject the
application. The final process is the Log out done by the Applicant/User.
STATE CHART DIAGRAM:
A state machine Diagram (or start diagram, also called state chart of state transition diagram) is a
behavior which specifies the sequence of states an entity (or object) visits during its lifetime in
response to events, together with its responses to those events.
Key concepts:
State:
A state is a condition during the life of an object during which it satisfies some condition, performs
some activity, or waits for some external event.
A state machine diagram is a graph consisting of:
• States (simple states or composite states)
• State transitions connecting the states
Example:
Initial and Final States:

• The initial state of a state machine diagram, known as an initial pseudo-state, is indicated
with a solid circle. A transition from this state will show the first real state.
• The final state of a state machine diagram is shown as concentric circles. An open loop
state machine represents an object that may terminate before the system terminates, while a
closed loop state machine diagram does not have a final state; if it is the case, then the object
lives until the entire system terminates.
Figure 1.22
EX.NO: 8
IMPLEMENT SYSTEM AS PER DETAILED DESIGN
DATE:
IMPLEMENT SYSTEM AS PER DETAILED DESIGN

Class Name: Applicant
import java.util.Vector;
public class Applicant {
public String Name;
public Integer Age;
public Integer Address;
public Integer Id;
public Passport applies for;
public Vector 1;
public void submit_details() {

}
Class Name: Police

public class Police {

public String Name;
public Integer id;
/**
*
* @element-type Applicant
*/
public Vector enquires;
public void verifydetails() {

}
public void updatestatus() {

}
}
Class Name: Credit card

public class Credit_card extends Payment {
public Integer Card-no.;
public Integer Pin_no.;
public void getreceipt() {

}
Class Name: Netbanking

public class Netbanking extends Payment {
public String username;
public String password;
public void getreceipt() {

}
Class Name: PassportVerificationOfficer

public class Passport Verification officer {
public String Name;
public Integer ID;
public Integer age;
public Vector myPayment;
public Police approach;
public Passport_Office works for;
public void verifydetails() {

}
public void updatedetails() {

}
}
Class Name: Payment

public class Payment {
public Integer Payment_time;
public Integer Date;
public Integer Amount;
public Vector myPassport Verification officer;
public Applicant makes;
public void getpaymentinfo() {

}
Class Name: Passport

public class Passport {
public Integer passport_No;
public Vector myPassport_Office;
public Passport_description described by;
public Vector verifies;
public void passport_details() {

}
Class Name: PassportDescription

public class Passport_description {
public Integer Passport_no;
public String Name;
public Integer Age;
public Integer DOB;

public void getpassportinfo() {
}
Class Name: PassportOffice

public class Passport_Office {
public String Branch_Name;
public Integer Branch_code;
public Vector myPassport;

/**
*
* @element-type Passport Verification officer
*/
public Vector works for;
public void getpassportofficedetails() {

}
}
EX.NO: 9 Test the software system for all the scenarios identified as per the
usecase diagram.
DATE:
Class Name: Applicant

public class Applicant {
public String Name;
public Integer Age;
public Integer Address;
public Integer Id;
public Passport applies for;
public Vector 1;
public void submit_details() {

}
}
Figure 1.23
Figure 1.24
EX.NO:10
DATE: IMPROVE REUSABILITY AND MAINTAINABILITY BY
APPLYING APPROPRIATE DESIGN PATTERN
For illustration purpose abstract factory pattern is used to describe the proposed method. Abstract
factory pattern known as a creational pattern, provides a method to encapsulate a group of individual
factories that have a familiar theme without specifying their concrete classes. In usual case, the client
software create a concrete implementation of the abstract factory then using generic interface of the
factory to create the concrete objects which is part of the theme. The client doesn‟t know which
concrete objects gets from all of these internal factories, since it uses only the generic interfaces of
their products. Abstract products describe interface for every different products of a single product
family. Concrete products implement the abstract product interface which is returned by creational
methods of concrete factories. Abstract factory defines the interface for creating products which is
common to all concrete factories. Concrete factories implement creational methods of the abstract
factory and each concrete factory should correspond to a specific products variant as shown in Figure.
Figure 1.25: Design Pattern - Abstract Factory
Purpose of abstract factory design pattern is to provide an interface for creating families of related
objects without specifying concrete classes. The following Figure( ) shows the example of abstract
factory design pattern for user login where two concrete factory and concrete product used for
execution.
Figure 1.26: Abstract Factory Design Pattern for User Login
Using proposed method design pattern asses where requirement is well documented and fixed which
is used as input. As step 1 firstly identify the design problem using alternative design solutions from
literature and experience, and solve using abstract factory design pattern. In step 2 maintainability,
reusability, understandability, flexibility, composability, completeness, stability, simplicity, and
expandability are selected as design objective. Using step 3 appropriate solution is selected as step 4
(tool) and step 5 (mathematical formation). In step 4 maintainability, reusability, understandability,
and flexibility are calculated using percerons design pattern advisor tool. In step 5 composability,
completeness, stability, simplicity, and expandability are measured using mathematical formation. In
step 6, combine step 4 and 5 output to get required quality product. Assessment of these nine quality
attributes are discussed as:
MAINTAINABILITY:
Use of a design pattern essentially complicates design to usually add abstract classes and additional
associations to employ a design pattern. The key advantage of using design pattern is that the resulting
software should be easier to adapt, to modify fewer classes, to add functionality to software. So,
maintenance Client AbstractFactory +doAction1:void +doAction2:void AbstractProduct
+doAction:voidAbstractFactory concreteProduct1 concreteProduct2 concreteFactory1
concreteProduct1: Admin concreteProduct2: User concreteProduct1 +doAction:void
concreteFactory2 concreteProduct1: Admin concreteProduct2: User concreteProduct2
+doAction:void 95 programmers should have to use less effort to adapt these changes. Every
introduced pattern caused an improvement in different quality attributes.
REUSABILITY:
Design patterns are reusable micro architectures that add to overall software architecture. Design
patterns detain static and dynamic structure and collaborations of components in successful solutions
to problems that occur when developing software like business data processing, databases, graphical
user interfaces, telecommunications, and distributed communication software. Patterns 96 help
development of reusable components and frameworks by using structure and collaboration of
participants in software architecture at a level higher than source code and object oriented design
models that focus on individual objects and classes. Thus, patterns facilitate reuse of software
architecture, even when additional forms of reuse are infeasible. An empirical investigation on
reusability of design patterns and software packages, attempts to empirically investigate reusability
of design patterns, classes, and software packages to identify the most beneficial starting points for
white box reuse, which is pretty popular among OSS.
CONCLUSION:
The Passport Automation System(PAS) can help to easy Register of Passport and Altering
any changes if you have in your Existing Passport also. The system is designed to reduce the human
labor and efficient. It provides flexible and powerful reports regarding the status of Passport and Many
facility. It also helps to overcome some Manual problems like Time delay.
BOOK BANK
SYSTEM
1
Ex.no:1 Problem Statement

Date:
Aim:
To develop the problem statement for Book Bank system.
PROBLEM STATEMENT:
Book bank software system deals between the member and book seller. It aims improving
efficiency in the issue of books, magazines and reduces the complexities involved in the maximum
possible extent. Considering the facts the number of book bank is increasing every year, an
automated system becomes essential to meet the demand.
3
Table of Contents
Table of Contents
ii Revision History 3
1. Introduction 4
1.1 Purpose
1.4 Product Scope
1.5 References
2. Overall Description 6
3. External Interface Requirements 7
3.1 User Interfaces
4. System Features 7
4.1 System Feature 1
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements 8
5.5 Business Rules
6. Other Requirements 9
Appendix A: Glossary 9
Appendix B: Analysis Models 9
Appendix C: To Be Determined List 9
Revision History
Name Reason For Changes Date Version
4
1.Introduction
Book bank software system deals between the member and book seller. It aims at improving the
efficiency in the issue of books, magazines and reduces the complexities involved in it to the
maximum possible extent.
1.1 Purpose
The purpose of this document is to present a detailed description of Book Bank System.
Considering the fact that the number of members for book bank is increasing every year, an
automated system becomes essential to meet the demand .So has been carefully verified and
validated in order to satisfy it. It uses as database techniques to clear or explain the entire process.

Sub heading Times New Roman 14 Bold

For different types of reader this document is intended for developers, project manager, marketing
staff, users and documentation writer. This SRS tells about distribution of books and how we are
managing this domain with this software.
1.4 Product Scope

The book bank software project is a software tool created to help and access the member gather
required information about the various book in the book bank. The project is web based interactive
application. Focus is laid solely on the book display,schedule,categories,syllabus and payment as
per required
1.5 References
The reference of the SRS is,
IEEE Software Requirement Specification format.

5
The Book bank is a self contained one for enabling a book bank organization to be connected with
its member through this system, the member can check for availability of books, makes request,
etc. This minimize the time duration in which the customer receivers the books or magazines.

This system functions with a database at the back end, for keep tracking its member dues and
payments, and also its available resources. Book bank system can easily create, delete and replace
the information of books and the details of the member. This system provide details about the
newly available books and magazines.
2.3 User Classes and Characteristic

● Member: They are the people who obtain the book and register their information. They
can be able to request newly available books and magazines.
● System operator: He / She has certain privileges to add and the approval of reservation of
books.

Operating System : Windows7
Database : Sql + Database
Platform :Vb.net /Java/PHP

● The system operator and the member requires computer to record the information.
● Although the security is high ,there is always a chance of intrusion in the web world so
constant monitoring is required.
Much care is required while updating information in the system

The user can register their information on the system. So that whenever any books or magazines
are requested they may get the notification.
6

The member and system operator should have a basic knowledge of English and computer
language. They may required to scan the document and store the information of reservation of
books

3.1 User Interfaces
This software is created for members who can interact easily with this software .GUI (Graphical
User Interface) is used in this software .Commands are given for users information.

The system should have a good hardware support .The processor should have high speed and must
be of high efficiency

Front End Client - The users online interface is built using HTML.
Back End – MySQL database .
3.4 Communications Interface

User are provided with reference number and their e-mails are get connected to the system, hence
notification are send. HTTP for security purpose is used which gives good communication
interface.
4. System Features
4.1 System Description and Priority
Allows a member, who becomes a member to login using unique id issued at the time of registering
as a member and after logging in , the member can browse through available books and make
request accordingly. The books will be issued provided there is no due, regarding returning of
previous books.
4.2 Stimulus /Response Sequence

7
Whenever the member wishes to get books , checks for the availability by logging in. when the
request is made, the director of the book bank decides on granting the request of books after
checking the member details for due in returning previous books.
4.3 Functional Requirements
A functional requirement defines a function of a software system on its component. A function is
described as a set of inout ,the behavior and output.
• Register: The register module contains the application form or registration from which
contains following details. Name, Address, Contact number, E-mail id, Password, etc.
● Login: The login module contains the form which contain membership name and member
password, It includes username and password
● Search Book: The search book module contain list of books, from this list we search for
the book which we need. This also contains another field called as categories where can
select the category of the book .
● Display Book: Display the details about the students particulars, the payments, the books,
rental and schedule times for books etc.
● Maintain Book Details: The administrator maintains the details of books. ● Logout: To
sign off from the webpage or your account log off

Performance requirements define acceptable response times for system functionality. The total
time for user interface screens will take no longer than two seconds. The login information shall
be verified within the seconds. Queries shall results within five seconds.
● Reliability: Specify the factors required to establish the required reliability of the software
system at time of delivery.
● Availability: The system should have an availability of 99.9%
● Portability: The system should be extremely via the usb drive. The system shall be easy
to migrate or backed up via another use drive.
● Maintainability: The system shall utilize interchangeable plugins. The system shall be
easily updateable for fixes and patches.

The member details should be made available in the database and must be updated everytime a
book is issued or returned or some kind of payment takes place to prevent errors.
8

The member can only access certain details from the database. He /she should not be able to modify
the database nor has any of its information corrupted. Only the DBA must be bestowed with the
privileges of handling any kind of modifications.
6. Other requirements
Appendix A:Glossary
● HTML
Hypertext Markup Language is the standard markup language for documents designed to
be displayed in a web Browser. It can be assisted by technologies such as cascading style sheets
and scripting languages such as JavaScript.
● GUI
The Graphical User Interface is a form of user interface that allows users to interact with
electronic device through graphical
9
Ex.no:3 Identify use cases and develop use case model

Date:
Use case diagram:

A use case diagram at its simplest is a representation of a user's interaction with the system that
shows the relationship between the user and the different use cases in which the user is involved.
A use case diagram can identify the different types of users of a system and the different use cases
and will often be accompanied by other types of diagrams as well. The use cases are represented
by either circles or ellipses.
Purpose of Use Case Diagrams :

The purpose of use case diagram is to capture the dynamic aspect of a system. However, this
definition is too generic to describe the purpose, as other four diagrams (activity, sequence,
collaboration, and Statechart) also have the same purpose.
Definition: Actors, Scenarios, and Use Cases
Actor:
An actor is something with behavior, such as a person (identified by role), computer system, or
organization; for example, a cashier.
Scenario:
A scenario is a specific sequence of actions and interactions between actors and the system; it is
also called a use case instance. It is one particular story of using a system, or one path through
the use case; for example, the scenario of successfully purchasing items with cash, or the scenario
of failing to purchase items because of a credit payment denial.
Usecase:
A use case is a collection of related success and failure scenarios that describe an actor using a
system to support a goal.
For example, here is a casual format use case with alternate scenarios
10
Name Symbol Description

Actor anything with behavior
Non-human Non human actors are

Actor usually not primary users,
<<actor>> and thus are usually shown
on the right, not the left
Use case A set of scenarios that

describing an interaction
between a user and a
system, including
alternative
System A system is shown as a

rectangle, labeled with the
system name.
Actors are outside
the system.
Use cases are inside the
system.
The rectangle shows the
scope or boundary of the
system.
Association An association is
Relationship the communication
path between an
actor and the use case that it
participates in.
It is shown as a solid line
11
include dashed line with an open

arrow pointing from the
base use case to the
inclusion use case. The
keyword «include» is
attached to the connector.
Extend dashed line with an open
arrowhead pointing from
the extension use case to the
base use case. The arrow is
labeled with the keyword
«extend»
generalize
12
Usecase diagram:
USE CASE NAME1:
Brief:
BOOK MAINTANENCE
Figure 1.1
Book maintenance deals between member and system operator. System operator maintains the
books in racks according to the rack no. System operator updates the returned books from the
member. He/She maintains the books according to date, author name and year.
Casual:
SUCCESS SCENARIO
13
To maintain the books in racks . Update the new collection of books and to refill the books. System
operator maintains the books in response to the author name, year, type of books.
ALTERNATE SCENARIO
Expected books are not available .Failed to update the new collection of books. Failed to refill the
returned books.
Fully dressed:
Usecase name Book maintanence
Scope Maintaining the books, magazines
and journals.
Level Maintanence of books and update the new
collection.
Primary actor System operator, Member.
Stake holders Member, Student, Faculty.
Precondition Book bank on working.
Main Success Scenario To maintain the books in racks.
Update the new collection of books.
Refill the return books.
Extension Proper maintanence is needed.
Exception/Failure Expected books not available.
Failed to update the new collection of books.
Failed to refill the returned books.
Special requirements Provide more authentication
Secondary/Supporting actor Student, Faculty
USE CASE NAME 2:

ISSUE BOOK
BRIEF FORMAT:
Here the system operator issues the books based on the request made by the member. Member
request for a particular book. System operator issue the books, journals and magazines based on
their request.
CASUAL FORMAT:
14
SUCCESS SCENARIO
Member made a request to a particular book. System operator whether the requested books are
available or not. If available the system operator issues the books, journals and magazines.
ALTERNATE SCENARIO
Requested books are not available. Journals and magazines are not in up to date.Member requested
author books are not present.
FULLY DRESSED FORMAT:

Usecase name Issue books
Scope Issue the book based on the request made by the
member.
Level Books, magazines, journals are issued by the
operator based on the members request.
Primary actor System opertor, Member
Stake holders Member, Student, Faculty
Precondition System operator must be available.
Main Success Scenario Member made a request of a particular book.
System operator checks whether the requested
book available/not.
If available the sends the requested book to the
members.
Extension Checks the availability of the books.
Special requirements Provides an authentication
USE CASE NAME 3:

MEMBER PROFILE:
BRIEF FORMAT:
Create a member profile who are all using the book bank system. Member profile is used to
maintain the usage of particular books by the member. By using this member profile the system
operator may be easily used to send the notification.
CASUAL FORMAT:
SUCCESS SCENARIO
Member profile can be used to maintain their details. If any books needed they may get any
notification about the books.
15
ALTERNATE SCENARIO
If the member does not provide with a membership card he/she may need to create a new profile.

Usecase name Member profile
Scope Create a member profile who are all using book

bank system.
Level Member profile are used to maintain the usage of
books by particular person.
Primary actor System Operator, Member
Stake holders Member, Faculty, Student
Main Success Scenario To create a member profile.
Get a email id to send notification
Exception/ Failure If the member does not provide with a
membership card he/she may need to create a
new profile.
16
Ex.no:4 Identify conceptual classes and develop the

Date: domain model with UML class diagram
Class diagram:
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a system but also for constructing
executable code of the software application. Class diagram describes the attributes and operations of a class
and also the constraints imposed on the system. The class diagrams are widely used in the modeling of
object oriented systems because they are the only UML diagrams, which can be mapped directly with object
oriented languages. Class diagram shows a collection of classes, interfaces, associations, collaborations,
and constraints. It is also known as a structural diagram.

Members:
UML provides mechanisms to represent class members, such as attributes and methods, and additional
information about them.
Visibility:
+ Public
- Private
# Protected
~ Package
Derived property:
Is a property which value (or values) is produced or computed from other information, for
example, by using values of other properties.
Scope:
17
Classifier members are commonly recognized as “static” in many programming languages. The
scope is the class itself. o Attribute values are equal for all instances o Method invocation does not
affect the classifer’s state
Instance members are scoped to a specific instance. o Attribute values may vary between
instances o Method invocation may affect the instance’s state (i.e. change instance’s attributes) To
indicate a classifier scope for a member, its name must be underlined. Otherwise, instance scope
Relationships:
Class Notation:
• The third section is used to describe the operations performed by the class. • The fourth
section is optional to show any additional components.
Elements
• Attributes
• Operations & Methods
• Relationship between classes
18
To create a Domain Model:

1. Find the conceptual classes.
2. Draw them as classes in a UML class diagram.
3. Add associations and attributes
TO FIND CONCEPTUAL CLASSES:

Three strategies to find conceptual classes are.
1. Reuse or modify existing models
2. Use a category list
3. Identify noun phrases
Domain Model:
19
Figure 1.2
CLASS DIAGRAM:
Figure 1.3
The class diagram consists of five classes namely book, system operator, member record, bill and
transaction.
• system operator may view the books in the system
• one or many members may create a profile
• member can make a payment to bill
• one or many member may request the books
• bill class generate the transactions
20
Ex.no:5 Using identified scenarios find interaction between objects and

represent them using UML sequence diagram
Date:
SequenceDiagram:
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order
in which these interactions take place. We can also use the terms event diagrams or event scenarios
to refer to a sequence diagram. Sequence diagrams describe how and in what order the objects in
a system function. These diagrams are widely used by businessmen and software developers to
Sequence Diagram Notations :

1. Actors:
An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we aim
to model using the UML diagram.
2. Object:
• Objects are instances of classes. Object is represented as a rectangle which contains the name
of the object underlined. • Because the system is instantiated, it is shown as an object.
:Object1
Lifeline: The LifeLine identifies the existence of the object over time. The notation for a Lifeline is a vertical
dotted line extending from an object.
21
Message: Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.
messageName(argument)
Messages can be broadly classified into the following categories :
Synchronous messages:
A synchronous message waits for a reply before the interaction can move forward. The sender
waits until the receiver has completed the processing of the message. The caller continues only
when it knows that the receiver has processed the previous message i.e. it receives a reply message.
A large number of calls in object oriented programming are synchronous. We use a solid arrow
head to represent a synchronous message.
Asynchronous Messages:
An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined arrow
head to represent an asynchronous message.
Create message:
We use a Create message to instantiate a new object in the sequence diagram. There are situations
when a particular message call requires the creation of an object. It is represented with a dotted
arrow and create word labelled on it to specify that it is the create Message symbol. For example
– The creation of a new order on a e-commerce website would require a new object of Order class
to be created.
22
Delete Message:
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of the
object in the system.It is represented by an arrow terminating with a x. For example: In the scenario
below when the order is received by the user, the objectof order class can be destroyed.
Self Message:
Certain scenarios might arise where the object needs to send a message to itself. Such messages
are called Self Messages and are represented with a U shaped arrow.
Reply Message:
Reply messages are used to show the message being sent from the receiver to the sender. We
represent a return/reply message using an open arrowhead with a dotted line. The interaction moves
forward only when a reply message is sent by the receiver. Figure: reply message For example:
Consider the scenario where the device requests a photo from the user. Here the message which
shows the photo being sent is a reply message.
Found Message:
A Found message is used to represent a scenario where an unknown source sends the message. It
is represented using an arrow directed towards a lifeline from an end point. For example: Consider
the scenario of a hardware failure.
Lost Message:
23
A Lost message is used to represent a scenario where the recipient is not known to the system. It
is represented using an arrow directed towards an end point from a lifeline. For example: Consider
a scenario where a warning is generated.
Guards:
To model conditions we use guards in UML. They are used when we need to restrict the flow of
messages on the pretext of a condition being met. Guards play an important role in letting software
developers know the constraints attached to a system or a particular process.
Figure 1.4
Sequence diagram:
24
Figure 1.5
The member login to the system which is seen by system operator. System operator request a
member card. Member provides the card. System operator checks the availability of the member
card and confirms the member card. Member search for books .It checks the availability. If the
book is available provide the book otherwise insufficient of books. If available member borrows
the books from the system operator. System operator stores the record in the server. System
operator notify the update. Member returns the books to the systemoperator. Member makes the
payment and server update the record.
25
Ex.no:6 Using the identified scenarios, find the interaction between

Objects and represent them using UML communication
Date: diagram
Communication diagram:
These diagrams can be used to portray the dynamic behavior of a particular use case and define
the role of each object. Collaboration diagrams are created by first identifying the structural
elements required to carry out the functionality of an interaction. A model is then built using the
relationships between those elements. Several vendors offer software for creating and editing
collaboration diagrams.

A collaboration diagram resembles a flowchart that portrays the roles, functionality and behaviour
of individual objects as well as the overall operation of the system in real time. The four major
Objects:
Objects are shown as rectangles with naming labels inside. The naming label follows the
convention of object name: class name. If an object has a property or state that specifically
Object
Links:
Links connect objects with actors and are depicted using a solid line between two elements. Each
link is an instance where messages can be sent.
3. Messages:
Messages between objects are shown as a labeled arrow placed near a link. These messages are
communications between objects that convey information about the activity and can include the
sequence number.
The most important objects are placed in the center of the diagram, with all other participating
objects branching off. After all objects are placed, links and messages should be added in between.
26
Figure 1.6
27
Ex.no:7 Draw relevant state charts and activity diagrams
Date:
Activity diagram:
An activity diagram visually presents a series of actions or flow of control in a system similar to a
flowchart or a data flow diagram. Activity diagrams are often used in business process modeling.
They can also describe the steps in a use case diagram. Activities modeled can be sequential and
concurrent. In both cases an activity diagram will have a beginning (an initial state) and an end (a
final state).
Activity Diagram Notations and Symbols

Initial State or Start Point
A small filled circle followed by an arrow represents the initial action state or the start point for
any activity diagram. For activity diagram using swimlanes, make sure the start point is placed in
the top left corner of the first column.
Activity or Action State

An action state represents the non-interruptible action of objects. You can draw an action state in
SmartDraw using a rectangle with rounded corners.
Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state to another.
They are usually drawn with an arrowed line.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow
from an action to an object means that the action creates or influences the object. An object flow
arrow from an object to an action indicates that the action state uses the object.
28
Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a decision prior to
moving on to the next activity, add a diamond between the two activities. The outgoing alternates
should be labeled with a condition or guard expression. You can also label one of the paths "else."
Guards
In UML, guards are a statement written next to a decision diamond that must be true before moving
next to the next activity. These are not essential, but are useful when a specific answer, such as
"Yes, three labels are printed," is needed before moving forward.
Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented
as a straight, slightly thicker line in an activity diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.
29
Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.
Merge Event
A merge event brings together multiple flows that are not concurrent.
Sent and Received Signals

Signals represent how activities can be modified from outside the system. They usually appear in
pairs of sent and received signals, because the state can't change until a response is received, much
like synchronous messages in a sequence diagram. For example, an authorization of payment is
needed before an order can be completed.
30
Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.
Swimlanes
Swimlanes group related activities into one column.
Final State or End Point

An arrow pointing to a filled circle nested inside another circle represents the final action state.
Activity diagram:
31
Figure 1.7
The activity diagram consist of three swim lanes namely member, system operator and server.
Member login in the system and request card. If the login is valid then search the books otherwise
32
create the mem card .If the searched book is available then issue the books otherwise request the
particular book. Return the books from member by notification. Final process is the payment and
the server receive the payment and update the record.
State diagram:
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams. These
terms are often used interchangeably. So simply, a state diagram is used to model the dynamic
behavior of a class in response to time and changing external stimuli. We can say that each and
every class has a state but we don’t model every class using State diagrams. We prefer to model
the states with three or more states.
Uses of statechart diagram

• To state the events responsible for change in state (we do not show what processes cause
those events).
• To model the dynamic behavior of the system .
• To understand the reaction of objects/classes to internal or external stimuli.
Basic components of a statechart diagram

Initial state – We use a black filled circle represent the initial state of a System or a class.
Initial state notation

Transition – We use a solid arrow to represent the transition or change of control from one state
to another. The arrow is labelled with the event which causes the change in state.
Transition State – We use a rounded rectangle to represent a state. A state represents the
conditions or circumstances of an object of a class at an instant of time.
State notation
Fork – We use a rounded solid rectangular bar to represent a Fork notation with incomig arrow
from the parent state and outgoing arrows towards the newly created states. We use the fork
notation to represent a state splitting into two or more concurrent states.
33
A diagram using the fork notation

Join – We use a rounded solid rectangular bar to represent a Join notation with incoming arrows
from the joining states and outgoing arrow towards the common goal state. We use the join notation
when two or more states concurrently converge into one on the occurrence of an event or events.
A diagram using join notation
Self transition – We use a solid arrow pointing back to the state itself to represent a self transition.
There might be scenarios when the state of the object does not change upon the occurrence of an
event. We use self transitions to represent such cases.
Self transition notation

Composite state – We use a rounded rectangle to represent a composite state also.We represent a
state with internal activities using a composite state.
A state with internal activities

Final state – We use a filled circle within a circle notation to represent the final state in a state
machine diagram.
34
final state notation
Steps to draw a state diagram :

• Identify the initial state and the final terminating states.
• Identify the possible states in which the object can exist (boundary values corresponding
to different attributes guide us in identifying different states).
• Label the events which trigger these transitions.
State Diagram:
Figure 1.8
35
Ex.no:8
Implement system as per detailed design
Date:
CLASS NAME:BILL
public class bill { public
Integer billno; public
Integer date; public
Integer memid; public
Integer amount; public
Vector generate; public
Vector payment; public
void billcreate() {
public void billupdate() {
CLASS NAME: BOOK
import java.util.Vector; public class book
extends systemoperator { private Integer id;
public Integer author; public Integer price;
public Integer rackno; public Integer date; public Vector views;

public Vector create; public
void displaybook() {

36
CLASS NAME:FACULTY
public class faculty extends memberrecord {
public Integer id; public Integer name;
public Integer phone;
CLASS NAME:JOURNALS
public class journals extends book {
public Integer price; public Integer
date; public Integer rackno;
CLASS NAME:MAGAZINE
public class Magazine extends book {
public Integer price; public Integer
date;
CLASS NAME:MEMBERRECORD
public class memberrecord {
public Integer memid; public
Integer date; public Integer
noofbook; public Integer
maxbook; public Integer
name; public Integer phone;
public Integer mailid; public

37
Vector payment; public
Vector create; public Vector
create; public void
retrievenum() {
public void paybill() {
CLASS NAME:STUDENT
public class student extends memberrecord {
public Integer id; public Integer name;
CLASS NAME:STUDENT BOOK
public class studybook extends book { public
Integer price;
public Integer bookid;
CLASS NAME:SYSTEM OPERATOR
public class systemoperator {
public String name; public
Integer password; public
Vector views; public Vector

38
create; public Vector create;
private void searchbook() {
public void verifynum() {
public void issuebook() {
public void createbill() {
public void returnbook() {
CLASS NAME: TRANSACTION
import java.util.Vector; public
class transaction { public
Integer memid; public Integer
transid; public Integer bookid;
public Integer dateofissue;
public Vector create; public
Vector generate; private void
createtrans() {
public void deletetrans() {
public void derive() {

39
}
40
Ex.no:9
Test the software system for all the scenarios identified as per the usecase
diagram.
Date:
Class name: Book

import java.util.Vector; public class book
extends systemoperator { private Integer id;
public Integer author; public Integer price;
public Integer rackno;

public Integer date; public
Vector views; public
Vector create; public void
displaybook() {
}
41
42
Ex.no:10 Improve the reusability and maintainability of the software system by

applying appropriate design patterns
Date:
factory pattern known as a creational pattern, provides a method to encapsulate a group of
individual factories that have a familiar theme without specifying their concrete classes. In usual
case, the client software create a concrete implementation of the abstract factory then using
generic interface of the factory to create the concrete objects which is part of the theme. The
client doesn’t know which concrete objects gets from all of these internal factories, since it uses
only the generic interfaces of their products. Abstract products describe interface for every
different products of a single product family. Concrete products implement the abstract product
interface which is returned by creational methods of concrete factories. Abstract factory defines
the interface for creating products which is common to all concrete factories. Concrete factories
implement creational methods of the abstract factory and each concrete factory should
correspond to a specific products variant as shown in Figure.
Figure 1.9: design pattern - abstract factory

Purpose of abstract factory design pattern is to provide an interface for creating families of
related objects without specifying concrete classes. The following Figure( ) shows the example
43
of abstract factory design pattern for user login where two concrete factory and concrete product
used for execution.
Figure 1.10 : Abstract Factory Design Pattern for User Login

Using proposed method design pattern asses where requirement is well documented and
fixed which is used as input. As step 1 firstly identify the design problem using alternative design
solutions from literature and experience, and solve using abstract factory design pattern. In step 2
maintainability, reusability, understandability, flexibility, composability, completeness, stability,
simplicity, and expandability are selected as design objective. Using step 3 appropriate solution
is selected as step 4 (tool) and step 5 (mathematical formation). In step 4 maintainability,
reusability, understandability, and flexibility are calculated using parecon’s design pattern
advisor tool. In step 5 composability, completeness, stability, simplicity, and expandability are
measured using mathematical formation. In step 6, combine step 4 and 5 output to get required
quality product. Assessment of these nine quality attributes are discussed as:
Maintainability:
Use of a design pattern essentially complicates design to usually add abstract classes and
additional associations to employ a design pattern. The key advantage of using design pattern is
that the resulting software should be easier to adapt, to modify fewer classes, to add functionality
to software. So, maintenance Client abstractfactory+doaction1:void+doaction2:void
abstractproduct+doaction:voidabstractfactory concreteproduct1 concreteproduct2
concretefactory1 concreteproduct1: Admin concreteproduct2: User concreteproduct1
+doaction:voidconcretefactory2 concreteproduct1: Admin concreteproduct2: User
44
concreteproduct2+doaction:void 95 programmers should have to use less effort to adapt these

changes. Every introduced pattern caused an improvement in different quality attributes.
Reusability:
patterns detain static and dynamic structure and collaborations of components in successful
solutions to problems that occur when developing software like business data processing,
databases, graphical user interfaces, telecommunications, and distributed communication
software. Patterns 96 help development of reusable components and frameworks by using
structure and collaboration of participants in software architecture at a level higher than source
code and object oriented design models that focus on individual objects and classes. Thus,
patterns facilitate reuse of software architecture, even when additional forms of reuse are
infeasible. An empirical investigation on reusability of design patterns and software packages,
attempts to empirically investigate reusability of design patterns, classes, and software packages
to identify the most beneficial starting points for white box reuse, which is pretty popular among
OSS.
Conclusion:
The book bank system provide books to the privileged people. It makes easier in search of books.
Book bank system is user friendly. Database updates the details at any time. The database notify the
member about the available of books,return date and also maintain the records. A member can reserve the
book or magazine at any time. This system is highly secured.
ONLINE EXAM
REGISTRATION
SYSTEM
Ex. No 1 PROBLEM STATEMENT
Date:
AIM:
To develop the problem statement for Online Exam Registration.
PROBLEM STATEMENT:
To develop an Online Exam Registration Software. An Online Exam Registration Software is
meant for those who want to register to competitive exams via Internet. The list of examination will be
displayed. The candidate has to choose the exam, the application form will be displayed. The candidate
has to fill their details and submit. The submitted details will be verified by the information Versifier. If
the candidates are eligible the it proceeds to the payment section. Once the payment is done, the
acknowledgment will be sent to their corresponding mail Id.
Table of Contents
Table of Contents ......................................................................................................................... iii
Revision History ........................................................................................................................... iii
1. Introduction ..............................................................................................................................4
1.1 Purpose ............................................................................................................................................. 4
1.4 Product Scope ................................................................................................................................... 4
1.5 References......................................................................................................................................... 4
3. External Interface Requirements ...........................................................................................5
3.1 User Interfaces .................................................................................................................................. 5
4. System Features .......................................................................................................................3
4.1 System Feature 1 .............................................................................................................................. 6
5.4 Software Quality Attributes .............................................................................................................. 7
5.5 Business Rules .................................................................................................................................. 7
6. Other Requirements ................................................................................................................5
Appendix A: Glossary....................................................................................................................5
Appendix B: Analysis Models .......................................................................................................5
Appendix C: To Be Determined List ............................................................................................6
Revision History
1. Introduction
1.1 Purpose
The Online Exam Registration Software is meant for those who want to register for all competitive
examinations via online. This SRS is used to document all the needed details of the complete system.
Font Style Font Size
Heading Times New Roman 18
Sub Headings Times New Roman 14
Description Times New Roman 11

The Document is referred by, Developers of the software, Product Managers who analyses and
supports the software and Testers who fixes and checks for bugs.
1.4 Product Scope

The project makes easier the registration for the competitive exams.
1.5 References
The document is referred from the template given by IEEE - “srs_template_ieee“.
The Online Exam Registration Software is a system developed to simplify the registration for
competitive exams. The system will be properly stared if the system is connected to a proper network
connection. Then in the interface the list of competitive exam will be displayed. For each competitive
exam the respective application form will be displayed. The eligibility for the exam will be verified in
the application filled and then it proceeds to the payment section. The confirmation of the registration
will be sent to the respective mail Id of the candidate.
4
The System consists of functions to list the competitive exams, a function to get the valid details, a
function to verify the given details are eligible for the exam or not.

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

The system is made to run on a Windows Platform of versions Windows xp, 7, 8, 8.1, 10, Linux, Mac.
The system is only being operated if the system is connected to a network connection.

The system needs an appropriate memory of 100mb and need the internet connection should be
properly installed. The login information’s of the candidates will be stored in a Data Base that uses
SQL+ for storing the data.

The product will include a user manual. The user manual will include product overview, complete
configuration of the required software and hardware, technical details and contact information which
will include email address.

• The candidates system should be properly connected to the internet.
• Login Id and password of the candidate must correct.

3.1 User Interfaces
The Interface consists of Login and Password text box and a sign in button. Next stage of the sign in,
the interface then consists of list of examination available, each examination is clickable and a form
will be displayed after clicking a exam. The form is included with respective text fields where the
details of the candidates will be filled. And a submit button will be found that helps the user to
proceed to the payment segment. A help button will included in the interface that helps the candidate
to get solution for the problems arise.
5
The Server machine should be connected to high speed internet connectivity. The system should
consist of database.
The client machine should be consisting of a free memory of 100mb approximately. And the system
should connect to an internet connection. As the software is web based application, the system should
be installed with a browser.

The Online Exam-Registration software is connected to a database where the login Id and password
are stored. And the software contains a specific space where the candidate can include their
certificates.

As the software is web based, the software needs web browser to run properly. The browser may be
any of the common browsers available.
4. System Features
The online Exam Registration software is a software to make the registration for a competitive exams
easier. The system where the software is going to run must consist of proper internet connection and a
web browser.

The software consists of an authentication service. This service is given to a higher priority. (8).
Then a database in included to the software. This is also given to a higher priority (9).

In the initial stage, the user is tested with an authentication service, and then the user attains
each service by choosing the particular exam listed. After applying the user is forwarded to
the payment section, and then a mail will be sent to the mail the user given.
This section gives a functional requirement that applicable to the On-Line
Examination system.There are three sub modules in this phase.
Candidate module.
Examiner module.
Administrator module.
Result rankings module
Discussion Forum module
REQ-1: Authentication
REQ-2: Registration
REQ-3: Verification...
6
The software needs a minimum network speed of 50k/s or more for its better performance. The
system where the software is going to run must contain a browser.

The network cables should be in a proper condition, else the network connection may be lost and
hence the registration may aborted or reloaded from the initial stage. The database included should
also be linked properly.

The software is built in way (i.e.)the software protect itself from the domination of other web sites ads
while running. The data provided by the candidates are only visible to the organizers of the exam,
hence data threat is restricted.

The software can be run on any windows machine. No external devices or software are needed. The
software is can used by any kind of candidates and it is also robust.
5.5 Business Rules

The software doesn't contain any business rules, (i.e.) there is no special circumstances to other then
the authentication failure and payment failure. By proper authentication for login and payment the
functionalities will be completed successfully.
7
Ex.No:3 Identify Use Cases and develop use case model
Date:
USE CASE DIAGRAM:

shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.
Purpose of Use Case Diagrams:
collaboration, and State chart) also have the same purpose.
Basic Use Case Diagram Symbols and Notations:
System:
Draw your system's boundaries using a rectangle that contains use cases. Place actors outside
the system's boundaries.
Use case:
8
Actors:
Actors are the users of a system. When one system is the actor of another system, label the
actor system with the actor stereotype.
Relationships:
Illustrate relationships between an actor and a use case with a simple line. For relationships
among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates
that one use case is needed by another in order to perform a task. An "extends" relationship
indicates alternative options under a certain use case.
9
USE CASE DIAGRAM:
10
USE CASE MODELING
SIGN UP
BRIEF:
The candidates Sign up to the system, for next level usage. The Candidates should give a
valid email ID and should give a valid and satisfying password with the proper condition that a
password should have. Then an acknowledgment will be sent for successful creation of the account to
the respected mail-Id given.
CASUAL:
Success Scenario:
The candidates Sign up to the system, for next level usage. The Candidates should give a valid
email Id and should give a valid and satisfying password with the proper condition that a password
should have. Then an acknowledgment will be sent for successful creation of the account to the
respected mail-Id given.
Alternate Scenario:
The candidates Sign up to the system, for next level usage. The Candidates should give a
valid email Id and should give a valid and satisfying password with the proper condition that a
password should have. If the given mail Id is not valid or the password entered doesn’t satisfies the
necessary condition a pop will be seen with an error message.
FULLY DRESSED:
Use Case Name Sign Up
Scope To create a user account that allows them to interact with the
system
Level To create a new user account

Primary Actor Candidates
Stack Holder Administrator
Preconditions The user must have an authorized email Id
Main Success Scenario * Entering a valid mail Id

* Entering a password with all necessary conditions
* Confirming the password
* Acknowledging
Exception * Has no valid mail Id
* Password doesn’t satisfy the primary conditions
LOGIN
11
BRIEF:
The Candidates enters the valid email Id and the password for that account. Then on clicking
the login button the authentication will be done. The candidate will be allowed to next level process if
the authentication is valid. If the authentication is not valid then a pop will be shown with a warning.
CASUAL:
Successful Scenario:
the login button the authentication will be done. The candidate will be allowed to next level process if
the authentication is valid.
Alternate Scenario:
the login button the authentication will be done. If the authentication is not valid the candidate will not
be allowed to the next steps. A pop up will be shown with a warning message.
FULLY DRESSED:
Use Case Name Login
Scope To login the user to the system
Level Authentication, To login the user
Primary Actor Candidates
Stack Holder Administrator
Preconditions The user should sign up to the system
Main Success Scenario * Entering the username

* Entering the password
* Logging in into the system
Exception * Incorrect mail Id or password

* User not signed up
12
Ex.No:4 Identify Conceptual classes and develop the
domain model and also derive a class diagram
Date: from that
Domain model:
Steps to create a domain model:
1. Find conceptual classes.
3. Add Associations and attributes.
Finding Conceptual classes:

1. Reuse or modify existing conceptual models
2. Use category list.
3. Identify noun phrases.
Category list:
1.Business transaction: Payment
2.Transaction item: Payment Line Item
3.Product or service Authentication, Registration, Payment

Related to transaction:
4. Where the transaction recorded: Exam Controller, Manifest.
5. Role of people or organization related to Candidate, Exam Controller, Admin

transaction:
6.Place of transaction: Web Center
7.Noteworthy events: Registration, Payment, Login
8.Physics objects: Computer
9.Description of things: Registration Description
13
Identify the noun phrase:
Main success scenario:
• The username and password are stored to the Admin Manifest.
• Candidate login to the system. Authentication will be done by the Administrator.
• Chooses the exam from the given list of examination.
• The Candidate fills the application form given by the exam controller.
• The detailed filled in the application form is validated.
• Then moves to the payment section.
• The candidate pays the amount for that examination.
• Acknowledgment will be sent to their respective email or phone.
Nouns:
• Candidate.
• Examination.
• Application Form.
• Exam Controller.
• Payment.
• Administrator.
• Admin Manifest.
14
Domain Model:
15
CLASS DIAGRAM:
Class diagram is a static diagram. It represents the static view of an application. Class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but
also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of objectoriented
systems because they are the only UML diagrams, which can be mapped directly with object-
oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.
Members:
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these notations must
be placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
example, by using value of other properties.
Scope:
16
• Classifier members are commonly recognized as “static” in many programming
languages. The scope is the class itself.
o Method invocation does not affect the classifer’s state
o Attribute values may vary between instances
o Method invocation may affect the instance’s state (i.e. change instance’s attributes)
To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance
scope is assumed by default.
Relationships:
Class Notation:

17
• The fourth section is optional to show any additional components
Classes are used to represent objects. Objects can be anything having properties and
responsibility.
Object Notation:
It is represented in the same way as the class. The only difference is the name which is
underlined as shown in the following figure.
18
CLASS DIAGRAM:
19
Ex.No:5 Using the identified scenarios find the interaction
between objects and represent them using UML
Date: sequence diagram
SEQUENCE DIAGRAM:
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order
the objects in a system function. These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and existing systems.
Sequence Diagram Notations:
1. Actors: An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the scope
of the system we aim to model using the UML diagram.
2. We use actors to depict various roles including human users and other external subjects.
We represent an actor in a UML diagram using a stick person notation. We can have
multiple actors in a sequence diagram. For example: Here the user in seat reservation
system is shown as an actor where it exists outside the system and is not a part of the
system.
20
Figure: an actor interacting with a seat reservation system
3. Lifelines: A lifeline is a named element which depicts an individual participant in a
sequence diagram. So basically each instance in a sequence diagram is represented by
a lifeline. Lifeline elements are located at the top in a sequence diagram. The standard
in in UML for naming a lifeline follows the following format – Instance Name : Class
Name
We display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
21
model an unnamed instance, we follow the same pattern except now the portion of
lifeline’s name is left blank.
Difference between a lifeline and an actor: A lifeline always portrays an object internal
to the system whereas actors are used to depict objects external to the system. The
following is an example of a sequence diagram:
4. Messages: Communication between objects is depicted using messages. The messages

appear in a sequential order on the lifeline. We represent messages using arrows.
Lifelines and messages form the core of a sequence diagram.
22
1. Synchronous messages: A synchronous message waits for a reply before the

interaction can move forward. The sender waits until the receiver has completed
the processing of the message. The caller continues only when it knows that the
receiver has processed the previous message i.e. it receives a reply message. A
large number of calls in object oriented programming are synchronous. We use
a solid arrow head to represent a synchronous message.
2. Asynchronous Messages: An asynchronous message does not wait for a reply

from the receiver. The interaction moves forward irrespective of the receiver
processing the previous message or not. We use a lined arrow head to represent
an asynchronous message.
23
3. Create message: We use a Create message to instantiate a new object in the
sequence diagram. There are situations when a particular message call requires
the creation of an object. It is represented with a dotted arrow and create word
labeled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would
require a new object of Order class to be created.
• Delete Message: We use a Delete Message to delete an object. When an object is de

allocated memory or is destroyed within the system we use the Delete Message symbol.
It destroys the occurrence of the object in the system. It is represented by an arrow
terminating x. For example – In the scenario below when the order is received by the
24
user, the object of order class can be destroyed.
• Self Message: Certain scenarios might arise where the object needs to send a message to
itself. Such messages are called Self Messages and are represented with a U shaped arrow.
25
• Reply Message: Reply messages are used to show the message being sent from the
receiver to the sender. We represent a return/reply message using an open arrowhead with
a dotted line. The interaction moves forward only when a reply message is sent by the
receiver.
For example – Consider the scenario where the device requests a photo from the user.
Here the message which shows the photo being sent is a reply message.
26
• Found Message: A Found message is used to represent a scenario where an unknown
source sends the message. It is represented using an arrow directed towards a lifeline from
an end point. For example: Consider the scenario of a hardware failure.
27
It can be due to multiple reasons and we are not certain as to what caused the hardware
failure.
• Lost Message: A Lost message is used to represent a scenario where the recipient is not
known to the system. It is represented using an arrow directed towards an end point from
a lifeline. For example: Consider a scenario where a warning is generated.
interacting with. Since the destination is not known before hand, we use the Lost Message
symbol.
Guards: To model conditions we use guards in UML. They are used when we need to restrict
the flow of messages on the pretext of a condition being met. Guards play an important role in
letting software developers know the constraints attached to a system or a particular process.
For example: In order to be able to withdraw cash, having a balance greater than zero is a
condition that must be met as shown below.
28
Uses of sequence diagrams:
procedure.
29
SEQUENCE DIAGRAM:
The candidate login to the system by entering the valid email id and password. Authentication will be
done by the Admin. The candidate requests for the list of examinations and the Exam Controller will
give the list of exams available. After choosing an exam from the list the Application form will be given
by the Exam Controller to the candidate. The Application form will be filled by the candidate and it
will be submitted to the Exam Controller. The Exam controller will analyse the application form with
the help of Information Versifier. If the details filled in the Application Form is valid for the
examination chosen by the candidate, then the candidate will be proceeded to the payment section. The
candidate chooses the type of payment and the Bank will validate the account and authenticates the
payment. Finally, an acknowledgment will give to the candidate after then payment executed
successfully.
30
Ex.No:6 Using the identified scenarios, find the interaction
Date: collaboration diagram
relationships and interactions among software objects in the Unified Modeling Language
(UML). These diagrams can be used to portray the dynamic behavior of a particular use
cases and define the role of each object.
Collaboration diagrams are created by first identifying the structural elements required to carry
out the functionality of an interaction. A model is then built using the relationships between
those elements. Several vendors offer software for creating and editing collaboration diagrams.
A collaboration diagram resembles a flowchart that portrays the roles, functionality and
behaviours of individual objects as well as the overall operation of the system in real time. The
four major components of a collaboration diagram are:
1. Objects- Objects are shown as rectangles with naming labels inside. The naming label
follows the convention of object name: class name. If an object has a property or state that
specifically influences the collaboration, this should also be noted.
2. Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a
name and a role, with one actor initiating the entire use case.
3. Links- Links connect objects with actors and are depicted using a solid line between two
elements. Each link is an instance where messages can be sent.
4. Messages- Messages between objects are shown as a labeled arrow placed near a link.
These messages are communications between objects that convey information about the
activity and can include the sequence number.
31
The most important objects are placed in the centre of the diagram, with all other participating
objects branching off. After all objects are placed, links and messages should be added in
between.
32
Ex.No:7 Draw relevant state chart diagram and activity
diagram
Date:
ACTIVITY DIAGRAM:
Activity diagram describe activities which involve concurrency and synchronization, which are
a variation of state diagrams that focuses on the flow of actions and events. They can be used
for:
• To model a human task (a business process, for instance).
33
ACTIVITY DIAGRAM:
34
A state machine Diagram (or start diagram, also called state chart of state transition
diagram) is a behaviour which specifies the sequence of states an entity (or object)
visits during its lifetime in response to events, together with its responses to those events.
Key concepts:
State
A state is a condition during the life of an object during which it satisfies some condition,
performs some activity, or waits for some external event.


• The initial state of a state machine diagram, known as an initial pseudo-state, is
indicated with a solid circle. A transition from this state will show the first real state
The final state of a state machine diagram is shown as concentric circles. An open loop
closed loop state machine diagram does not have a final state; if it is the case, then the
object lives until the entire system terminates.
35
STATE DIAGRAM:
36
Ex.No:8 Implement system as per detailed design
Date:
Class Name: Admin
public class Admin {
public Integer id;
public String Cand_username;
public String Cand_password;
public Vector myAdminManifest;
public Vector myCandidate;
public Vector my;
public Vector validate;
public void Validate() {
Class Name: AdminManifest
public class AdminManifest {
public Integer cust_username;
public Integer cust_password;
public Vector myCandidate;
public Vector myAdmin;
public Admin getDetails;
public void getAccountDetails() {
37
}
Class Name: Application Form
public class AplicationForm {
public String exam_details;
public void fillApplication() {
Class Name: Candidate
public class Candidate {
public Integer id;
public String name;
public String email;
public String address;
public String qualification;
public Vector myAdminManifest;
public Vector myAdmin;
public Payment pays;
public ExamController register;
public void SignUp() {
public void Login() {
38
}
Class Name: ExamController
public class ExamController {
public String list_exams;
public Candidate cand_acc;
public Integer hallticket_id;
public Vector manages;
public void giveExamList() {
public void giveApplication() {
public void ShowExamList() {
public void ChooseExam() {
public void FillingApplication() {
public void Eligible() {
public void Payment() {
public void Authenticated() {
39
Class Name : Examination
public class Examination {
public Integer exam_id;
public String exam_name;
Class Name : Payment
public Integer Trans_id;
public Integer Bank_id;
public Integer Acc_no;
public void pay() {
40
Ex. No:9 Test the software system for all the scenarios
identified as per the use case diagram
Date:
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network or object to
test its strength or to analyze overall response time under different load types. JMeter simulates
a group of users sending requests to a target server, and returns statistics that show the
performance and functionality of the target server via tables, graph, etc.
Apache JMeter is open source software, a 100% pure Java desktop application, designed to
load test functional behavior and measure performance of web sites. It was originally designed
for load testing web applications but has since expanded to other test functions.
The protocols supported by JMeter are:
• Web - HTTP, HTTPS sites web1.0, web 2.0 (ajax, flex and flex-ws-amf).
• Web services – SOAP / XML-RPC.
• Database services via JDBC drivers.
• Directory – LDAP.
• Messaging oriented services via JMS.
• Service – POP3, IMAP, SMTP.
• FTP services.
JMeter Features:
• Being an open source software, it is freely available.
• It has simple and intuitive GUI.
• JMeter can conduct load and performance test for many different server types.
• It has platform independent tool.
• JMeter stores its test plans in XML format.
• It is highly extensible.
To sum up, JMeter allows you to swarm a web application without thousand virtual users and
measure its performance at the same time.
41
Class name: User.java
package onlineExam;
public class Candidate {
public String Username="ggg";
public String Password="ggg679";
public String Login(String usern_, String pass) {
return “success”;
JMETER CODING :
import onlineExam.Candidate;
Candidate cand = new Candidate ();
C= new cand.Login(“ggg”, “ggg679”);
42
SUCCESS:
43
FAILURE:
44
Exp.No:10 Improve reusability and maintainability by
applying appropriate design pattern
Date:
For illustration purpose abstract factory pattern is used to describe the proposed method. Abstract factory
pattern known as a creational pattern, provides a method to encapsulate a group of individual factories that
have a familiar theme without specifying their concrete classes. In usual case, the client software create a
concrete implementation of the abstract factory then using generic interface of the factory to create the concrete
objects which is part of the theme. The client doesn‟t know which concrete objects gets from all of these
internal factories, since it uses only the generic interfaces of their products. Abstract products describe interface
for every different products of a single product family. Concrete products implement the abstract product
interface which is returned by creational methods of concrete factories. Abstract factory defines the interface
for creating products which is common to all concrete factories. Concrete factories implement creational
methods of the abstract factory and each concrete factory should correspond to a specific products variant as
shown in Figure.
Figure: Design Pattern - Abstract Factory
Purpose of abstract factory design pattern is to provide an interface for creating families of related objects
without specifying concrete classes. The following Figure () shows the example of abstract factory design
pattern for user login where two concrete factory and concrete product used for execution.
45
Figure: Abstract Factory Design Pattern for User Login
Using proposed method design pattern asses where requirement is well documented and fixed which is used as
input. As step 1 firstly identify the design problem using alternative design solutions from literature and
experience, and solve using abstract factory design pattern. In step 2 maintainability, reusability,
understandability, flexibility, composability, completeness, stability, simplicity, and expandability are selected
as design objective. Using step 3 appropriate solution is selected as step 4 (tool) and step 5 (mathematical
formation). In step 4 maintainability, reusability, understandability, and flexibility are calculated using
parecons design pattern advisor tool. In step 5 composability, completeness, stability, simplicity, and
expandability are measured using mathematical formation. In step 6, combine step 4 and 5 output to get required
quality product. Assessment of these nine quality attributes are discussed as:
Maintainability: Use of a design pattern essentially complicates design to usually add abstract classes and
additional associations to employ a design pattern. The key advantage of using design pattern is that the
resulting software should be easier to adapt, to modify fewer classes, to add functionality to software. So,
maintenance Client Abstract Factory +doAction1: void +doAction2: void Abstract Product +do Action: void
Abstract Factory concreteProduct1 concreteProduct2 concreteFactory1 concreteProduct1: Admin
concreteProduct2: User concreteProduct1 +do Action: void concreteFactory2 concreteProduct1: Admin
concreteProduct2: User concreteProduct2 +do Action: void 95 programmers should have to use less effort to
adapt these changes. Every introduced pattern caused an improvement in different quality attributes.
Reusability: Design patterns are reusable micro architectures that add to overall software architecture. Design
patterns detain static and dynamic structure and collaborations of components in successful solutions to
problems that occur when developing software like business data processing, databases, graphical user
interfaces, telecommunications, and distributed communication software. Patterns 96 help development of
reusable components and frameworks by using structure and collaboration of participants in software
architecture at a level higher than source code and object-oriented design models that focus on individual
objects and classes. Thus, patterns facilitate reuse of software architecture, even when additional forms of reuse
are infeasible. An empirical investigation on reusability of design patterns and software packages, attempts to
empirically investigate reusability of design patterns, classes, and software packages to identify the most
beneficial starting points for white box reuse, which is pretty popular among OSS
46
CONCLUSION:
The Online Exam Registration system is developed with all the implementation techniques.
And the system is implemented using java program. The methods of the classes are defined and the
objectives of the software are full filled. Then the system is tested for proper execution and then the
testing is done to avoid the bugs in the software. The reusability of the software is checked and
maintenance techniques are applied to avoid future bugs over the software.
47
STOCK
MAINTENANCE
SYSTEM
1
Ex.no:1 PROBLEM STATEMENT
Date:
AIM
To develop the problem statement for stock maintenance system.
PROBLEM STATEMENT
Stock Maintenance System is meant for maintaining the stocks by the Inventory manager.
To manage the entire stock management process of a company. It ensures portability and
compatibility. Here the role manager’s role is to control the login of the software with the valid
user name and password, also checks the stock purchase order, and to remove the expires stocks,
then he prepares the daily report and monthly report consists of information about the stocks and
estimation.
3
Table of Contents
Table of Contents...........................................................................................................................3
Revision History.............................................................................................................................4
1. Introduction..............................................................................................................................5
1.1 Purpose..............................................................................................................................................5
1.2 Document Conventions.....................................................................................................................5
1.3 Intended Audience and Reading Suggestions...................................................................................5
1.4 Product Scope................................................................................................................................... 5
1.5 References.........................................................................................................................................5
2. Overall Description..................................................................................................................6
2.1 Product Perspective...........................................................................................................................6
2.2 Product Functions............................................................................................................................. 6
2.3 User Classes and Characteristics.......................................................................................................6
2.4 Operating Environment.....................................................................................................................6
2.5 Design and Implementation Constraints...........................................................................................7
2.6 User Documentation......................................................................................................................... 7
2.7 Assumptions and Dependencies........................................................................................................7
3. External Interface Requirements...........................................................................................7

3.1 User Interfaces.................................................................................................................................. 8
3.2 Hardware Interfaces..........................................................................................................................8
3.3 Software Interfaces........................................................................................................................... 8
3.4 Communications Interfaces...............................................................................................................9
4. System Features....................................................................................................................... 9
4.1 Description and priority....................................................................................................................9
4.2 Stimulus / Response Sequences …………………………………………………………………..10

..……………………………………………………………………..10
5. Other Nonfunctional Requirements.....................................................................................11

5.1 Performance Requirements.............................................................................................................11
5.2 Safety Requirements.......................................................................................................................11
5.3 Security Requirements....................................................................................................................11
5.4 Software Quality Attributes............................................................................................................12
5.5 Business Rules................................................................................................................................ 13
4
6. Other Requirements..............................................................................................................
13
Revision History
8
1. Introduction
Stock Maintenance System is an interface between the Consumer and the Inventory
Manager who is responsible for maintaining the stocks. This system mainly aims at the
portability and compatibility of the stocks.
1.1Purpose
The Software Requirement Specification document contains the entire software
requirements for Stock Maintenance System and provides the full details about the stocks. The
complete process of Stock maintenance is done in a manual manner till ancient era. Considering
the fact that the number of customers for purchase is increasing every year, a maintenance
system is essential to meet the demand for efficient usage. So this system uses recent trends
with programming and database techniques to improve the work involved. This process
elucidate the efficient maintenance of stocks.
The format used in this SRS are specified as the font style used in this complete
document is Times New Roman, The font size of content is 12. The title’s font size is 14.

The different types of reader that the Stock maintenance system is intended for such as
Inventory manager, Customer, Administrator, Business Entrepreneurs, Developer, Tester,
Analyst. For more details about the Stock maintenance system the upcoming headings such as
Product scope and References.
1.4 Product Scope

• Provide a communication platform between the Consumer and the Inventory manager.
• The System provides an interface to the Consumer to meet their needs.
• The Inventory manager is concerned with the login of the system.
1.5 Reference
The References of this SRS are
1.IEEE Recommended practice for software requirements specification-IEEE std 830-

199.
2.”Software Engineering”-By K.K.Agarwal and Yogesh Singh, New age
publishing house 2nd Edition.
9
2.1Product Perspective
The proposed stock maintenance system is an advanced software system that reduces
the manual power for the efficient management of stocks. This System will provide available
stock products for consumer needs . This system also provides consumer feedback service
which can be updated in the system by the inventory manager.
2.2 Product Function

The main function of this product are :
• Provides friendly relationship between the shop owner and the consumer.
• Facilitates both the direct consumption and online purchasing.
• Easy analysis of the stocks, with complete statistical data.
• Obtain the current stock rates.
• Expiry of stocks can be identified by the updation of the database.

There are various kinds of user in this module such as :
• Inventory Manager:
Manages the entire stock management process of the company such as updation,
verification, maintenance of database.
• Administrator :
The work of administrator is to ensure dealership with various dealers and
elucidate entrepreneurship.
• Naive Users:
Customers who require product to consume for
various types of consumption(daily, monthly, yearly).

Requirements Particulars
➢ Operating Windows
system Environment
Pentium 4 and
➢ Processor
above
100GB to
➢ Hard disk 150GB
10
➢ RAM 1GB
➢ Web Browser Google Chrome or or Mozilla
Internet
Explorer
Firefox
Software Stock master 1.0,
➢ Required MYSQL Oracle 9i
This application takes care of all supply orders reducing cost for warehousing,
transportation while improving customer service. It significantly improves inventory turns,
optimizes flow of goods. It also improves cash flow, visibility and decision making. It provides
efficient execution of tasks using this fast and reliable computerized method. This project was
constrained by the following factors:
▪ Financial Constraint: Considering the economic state of the nation, it was

found difficult in making both ends meet, because of the nature of things
nowadays in travelling for the collection of data needed for the project.
▪ Time Constraints: The time given seemed to be short for the collection of
required information for better work to be done for the updation of stocks.
▪ Unavailability of Material: During this project, it was noticed that the required
materials needed for the project are not documented. Those that were
documented lacked storage facilities where they can be reached.

The product will include the user manual. This will include product overview,
complete configuration of the software’s to be used and hence the description of the overall
product. The application will allow users to access the offline and online help manual. This
manual will be updated with each new service pack.

Each user must be provided with id and password on his/her first appearance.
Administrator is responsible for all activities happening. The Inventory manager should hold
the authority of permitting any activities regarding stocks. Database system must be connected
across the network for any time and any where access. Customers alone are responsible for the
safety of their product.
11
3.External Interface Requirements

The system uses the GUI – Graphical User Interface for easy interaction with the
customer. The system maintains a relationship with the Rational Rose Tool. According to the
code generated by the Rose tool, the system is developed. This gives more sequential access
for the functions and the functions can be coded easily.
3.1 User Interfaces
The User Interfaces for the software shall be compatible to any browser such as Internet
Explorer, Mozilla or Netscape Navigator by which user can access to the system.
The User Interfaces shall be implemented using any tool or software package like Java
Applet, MS Front Page, EJB etc.
The User Interface should be very attractive featuring importance of our system. The
introductory screen consists of a Welcome note and product advertisement. The next screen is
the user login screen.
The next interface displays the product details under different categories and the
subsequent screens contain the details of each and every product and finally provided with
provision for getting card number for settling the cash by the customers. The final screen
displays salutations to the customer by displaying Thank You. At the same time the stock details
are updated.

Since the application must run over the internet, all the hardware shall require to
connect internet will be hardware interface for the system. As for eg. Modem, WAN-LAN,
Ethernet cross-cable.
▪ Needed: Computers
▪ Hard Disk: 100-150 GB
▪ RAM: 512-1 GB required
▪ Internet Connection required.

▪ Cables, wires, Network adapters are required.
• FRONT-END DESIGN:
o visual studio 12.0
• BACK-END DATABASE:
o Microsoft SQL server
12
• SYSTEM SOFTWARE REQUIRED: o Windows XP or Windows 7

with 32 bit (recommended).
• APPLICATION SOFTWARE REQUIRED: o Stock Master v 1.0,
Oracle 9i, MY SQL, Tally 5.0.
Source of input:
The input is given by the user who wishes to use the Stock Maintenance system. The
user feels it easy to give the inputs, as the system is more user-interactive. They find the option
to perform their work more easily rather than waiting for a long time to get the transactions to
be completed manually.
Destination of output:
The input given by the user is updated into the database where the account details
corresponding to the user are stored. With the help of the database the account details of the
customer can be administered and monthly statements can be generated.
Accuracy:
The Stock Maintenance system that is developed is more accurate and is efficient.
The details are maintained accurately and updated properly.
Information flows:
The data given by the user flows over stage by stage and reaches the database finally
for making insertion or updating for storing the details.

The system shall use the HTTP protocol for communication over the internet and for
the intranet communication will be through TCP/IP protocol suite.
The local system must be connected to the server via Internet Connection. Email and
file transfer services are provided. E-Shopping is the key concept. Communication is key to
creating the perfect inventory management system. As soon as a shipment arrives, raw materials
should be counted. Then, quantity information about those raw materials should be entered into
the computer.
Ideally, inventory management software should be used to keep track of all

information about inventory. In order to ensure proper inventory control, an employee or
employees should document when raw materials hit the production line and the status of all
inventory as it goes from the raw materials phase to the goods in progress phase to the finished
products phase.
13
4. System Features
4.1 Description and Priority
The stock maintenance system maintains the items name ,rate ,quantity , sales rate and
other sales details .This project is of high priority. Because it is very difficult to maintain the
details of all the item present .In the store .It is also difficult to maintain the details over a long
period of item.
Analysis:
The stock manager analyses the stocks .He identifies the old stocks and the expired
goods and also the list of the items needed.
Old stock clearance:

The stock manager clears the old stock goods by selling it at a offer price.
Order list preparation:
The stock manager prepares the list of the items to be bought. Then he calls the
company for the quotations.
Quotations:
The stock manager calls the company for the quotations. After receiving the quotations
from the company, the stock manager chooses the quotations.
Purchase:
The stock manager purchases the needed goods from the corresponding company in
which the quotations are selected.
Payment:
The stock manager pays the bills along with the tax and the goods are delivered by the
company manager.
4.2 Stimulus/Response Sequences

• Search for the item.
• Analysis the availability of stocks.
• Displays the item details and availability.
• Remove the sold out item and expired item.

Functional requirements are product features or functions that developers must
implement to enable users to accomplish their tasks. So, it’s important to make them clear both
for the development team and the stakeholders. Generally, functional requirements describe
system behavior under specific conditions.
Login:
Login is achieved by the stock manager. The login is used for security of the
management. It can be logged with the user name and the password.
14
Analysis of goods:
Analyse the requirements whether it provides proper operations/output and performs
the task. The System holds all the details of the all the employees who are working in the
organization.
• Finding the expired goods.

• Finding the older ones and selling with the offer prices.
Preparing the list:
List of goods or items which are needed are prepared by the stock manager. The stock
manager prepares the list of items to be bought. Then he calls the company for quotations.
Getting the quotations:

Stock manager gets the quotations from the company manager. Thus the stock manager
requests the quotations from the corresponding company manager.
Choosing the best one:

The stock manager calls the company for quotations. After receiving the quotations
from the company, the stock manager chooses the best quotations.
Purchasing the goods:

Stock manager purchase the needed goods from the company manager in which the
quotations are selected.
Deliver and payment:

Delivery of goods by the required company and the payment settled by the stock
manager. The stock manager pays the bills along with the tax and the goods are delivered by
the company manager.
Update:
It is performed by the stock manager in the database. Whenever an outward entry is
entered then accordingly the stock number will be automatically updated.
5. Other functional requirements

The number of users is not confined to any specific value. Any number of users can
use the system. But the only constraint is that only one user can use this system at a time. The
response time is greater for the system. It gives the output quickly so that the user will feel easy
to proceed with the next transaction. The amount of information to be handled is enormous.
The database stores a large amount of data and it also helps in quick insertion and retrieval of
15
data from it. So, the system furnishes all the required information at the request of the user to
view the details.

Avoid frequent usages of flash devices such as pen drive to prevent database collapse.
System must be installed with original version of Windows OS with perfect license to avoid
duplication problems. Take regular backup of data. Store the stocks in a closed place to avoid
loss of stocks by theft, misplacement etc.

There will be proper security mainly regarding data accessibility. Security to user can be
provided by login authentication. Data stored in database should be private that is it must be
known only to administrator who is authorized using a secured id. The whole system is
prevented from unauthorized access.

The additional quality characteristics are important both for the customers and the shop
administrators and also for the developers. Some of the attributes of our system are as follows:
Adaptability:
The software designed must be suitable for managing any kind of products. It should be
well received both in a provision store and in a medical dispensary.
Availability:
The system must be available at an affordable rate. Also must be provided with proper
license only for a period of days.
Correctness:
The system must be accurate and less error prone. During design phase itself, the system
must ensure that each and every module is accurate.
Flexibility:
The system must be flexible in the sense that it must able to handle different types of
users and different types of administrators. Also it should run in different environments.
Maintainability:
The system should have the capability of self-maintenance. For a good performance,
everything must be optimized time to time. This feature tests the maintenance and ability to
maintain the system by administrator.
Portability:
16
The system developed as a whole should be of very small size. So that it is easily portable
with the help of hand-held device.
Reliability:
The system should be reliable. That it should be consistent and should provide good
results over a period of time.
Reusability:
The system should have the provision of using it more number of times. If any problem
occurs to the whole system, it must be reinstalled and again it should be installed and put to
use.
Robustness:
The system should be incorruptible. It should be able to produce results for important
details though some of the features have failed.
5.5 Business Rules

The simple rules to be followed are:
• If customer wants an enquiry of products he should definitely have ID and password.
• Cell phones, cameras are not permitted inside the stores.
• No bribing must be involved.
• No unnecessary conflicts and nuisances are entertained
6. Other Requirements
Foreign exchanges and foreign credit cards are accepted through special and card
readers. The system requires collaboration with any banks for financial handlings.
Depending upon the type of user the access rights are decided .If the user is an
administrator he can be able to update ,delete data .All the other user except manager only have
the right to retrieve information about the database. There may be different categories of item
available according to the category of item. The relevant data should be displayed .The category
and data related to the category should be coded in a particular format.
Inventory Manager
An Inventory manager is the person who is here considered to be the person in charge.
He undertakes responsibility of maintaining, operating the store and keeps information of each
and every specifics. He is also responsible for taking decisions regarding issuing orders to
vendors , add new vendors and etc.
Order
17
Order is a generalized function used for replenishment of sold out items .The order
usually consists of an order form which is supplied by the manager to the vendors.
Consumer
The necessary items are provided by the consumer on a regular basis. The manager is
responsible for checking the current level of inventory with the threshold levels and if any
particular ingredient is found to be in the danger zone then an order is processed by the manager
to the consumer.
Update Database
Updating the resource gives a crystal clear idea to the manager regarding the usage of the
stocks from the quantity sold in a particular time period. This leads to the checking the
threshold.
18
EX.NO: 3 IDENTIFY USE CASES AND DEVELOP USE CASE MODEL
DATE:
USE CASE DIAGRAM:

A use case diagram at its simplest is a representation of a user's interaction with the
system that shows the relationship between the user and the different use cases in which the
user is involved. A use case diagram can identify the different types of users of a system and
the different use cases and will often be accompanied by other types of diagrams as well. The
use cases are represented by either circles or ellipses.

The purpose of use case diagram is to capture the dynamic aspect of a system. However,
this definition is too generic to describe the purpose, as other four diagrams (activity, sequence,

SYSTEM
Draw your system's boundaries using a rectangle that contains use cases. Place actors
outside the system's boundaries.
USE CASE
Draw use cases using ovals. Label the ovals with verbs that represent the system's
functions.
ACTORS
Actors are the users of a system. When one system is the actor of another system, label
the actor system with the actor stereotype.
RELATIONSHIPS
19
USECASE DIAGRAM:
USE CASE MODELLING

LOGIN
BRIEF FORMAT
20
The Inventory manager enters into the system’s software and looks into the control
panel, then he enters the login ID and password. If the password is valid then the Stock
maintenance system is opened and the Inventory manager can view or update or remove the
details of the products, purchase, sales etc.
CASUAL FORMAT
SUCCESS SCENARIO
The Inventory manager enters into the system’s software and looks into the control
panel, then he enters the login ID and password. If the password is valid then the Stock
maintenance system is opened and the inventory manager can view or update or remove the
details of the products, purchase, sales etc.
ALTERNATE SCENARIO
If the password entered by the Inventory manager is invalid, the system cannot be
opened and can’t perform any actions. So he must reenter the valid password. The system
allows to enter the valid password upto three attempts.
Use case name Login
Primary actor Inventory manager.
Secondary / Supporting actor Admin , Server.
Stake holders Inventory manager plays the important role in

the system. He login to the system and can
view or update or remove details about
products, sales, purchases etc.,
Main success scenario Enter to the system software. Look at the

control panel. Enter the login ID and
password. View or update or remove details
about products, sales, purchases etc.,
Exception Incorrect password. Forget password.

system.
Special requirements Security is Provide more

important.
authentication.
21
MAINTENANCE
BRIEF FORMAT
The Inventory manager can maintain the stocks by acquiring details about number of
products, where the products were pursued, due dates of the products and updation of the
products.
CASUAL FORMAT
SUCCESS SCENARIO
The Inventory manager can maintain the details of the stocks by acquiring details about
the number of products, server details, pursuing due dates such as manufacturing dates and the
expiry dates for proper maintenance of the system.
ALTERNATE SCENARIO
But at some situations, the stocks are mischecked, number of products could be lower
than the minimal number of products. Due dates are not properly checked before selling.
Use case name Maintenance
Goal The system is maintained to view or update or

remove the details about server, disposal of
product, expiry date etc.,
Level To verify and update or remove the details.
Secondary / Supporting actor Admin , Server

Precondition The details about the level of stocks and

expiry dates should be known.
Main success scenario The Inventory manager successfully

maintains the system by verifying, updating or
removing the details about the product,
server, disposal of products etc.,
Exception Any other intervention of hazardous virus

occurred, the whole system may be collapsed.
22
Extension Proper maintenance of the system during the

regular interval time.
Special requirements To know about the minimal

number of products.
STOCK DETAILS
BRIEF FORMAT
The Inventory manager maintains the old stocks and new stocks details to ordering to
pursue stocks.
CASUAL FORMAT
SUCCESS SCENARIO
The Inventory manager maintains the old stocks and new stocks details to ordering to
pursue stocks.
ALTERNATE SCENARIO
At some situation, the old stocks and new stocks will collapses the ordering level of
the system. The wrong checking of due dates collapses ordering level of stocks..
Use case name Stock details.
Goal Management of old stocks and new stocks.
Level By ordering the number of old stocks, its

details and number of current stocks should be
known.
Secondary / Supporting actor Admin, Server.

Precondition Number of old stocks, details, due dates and

number of new stocks, details, due dates
should be known.
23
Main success scenario By knowing the number of old stocks, the new
stocks are bought and old stocks should be
selled before expired.
Exception Collapse in old stocks and new stocks, will
lead to the collapse of ordering level of stocks.
Extension The updation of old stock details and new

stock details should be known.
Special requirements Old stocks sold before expiry and old stocks
are replaced by new stocks.
24
EX.NO:4 IDENTIFY CONCEPTUAL CLASSES AND DEVELOP THE

DOMAIN MODEL AND ALSO DERIVE A CLASS
DIAGRAM FROM THAT
DATE:
CLASSDIAGRAM:
Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software application.
imposed on the system. The class diagrams are widely used in the modelling of object oriented
oriented languages.

Members:
UML provides mechanisms to represent class members, such as attributes and
methods, and additional information about them.
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these
notations must be placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
Derived property is a property which value (or values) is produced or computed from
other information, for example, by using values of other properties.
25
Scope:
The UML specifies two types of scope for members: instance and classifier, and the latter
is represented by underlined names.
o Attribute values are equal for all instances o Method
invocation does not affect the classifier’s state Instance
members are scoped to a specific instance. o Attribute values
may vary between instances
o Method invocation may affect the instance’s state (i.e.
change instance’s attributes)
To indicate a classifier scope for a member, its name must be underlined. Otherwise,
instance scope is assumed by default.
Relationships
Class Notation:
UML class is represented by the following figure. The diagram is divided into four
parts.
26
responsibility.
Object Notation:
It is represented in the same way as the class. The only difference is the name which
is underlined as shown in the following figure.
27
Domainmodel
As the object is an actual implementation of a class, which is known as the instance

of a class. Hence, it has the same usage as the class.
Class diagram:
28
The class diagram consists of ten classes namely, Shop, Customer, Stock details,
Product details, Purchase details, Server details, Sales person, Inventory
manager, Administrator, maintenance. The associations between the classes are as
follows:
➢ Many Shops has many Customers.

➢ Many Sales persons works at one Shop.
➢ One shop contains one Maintenance system..
➢ One Inventory manager has one Maintenance system.
➢ One Administrator contains many Maintenance systems.
➢ One Maintenance system issues many Stock details.
➢ One Maintenance system issues many Server details.
➢ Many Stock details describes many Product’s details.
➢ Many Product details has many Purchase details.

BETWEEN OBJECTS AND REPRESENT THEM USING
29
DATE: UML SEQUENCE DIAGRAM

SEQUENCE DIAGRAM:
A sequence diagram simply depicts interaction between objects in a sequential order
i.e. the order in which these interactions take place. We can also use the terms event diagrams
or event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what
order the objects in a system function. These diagrams are widely used by businessmen and
software developers to document and understand requirements for new and existing systems.
1.Actors
An actor in a UML diagram represents a type of role where it interacts with the system
and its objects. It is important to note here that an actor is always outside the scope of the system
we aim to model using the UML diagram.
2.We use actors to depict various roles including human users and other external subjects. We
30
Figure – an actor interacting with a seat reservation system
3.Lifelines – A lifeline is a named element which depicts an individual participant in a sequence

elements are located at the top in a sequence diagram. The standard in UML for naming a
lifeline follows the following format – Instance Name : Class Name
Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head is
located on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
31
model an unnamed instance, we follow the same pattern except now the portion of lifeline’s
name is left blank.
A lifeline always portrays an object internal to the system whereas actors are used to
depict objects external to the system. The following is an example of a sequence diagram:
Figure – a sequence diagram
4.Messages – Communication between objects is depicted using messages. The messages

appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines and
messages form the core of a sequence diagram. Messages can be broadly classified into the
following categories :
Figure – a sequence diagram with different types of messages

32
1.Synchronous messages
A synchronous message waits for a reply before the interaction can move forward.
The sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e. it
receives a reply message. A large number of calls in object oriented programming are
synchronous. We use a solid arrow head to represent a synchronous message.
Figure – a sequence diagram using a synchronous message
2.Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver processing the previous message or not.
We use a lined arrow head to represent an asynchronous message.
3.Create message
We use a Create message to instantiate a new object in the sequence diagram. There
are situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.
For example – The creation of a new order on a e-commerce website would require a new
object of Order class to be created.
33
Figure – a situation where create message is used
Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory
or is destroyed within the system we use the Delete Message symbol. It destroys the occurrence
of the object in the system. It is represented by an arrow terminating with a x. For example :
In the scenario below when the order is received by the user, the object of order
class can be destroyed.
Figure – a scenario where delete message is used
Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
Figure – self message
For example – Consider a scenario where the device wants to access its webcam.
Such a scenario is represented using a self message.
34
Figure – a scenario where a self message is used
Reply Message
Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line. The
interaction moves forward only when a reply message is sent by the receiver.
Figure – reply message
Figure – a scenario where a reply message is used
Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point. For
example: Consider the scenario of a hardware failure.
35
Figure – found message
failure.
Figure – a scenario where found message is used
Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline. For
example: Consider a scenario where a warning is generated.
Figure – lost message
interracting with. Since the destination is not known before hand, we use the Lost Message
symbol.
Guards
To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role in
36
• Used to model and visualise the logic behind a sophisticated function, operation or
procedure.

• Visualise how messages and tasks move between objects or components in a system.
SEQUENCE DIAGRAM:
37
The Inventory manager logins to the system by entering a valid ID and password. Then he
Manages and Displays the details of the Stock maintenance, Product maintenance, Quality
maintenance, Bill maintenance and Customer maintenance through the request messages such
as Manage products, stocks, quality, bills, customer and the delivery messages such as Display
products, stocks, quality, bills, customer respectively. The other operations are Add or Modify
stocks, products, quality, bills, customer details, Save or Update stocks, products, quality, bills,
customer details, List or Delete products, quality, bills, customer details, View , quality, bills,
customer details.
EX.NO:6 USING THE IDENTIFIED SCENARIOS,FIND THE INTERACTION

38
DATE: BETWEEN OBJECTS AND REPRESENT THEM USING UML

A collaboration diagram, also known as a communication diagram, is an illustration of

the relationships and interactions among software objects in the Unified Modeling Language
(UML). These diagrams can be used to portray the dynamic behavior of a particular use case
and define the role of each object.
Collaboration diagrams are created by first identifying the structural elements required
to carry out the functionality of an interaction. A model is then built using the relationships
between those elements. Several vendors offer software for creating and editing collaboration
diagrams.
behaviour of individual objects as well as the overall operation of the system in real time. The
between.
39
EX.NO : 7 DRAW STATE CHART DIAGRAM AND ACTIVITY

DIAGRAM:
DATE:
ACTIVITY DIAGRAM:
40
Activity diagram describe activities which involve concurrency and synchronization,

which are a variation of state diagrams that focuses on the flow of actions and events. They can
be used for:

ACVITITY DIAGRAM:
41
This Activity diagram consists of three swimlanes namely, Inventory manager, Stock
maintenance system and the Administrator. The initial process is the Login done by the
Inventory manager. The parallel behaviour such as branch and merge operations are used for
the Login authentication. The structural behaviour such as fork and join operations are used for
Manage and Display of products, stocks, quality, bills, customer maintenance and to Perform
actions of Add, Modify, Delete, Save, View, List. The final process is the Log out done by the
Inventory manager.

42
behavior which specifies the sequence of states an entity (or object) visits during its lifetime in response
to events, together with its responses to those events.
Key concepts:
State
performs some activity, or waits for some external event. A state machine diagram is a
graph consisting of:
• State transitions connecting the states Example:

indicated with a solid circle. A transition from this state will show the first real state.
state machine represents an object that may terminate before the system terminates,
while a closed loop state machine diagram does not have a final state; if it is the case,
then the object lives until the entire system terminates.
STATECHART DIAGRAM:
43
EX.NO: 8 IMPLEMENT SYSTEM AS PER DETAILED DESIGN
DATE:
Class Name: Admin

public class admin {
44
public String adminid;
public String admpassword;

public Vector *; public
Vector *; public void
checkprocess()
{}
Classs Name: Customer

public class customer {
public String cname;
public String caddress;
public String purchase;
public Vector myshop;
public shop myshop;
void addcustomer()
{}
public void editcustomer()
{}
public void deletecustomer()
45
public
public
{}
String getName() {
return null; } public String
getPhone() { return null; }
public String getAddress() {
return null; } public void
payment()
{}
public void receive()
{}
Class Name:Maintainence
public class maintenance {
public String loginid; public
String loginpassword; public
integer stockid; public String
stockname; public integer
pid; public String pname;
public Vector 1; public
Vector mystockdetails; public
Vector *; public Vector 1;
Vector 1;
46
public
Vector 1; public
Vector *; public void
updatestock()
{}
public void retrieve()
{}
public void reorderstock()
{}
Class Name:Product details

public class productdetails {
public String pname; public
integer pid; public integer
price; public date mfd;
public date exp; public
Vector *; public Vector *;
public float getprice() {
return 0.0; }
public float setprice() {
return 0.0; } public void
addproducts() { }
void updateproducts()
{}
public void deleteproducts()

47
public
public
{}
} Class
Name:Purchasedetails
public class purchasedetails {
public integer stockid; public
String stockname; public
date dateofpurchase; public
date exp; public Vector *;
public void updatebill()
{}
public string collect_cust_info() {
return null; } public void
placestockorder()
{}
Class Name:Salesperson
public class salesperson {
public String name;
public String id;
String address;
Vector 1; public void
receive_packing_order()
48
public
{}
public void add_info()
{}
public void ordershipping()
{}
} Class
Name:Serverdetails
public class serverdetails {
public String serverid;
public String servername;
public String roleofserver;
public Vector 1; public
void delieverstock()
{}
public void shopdet()
{}
public void shippingstock()
{}
Class Name: Shop

public class shop {

49
public
public
Integer productid;
String productname;
public String shopname;
public String shopaddress;
public Vector mycustomer;
public customer mycustomer;
Vector *; public Vector 1;
public void orderstock()
{}
public void receivestock()
{}
public void billingpayment()
{}
} Class
Name:Stockdetails
import java.util.Vector; public
class stockdetails { public
integer stockid; public String
stockname; public integer
quantity; public integer
oldstockname; public integer
newstockname; public Vector

50
mymaintenance; public Vector
1; public Vector *;
void addstocks()
{}
public void editstock()
{}
public void deletestock()
{}
public void viewstock()
{}
Class Name: Inventory Manager

import java.util.Vector; import
java.lang.*; public class
inventorymanager { public
String invid; public String
invpassword; public String
stocks(String in) {
if(in.equals("hema")) return
"true"; else return "false";
EX.NO:9 TEST SOFTWARE SYSTEM FOR ALL SYSTEM AS PER

USE CASES
DATE:
51
public
Class Name: Inventory Manager
import java.util.Vector; import
java.lang.*; public class
inventorymanager { public
String invid; public String
invpassword; public String
stocks(String in) {
if(in.equals("hema")) return
"true"; else return "false";
}}
SCRIPT PROGRAM:
52
POSITIVE_OUTPUT
NEGATIVE_OUTPUT
EX.NO:10 IMPROVE REUSABILITY AND MAINTAINABILITY BY

DATE:
53
For illustration purpose abstract factory pattern is used to describe the proposed method.
Abstract factory pattern known as a creational pattern, provides a method to encapsulate a
group of individual factories that have a familiar theme without specifying their concrete
classes. In usual case, the client software create a concrete implementation of the abstract
factory then using generic interface of the factory to create the concrete objects which is part
of the theme. The client doesn‟t know which concrete objects gets from all of these internal
factories, since it uses only the generic interfaces of their products. Abstract products describe
interface for every different products of a single product family. Concrete products implement
the abstract product interface which is returned by creational methods of concrete factories.
Abstract factory defines the interface for creating products which is common to all concrete
factories. Concrete factories implement creational methods of the abstract factory and each
concrete factory should correspond to a specific products variant as shown in
Figure.
Figure : Design Pattern - Abstract Factory

Purpose of abstract factory design pattern is to provide an interface for creating families
of related objects without specifying concrete classes. The following Figure( ) shows the
example of abstract factory design pattern for user login where two concrete factory and
concrete product used for execution.
54
Figure : Abstract Factory Design Pattern for User Login
Using proposed method design pattern asses where requirement is well documented
and fixed which is used as input. As step 1 firstly identify the design problem using alternative
design solutions from literature and experience, and solve using abstract factory design pattern.
In step 2 maintainability, reusability, understandability, flexibility, composability,
completeness, stability, simplicity, and expandability are selected as design objective. Using
step 3 appropriate solution is selected as step 4 (tool) and step 5 (mathematical formation). In
step 4 maintainability, reusability, understandability, and flexibility are calculated using
percerons design pattern advisor tool. In step 5 composability, completeness, stability,
simplicity, and expandability are measured using mathematical formation. In step 6, combine
step 4 and 5 output to get required quality product. Assessment of these nine quality attributes
are discussed as:
MAINTAINABILITY:
Use of a design pattern essentially complicates design to usually add abstract classes
and additional associations to employ a design pattern. The key advantage of using design
pattern is that the resulting software should be easier to adapt, to modify fewer classes, to add
functionality to software. So, maintenance Client AbstractFactory +doAction1:void
+doAction2:void AbstractProduct +doAction:void AbstractFactory
concreteProduct1 concreteProduct2 concreteFactory1 concreteProduct1: Admin
concreteProduct2: User concreteProduct1 +doAction:void concreteFactory2
concreteProduct1: Admin concreteProduct2: User concreteProduct2 +doAction:void 95
programmers should have to use less effort to adapt these changes. Every introduced pattern
caused an improvement in different quality attributes.
REUSABILITY:
55
Design patterns are reusable micro architectures that add to overall software
architecture. Design patterns detain static and dynamic structure and collaborations of
components in successful solutions to problems that occur when developing software like
business data processing, databases, graphical user interfaces, telecommunications, and
distributed communication software. Patterns 96 help development of reusable components and
frameworks by using structure and collaboration of participants in software architecture at a
level higher than source code and object oriented designmodels that focus on individual objects
and classes. Thus, patterns facilitate reuse of software architecture, even when additional forms
of reuse are infeasible. An empirical investigation on reusability of design patterns and software
packages, attempts to empirically investigate reusability of design patterns, classes, and
software packages to identify the most beneficial starting points for white box reuse, which is
pretty popular among OSS.
56
CONCLUSION:
The Stock maintenance system can help to manage inventory well during business
operation. The system is designed to reduce the human labour and efficiently maintaining the
stock. It provides flexible and powerful reports regarding items, purchase, sales and ledger. It
also helps to overcome some business problems like overstock and transaction record.
ONLINE
COURSE
RESERVATION
SYSTEM
1

Date:
AIM:
To develop the problem statement for Credit Card Processing system.
PROBLEM STATEMENT:
Online Course Reservation System is meant for students who wish to apply for the course
through online in a college. At first the system will list the available courses in the college. Then
the student will check the available seats for the particular course in the college. If the interested
course is available then the student will login and directed to fill the application. The system will
check for the eligibility and if the student is eligible then they will directed for payment to
reserve the course. If the course is reserved, then an acknowledgement will be sent to the student
and also to the registrar of the college.
3
Table of Contents
Table of Contents .......................................................................................................................... 3
Revision History ............................................................................................................................ 3
1. Introduction ............................................................................................................................. 4
1.1 Purpose............................................................................................................................................. 4
1.2 Document Conventions.................................................................................................................... 4
1.3 Intended Audience and Reading Suggestions .................................................................................. 4
1.4 Product Scope .................................................................................................................................. 4
1.5 References ........................................................................................................................................ 4
2. Overall Description ................................................................................................................. 5
2.2 Product Functions ............................................................................................................................ 5
2.3 User Classes and Characteristics ..................................................................................................... 5
2.5 Design and Implementation Constraints .......................................................................................... 5
2.6 User Documentation ........................................................................................................................ 5
2.7 Assumptions and Dependencies....................................................................................................... 6
3. External Interface Requirements .......................................................................................... 6
3.1 User Interfaces ................................................................................................................................. 6
3.2 Hardware Interfaces ......................................................................................................................... 6
3.3 Software Interfaces .......................................................................................................................... 6
3.4 Communications Interfaces ............................................................................................................. 6
4. System Features ...................................................................................................................... 7
4.1 System Feature 1 .............................................................................................................................. 7
4.2 System Feature 2 (and so on) ........................................................................................................... 8
5. Other Nonfunctional Requirements ...................................................................................... 9
5.1 Performance Requirements .............................................................................................................. 9
5.2 Safety and security Requirements ................................................................................................... 9
Revision History

4
1. Introduction
1.1 Purpose
This SRS is developed for the entire system. Course Reservation by means of Direct
communication would consume time and takes more man power. In order to resolve this one, an
Automated Online Course Reservation System provides a smart way to reserve the course
through online which helps the Student to apply in an efficient and convenient way.

In general, this document follows IEEE formatting requirements. This document contains Times
template font size 14 for Sub headings, Size 18 for Headings and Arial template font size 11 for
Descriptions throughout the document. Heading are followed by subheadings which is followed
by paragraphs.

Sub Heading Times New Roman 14 Bold

This document can be used by,
 Developers
 Testers
 Users
1.4 Product Scope

 The objective of the Software is to provide an easy way for students to reserve a course
through online.
 The main goal of this system is the time efficiency.
1.5 References
 IEEE Software Requirement Specification Template
 https://krazytech.com/projects/sample-software-requirements-specificationsrs
5
The Online Course Reservation System will be useful for students so that they can reserve their
interested course in a college. This Online Course reservation system is a interface between
‘Students’ and the ‘College’. This system is developed to save energy and time of the student.
In the System, Students must register to reserve their interested course in a college. Then
Students must enter the details in the application form and the system checks for the eligibility of
student. If the student is eligible, he/she will be allowed to pay for the course through E-Pay after
payment both the student and registrar will be notified.

 The System secures the information about the student’s reservation
 The Students will receive SMS and Mail updates
 The Registrar will get the report about the registration made by each students

Students - They are the person who desires to obtain the course and submit the information tothe
database.
Administrator – He has privilege to allocate the seats for the course and check the eligibility of
the student. He can approve or reject student’s application.

This System Support following Operating Systems
 Windows10
 Windows 8
 Windows 7
 Windows XP.

 The information of all users must be stored in a database that is accessible by the
administrators.
 My SQL Server will be used to maintain a database.
 Users may access from any computer that has internet browsing capabilities.
 The system will work 24*7

 The System provides User manual that defines the functions and option available in the
system.
 The User manual will be available in a document format.
6

 The student may be required to upload the certificates.
 The student and admin should have a internet connection to avoid disruption.

3.1 User Interfaces
 The interface should be user friendly for the user. It can be implemented by using java
script.
 The user interface is easy to implement.

The System requires the Intel processor and minimum of 2 GB RAM for the client. And also
have the dedicated links between theserver and clients.

The client machines require Microsoft Windows XP or better. The server requires Oracle
Database to hold all information, both the client and server computer must have internet browser
to work online.

The System will perform the following functions:
• Sophisticated and -friendly interface for all system.
• Individual account or profile for all related to the system.
• Sophisticated interfaces for all people who related to the system.
• Implement student, course and instructor database systems.
• Implement Account System for managing invoices.
• Keep secret for all of student profiles. Each division can see only necessary data of each
student for analyzing
• Internet connection to work on with the system.

7
4. System Feature
4. 1 System Feature
Description and Priority
Reserve Seat:
• Sign In: The first needs to sign in to the system with the name and password he/she have
provided with. The system needs to check for validation of that name and password and then
only allow he/she to access the system.
• Check Availability: They must be allowed to see all available options for courses. And see if
the seat is available or not.
• Reserve Position: Then if the position is available then it must be booked by the only and
should not be granted to any other again till it gets free.
Maintain History:
• The watch history for the course registered by the user must be maintained regularly when
he/she signs out from the account.
Report Generation:
• Course Information: The System shall generate reports on course about the following
Information: Course ID, Course Name

• The System will generate reports on seats availability about thefollowing
information: Course ID, Seat Number, Reserved or Unreserved.
8
Database:
• Mandatory Information: First Name, Last Name, Phone Number, ID, Address, Postal
Code, City, Country, name and Password.
• Course Related Information: Course ID, No. of Seats.
• Course Type: Technical or Non-Technical, Instructor, Instructor Details.
• Update Information: The registrar will allow Administrator to update any of the
information.
The course registration system has the following requirements:
1. Login
2. View course details
3. Reserve for course
4. Pay fee
5. Check Status
ACTORS INVOLVED
1. Student
2. Registrar
REQ-1: LOGIN
The User enters the name and password and chooses whether 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.
REQ-2: 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 ofthe courses he may choose.
REQ-3: 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.
9
REQ-4: 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.
REQ-5: CHECK STATUS

The student tries to check the status in which category applied. The system displays the
status information to the student.
5.1 Performance Requirement
• Capacity: The System must support 1000 people at a time.
• Interface: The interface screen shall respond within 5 seconds.
• Conformity: The systems must confirm to the Microsoft Accessibility guidelines.
• Network Connection: It should be connected to internet 24 X 7. And the

Server must be on all time.
5.2 Safety and Security Requirements
• Identification: The system requires to identify himself or herself using E-mail.
• Login ID: Any who uses the system shall have a Login ID and Password.
• Modification: Any modification (Insert, Delete, Update) for the Database shall be
synchronized and done only by the administrator.
• Administrator’s Rights: Administrator shall be able to view and modify all information in
System.
• Back Up: The system shall provide the capability to back-up the Data
• Errors: The system shall keep a log of all the errors.
• Reliability: The system keeps the data securely students who enrolled the courses
• Availability: The system shall be available all the time

10
Ex.No:3
Identify Use Cases and develop use case model
Date:
USE CASE DIAGRAM:

A use case diagram can identify the different types of users of a system and the different use
cases and will often be accompanied by other types of diagrams as well. The use cases are
represented by either circles or ellipses.
System:
11
UseCase:
Actors:
Relationships:
12
USE CASE DIAGRAM:

13
USE CASE MODELLING

LOGIN
BRIEF FORMAT
The Student enters into the system’s software and looks into the control panel, then he
enters the login ID and password. If the password is valid then the system will display the next
step or if the password is wrong then it shows a message.
CASUAL FORMAT SUCCESS SCENARIO

The Student enters into the system’s software and looks into the control panel, then he enters the
login ID and password. . If the password is valid then the system will display the next step.
ALTERNATE SCENARIO
If the password entered by the Student is invalid, the system cannot be opened and can’t
perform any actions. So he must reenter the valid password. The system allows to enter the valid
password upto three attempts.
Use case name Login

Primary actor Student.
Secondary / Suporting actor Admin
Stake holders Student plays the important role in the
system. He login to the system and and then
fill the application.

Main success scenario Enter to the system software.
Look at the control panel.
Enter the login ID and password
Exception Incorrect password.

Forget password.
system.
14
CHECK STATUS BRIEF FORMAT
The Student can enter the system and select the course to check the status of seat availability for
the course. If the seat is available for that course then the student will select the course else the
student will select the other available course.
CASUAL FORMAT SUCCESS SCENARIO
The student can enter the system and select the course to check the status of seat availability for
the course. If the seat is available for that course then the student will select the course.
ALTERNATE SCENARIO
But at some situations, if the seat is not available then the student will select the other available
course.
Use case name Check Status

Goal To select the course from the list of course.
Level To check the status of the course.

Primary actor Student.
Secondary / Supporting actor Admin , Registrar.
Stake holders Student plays the important role in the
system.
Precondition The Student should eligible for that course
Main success scenario The student can enter the system and select the
course to check the status of seat availability for
the course. If the seat is available for that course
then the student will select the course.
Exception Any other intervention of hazardous virus
occurred, the whole system may be
collapsed.
Extension Proper maintenance of the system during the
regular interval time.
Special requirements Security Maintainence.
15
Identify Conceptual classes and develop the

Ex.No:4 domain model and also derive a class diagram
from that
Date:
Domain model:


1. Reuse or modify existing conceptual models.
Category list:
1.Business transaction: Reservation.

2.Transaction item: Reservation line items.
3.Product or service Course.
4. Where the transaction recorded: Database
5. Role of people or organization related to Student, registrar, College
transaction:
6.Place of transaction: Browsing center, College
7.Noteworthy events: Reserve course, fee pay.
8.Physics objects: System(pc or laptop).
9.Description of things: Course description.
10.Catalogue Course catalogue
16

• First, the respected student can view the course details.
• If the student wants to enrolled the course then the student should login with their username
and password.
• Next for the selected course the student should reserve .
• For the reservation process we should give the appropriate details of the students.
• Then the system validate the user details.
• After the validation step, the student should pay the fees for the reserved course.
• After the end of payment the acknowledgement sent via the email of the student and so only
the student can easily check their details.
NOUNS:
Course Student Registrar
Details Username Password
Acknowledgement E-mail Fees
Domain Model:
17
CLASS DIAGRAM:
not only used for visualizing, describing, and documenting different aspects of a system but also
for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed
on the system. The class diagrams are widely used in the modeling of objectoriented systems
because they are the only UML diagrams, which can be mapped directly with object-oriented
languages.


 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
Members:
Visibility:
+ Public
- Private
# Protected
~ Package
Derived property:
18
Scope:
 Classifier members are commonly recognized as “static” in many programming languages.

The scope is the class itself.
 Attribute values are equal for all instances
 Method invocation does not affect the classifer’s state
 Instance members are scoped to a specific instance.
 Attribute values may vary between instances
 Method invocation may affect the instance’s state (i.e. change instance’s attributes)
 To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance
scope is assumed by default.
Relationships:
Class Notation:
 The top section is used to name the class.

 The second one is used to show the attributes of the class.
 The third section is used to describe the operations performed by the class.
19
 The fourth section is optional to show any additional

components
responsibility.
Object Notation:
20
Classes:
1. Course details:
• Course name: String
• Course type: String
• Course duration: Integer
2. User:
• User name: String
• Password: String
3. Reservation:
• Name: String
• Age: Integer
• DOB: String
• Marks: Integer
• Parent details: String
4. Payment:
• Amount: Integer
• Mode of payment: String
5. Net Banking:
• User Id: String
• Password: String
6. Card Payment:
• Card Number: Long
• CVV Number: Integer
• Expiry Date: String
7. Status:
• Name: String
• Paid Amount: Integer
21
CLASS DIAGRAM:
22

Date: sequence diagram
SEQUENCE DIAGRAM:
in which these interactions take place. We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order the
objects in a system function. These diagrams are widely used by businessmen and software
1. Actors: An actor in a UML diagram represents a type of role where it interacts with the system
weaim to model using the UML diagram.
actors in a sequence diagram. For example: Here the user in seat reservation system is shown
as an actor where it exists outside the system and is not a part of the system.
23

3. Lifelines: A lifeline is a named element which depicts an individual participant in a sequence
elements are located at the top in a sequence diagram. The standard in in UML for naming a
24
We display a lifeline in a rectangle called head with its name and type. The head is located on top
of a vertical dashed line (referred to as the stem) as shown above. If we want to model an
unnamed instance, we follow the same pattern except now the portion of lifeline’s name is left
blank.
Difference between a lifeline and an actor: A lifeline always portrays an object internal to the
system whereas actors are used to depict objects external to the system. The following is an
example of a sequence diagram:

appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines
and messages form the core of a sequence diagram.
25
1. Synchronous messages: A synchronous message waits for a reply before the interaction
can move forward. The sender waits until the receiver has completed the processing of the
message. The caller continues only when it knows that the receiver has processed the
previous message i.e. it receives a reply message. A large number of calls in object oriented
programming are synchronous. We use a solid arrow head to represent a synchronous
message.
2. Asynchronous Messages: An asynchronous message does not wait for a reply from the
receiver. The interaction moves forward irrespective of the receiver processing the previous
message or not. We use a lined arrow head to represent an asynchronous message.
26
3. Create message: We use a Create message to instantiate a new object in the sequence
diagram. There are situations when a particular message call requires the creation of an
object. It is represented with a dotted arrow and create word labeled on it to specify that it is
the create Message symbol.
 Delete Message: We use a Delete Message to delete an object. When an object is de

allocated memory or is destroyed within the system we use the Delete Message symbol. It
destroys the occurrence of the object in the system. It is represented by an arrow terminating
x. For example – In the scenario below when the order is received by the user, the object of
27
 Self Message: Certain scenarios might arise where the object needs to send a message to
itself. Such messages are called Self Messages and are represented with a U shaped arrow.
28
 Reply Message: Reply messages are used to show the message being sent from the receiver
to the sender. We represent a return/reply message using an open arrowhead with a dotted
line. The interaction moves forward only when a reply message is sent by the receiver.
For example – Consider the scenario where the device requests a photo from the user. Here
the message which shows the photo being sent is a reply message.
29
 Found Message: A Found message is used to represent a scenario where an unknown

an end point. For example: Consider the scenario of a hardware failure.
30
failure.
 Lost Message: A Lost message is used to represent a scenario where the recipient is not
known to the system. It is represented using an arrow directed towards an end point from a
lifeline. For example: Consider a scenario where a warning is generated.
symbol.
Guards: To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role in letting
software developers know the constraints attached to a system or a particular process.
31
 Used to model and visualize the logic behind a sophisticated function, operation or procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
 Visualize how messages and tasks move between objects or components in a system.
32
SEQUENCE DIAGRAM:
Flow of messages:
 The student login to the system by entering a valid ID and password.

 Then student select a course from the list of available courses.
 Next student has to enter the details of them such as name, dob, age marks.
 After entering the details, system will validate the details.
 Once the validation is complete the student done the payment.
 After completing the payment an acknowledgement will be sent to the student via email.
 The student can check their status of the course reserved using the status option.
33
Ex.No:6
Using the identified scenarios, find the interaction
Date: between objects and represent them using UML
collaboration diagram
These diagrams can be used to portray the dynamic behavior of a particular use cases and define
the role of each object.
out the functionality of an interaction. A model is then built using the relationships between those
behaviours of individual objects as well as the overall operation of the system in real time. The
1. Objects- Objects are shown as rectangles with naming labels inside. The naming label follows
the convention of object name: class name. If an object has a property or state that specifically
2. Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a name
and a role, with one actor initiating the entire use case.
34
messages are communications between objects that convey information about the activity and
can include the sequence number.
between.
35

diagram
Date:
ACTIVITY DIAGRAM:
 To model a human task (a business process, for instance).
 To describe a system function that is represented by a use case.
36
ACTIVITY DIAGRAM:
37
This Activity diagram consists of three swimlanes namely student,reservation

system,admin,accountant. The initial process is course selection by the student. The parallel
behaviours such as branch used for selection of the course and login. The reservation then next
processed by the filling the application by entering the details and get validate by the
system,then payment is done by the help of accountant, then the acknowledgement send to the
student for the reservation of a course.

A state machine Diagram (or start diagram, also called state chart of state transition diagram) is
a behaviour which specifies the sequence of states an entity (or object) visits during its lifetime
in response to events, together with its responses to those events.
Key concepts:
State
 States (simple states or composite states)
 State transitions connecting the states
38

 The initial state of a state machine diagram, known as an initial pseudo-state, is indicated
with a solid circle. A transition from this state will show the first real state
 The final state of a state machine diagram is shown as concentric circles. An open loop
closed loop state machine diagram does not have a final state; if it is the case, then the
object lives until the entire system terminates.

39
Date:
CLASS NAME: CARD PAYMENT.JAVA

public class CardPayment extends Payment {
public Long Cardnumber;
public Integer CVVnumber;
public String Expirydate
public void pay() {
CLASS NAME: COURSE DETAILS.JAVA

public class CourseDetails {
public String coursename;
public String Coursetype;
public Integer Courseduration;
public void viewCourse() {
CLASS NAME: NETBANKING.JAVA

public class NetBanking extends Payment {
40
public String Userid;
public String Password;
public void pay() {
CLASS NAME: PAYMENT.JAVA

public Integer Amount;
public String ModeofPayment;
public Vector generates;
public void payMethod() {
CLASS NAME: RESERVATION.JAVA

public class Reservation {
public String Name;
public Integer Age;
public String DOB;
public Integer Marks;
public String ParentDetails;
public String Coursename;
public void fillApplication() {

41
public void validate() {
CLASS NAME: STATUS.JAVA

public class Status {
public String Name;
public String CourseName;
public Integer Paidamount;
public void sendack() {
CLASS NAME: USER.JAVA

public class User {
public String Username=”hhh”;
public String Password=”abc”;
public CourseDetails enters;
public Reservation fill;
public void login(String uname,String pwd) {
if(uname==Username){
System.out.println(“LOGIN SUCCESSFUL”);
else{
System.out.println(“INVALID LOGIN” \n “ENTER THE CORRECT DETAILS”);

}
}}
42
Ex.No:9 Test the software system for all the scenarios

Date:
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network or object to
test its strength or to analyze overall response time under different load types. JMeter simulates a
group of users sending requests to a target server, and returns statistics that show the performance
and functionality of the target server via tables, graph, etc.
Apache JMeter is open source software, a 100% pure Java desktop application, designed to load
test functional behavior and measure performance of web sites. It was originally designed for load
testing web applications but has since expanded to other test functions.
 Web - HTTP, HTTPS sites web1.0, web 2.0 (ajax, flex and flex-ws-amf).
 Web services – SOAP / XML-RPC.
 Database services via JDBC drivers.
 Directory – LDAP.
 Messaging oriented services via JMS.
 Service – POP3, IMAP, SMTP.
 FTP services.
JMeter Features:
 Being an open source software, it is freely available.
 It has simple and intuitive GUI.
 JMeter can conduct load and performance test for many different server types.
 It has platform independent tool.
 JMeter stores its test plans in XML format.
 It is highly extensible.
Class name: Userlogin.java

import ocrs.User;
User u=new User();
u.login(“hhh”,” abc”);
43
44
45

Date:
Abstract factory pattern known as a creational pattern, provides a method to encapsulate a group
of individual factories that have a familiar theme without specifying their concrete classes. In
usual case, the client software create a concrete implementation of the abstract factory then using
generic interface of the factory to create the concrete objects which is part of the theme. The client
doesn’t know which concrete objects gets from all of these internal factories, since it uses only the
generic interfaces of their products. Abstract products describe interface for every different
products of a single product family. Concrete products implement the abstract product interface
which is returned by creational methods of concrete factories. Abstract factory defines the
interface for creating products which is common to all concrete factories. Concrete factories
implement creational methods of the abstract factory and each concrete factory should correspond
to a specific products variant as shown in Figure.

46
objects without specifying concrete classes. The following Figure shows the example of abstract
execution.
Using proposed method design pattern asses where requirement is well documented and fixed
which is used as input. As step 1 firstly identify the design problem using alternative design
simplicity, and expandability are selected as design objective. Using step 3 appropriate solution is
selected as step 4 (tool) and step 5 (mathematical formation). In step 4 maintainability, reusability,
understandability, and flexibility are calculated using percerons design pattern advisor tool. In
step 5 completeness, stability, simplicity, and expandability are measured using mathematical
formation. In step 6, combine step 4 and 5 output to get required quality product. Assessment of
these nine quality attributes are discussed as:
Maintainability: Use of a design pattern essentially complicates design to usually add abstract
classes and additional associations to employ a design pattern. The key advantage of using design
+doAction2:void AbstractProduct+doAction: void AbstractFactory concreteProduct1
concreteProduct2 concreteFactory1 concreteProduct1: Admin concreteProduct2: User
concreteProduct1 +doAction: void concreteFactory2 concreteProduct1: Admin concreteProduct2:
User concreteProduct2 +doAction: void 95 programmers should have to use less effort to adapt
these changes. Every introduced pattern caused an improvement in different quality attributes.
47
Reusability: Design patterns are reusable micro architectures that add to overall software
architecture. Design patterns detain static and dynamic structure and collaborations of components
in successful solutions to problems that occur when developing software like business data
processing, databases, graphical user interfaces, telecommunications, and distributed
communication software. Patterns 96 help development of reusable components and frameworks
by using structure and collaboration of participants in software architecture at a level higher than
source code and object oriented design models that focus on individual objects and classes. Thus,
OSS.
48
Conclusion:
To make the course reservation easy for students, the online course reservation system has been
developed which helps the students to reserve the course through online and also to do payment
through online. An acknowledgement will be sent to the student and also to the registrar of the
college after the reservation of the course.
RAILWAY
RESERVATION
SYSTEM
-1-
Exp no:1
Problem statement
Date:
Aim:
To develop a problem statement.
Problem statement:
Railway reservation system is an automated system. The system is used for booking tickets with
various options like AC, Non-AC, two-tier, sleeper etc. Ticket cancellation can be made with the
facility of refund. This system also includes checking the availability of train/seat with timings
and route. The payment should secure and all the modes of payment like net banking, debit card
etc should be accepted by the system. The price is based on the user’s preference and the cost
varies according to the class selected by the passenger. The status of the ticket will be intimated
to the passengers via messages and the changes made will be updated instantly in the server. The
overall system is user-friendly.
-3-
Table of Contents
Table of Contents ......................................................................................................................... vi

Revision History ........................................................................................................................... vi
1. Introduction ..............................................................................................................................7
1.1 Purpose ............................................................................................................................................. 7
1.4 Product Scope ................................................................................................................................... 7
1.5 References......................................................................................................................................... 7
3.1 User Interfaces .................................................................................................................................. 9
3.2 Hardware Interfaces........................................................................................................................ 10
3.3 Software Interfaces ......................................................................................................................... 10
3.4 Communications Interfaces ............................................................................................................ 10
4. System Features .....................................................................................................................10
4.1 System Feature 1 ............................................................................................................................ 10
5. Nonfunctional Requirements ................................................................................................11
5.1 Performance Requirements............................................................................................................. 11
5.2 Safety Requirements ....................................................................................................................... 11
5.3 Security Requirements.................................................................................................................... 11
5.4 Software Quality Attributes ............................................................................................................ 12
5.5 Business Rules ................................................................................................................................ 12
6. Other Requirements ..............................................................................................................12
Appendix B: Analysis Models .....................................................................................................13
Appendix C: To Be Determined List ..........................................................................................13
Revision History
-4-
1. Introduction
1.1 Purpose
The purpose of the Software Requirement Specification document is to provide a detailed overview of
the software products. The SRS document consists of all necessary requirements for project
development. It provides easy understanding for developers to build up the software.

This document follows IEEE formatting requirements.
Category Font Size
Title Times new roman 18
Subtitle Times new roman 16
Text Times new roman 12
The different types of readers are client, developers, users and testers. For better understand ability, read
from product scope followed by overview, functional and non functional requirements.
1.4 Product Scope

The railway reservation system should be easily accessible. The system facilitates easy online reservation
and immediate response to the user. Reservation and cancellation of tickets is intimated
through messages. The system provides security and privacy. The product is convenient and saves time
and effort. The product does all the calculations and seat reservation so, the chances of error are low.
1.5 References
• https://www.ieee.org/conferences/publishing/templates.html
• Object Oriented Software Construction (second edition) by Bertrand Meyer published in
1988.
-5-
• Software Requirements (second edition) by Karl.E.Wiegers.
The origin of the product being specified in this Software Requirement Specification is a new self-
contained product. The product is not a component of any system. The system is an open source and web
based model and provides an interface between passenger and administrator.
The major functions of the product are:

• For security reasons, each user is given an individual id and password. If the id and password are
correct, the user is allowed to enter into the system
• After logging in the user is able to view the train schedules in the system dashboard. Train status
includes filters like train name, train number, train availability and timings.
• The passenger is able to reserve seats by filling the details such as name, age, sex, boarding
station, destination, time, number of seats, date of journey etc. The passenger is also expected to
submit the id proof.
• After reservations, the passenger is guided to the payment portal where they can make the payment.
The system provides different payment modes like Net banking or by using credit or debit cards.
• The passenger can cancel the ticket at any cause. They will be refunded within few hours of
cancellation.
• Reservation/Cancellation is intimated to the passenger via messages and email.

The various user classes that will use the product are passengers, general audience and administrators.
Administrators must have technical knowledge about the system and must be able to manage the system.
Administrators have more responsibility than user as the system entirely depends on the administrator.
• Operating system is Windows 7 32-bit/x86 and 64-bit/x64 PC architectures.

• MS Access for database.
• Java for coding.
Design constraints can be imposed by other standards, hardware limitations, etc.

Hardware Limitations:
-6-
Identify the requirements for the software to operate inside varioushardware constraints.
Quality Characteristics:-
There are a number of quality characteristics that can apply to software. Pick the ones most important
to this product and develop a section for each one. Definitions of thequality characteristics follow:
• Correctness:
Extent to which program satisfies specifications, fulfills users mission objective.
• Efficiency:
Amount of computing resources and code required to perform function.
• Flexibility:
Effort needed to modify operational program.

The product has helpline page for guiding the user. It gives detailed explanations about the product and
helps to solve any queries. If the user is facing any difficulties in understanding the product they can refer
the helpline page.
The software is dependent on internet access as it is a remote application. The system needs user to have
some knowledge of railway reservation system and its working. The system provides booking facility
from 00hrs to 2200hrs.Enquiry facility is available for 24*7.

3.1 User Interfaces
The user interface like keyboard, mouse and menus of computer system help to communicate with the
operating system. For efficient use of user interface (front end) the system should be installed with internet
explorer with network access. The Product is GUI based with images and components, so the system
should have basic graphics facility. The member has to register using a form provided on the website...
The package provides drop down menus from which the user can select and links and icons to navigate
among the WebPages. The railway reservation system is expected to offer customers an easier way to
book tickets as well as smooth navigation .The system allows travellers to search for trains and check seat
availability by logging in to the interface. Customers can able to sort trains on multiple filters like class
and destination. The interface includes a waitlist prediction feature and Reservation against Cancellation
(RAC) tickets getting confirmed.
3.2 Hardware Interface
• Basic desktop or laptop with Intel corei3 processor.

• Atleast 256 MB RAM and atleast 1TB of free hard disk space.
-7-
Software interfaces (programming interfaces) are the languages, codes and messages that programs use to
communicate with each other and to the hardware. Examples are the Windows, Mac and Linux operating
systems, SMTP email, IP network protocols and the software drivers that activate the peripheral
devices.The Railway reservation system is developed in windows operating system with at least internet
explorer installed with a working LAN connection.
Communications functions required by the product include e-mail, web browser, electronic forms, and so
on. The communication between the different parts of the system is important since they depend on each
other. However, in what way the communication is achieved is not important for the system and is
therefore handled by the underlying operating systems for both the mobile application and the web portal
4. System Features
The railway network is a very vast system to be handled manually and its computerization will prove to
be of great help to both the employees and the passengers .Even from security point of view, authentication
will be done by password checking if correct password has been entered by the user, the user will get
further access to the system, otherwise user will have to re-enter the password.

• Description and Priority
The software is not able to reserve tickets more than 10 people per train. The fare allotted for reservation
is independent of Kilometers travelled instead it is set for every mode (AC, non AC or General) of each
train.The software is made such to carry out Reservation in max 15 trains.The software does not support
multiday reservation system, i.e., the Reservations cannot be one in advance rather it is carried out for
single day. The software does not provide concession in Fare rates for children, aged people, armament
etc. The software does not take into consideration the stations falling in between the source and destination
station.
• Stimulus/Response Sequences
The user login into the railway reservation system by entering the password. The user can check
the availability of trains and reserve tickets. They can cancel tickets in case of emergency. After
reservation, they pay the fare and eprint of the ticket is sent to the passenger via mail.
• Functional Requirements
Functional requirements refer to the function which were required before and covered in the system
or software developed.
➢ Train details:
Customers may view the train timing, date, their name and number of tickets
➢ Reservation:
-8-
After checking the number of seats available the customers reserve the tickets
➢ Payment:
After reserving the required number of tickets the customer makes the payment.
➢ Cancellation:
` If the customer wants to cancel the ticket then the half of the amount paid by
the customer will be refunded according to certain terms and conditions.
➢ User Satisfaction:
The system is such that it stands up to the user expectation
➢ Safety and Robustness:
The system is able to avoid or tackle disastrous actions. The system safeguards
against undesired events without human intervention.
➢ Response Time:
The response of all the operation is good. This has made possible by careful programming.

The system should be portable and possible to users of internet explorer as well as other browsers. The
response time should not be greater than 3-4 seconds. The database should be scalable. The system must
have capacity to hold large number of users. The number of connections to the system should not slow
down the system to a large degree. The response time for query from the client side to the database side
should not be more than 5 seconds. Error handling should be implemented and the application should be
able to handle all run time errors. The application should be flexible for future enhancements.
If there is a extensive damage to a wide portion of database due to catastrophic failure, such as a disk
crash, the recovery methods restores a past copy of the database that was backed up to archival storage
and reconstructs a more current state by reapplying or redoing the operation of committed transactions
from the backed up log up to the time of failure.
The system use SSL (secured socket layer) in all transactions that include any confidential customer
information. The system must automatically logout all customers after a period of inactivity. The system
should not leave any cookies on the customer’s containing the user’s password. The system is only
accessible to authenticated management.
• Maintainability: The software design is being done with modularity so that

maintainability can be done. In case of failure the software is reinitialized with good
quality.
-9-
• Reliability: The reliability of system depends upon reliability of individual component.

By working project under different working environment the product should be reliable
enough to sustain in any condition.
• Usability: The system should be user friendly and very easy to learn .Navigation must be
simple.
5.5 Business Rules
Tickets can be booked up to 120 days in advance, an Aadhaar-verified user can book 12 tickets every
month and passengers can now claim refunds if the train fails to depart within three hours of the scheduled
departure. Now, ticket booking has been made time sensitive. This means, 25 seconds has been allotted
to fill up passenger details. Further, the minimum input time for Captcha on passenger details page and
payment page is 5 seconds.
Certain requirements may, due to the nature of the software, the user
organization, etc., be placed in different
categories such as Database.This could specify the requirements for any data base that is to be
developed as part of the product. This might include:
• Types of information
• Frequency of use
• Accessing capabilities
• Data element and file descriptions
• Relationship of data elements, records and files
• Static and dynamic organization
• Retention requirements for data.
Operations could specify the normal and special operations required by the user such as:
The various modes of operations in the user organization for example are,
• User-initiated operations
• Periods of interactive operations and periods of unattended operations
• Data processing support functions
• Backup and recovery operations
• Basic building blocks
• rules
• common mechanisms
Appendix A:
Glossary:
SRS: A software requirements specification (SRS) is a comprehensive description of the intended
purpose and environment for software under development.
RAC: Ticket that has confirmed the status of wait list birth.
- 10 -
Appendix B:
Analysis Models:
The Unified Modelling Language (UML) is a graphical language for OOAD that gives a standard way
to write a software system’s blueprint. It helps to visualize, specify, construct, and document the
artefacts of an object-oriented system. It is used to depict the structures and the relationships in a
complex system.
System: A set of elements organized to achieve certain objectives form a system. Systems are often
divided into subsystems and described by a set of models.
Model: Model is a simplified, complete, and consistent abstraction of a system created for better
understanding of the system.
View: A view is a projection of a system’s model from a specific perspective. Conceptual Model of
UML the Conceptual Model of UML encompasses three major components:
Exp no:3
Identify the usecases and develop the use case model
Date:
Use case diagram:

- 11 -
A use case diagram at its simplest is a representation of a user's interaction with the system that shows the
relationship between the user and the different usecases in which the user is involved. A use case diagram
can identify the different types of users of a system and the different use cases and will often be
accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses.
Purpose of Use Case Diagrams
The purpose of use case diagram is to capture the dynamic aspect of a system. However, this definition is
too generic to describe the purpose, as other four diagrams (activity, sequence, collaboration, and
Statechart) also have the same purpose.
Basic Use Case Diagram Symbols and Notations
System
Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's
boundaries.
Usecase
Actors
Actors are the users of a system. When one system is the actor of another system, label the actor system
with the actor stereotype.
- 12 -
Relationships
Illustrate relationships between an actor and a use case with a simple line. For relationships among use
cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is
needed by another in order to perform a task. An "extends" relationship indicates alternative options under
a certain use case.
- 13 -
- 14 -
Usecase templates:
Usecase name: Book tickets
Brief:
The passenger has to enter the details asked for booking tickets in the given page.After filling the
correct details,the tickets will be booked.
Casual:
After entering the login page,passenger should select book ticket category.Passenger should fill in the
details asked in the webpage. If the details are accepted the tickets will be booked or else passenger will
see some error message. Tickets booked will be intimated via messages.
Alternate scenario:
The details must be given properly by the passengers and the system should be convenient for users.
Fully dressed:
Usecase name Book tickets.
Goal To reserve tickets.
Level Booking tickets.
Primary actor Passenger.
Stakeholders Passenger,bank,admin,server.
Preconditions System should be in proper condition (all the
information should be collected properly).
Success scenario 1. Fill the details.

2.Confirm the ticket status.
3.Book the tickets.
Failure or exception scenario 1.Details not accepted.

2.Tickets unavailable.
3.Error in the system.
Extension 1.All the changes must be updated instantly.

2.System should be properly maintained.
Secondary actor Admin.
Special requirements Authentication is required.
- 15 -
Usecase name: Payment

Brief:
The passenger can select his mode of payment and can make his payment and the exits the page. The
payment amount differs by classes the passenger chooses.
Casual:
After booking the tickets, passenger makes his payment. All modes of payment should be accepted by
the system without any inconvenience. Passenger makes his payment and the payment status is
intimated via messages to the passengers.
Alternate scenario:
All the evolving methods of making payment should be updated in the system so that passengers will
not find any inconvenience
Fullydressed:
Usecase name Making payment.
Goal Make a payment.
Level Processing payment.
Stakeholders Passenger, admin, bank, server.
Preconditions 1. All the modes of making payment should be
accepted by the system.
2. Transaction should be made properly.
Success scenario 1. Select the convenient mode of payment.

2. Process the payment in the selected mode.
Failure or exception scenario 1. In case of using card swipe mode, card not
accepted.
2. Payment unsuccessful.
Extensions System should be updated with all the evolving

methods or modes of payment.
Secondary actor Bank.

- 16 -
Usecase name: Cancellation

Brief:
On any circumstance passenger can cancel the ticket (either reserved or unreserved or RAC)and the
amount will be refunded under certain terms and conditions.
Casual:
Passenger can cancel the tickets and the amount will be refunded under some terms and conditions. The
amount will be credited to his account and it will be intimated via messages. If there is any query
passenger can make use of the help options in the system.
Alternate scenario:
The system should be updated with all the changes instantly so that the vacant tickets can be booked by
passengers who need tickets.
Fully dressed:
Usecase name Cancellation.
Goal Cancelling the tickets.
Level To cancel the tickets.
Stakeholders Passenger, admin, bank, server.
Preconditions Tickets must be booked for cancellation.
Success scenario 1.Select the cancel category.
2. After cancellation,the amount will be
refunded under some terms and conditions.
Failure or exception scenario 1.Amount not refunded.
2.Ticket not cancelled.
Extension Proper notification should be sent to the
passenger about the cancellation.
Secondary actor Admin.
Usecasename:login
Brief:
When the passenger makes login, he will be given the authority to access the system only if enters the
valid password.
- 17 -
Casual:
The passenger will be given the authority to access the system if and only if he enters the valid
password. If passenger enters wrong or invalid password the system shows error message and the
passenger cannot access the services provided by the system.
Alternate scenario:
The passenger should enter the valid password .The system should be in proper condition so that there
will not be any problem with the system.
Fullydressed:
Usecase name Login.
Goal Making login.
Level Accessing the system.

Stakeholders Passenger, admin, server, bank.
Preconditions Passenger should have use rid and password.
Success scenario 1. Passenger should enter the use rid.

2. Enter the password and login the system.
Failure or exception scenario 1. Password incorrect.

2. System failure.
Extension 1. The system should be in proper condition.

2. Valid username and password should be
entered.
Secondary actor Server.

- 18 -
Exp no: 4
Identify conceptual class and develop a domain model
Date: with UML class diagram
Domain model
Domain model is a visual representation of conceptual class or real situation objects in a domain. It is
also called as conceptual models, domain object models, analysis object models.
Steps to create a domain model
3. Add associations and attributes.
Finding conceptual classes

2. Use a category list
3. Identify noun phrases
Category list
Conceptual class category Examples
Business transaction Railway reservation
Transaction line item Reservation line item
Product or service related to a transaction or Ticket booking, cancellation

transaction line item
Where is the transaction recorded? Railway database
Roles of people or organization related to the Passenger, Bank, Admin

transaction; actors in the use case
Place of transaction; place of service Online
Noteworthy events, often with a time or service Book, cancel, update

place we need to remember
Physical objects Tickets,train,seat,system
- 19 -
Description of things Train description

Ticket description
Noun phrase identification
It identifies the nouns and noun phrases in textual description of a domain and considers them as
candidate conceptual classes or attributes
Steps to identify noun classes
1. Identify the nouns.
2. Remove the redundant classes.
3. Identify the candidate or proper noun
Main success scenario

The passenger enters the login page with user id and password. Login page has many filters like search
train, reservation, cancellation. The passenger can search trains by train number, source and destination.
The passenger can book tickets by filling the required details and all payment modes will be accepted.
The passenger can cancel ticket and the money will be refunded based on certain terms and conditions.
The passenger exits the system.
Step1:-Identify the noun
• Passenger
• User id
• Password
• Reservation
• Cancellation
• Passenger
• Train number
• Source
• Destination
• Passenger
• Details
• Payment
• Passenger
• Money
• Passenger
• System
• Train
Step2:-Remove the redundant classes

• Passenger
• User id
• Password
- 20 -
• Reservation
• Cancellation
• Train number
• Source
• Destination
• Details
• Payment
• Money
• System
• Train
Step3:-Identify candidate or proper noun
Passenger Reservation Cancellation Payment
Admin Train
Domain model diagram
Train Passenger Payment

Searches books Reservation generates
+train no +Name +Ticket no +amount
+train name +id proof +no of ticket +Mode
refers
Cancels Verifies
Updates
Cancellation Admin Bank
+name
+ticket no +name
+bank id
+refund +Id
Attributes
An attribute is a logical data value of an object. Attributes are sown in the second compartment of the
class box
• Train needs a string train name and integer train number attribute.
- 21 -
• Passenger needs a string name attribute.

Attributes used are
• Train number
• Train name
• Ticket number
• Number of ticket
• Amount
• Modes
• Refund
• Admin
UML class diagram for Railway reservation system

Class diagram:
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a system but also for constructing
executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on the
system. The class diagrams are widely used in the modeling of objectoriented systems because they are
the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is
also known as a structural diagram

• Forward and reverse engineering
- 22 -
Members:
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these notations must
be placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
Scope:

Relationships
- 23 -
Class Notation:

responsibility.
Object Notation:
As the object is an actual implementation of a class, which is known as the instance of a class.
Hence, it has the same usage as the class.
- 24 -
- 25 -
Exp no:5
between objects and represent them using
Date:
UML sequence diagram
Sequence diagram
Actors – An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the scope of
the system we used to model using UML diagram.
We use actors to depict various roles including human users and other external subjects. We
actorsin a sequence diagram.
- 26 -

1. Lifelines – A lifeline is a named element which depicts an individual participant in a
in UML for naming a lifeline follows the following format – Instance Name : Class
Name
- 27 -
Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head is located on
top of a vertical dashed line (referred to as the stem) as shown above. If we want to model an
blank.
Difference between a lifeline and an actor – A lifeline always portrays an object internal to
the system whereas actors are used to depict objects external to the system. The following is
an example of a sequence diagram:

2.Messages – Communication between objects is depicted using messages. The messages
- 28 -

1.Synchronous messages – A synchronous message waits for a reply before the interaction
can move forward. The sender waits until the receiver has completed the processing of the
message. The caller continues only when it knows that the receiver has processed the previous
message i.e. it receives a reply message. A large number of calls in object oriented
programming are synchronous. We use a solid arrow head to represent a synchronous message.

1.Asynchronous Messages – An asynchronous message does not wait for a reply from the
receiver. The interaction moves forward irrespective of the receiver processing the previous
message or not. We use a lined arrow head to represent an asynchronous message.
- 29 -
1.Create message – We use a Create message to instantiate a new object in the sequence
diagram. There are situations when a particular message call requires the creation of an
object. It is represented with a dotted arrow and create word labelled on it to specify that it is
the create Message symbol.

2.Delete Message – We use a Delete Message to delete an object. When an object is
deallocated memory or is destroyed within the system we use the Delete Message symbol. It
destroys the occurrence of the object in the system.It is represented by an arrow terminating
with a x.
For example – In the scenario below when the order is received by the user, the object of
- 30 -
Order can be destroyed

• Self Message – Certain scenarios might arise where the object needs to send a
message to itself. Such messages are called Self Messages and are represented with a
U shaped arrow.

- 31 -

• Reply Message – Reply messages are used to show the message being sent from the
receiver to the sender. We represent a return/reply message using an open arrowhead with
a dotted line. The interaction moves forward only when a reply message is sent by the
receiver.

- 32 -

• Found Message – A Found message is used to represent a scenario where an unknown

- 33 -
failure.

• Lost Message – A Lost message is used to represent a scenario where the recipient is not
known to the system. It is represented using an arrow directed towards an end point from
a lifeline. For example: Consider a scenario where a warning is generated.

interracting with. Since the destination is not known before hand, we use the Lost
Message symbol.
Guards – To model conditions we use guards in UML. They are used when we need to restrict
the flow of messages on the pretext of a condition being met. Guards play an important role in
- 34 -
procedure.
Flow of message in sequence diagram:

- 35 -
• Passenger login into the railway server and enters the name and password
• Server checks the name and password into the admin if it is valid then authentication is
successful otherwise, unsuccessful.
• Passenger searches the train into the server and then server displays the train details.
• Passenger book tickets into the server and the server checks the availability through
admin if available then notify to the passenger.
• Passenger pays for ticket into server through bank successfully, and then the tickets are
reserved.
• Passenger also cancel ticket into server by request through admin, request accepted by
admin and notify about cancellation and refund details.
• Passenger request for refund to server through bank, then the amount is refunded.
- 36 -
- 37 -
Exp no:6
Date: collaboration diagram
Collaboration diagram:

(UML). These diagrams can be used to portray the dynamic behavior of a particular use
case and define the role of each object.
behavior of individual objects as well as the overall operation of the system in real time. The
- 38 -
between.
- 39 -
- 40 -
Exp no:7
Draw relevant state chart and activity diagrams
Date:
Activity diagram:
for:
- 41 -
- 42 -
Activities:
• Login & verification
• Reservation
• Payment
• Cancellation
• Refund
State diagram:
diagram) is a behavior which specifies the sequence of states an entity (or object)
visits during its lifetime in response to events, together with its responses to those events.
Key concepts:
State

Example:
- 43 -

• The final state of a state machine diagram is shown as concentric circles. An open
loop state machine represents an object that may terminate before the system
terminates, while a closed loop state machine diagram does not have a final state; if
it is the case, then the object lives until the entire system terminates.
States:
• Login
• Search details
• Book ticket
• Pay for the ticket
• Cancel ticket
• Refund the amount
- 44 -
Exp no:8
Implement system as per detailed design
Date:
Class name: - Reservation.java
public class Reservation {
public Integer ticket_no;
public Integer no_of_tickets;
public String destination;
public String source;
public Vector 1;
public Vector verifies;
public Vector myPayment;
public void create_reservation() {
}
}
Classname:-Cancellation.java
public class cancellation {
public Integer ticket_no;
public Integer refund_amt;
public Vector cancel;
public Vector update;
public void cancel() {
}
}
- 45 -
Class name:-Train.java
public class Train {
public Integer timing;
public Integer train_no;
public String train_name;
public Integer train_timings;
public Vector *;
private void display_details() {
}
}
Class name:-Passenger
public class Passenger {
public String name;
public String gender;
public Integer age;
public Vector *;
public Vector *;
public Vector cancel;
public Vector notify;
public void fill_details() {
}
public void show_id_proof() {
}
}
Class name:-credit.java
public class credit extends Payment {
}
- 46 -
Class name:-Debit.java
public class debit extends Payment {
}
Class name:-netbanking.java
public class netbanking extends Payment {
}
Class name:-Admin.java
public class Admin {
public String admin_name;
public Integer admin_id;
public String update_status(String in){
if(in. equals("kar"))
return "true";
else
return "false";
}
}
- 47 -
Exp no: 9
Test the software system for all the
Date: scenarios identified as per the Usecase diagram
- 48 -
- 49 -
Exp no:10
Improve reusability and maintainability by

Date:
of the theme. The client doesn’t know which concrete objects gets from all of these internal
concrete factory should correspond to a specific products variant as shown in Figure.

Purpose of abstract factory design pattern is to provide an interface for creating
families of related objects without specifying concrete classes. The following Figure () shows
the example of abstract factory design pattern for user login where two concrete factory and
- 50 -

fixed which is used as input. As step 1 firstly identify the design problem using alternative
In step 2 maintainability, reusability, understand ability, flexibility, compos ability,
percerons design pattern advisor tool. In step 5 composability, completeness, stability,
are discussed as:
Maintainability:
additional associations to employ a design pattern. The key advantage of using design pattern
is that the resulting software should be easier to adapt, to modify fewer classes, to add
functionality to software. So, maintenance Client abstractfactory+doaction1:void
+doaction2:void abstractproduct+doaction:voidabstractfactory concreteproduct1
concreteproduct2 concretefactory1 concreteproduct1: Admin concreteproduct2: User
concreteproduct1 +doaction:voidconcretefactory2 concreteproduct1: Admin
concreteproduct2: User concreteproduct2 +doaction:void 95 programmers should have to use
less effort to adapt these changes. Every introduced pattern caused an improvement in different
quality attributes.
Reusability:
- 51 -
Design patterns are reusable micro architectures that add to overall software architecture.
Design patterns detain static and dynamic structure and collaborations of components in
successful solutions to problems that occur when developing software like business data
communication software. Patterns 96 help development of reusable components and
level higher than source code and object oriented design models that focus on individual objects
of reuse are infeasible. An empirical investigation on reusability of design patterns and
software packages, attempts to empirically investigate reusability of design patterns, classes,
and software packages to identify the most beneficial starting points for white box reuse, which
is pretty popular among OSS.
Conclusion:
To make ticketing more convenient for travellers the online reservation system
has been developed, which helps passengers in booking tickets from the comfort of our
homes or offices. The passengers use their account to book a railway ticket and also cancel
a railway reservation that they have made.
AIRLINE
RESERVATION
SYSTEM
Date:
AIM:
To develop the problem statement for Airline Reservation system.
PROBLEM STATEMENT:
Airline reservation system is used to book the online flight tickets. Sign is required for booking
tickets. It ensures portability and compatibility. Source, destination, trip(one way or round trip)
details should be choose along with the date of journey. The payment of the tickets will be done
through only online methods. Insurance option is also available. The ticket details will be shared
through SMS and e-mail for the traveller reference.
iii
Table of Contents
Table of Contents ...........................................................................................................................3
Revision History .............................................................................................................................3
1. Introduction ..............................................................................................................................4
1.1 Purpose ............................................................................................................................................. 4
1.4 Product Scope ................................................................................................................................... 4
1.5 References......................................................................................................................................... 4
3.1 User Interfaces .................................................................................................................................. 7
4. System Features .......................................................................................................................7
4.1 Descriptionand priority…………….………………………………………………………………7
4.2 Functional requirements…………………………………………………………………………....7
5.5 Business Rules .................................................................................................................................. 8
Revision History
4
1. Introduction
1.1 Purpose
The purpose of this SRS document is to provide a detailed overview of our software product. Here in this
product the entire process of reservation is done in a manual manner then it consumes more time for
reservation to reach the applicant. To overcome this disadvantage we use a computerized system used to
store and retrieve information and conduct transactions related to air travel and it is high secure than other
software products
The document conventions include:
Font Times New Roman

Title size 18
Sub-heading size 14
Content size 12

The Airline Reservation System Project is an implementation of a general Airline Ticketing
website of Orbitz, along with the different packages available with the reservations. This project is
intended for the software developers, software testers, software engineers, web designers, web developers
and flight management. This project is useful for flight management team as well as passengers.
1.4 Product Scope

The name of the software is “AIRLINE RESERVATION SYSTEM”. The Airline booking
website is an application stored in the user server. The purpose of the website is to resolve the client to
allow website users to perform tasks related to booking an airline flight. Requirements are the description
of how the system should behave, or of a system property. They are capabilities and objectives to which
software must confirm. Or in other words, they are constraints on the development process and describe.
This software provides options for viewing different flights available with different timings for a
particular date and provides passengers with the facility to book a ticket, modify or cancel a particular
reservation.
1.5 References
• IEEE Software Requirement Specifications

• https://www.scribd.com/doc/130966364/Airline-Reservation-System-SRS
5
• Flight details:
It includes the originating flight terminal and destination terminal, along with the
stop in between the number of seats booked/available sets two destinations.
• Passengers description:
It includes passenger name, address and phone number. This information may be
used for keeping the records of the passenger for any emergency or for any kind of
information.
• Reservation description:
It includes passenger details, code number, flight number, date of booking, date of
travel.

The main functions include:
• Secure Registration of information by the customers.

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

User of the system should be able to retrieve flight information between two cities with the given
date and time of travel from the database. The system will support two types of user privileges, passenger
and developer. Passenger will access to passenger function and developer will access to both passenger
and flight management functions.
• Passenger functions:
▪ Make a new reservation:
• One way.
• Round trip.
• Date and time.
• Confirmation.
▪ Cancel reservation
6
• Developer function:
▪ Passenger function:
• Get all the passenger details.
• Get all the flight details for a given airport.
• View flight schedule.
• Get all flights whose arrival and departure time are on
time/delayed.
• Calculate total sales for a given flight.
• Administrative:
▪ Add or delete a flight.
▪ Add a new airport.
▪ Update fare for flight.
▪ Update departure/arrival time for flight.

Operating environment includes :
▪ Processor-Pentium III @500MHz or above

▪ RAM-256 MB
▪ Hard Disk-40 GB
▪ Operating system: Windows, Linux
▪ Platform:vb.net/java/PHP
▪ Regulatory policies:
▪ It is a mandatory that no text box must be left empty or contains
insufficient data.
▪ It is the responsibility of the traveller to maintain the application and keep
it updated.
▪ Hardware limitations:
▪ There must be a 64 MB on board memory.
▪ Control functions:
▪ The software must be very user-friendly and display appropriate
messages.
The server is available 24/7,except during scheduled maintenance times.
▪ Parallel operations:
▪ It must support many users simultaneously.
7
▪ Safety/security considerations:
▪ The application must be exited always normally.
▪ Secure sessions will be monitored in order to ensure proper closure after 5
minutes of inactivity for security purposes.
▪ Interruption of cell phone service will cause the application to close and
require the establishment for the new secure session.

The user document can be found in SRS.

It is assumed that the details of the cost of the ticket are already known to the customer. Future changes
like providing different types of flight with different classes like business class, economic class will allow
the customer to benefit from one facility.

3.1 User Interfaces
This requirement will come along with a basic user interface tool with GUI along with simple and easy to
navigate icons thus avoiding any complexity which may not be understandable for novice users. The
interfacing will contain arrow marks ,text boxes and some different shaped boxes reduce complexity.
a) Server side
• The web application will be hosted on a web server which is listening on the web
standard port, port 80.
b) Client side
• Monitor screen – the software shall display information to the user via the monitor
screen.
• Mouse – the software shall interact with the movement of the mouse and the mouse
buttons. The mouse shall activate areas for data input, command buttons and select
options from menus.
• Keyboard – the software shall interact with the keystrokes of the keyboard. The
keyboard will input data into the active area of the database.

➢ Front End Client- The credit card interface is built using jsp and HTML.
➢ Web server- Glassfish application server(SQL corporation).
➢ Back End- SQL database.
➢ Java for coding.
8
➢ MS ACCESS for db.

➢ Agrouml for diagrams.
➢ Internet explorer with working LAN connection.
3.4 Communications interfaces
Communication interfaces will use TCP/IP for data transmission, e-mail, electronics form and so
on. All offline and online access will be monitored, for transparency purposes, and in order to
reduce abuse and unauthorized access of the system. This project supports all types of web
browsers
3.5 System Features
Description and priority:
➢ Accept credit card numbers on the web, store them in a database, then process them offline.
➢ Credit card processing with a third party credit card processing company.
➢ Credit card payment in offline using OTP. Give prior information if the amount exceeds
the credit limit.
➢ The credit card processing system is vast and is computerized.
➢ From the security point of view, authentication is done by password checking and if the
password is correct, the user will get further access to the system otherwise the user will
have to re-enter the password.
➢ The software is able to provide service for at most 10 people per minute.
➢ The software is made with credit limit and if it exceeds an warning message is sent to the
user.
Functional requirements:
➢ Customer may view about the transactions and credit limit.

➢ After checking the credit limit the transaction is made either online or offline.
➢ If the customer wants to cancel a transaction then the amount must be refunded.
➢ The system is in such a way that it stands upto user expectations.
➢ The system is able to avoid disastrous actions. The system safeguards against undesired
events without human intervention.
➢ The responses of all the operations are good.

The software should have high performance and low failure rates. Machines must have
firewalls installed and active virus scanning software in usage. Machines should solely be used for
operation of the software, in order to maximize performance and security.
• User Identification: The system requires the user to identify himself / herself using E-mail.
9
• Login ID: Any user who uses the system shall have a Login ID and Password
• Instructor Rights: Front Desk staff shall be able to view all information in RRS, add new course
to RRS but shall not be able to modify any information in it.
• Administrator’s Rights: Administrator shall be able to view and modify all information in
RRS.\
❖ Maintainability:
• Back Up: The system shall provide the capability to back-up the Data
• Errors: The system shall keep a log of all the errors.
❖ Reliability:
• Availability: The system shall be available all the time.
4.5 Business Rules

Transaction done in online requires OTP for security purpose, for offline transactions a four digit
pin number is used which is unique for each customer. The transactions made should not exceed
the credit limit.
• Use of captcha and encryption to avoid bots from booking tickets
• Search results should populate within acceptable time limits
• User should be helped appropriately to fill in the mandatory fields, incase of invalid
input
• System should accept payments via different payment methods, like PayPal, wallets,
cards, vouchers, etc
• System should visually confirm as well as send booking confirmation to the user's contact
• VB.Net: (Visual Basic .Net) is a multi-paradigm; object oriented programming
language, implemented on the .NET Framework.
• GUI: (graphical user interface) is a form of user interface that allows users to
interact with electronic devices through graphical icons and visual indicators.
10
• SRS: (software requirements specification) is a comprehensive description of the

intended purpose and environment for software under development.
• HTML (hypertext markup language) is the main markup language for displaying
web pages and other information that can be displayed in a web browser.
Appendix A: Analysis Models

Use case model, Object model, Dataflow model and SADT model, Dynamic model.
10
Date:
USE CASE DIAGRAM:

System:
Usecase:
11
Actors:
Relationships:
use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one
use case is needed by another in order to perform a task. An "extends" relationship indicates
alternative options under a certain use case.
12
USE CASE DIAGRAM:

13
Use case Modeling:

Use case name: PAYMENT
Brief:The passenger can book the flight ticket and the payment is done through via online for
our software system.
Casual:
Success scenario: If passenger want to book the flight ticket, then user can give a valid debit
or credit card details and OTP sent to the required email or mobile number, then the payment
process is done successfully.
Alternate scenario: At some situation, passenger cannot give the valid email or mobile
number, then the OTP will not be generated and payment is in incomplete stage.
Fully Dressed:
Use case name Payment
Goal To book the flight ticket
Level Transfer the payable amount
Primary actor Bank
Secondary actor Administrator, server
Stake holders Here bank plays the important role in the
system. user logged into the system and link
the bank account for the payment and to book
the flight ticket. Here bank plays the important
role in the system. user logged into the system
and link the bank account for the payment and
to book the flight ticket.
Precondition Before payment, link the bank account into the
system.
Main success scenario If passenger want to book the flight ticket,
then user can give a valid debit or credit card
details and OTP sent to the required email or
mobile number, then the payment process is
done successfully.
Exception At some situation, passenger cannot give the
valid email or mobile number, then the OTP
will not be generated and payment is in
incomplete stage.
Extension Give valid bank account.
14
Use case name: LOGIN

Brief:
The Passenger enters into the system’s software and look into the control panel then he enters the
login ID and password. If the password is valid, once the user is logged in, then the user can
book, cancel and view the details of the flight ticket.
Casual:
Success scenario: The Passenger enters into the system’s software and look into the control
panel then he enters the login ID and password. If the password is valid, once the user is logged
in, then the user can book, cancel and view the details of the flight ticket.
Alternate scenario: If the password entered by the passenger is invalid, the system cannot be
opened and can’t perform and operation. So he must re-enter the valid password. The system
allows to enter the valid password up to five attempts.
Fully Dressed:
Use case name Login
Primary actor Passenger
Secondary actor Administrator, Server
Stake holders Passenger plays the important role in the system. He login to the
system and can book, cancel and view the details of the flight
ticket etc.,
Precondition Create an account to enter into the system.
Main success scenario Enter to the system software.
Look at the control panel.
Enter the login ID and password.
Book or cancel or view the details of the flight ticket etc.,
Exception Forget password
Incorrect password
Extension Unauthorized user cannot login to the system.
Special requirements Security is important, provide more authentication

15
Use case name: BOOKING

Brief:
The passenger can book the ticket by acquiring details about user. And select that one way or
round trip should be selected along with the date of journey, link the bank details for payment
and then book the ticket.
Casual:
Success scenario: The passenger can book the ticket by acquiring details about user. And select
that one way or round trip should be selected along with the date of journey, link the bank details
for payment and then book the ticket.
Alternate scenario: But at some situation, the passenger can’t able to book the ticket
because number of flights is not available for the passenger’s convenient time. User’s Login ID
and password is incorrect, so the user cannot able to book the ticket.
Fully dressed:
Use case name Booking
Goal Booking flight ticket
Level To book the flight ticket for the user.
Primary actor Passenger
Secondary actor Administrator, Server
Stake holders Passenger plays the important role in the
system. He logged into the system and book
the flight ticket.
Precondition Create an account and login into the system
before booking.
Main success scenario The passenger can book the ticket by
acquiring details about user. And select that
one way or round trip should be selected
along with the date of journey, link the bank
details for payment and then book the
ticket.
Exception Many of them can book the ticket in some

offer time, sometimes the system may not
respond.
Extension The ticket is not available.
Special requirements Check availability.
Authenticated user.
16

Date: from that
Domain model:

Category list:
1.Business transaction: Transaction.
2.Transaction item: Transaction line items.
3.Product or service Online / offline.

5. Role of people or organization related to Customer, bank, seller.
transaction:
6.Place of transaction: Store, online.

7.Noteworthy events: Purchase product, payment.
8.Physics objects: Credit card
9.Description of things: Product description transaction description.
17

• First, the passenger can login into account and the required page will be shown.
• If the passenger wants to search the flights, then the passenger give the flight details,
timing or source-destination.
• The passenger can check the seat availability.
• The passenger cannot selected the already reserved seats.
• For the booking process, we should give the appropriate details of the user, and then the
system validate the user details.
• Give the valid credit or debit card and proper bank details .
• After the validation, the user should pay the amount for booking the flight ticket.
• After the end of payment process, the user can receive confirmation through via email or
mobile number.
Payment
Mobile number
Passenger
Flight
Bank
Seat
email
Credit card
18
Domain Model:
CLASS DIAGRAM:
on the system. The class diagrams are widely used in the modelling of object oriented systems
languages.
19

Members:
Visibility:
+ Public
- Private
# Protected
~ Package
Derived property:
Scope:
• Classifier members are commonly recognized as “static” in many programming languages.

The scope is the class itself.
20

Relationships:
Class Notation:

21
responsibility.
Object Notation:
Classes:
1. Airport
• name: String
• locatin: String
2. Flight
• Flight_no: Integer
• Flight_name: String
3. Seats
• Available_seat: Integer
4. Passengers
• Passenger-id: Integer
• name: String
22
• Phn_no: Integer
• Email_id: String
5. Flightmanifest
• Booked_tickets: Integer
6. Flight_description
• No.of_seats: Integer
• Available_classes: String
• Source: Integer
• Destination:Integer
7.Ticket
• Ticket_no:Integer
• Toatal:Integer
8.Pilot
• Pilot_name:String
• Pilot_id:String
23
CLASS DIAGRAM:
24
Ex.No:5
Using the identified scenarios find the interaction
sequence diagram
SEQUENCE DIAGRAM:
25
system.

sequence diagram. So basically each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in in
UML for naming a lifeline follows the following format – Instance Name : Class Name
26
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to model
an unnamed instance, we follow the same pattern except now the portion of lifeline’s name
is left blank.
Difference between a lifeline and an actor: A lifeline always portrays an object internal to

27

receiver has processed the previous message i.e. it receives a reply message. A large
number of calls in object oriented programming are synchronous. We use a solid
arrow head to represent a synchronous message.

processing the previous message or not. We use a lined arrow head to represent an
asynchronous message.
28

• Delete Message: We use a Delete Message to delete an object. When an object is de

allocated memory or is destroyed within the system we use the Delete Message symbol. It
destroys the occurrence of the object in the system. It is represented by an arrow
terminating x. For example – In the scenario below when the order is received by the user,
29
the object of order class can be destroyed.
30
• Reply Message: Reply messages are used to show the message being sent from the receiver
line. The interaction moves forward only when a reply message is sent by the receiver.
31
• Found Message: A Found message is used to represent a scenario where an unknown source
sends the message. It is represented using an arrow directed towards a lifeline from an end
point. For example: Consider the scenario of a hardware failure.
32
failure.
lifeline. For example: Consider a scenario where a warning is generated.
symbol.
33
procedure.
34
SEQUENCE DIAGRAM:
35
Flow of messages:
• The Passenger logins to the system by entering a valid ID and password.
• The Passenger can search flight in the reservation system.
• The system can check the available flights for the user from the database.
• The system can display the available flights to the user.
• The user can select the flights and select number of seats.
• The system can check the seat availability and display to the user.
• The Passenger enter and submit the details to the system.
• The system can update the details to the database.
• The system can print the ticket.
36
Ex.No:6 Using the identified scenarios, find the

interaction between objects and represent
Date: them using UML collaboration diagram
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behaviours
37
38

diagram
Date:
ACTIVITY DIAGRAM:
39
ACTIVITY DIAGRAM:
The activity diagram consists of four swim lanes namely passenger, administrator, system server
and bank. First passenger want to login into the system, then passenger can search flights to give
the required details like source-destination, timing ,one-way or round trip, date of journey etc.,
The user can check the seat availability and the user cannot select that already reserved seats.
40
Enter bank details for the payment method. After completing the payment, then reserve the seats
that are available for you. The passenger also receive acknowledgement for the system through
email or mobile number. The passenger can also cancel the tickets by entering the mandatory
details and half of the amount should be refund. The passenger can also check the flight status.

Key concepts:
State


with a solid circle. A transition from this state will show the first real state
41
state machine represents an object that may terminate before the system terminates, while
a closed loop state machine diagram does not have a final state; if it is the case, then the

42
Date:
CLASS NAME: Airport.java
package ars;
public class Airport {
public String name;
public String location;
public void getmaxcapacity() {

}
}
CLASS NAME: Flight.java
package ars;
public class Flight {
private Integer flight_number;
public String flight_name;
public void getflightdetails() {

}
public Integer getFlight_number() {

return flight_number;
}
public void setFlight_number(Integer flight_number) {

this. Flight_number = flight_number;
}
}
43
CLASS NAME: flightdescription.java
package ars;
public class flight description{
public Integer no_of_seats;
public String available classes;
public String source;
public String destination;
public void getflightdesc() {

}
CLASS NAME: flightmanifest.java
package ars;
public class flightmanifest {
public Integer bokked_tickets;
public void showbokkedtickets() {

}
CLASS NAME: Passengers.java
package ars;
public class Passengers {
public Integer passenger_id;
public String name;
public Integer phone_no;
public String email_id;
public Payment makes;
public void getpassengerdet() {

44
}
CLASS NAME: Payment.java
package ars;
public Integer Amount=1000;
public String mode="netbanking";
public void makepayment(Integer amt) {

if(amt==Amount) {
System.out.println("successfull");
}
}
public void modeofpayment(String p_mode) {

if(p_mode==mode) {
System.out.println("payment completed");
}
}
CLASS NAME: Pilot.java
package ars;
public class Pilot {
public String flight_name;
public Integer pilot_id;
public String pilot_name;
public Flight flies;
public void getpilotdet() {

}
CLASS NAME: Seats.java

45
package ars;
public class Seats {
private Integer available_seat;
public void getavailableseats() {

}
public void getseatno() {

}
public Integer getAvailable_seat() {

return available_seat;
}
public void setAvailable_seat(Integer available_seat) {

this. Available_seat = available_seat;
}
CLASS NAME: Ticket.java
package ars;
public class Ticket {
public Integer ticket no;
public Integer total;
public void getfare() {

}
public void gettaxadded() {

}
public void book tickets() {

}
public void cancel tickets() {

}}
46

Date:
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network or object to test
its strength or to analyze overall response time under different load types. JMeter simulates a group
of users sending requests to a target server, and returns statistics that show the performance and
functionality of the target server via tables, graph, etc.
• FTP services.
JMeter Features:
47
CLASS NAME: Payment.java
package ars;
public String mode="netbanking";
public void makepayment(Integer amt) {

if(amt==Amount) {
System.out.println("successfull");
}
}
public void modeofpayment(String p_mode) {

if(p_mode==mode) {
System.out.println("payment completed");
}
}
Positive output:
48
Negative output:
49

Date:
of individual factories that have a familiar theme without specifying their concrete classes. In usual
case, the client software create a concrete implementation of the abstract factory then using generic
interface of the factory to create the concrete objects which is part of the theme. The client doesn’t
know which concrete objects gets from all of these internal factories, since it uses only the generic
interfaces of their products. Abstract products describe interface for every different products of a
single product family. Concrete products implement the abstract product interface which is
returned by creational methods of concrete factories. Abstract factory defines the interface for
creating products which is common to all concrete factories. Concrete factories implement
creational methods of the abstract factory and each concrete factory should correspond to a specific
products variant as shown in Figure.
50
execution.
understandability, and flexibility are calculated using percerons design pattern advisor tool. In step
5 completeness, stability, simplicity, and expandability are measured using mathematical
+doAction2:void AbstractProduct +doAction:void AbstractFactory concreteProduct1
concreteProduct1 +doAction:void concreteFactory2 concreteProduct1: Admin concreteProduct2:
User concreteProduct2 +doAction:void 95 programmers should have to use less effort to adapt
51
OSS.
Conclusion:
The Airline Reservation System reduces the scope of manual error and conveniently maintains
any modifications, cancellations in the reservations. It not only provides flight details but also
but also creates a platform to book tickets, cancels or modifies ticket timings or dates and even
informs about the number of people on board!
CREDIT CARD
PROCESSING
1

Date:
AIM:
To develop the problem statement for Credit Card Processing system.
PROBLEM STATEMENT:
Credit cards are used for both offline and online payment. For offline payment a four-digit
pin number provided. Credit cards are provided with credit limit and after each transaction the
details are sent to the user by the bank. The Money spent by the user should be paid back within
the deadline. For both online and offline payments the credit limit is checked and if the amount
requested exceeds the limit, then an error message should be sent to the user. Prior notification
should be sent to the user about the deadline. For online payment, an OTP is generated for security
purpose. Penalty should be issued when the amount is not paid back.
iii
Table of Contents
Table of Contents ...........................................................................................................................3
Revision History .............................................................................................................................3
1. Introduction ..............................................................................................................................4
1.1 Purpose ............................................................................................................................................. 4
1.4 Product Scope ................................................................................................................................... 4
1.5 References......................................................................................................................................... 4
3.1 User Interfaces .................................................................................................................................. 7
4. System Features .......................................................................................................................7
4.1 Descriptionand priority…………….………………………………………………………………7
4.2 Functional requirements…………………………………………………………………………....7
5.5 Business Rules .................................................................................................................................. 8
Revision History
4
1. Introduction
1.1 Purpose
The purpose of software requirement specification(SRS) document in credit card processing
system is to provide a detailed description of how to develop a credit card processing which is
issued for both online and offline payment or transaction on the condition that they will repay the
amount plus interest. This document helps the user to develop the software without the knowledge
of the system
Font Times New Roman

Title size 18
Sub-heading size 14
Content size 12
This document is intended for the initial users, software developers, software testers, customer.
This project is a prototype for credit card processing system and it is intended to focus on people
who uses credit card.
1.4 Product Scope

The purpose of the credit card processing system is to provide services for both online and offline
transactions. In the case of offline payment, when a customer swipes a credit card authentication
is done. Security is ensured by providing a unique pin number to individual credit card users.
Automatically connects to the financial network for credit card authorization. Multiple
verifications should be available. In the case of offline payment, a secure way will be provided for
the billing. Notify the customer if the credit limit is exceeded.
1.5 References
➢ IEEE Software Requirement Specifications.
➢ https://krazytech.com/projects/sample-software-requirements-specificationsrs
➢ https://www.moneycrashers.com/credit-card-payment-processing-systems-networks/
by Brian Martucci
5
The origin of the product being specified in the SRS is a new product. The product is not a
component of any system. The system is open source and web based and it provides an interface
between customer and administrator.
▪ Card details:
It includes account holder’s name, account number, system number, ccv number, bank
number, check digit. It also includes expiry date.
▪ Customer details:
It includes customer name, account details, address, mobile number, name of the bank,
IFSC code.

User should be able to make both online and offline payment. User should know about the credit
limit. User should repay the amount within the deadline. Every user should have unique pin
number. Card authentication and verification should be made. In this system, the cardholder
purchases items and pays bill with the credit card. The cashier accepts the card and proceeds for
transaction. In the case of transaction failure, the amount is refunded. The CCV number of every
card is unique. The transaction is possible only when the amount does not exceed the credit limit.
The amount should be repaid within the mentioned period of time. In online payment, OTP is
generated for every transaction and the details of the transactions are sent to both the user and the
bank.
Purchase product: Customer purchases items from ecommerce site and then proceeds to
checkout area.
Authorization request: Payment is done in a secure way
Authorization response: Billing information is verified and the transaction is completed by

issuer.
Payment approval: The transaction details are recorded by the credit card processor and the
results are sent to the retailer to make a successful transaction
Transaction failed: The transaction which failed is reported to the bank and the amount is
refunded within a short period of time.
6
Credit limit: The transaction should be within the credit limit.
Maintenance: The transaction details are maintained and the information is provided to the user.
Online purchase: The payment done in online will be recorded and the transaction is within
the credit limit.

➢ Operating system is Windows 32-bits/x86 and 64-bit/x64 PC architectures.
➢ The program are based on Graphical User Interface (GUI).
➢ Software is platform independent.
➢ MS access for database.
➢ Java for coding purpose.
➢ Argo Uml.

Security features and login fail safes shall be of the highest concern when developing this project.
Such security features include high-security of data transfers, and encrypted network
communications, as well as programming logging of function calls as well as parameters passed.
Check whether the customer is able to maintain the software. Due to the large nature of the project,
keeping track of the source code between the developer sub-teams will be difficult. The source
code, as well as the current folder/file structure, will be able to be uploaded and fetched from our
Github account. Encryption is provided to keep the customer and transaction details secure.
The application will come with an “About” tab, which will allow users to access the help manual.
This manual will be updated with each new service pack. Other user documentation includes one
user manual for lowest level users, one technical document describing the functionality of the sub-
section in detail for use of technicians, one copy of documentation and link to current source for
future contributors.
Let us assume that this is a distributed credit card processing system and it is used for the following
applications:
The system needs user to have some knowledge of credit card processing system and its working.
Request for online or offline payment given along with credit limit. Calculation of credit card
users and calculating the appropriate interest for the amount they have used. Assuming both the
transactions are single transactions, we have designed a distributed database. The system provides
transaction facilities 24/7. Enquiry facilities are available for 24/7. The software is dependent on
internet access as it is a remote application. It is assumed that the user is familiar in handling the
software.
7

3.1 User Interfaces
➢ The user interface of the software will use standard Windows API and GUIs using java.
The user interfaces include chrome, Mozilla fire box.

➢ The server is directly connected to the client system. The client system has access to the
database in the server. Windows, A browser that supports HTML.

➢ Front End Client- The credit card interface is built using jsp and HTML.
➢ Web server- Glassfish application server(SQL corporation).
➢ Back End- SQL database.
➢ Java for coding.
➢ MS ACCESS for db.
➢ Agrouml for diagrams.
➢ Internet explorer with working LAN connection.
3.4 Communications interfaces
Communication interfaces will use TCP/IP for data transmission, e-mail, electronics form and so
on. All offline and online access will be monitored, for transparency purposes, and in order to
reduce abuse and unauthorized access of the system. This project supports all types of web
browsers
3.5 System Features
Description and priority:

➢ Accept credit card numbers on the web, store them in a database, then process them offline.
➢ Credit card processing with a third party credit card processing company.
➢ Credit card payment in offline using OTP. Give prior information if the amount exceeds
the credit limit.
➢ The credit card processing system is vast and is computerized.
➢ From the security point of view, authentication is done by password checking and if the
password is correct, the user will get further access to the system otherwise the user will
have to re-enter the password.
➢ The software is able to provide service for at most 10 people per minute.
➢ The software is made with credit limit and if it exceeds an warning message is sent to the
user.
Functional requirements:
➢ Customer may view about the transactions and credit limit.

8
➢ After checking the credit limit the transaction is made either online or offline.
➢ If the customer wants to cancel a transaction then the amount must be refunded.
➢ The system is in such a way that it stands upto user expectations.
➢ The system is able to avoid disastrous actions. The system safeguards against undesired
events without human intervention.
➢ The responses of all the operations are good.

The software should have high performance and low failure rates. Machines must have
firewalls installed and active virus scanning software in usage. Machines should solely be used for
operation of the software, in order to maximize performance and security.

The user should feel secured because he is giving his personal details for registration. All offline
and online transactions should be monitored and stored.

The security should be tight so that it makes it difficult for the hackers to hack the database. All
the transactions should be one to one encrypted and security should be ensured.
Flexibility, availability, correctness, reusability, robustness, and maintainability of the system

should be maximized for the customers and it should be secure and updatable when new updates
are made.
4.5 Business Rules

Transaction done in online requires OTP for security purpose, for offline transactions a four digit
pin number is used which is unique for each customer. The transactions made should not exceed
the credit limit.
Name of the customer, a unique CCV number should be in the credit card. SQL database is
required to keep the details about the user, keep track of the transactions and other details. The
card should be internationalized and should be able to be used in other countries. The card should
contain only valid details of the customer approved with their id. The project should be able to be
reused with the inclusion of further updates.
9
1. Baud rate: Rate of transfer of data over the internet/network.
2. Bit: Binary Digit, zero (0) or one (1).
3. TLS: Transport Layer Security, A high-encryption security protocol for internet connection.
4. Tx/Rx: Transfer/Receive
5. Windows API: Windows Application Programming Interface, the API used to program
Windows applications and elements
6. ATM: Automated Teller Machine.
7. PIN: Personal Identification Number.
8. OTP: One Time Password.
9. SQL: Structured Query Language.
10. SRS: Software Requirements Statement.
11. GUI: Graphical User Interface.

10
Date:
USE CASE DIAGRAM:

System:
Usecase:
11
Actors:
Relationships:
12
USE CASE DIAGRAM:

13
Use case Modeling:

Use case name: Transaction
Brief:
The transaction is done by using the credit card. The customer purchases the product. Seller bills
the product and the payment is done successfully after verifying the card.
Casual:
Success scenario:
The transaction is done successfully and the payment is done either online or offline.
Alternate scenario:
The card may be invalid, the credit limit may be exceeded. The validity of the card may be expired.
Transaction may fail due to network failure or wrong entry of pin in case of offline payments.
Fully Dressed:
Use case Name Transaction
Goal To provide services for both online and
offline
Transactions.
Level To perform transaction.
Primary actor Customer.
Secondary actor Seller, bank.
Stack holders Customer, seller, bank.
Pre-conditions Check the credit limit.
Main success scenario •Customer purchases the product in shop.
•Seller bills that product.
•Customer gives the credit card for
payment..
•Seller authorizes purchase.
•Seller confirms sale.
•If the transaction is successful, the bank
sends SMS to the customer.
Extension Card is invalid.
Special requirements Security.
Use case name: Credit bill

14
Brief:
After the transaction is completed a credit bill will be generated by the bank. The bill is sent to the
user. Credit bill contains the details about the transaction amount and the balance. The bank
generates e-bill to the customer.
Casual:
Success scenario:
The e-bill is generated successfully for the transaction by the bank and it is given to the user.
Alternate scenario:
The e-bill may not be generated due to network issues. The network may be busy, e-bill may be
generated after a short delay.
Fully Dressed:
Use case Name Credit bill
Goal To provide service for both online and
offline transaction.
Level To generate credit bill.

Primary actor Bank.
Secondary actor Customer.
Stack holders Bank, customer.
Pre-conditions To check the transaction list for the

customer.
Main success scenario •Bank verifies the customer transaction list.
•Bank repeats the process until the due date.
•Bank generates the bill.
Extension e-bill is not generator due to some network

issues or server failure.
Special requirements Efficient network facilities.
Use case name: Authenticate payment

15
Brief:
The transaction is done only after the authentication of the card which is done by the bank. This
authentication is required for security purpose.
Casual:
Success scenario:
The card is authenticated successfully and the transaction is processed.
Alternate scenario:
The card may not be authenticated due to network failure, invalid card, fake details or duplicate
card.
Fully dressed:
Use case Name Authenticate payment.
Goal To provide service for the payment.
Level To authenticate the payment.
Primary actor Bank.
Secondary actor Customer.
Stack holders Bank, customer.
Pre-conditions To check the bank whether its network
facility is good to provide authentication.
Main success • Customer provides the credit card.
Scenario •The bank authenticates the card by checking
the customer details with respect to the card
and the credit limit.
Extension Authentication is not provided by the bank

due to invalid card or network issues.
Special requirements Efficient network facility authentication
provides immediately
16

Date: from that
Domain model:

Category list:
3.Product or service Online / offline.
5. Role of people or organization related to Customer, bank, seller.
transaction:
6.Place of transaction: Store, online.
8.Physics objects: Credit card
9.Description of things: Product description transaction description.

Main success scenario:
17
• Customer gets credit card that is issued by the Bank.
• Customer purchase products either online or offline.
• For offline payments customer purchase and swipes the card for payment.
• Seller does the billing and the receipt is given to the customer.
• The transaction is done after checking whether the credit limit is greater than the amount.
• Successful transaction sends a notification to the customer and the details are updated in database.
• Customer gets the product and leaves the store.
• For online payment after selecting the product customer pays with the credit card.
• OTP is generated and the transaction is completed successfully.
NOUNS:
• Customer
• Payment
• Credit card
• Receipt
• Bank
• Bill
• Product
• Credit limit
• Notification
• Online
• Offline
• Store
• Database
Domain Model:
18
CLASS DIAGRAM:
on the system. The class diagrams are widely used in the modeling of objectoriented systems
languages.
Members:
Visibility:
+ Public
19
- Private
# Protected
~ Package
Derived property:
Scope:

Relationships:
20
Class Notation:

responsibility.
Object Notation:
21
Classes:
1. Customer
• Cust-name: String
• Cust-id: String
• DOB: String
• Contact no: Integer
2. Credit card
• Card no: Integer
• Pin no: Integer
• Credit limit: Integer
3. Transaction
• Trans-id: String
• Trans-date: String
• Trans-amount: Integer
4. Bank
• Bank-id: String
• Bank name: String
• Branch: String
• Address: String
5. Seller
• S-id: String
• S-name: String
• S-address: String
• S- mail id: String
6. Bill
• Bill no: String
• Date: String
• Bill-amount: Integer
22
CLASS DIAGRAM:
23
Ex.No:5
Using the identified scenarios find the interaction
sequence diagram
SEQUENCE DIAGRAM:
24
system.

lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in in
25
is left blank.
Difference between a lifeline and an actor: A lifeline always portrays an object internal to

26


27

• Delete Message: We use a Delete Message to delete an object. When an object is de allocated
memory or is destroyed within the system we use the Delete Message symbol. It destroys the
occurrence of the object in the system. It is represented by an arrow terminating x. For
example – In the scenario below when the order is received by the user, the object of order
28
29
For example – Consider a scenario where the device wants to access its webcam. Such a scenario
is represented using a self message.
30
31
failure.
symbol.
32
procedure.
33
SEQUENCE DIAGRAM:
34
Flow of messages:
• Customer purchases the items from the seller.
• Seller calculates the amount and generates a bill.
• Customer swipes the card and the bank verifies the card.
• The bank sends a verification signal to the customer.
• If the card is valid the transaction is processed otherwise the card is returned to the
customer
• If the card is valid, customer enters the amount of the bill.
• Seller requests pin from the customer.
• Customer enters the pin and the bank validates the pin.
• If the pin is valid and the bill amount is less than the credit limit then the transaction is
processed.
• After the transaction is completed the bill is generated by the bank.
• If the pin is wrong and the bill amount is greater than the credit limit an error message is
popped.
• Finally the card is returned to the customer.
35
Ex.No:6 Using the identified scenarios, find the

interaction between objects and represent
Date: them using UML collaboration diagram
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behaviours
36
37

diagram
Date:
ACTIVITY DIAGRAM:
38
ACTIVITY DIAGRAM:
The activity diagram consists of three swim lanes namely customer, seller and bank. The initial
process is purchase item done by the customer. The seller calculates the amount. The customer
swipes the card. The parallel behavior such as branch and merge are used in verifying the card
39
which is done by the bank. If the card is valid the customer enters the pin and the pin is checked
by the bank. If the pin is correct then the customer enters the amount and if the credit limit is
greater than the bill amount the transaction is done otherwise an error message is generated to the
customer by the bank. If the card is invalid and the pin is wrong, under both cases the card is
ejected and returned to the customer.

Key concepts:
State


40

41
Date:
Class name: Customer.java

public class Customer {
public string customername;
public string contactno;
public string cusrtomerID;
public string DOB;
public string Address;
public Vector gets;
public Bank has;
public Vector do;
public void getDetails() {
public void updateDetails() {
}}
Class name: Bank.java

public class Bank {
public String BankID;

42
private String BankName;
public String Branch;
public String Address;
public Vector issues;
public Vector provides;
public Vector has;
public void Create() {
public void Update() {
public void Verify() {
}}
Class name: Creditcard.java

public class Credit card {
public Integer CardNo;
public Integer pin;
public Integer creditLimit;
public Vector gets;
public Bank issues;
public void updatecard() {
public void validateCard() {
}
43
Class name: Seller.java

public class Seller {
public Integer S-Id;
public String S-Name;
public String S-Address;
public String S-mailId;
public Vector create;
public void Check() {
public void Validate() {
public void Bill() {
public void c() {
}}
Class name: Transaction.java

public class Transaction {
public Sting transID;
public Integer transDate;
public Integer transAmount;
public Bank provides;
public void CreateTransaction() {
public void DeleteTransaction() {

44
public void Retrive() {
}}
Class name: Offline.java

public class offline extends Transaction {
Class name: Online.java

public class online extends Transaction {
Class name: Bill.java

public class Bill {
public String BillNo=”c1”;
public String Date=”11.09.2019”;
public Transaction refers;
public String BillCreate(String billid) {
System.out.println(BillNo);
System.out.println(Date);
System.out.println(Amount);
Return “t”;
public void BillUpdate() {
}}
45

Date:
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network or object to test
its strength or to analyze overall response time under different load types. JMeter simulates a group
of users sending requests to a target server, and returns statistics that show the performance and
functionality of the target server via tables, graph, etc.
• FTP services.
JMeter Features:
46
Class name: Bill.java

public class Bill {
public String BillNo=”c1”;
public String Date=”11.09.2019”;
public Transaction refers;
public String BillCreate(String billid) {
System.out.println(BillNo);
System.out.println(Date);
System.out.println(Amount);
Return “t”;
public void BillUpdate() {
}
47
48
49

Date:
products variant as shown in Figure.
50
execution.
5 completeness, stability, simplicity, and expandability are measured using mathematical
+doAction2:void AbstractProduct +doAction:void AbstractFactory concreteProduct1
concreteProduct1 +doAction:void concreteFactory2 concreteProduct1: Admin concreteProduct2:
User concreteProduct2 +doAction:void 95 programmers should have to use less effort to adapt
51
OSS.
52
Conclusion:
To make the payment more convenient for customers the credit card processing system has been
developed which helps the customers for both online and offline payment within the credit limit.
The credit card is used for easy transaction in both online and offline mode. The customers use the
money within the credit limit and repay the amount within the given time.
SOFTWARE
PERSONNEL
MANAGEMENT
SYSTEM
1
EX.NO:1
Date:
PROBLEM STATEMENT
AIM
To develop a problem statement for the Software Personnel Management System.
PROBLEM STATEMENT
Software personnel management system allows employees 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.
3
Table of Contents
Table of Contents .......................................................................................................................... 3
Revision History ............................................................................................................................ 4
1. Introduction .............................................................................................................................. 5
1.1 Purpose................................................................................................................................. 5
1.2 Document Conventions ....................................................................................................... 5
1.3 Intended Audience and Reading Suggestions ..................................................................... 5
1.4 Product Scope ...................................................................................................................... 6
1.5 References ....................................................................................................................................... 6
2. Overall Description .................................................................................................................. 7
2.1 Product Perspective ............................................................................................................. 7
2.2 Product Functions ................................................................................................................ 7
2.3 User Classes and Characteristics ......................................................................................... 7
2.4 Operating Environment ....................................................................................................... 8
2.5 Design and Implementation Constraints .............................................................................. 8
2.6 User Documentation ............................................................................................................ 8
2.7 Assumptions and Dependencies .................................................................................................. 9
3. External Interface Requirements ........................................................................................... 9
3.1 User Interfaces ..................................................................................................................... 9
3.2 Hardware Interfaces ............................................................................................................. 9
3.3 Software Interfaces .............................................................................................................. 9
3.4 Communications Interfaces ................................................................................................. 9
4. System Features ...................................................................................................................... 10
4.1 Description and priority..................................................................................................... 10
4.2Stimulus / Response Sequences ........................................................................................... 10
4.3Functional Requirements .................................................................................................... 10

5. Other Nonfunctional Requirements ..................................................................................... 10
5.1 Performance Requirements ............................................................................................... 10
5.2 Safety Requirements .......................................................................................................... 10
5.3 Security Requirements ....................................................................................................... 11
5.4 Software Quality Attributes............................................................................................... 11
5.5 Business Rules ................................................................................................................... 11
4
6. Other Requirements ............................................................................................................... 11

Appendix A: Glossary ................................................................................................................ 11
Revision History
Name Date Reason for Changes Version
1.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.1Purpose
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
employees 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.2Document Conventions
The Document is presented with a Times font face entirely. Every Heading of font size 24,
bolded is followed by a sub-heading of font size 14, bolded followed by an explanation
paragraph of font sizes 12 which is aligned to justify. The Headings are referred in whole
numbers and the subheadings are referred in decimals following the convention ‘Heading_id.
Subheading id’ (i.e...) A heading number followed by a sub heading. The paragraphs are
presented in italics. Heading are followed by subheadings which is followed by paragraphs.

Times New Roman Bold
Heading 24
Times New Roman 14 Bold
Sub heading
Convention Example Heading ID Sub Heading ID

1.2 1 2
3.3 3 3
2.7 2 7
1.3Intended Audience and Reading Suggestions

This Document is intended for readers such as developers, project managers, marketing staff,
users, testers, and documentation writers. The SRS contains Product Perspective, Product function,
User classes and characteristics, Operating environment, Design and Implementation Constrains,
Assumptions and Dependencies of the project under Overall Description. It also contains User
Interfaces, Hardware interfaces, Software interfaces, Communication interfaces under External
Interface Requirements and Functional and Non-Functional Requirements in Software Features.
Sections Intended Readers

Product Perspective Project managers, marketing staff, user
External Interface Requirements Testers, Document Writers
System Features Developers, testers
1.4Product 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 employees.
1.5Reference
 IEEE Software Requirements Specification template.

 IEEE Recommended practice for software requirements specification-IEEE std 830-199.
“Software Engineering”-By K.K.Agarwal and Yogesh Singh, New age publishing house 2nd
Edition.
https://krazytech.com/projects/sample-software-requirements-specificationsrs
2.Overall Description
The Software Personnel Management System 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. The Automated Pay Slip Generation
for Employees is a self-contained product.
2.2Product Function
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 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 Software Personnel
Management System. 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.3User Classes and Characteristics
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
Employee are the person who desires to view their salary details.
2. Administrator
Administrator has the certain privileges to generate pay slip for the employee.
3. Database Manager
Database manager stores all the data related to Employee and Administrator.
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 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.
2.4Operating Environment
• Windows 32-bit and 64-bit PC architectures

• HTML
• JSP
• JavaScript
• Java
•ArgoUml
• XML
• AJAX
2.5Design and Implementation Constraints

• The administrator requires a system to monitor information of the employee.
• It uses a modular design where every feature is wrapped into a separate module and the
modules depend on each other through well-written APIs. There are several APIs available to
make plugin development easy.
2.6User Documentation
The application will come with an “About” tab, which will allow users to access the help
manual. This manual will be updated with each new service pack. Other user documentation
includes one user manual for lowest level users, one technical document describing the
functionality of the sub- section in detail for use of technicians, one copy of documentation and
link to current source for future contributors.
2.7Assumptions and Dependencies
• The employee and Administrator must have basic knowledge of computers and English
Language.
• The Software Personnel Management System is developed in Java and therefore requires Java
to be installed on the user’s system. The latest stable version of Software Personnel Management
System requires Java version 7 or higher. This applies to Windows and Linux users. On Mac OS X,
Java is bundles with the application.
3.External Interface Requirements

3.1User Interfaces
The user interface of the software will use standard Windows API and GUIs using
java. The user interfaces include Chrome, Mozilla Firefox and Internet Explorer.
3.2Hardware Interfaces
The server is directly connected to the client systems. The client systems have access to
the database in the server.
• 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.

The system shall use the HTTP protocol for communication over the internet and for
the intranet communication will be through TCP/IP protocol suite. Communication interfaces will
use TCP/IP for data transmission. The database is updated from the moment changes are made in
the system with immediate synchronization.
4.System Features
4.1 Description and Priority
The Software Personnel Management System maintains information on employee details
such as the number of hours worked per day and total of all hours spent on a project and total pay
received year-to-date, etc. Of course, this project has a high priority because it is also the duty of the
Administrator to ensure the correctness of the details generated by the automated payroll process
whether completed on time and without any errors.
4.2 Stimulus/Response Sequences

There are no immediate actions needed to be taken as the process of Payment Slip is
automated and checked for any errors by the Administrator in the database. The employee reviews
the details and receives the appropriate salary.
There are certain software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. This can be shown by including how
the product should respond to anticipated error conditions or invalid inputs.
For example, the employee and administrator should provide a password to login and view the
salary details and the generation of the payment slip by the administrator. The database manager
will create, update or delete the database depending on the level of the input generated by the
employee. If the person forgets the password, then he should contact the database manager for his
forgotten password.
The requirements needed to be fulfilled are specified below:
REQ-1: Password for login and viewing the employee details.
REQ-2: Job assignment for each employee should be updated by the administrator.
REQ-3: Database Manager can create and modify the database.
5.Other functional requirements

The software should have a very high performance on a wide range of the platforms in
which they use to view. The password entered during the login is taken and encrypted.

To prevent viewing, modification or alteration of other employees’ details, each
employee/user is provided with a unique username and password. Each session of the
employee’s status at the application is logged and used to debug for later use and rectification over
the next iteration/release of the product.
The product is considered to be more stable and secure over the final release and should be
free of any bugs or problems. The logging of user (employee) is tracked and checked for any
suspicion if anything is found, then the respective action will be taken over the user’s
account.
The software will be stable over the final release and the fore coming releases. Despite any
faults or crashes or any events occur, then the user is provided with an FAQ section and a feedback
to ask for any assistance and the further improvement of the product.
5.5 Business Rules
The Administrator and database Manager have full access to the employees’ information
and payroll information and are said to be trustworthy and provided with their respective jobs and
tasks
6.Other Requirements
Other requirements include the maintenance of the database by a secondary manager for
efficient database management. Some attributes including employee name, id, address, mobile
number, date and hours worked and payment calculation attributes while the admin needs a user
authentication element, same with a database manager
DB: Refers to the Database specified.
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: Mark-up 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.
SQL: Structured Query Language.
SRS: Software Requirements Statement.
GUI: Graphical User Interface.
EX.NO:3 IDENTIFY USE CASES AND DEVELOP
DATE: USE CASE MODEL
USE CASE DIAGRAM:

user is involved. A use case diagram can identify the different types of users of a system and the

The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four diagrams
(activity, sequence, collaboration, and State chart) also have the same purpose.

SYSTEM
Figure 3.1
USE CASE
functions.
Figure 3.2
ACTORS
Actors are the users of a system. When one system is the actor of another system, label the actor system
with the actor stereotype.
Figure3.3
RELATIONSHIPS
among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship
indicates that one use case is needed by another in order to perform a task. An "extends"
relationship indicates alternative options under a certain use case.
Figure 3.4
USECASE DIAGRAM:
Figure 3.5
s
USE CASE MODELLING

LOGIN
BRIEF FORMAT
The user enters into the system’s software and looks into control panel, then he enters the
login ID and password. If the credentials are valid then the user is directed to the personnel
management system’s dashboard. An employee can view the hours worked, pay slip and has
privileges to edit their personal information. Manager can view employee details and employee
salary details and generate pay slip. An administrator has the privilege to view, create, edit and
update overall information.
CASUAL FORMAT
SUCCESS SCENARIO
The user enters into the system’s software and looks into control panel, then he enters the
login ID and password. If the credentials are valid then the user is directed to the personnel
management system’s dashboard displaying the privileges of the specific user.
ALTERNATE SCENARIO
If the credentials are wrong then they are invalid, the dashboard will not be displayed and no
further actions will be performed. The user must try re-entering the username or password. The
system provides and Help pop-up on attempts of failure on more than three times.
Use case name Login
Primary actor User (Employee, manager)
Secondary / Supporting actor Admin, Server.
Stake holders The user plays the important role in the

system. He login to the system and can
perform actions provided under his
privileges.

Main success scenario Enter into the system Software.
Look at the control panel
Enter the login ID and Password
Perform actions such as view edit details
and generate or view pay slip.
Exception Incorrect password. Forget password.

Unauthorized person cannot login to the
system.
Special Requirements Provided help pop up while trouble in login
PAYSLIP
BRIEF FORMAT
The Payslip is generated automatically based on the hours worked by the employees and the
payslip is generated after the manager’s call and can be viewed by the employees. The payslip
contains payment id, HRA, DA, Net pay and Gross pay.
CASUAL FORMAT
SUCCESS SCENARIO
The Payslip is generated on manager’s call and the payslip generated automatically based on
the hours worked by the employees. The Payslip will be generated and can be viewed by the
employees. The payslip will contain payment id, HRA, DA, Net pay and Gross pay.
ALTERNATE SCENARIO
On receiving irrelevant data on hours worked or wrong payment id for respected user, the
employee will not be viewing a relevant and fully-generated payslip. On receiving inappropriate
data for payslip generation, the manager will not be able to start payslip generation process.
Use case name Pay Slip

Goal To generate and view fully updated proper
payment slip for the respected employee
based on the hours worked by the employee.
Level To generate and view payment slip
Primary Actor Manager, Employee
Secondary/ Supporting Actor Admin, Server
Stake Holders The Manager plays an important role in the
system. The Payslip generation process starts
his call and the Employees view the
generated payslip.
Precondition The payslip generation function should work.
Main Success Scenario The Manager successfully completes the
payment generation process by fetching
employee details and the employee must be
able to view payslip properly.
Exception Inappropriate data received while payslip
generation
The payslip will be inappropriate when data
received is not relevant
Extension The updating of employee details and new
employee details must be maintained
Special Requirements Redundant data must be removed and proper
flow of data must be maintained
INFORMATION MANAGEMENT
BRIEF FORMAT
The Administrator maintains the overall details involved in the system which includes
employee details and payment details.
CASUAL FORMAT
SUCCESS SCENARIO
The Administrator maintains the overall details involved in the system which includes
employee details and payment details successfully.
ALTERNATE SCENARIO
At some situations, the employee details and new details will collapse due to redundant or
irrelevant entry of data into the system.
Use case name Information Management

Goal Management of overall data involved in the
system
Level To maintain and update the overall data
involved in the system. To track the data flow
in the system for proper functioning.
Primary Actor Administrator
Secondary/ Supporting Actor Server
Stake Holders The Administrator plays an important role in
the system. The Data flowing through the
system is checked and maintained by the
admin.
Precondition The admin should be able to login to system.
Main Success Scenario The Administrator maintains the overall
details involved in the system which includes
employee details and payment details
successfully.
Exception At some situations, the employee details and
new details will collapse due to redundant or
irrelevant entry of data into the system.
Extension The updating employee details and new
details into the system should be clear.
Special Requirements Redundant information must be removed,
available and new details must be maintained
and updated properly.
EX.NO:4
IDENTIFY CONCEPTUAL CLASSES AND DEVELOP
THE DOMAIN MODEL AND ALSO DERIVE A CLASS
DIAGRAM FROM THAT
CLASS DIAGRAM:
imposed on the system. The class diagrams are widely used in the modelling of object-
oriented systems because they are the only UML diagrams, which can be mapped directly with
object-oriented languages.
Members:
UML provides mechanisms to represent class members, such as attributes and methods,
and additional information about them.
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these notations
must be placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
Derived property is a property which value (or values) is produced or computed from other
information, for example, by using values of other properties.
Scope:
The UML specifies two types of scope for members: instance and classifier
assifier, and the latter is
To indicate a classifier scope for a member, its name must be underlined. Otherwise,
Relationships
Figure. 4.1
Class Notation:
UML class is represented by the following figure. The diagram is divided into four
parts.
• The third section is used to describe the operations perform

performed by the class.

Figure 4.2
responsibility.
Object Notation:
It is represented in the same way as the class. The only difference is the name which
is underlined as shown in the following figure.
Figure .4.3
21
DOMAIN MODEL
Figure. 4.4
As the object is an actual implementation of a class, which is known as the instance of a

class. Hence, it has the same usage as the class.
CLASS DIAGRAM
Figure. 4.5
The class diagram consists of four classes namely, Employee, Manager, Payment, Administrator.
The Associations between the classes are as follows:
• One Manager view many employee details.

• One Manager generates many Payments.
• One Administrator manages many Payments.
BETWEEN OBJECTS AND REPRESENT THEM USING
UML SEQUENCE DIAGRAM
DATE:
SEQUENCE DIAGRAM:
A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place. We can also use the terms event
diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how
and in what order the objects in a system function. These diagrams are widely used by
businessmen and software developers to document and understand requirements for new and
existing systems.
1.Actors
An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the scope of the
system we aim to model using the UML diagram.
Figure.5.1
multiple actors in a sequence diagram.
For example - Here the user in seat reservation system is shown as an actor where it exists
Figure - 5.2 an actor interacting with a seat reservation system
3.Lifelines - A lifeline is a named element which depicts an individual participant in a

sequence diagram. So basically, each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in UML for
naming a lifeline follows the following format - Instance Name: Class Name
Figure5.3 - lifeline
located on top of a vertical dashed line (referred to as the stem) as shown above. If we want
to model an unnamed instance, we follow the same pattern except now the portion of
Figure -5.4 a sequence diagram
4.Messages - Communication between objects is depicted using messages. The messages

appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines and
messages form the core of a sequence diagram. Messages can be broadly classified into the
following categories:
Figure – 5.5 a sequence diagram with different types of messages

i) Synchronous messages
receives a reply message. A large number of calls in object-oriented programming are
Figure – 5.6 a sequence diagram using a synchronous message
ii) Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction
moves forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.
Figure – 5.7
iii) Create message
We use a Create message to instantiate a new object in the sequence diagram.

There are situations when a particular message call requires the creation of an object. It is
represented with a dotted arrow and create word labelled on it to specify that it is the create
Message symbol.
For example - The creation of a new order on an e-commerce website would require a new object
of Order class to be created.
Figure - 5.8 a situation where create message is used
iv) Delete Message
We use a Delete Message to delete an object. When an object is

deallocated
memory or is destroyed within the system, we use the Delete Message symbol. It
destroys the
occurrence of the object in the system. It is represented by an arrow terminating with a
x.
For example:
In the scenario below when the order is received by the user, the object of order
Figure – 5.9 a scenario where delete message is used
v) Self-Message
messages are called Self Messages and are represented with a U-shaped arrow.
Figure – 5.10 self message

For example - Consider a scenario where the device wants to access its webcam.
Such a scenario is represented using a self-message.
Figure – 5.11 a scenario where a self-message is used
vi) Reply Message
Reply messages are used to show the message being sent from the receiver to the
sender. We represent a return/reply message using an open arrowhead with a dotted line. The
Figure - 5.12 reply message
For example - Consider the scenario where the device requests a photo from the user. Here
Figure – 5.13 a scenario where a reply message is used
vii) Found Message
Figure – 5.14 found message
failure.
Figure – 5.15 a scenario where found message is used
viii) Lost Message

A Lost message is used to represent a scenario where the recipient is not known to the
Figure -5.16 lost message
symbol.
GUARDS
Figure -5.17
procedure.
SEQUENCE DIAGRAM
Figure – 5.18
The Employee logins to the system by entering a valid ID and password then he will be able to
view salary on successful login. The manager logins to the system and will be able to view employee
details and generate payslip on a successful login. The Payment generation process flow follows admin
privileges to calculate salary on return of calculated salary the payroll is generated and displayed to
manager. The Employee will be able to view only after the payslip is generated by the manager. The
other operations involve create, delete and update details in the system by administrator and view and
update operations for employees’ personal details.
EX.NO:6
DATE: USING THE IDENTIFIED SCENARIOS, FIND THE INTERACTION

A collaboration diagram, also known as a communication diagram, is an illustration
of the relationships and interactions among software objectsin the Unified Modeling
Language (UML). These diagrams can be used to portray the dynamic behavior of a
particular use caseand define the role of each object.
diagrams.

behavior of individual objects as well as the overall operation of the system in real time. The
4.Messages- Messages between objects are shown as a labeled arrow placed near link. These
The most important objects are placed in the center of the diagram, with all other
participating objects branching off. After all objects are placed, links and messages should be
added in between.
Figure 6.1
EX.NO:7 DRAW STATE CHART DIAGRAM AND
DATE:
ACTIVITY DIAGRAM
ACTIVITY DIAGRAM:
be used for:
Figure 7.1
ACTIVITY DIAGRAM
Figure – 7.2
The Activity diagram consists of three swim lanes, the employee and the manager. The initial
process is done by the login of the user. The user may be manager or the employee. In case of user
being employee, they can view their work details and view their salary details. In case of the user
being the manager, he also must login and can view the employee details and also initiate the
process of generating the payroll and also view the generated payroll. The Employee can view the
payroll once generated.
diagram) is a behavior which specifies the sequence of states an entity (or object) visits
during its lifetime in response to events, together with its responses to those events.
Figure -7.3
Key concepts:
State
A state is a condition during the life of an object during which it satisfies some
condition, performs some activity, or waits for some external event.

Example:
Figure – 7.4

indicated with a solid circle. A transition from this state will show the first real state.
• The final state of a state machine diagram is shown as concentric circles. An open
loop state machine represents an object that may terminate before the system
STATECHART DIAGRAM
Figure- 7.5
EX.NO:8 IMPLEMENT SYSTEM AS PER DETAILED DESIGN
DATE:
Class Name: Administrator
import java.util.*;
public class Administrator {
public Integer adminid;
public String adminname;
public String adminpassword;
public void create() {}
public void update() {}
public void delete() {}
public void displaypayroll() {}
public void Employeedetaikls() {}
public void Employeedetails() {}
public void Viewemployeedetails() {}
public void
displayemployeedetails() {}
public void
Displayemployeedetails() {}
public void Gener
tepayslip() {} public void
FetchDe() {}
}
Class Name: Employee

import java.util.*;
public class Employee {
public Integer empid;
public String empname;
public String emppassword;
public String date;
public Integer hoursworked;
public void login() {}
public void viewsalary() {}
public void LoginSuccess() {}
}
Class Name: Manager
import java.util.*;
public class Manager {
public Integer managerid;
public String managername;
public String managerpassword; public void login() {}
public void generatepayroll() {}
public void viewpayroll() {}
public void viewemployeedetails() {}
public void Loginsucess() {}
public void LoginSucess() {}
public void LoginSuccess() {}
public void Success() {}
public void Loginsuccess() {}
public void Displayemployeedetails() {}
}
Class Name: Payment

import java.util.*;
public Integer paymentid;
public String date;
public Integer basicpay;
public Integer HRA;
public Integer DA;
public Integer PF;
public Integer Netpay;
public Integer Grosspay;
public void CalculateSalary() {}
public void GenerateSlip() {}
}
EX.NO:9 TEST SOFTWARE SYSTEM FOR ALLSYSTEM AS
DATE: PER USE CASE
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network or
object to test its strength or to analyze overall response time under different load types. JMeter
simulates a group of users sending requests to a target server, and returns statistics that show the
performance and functionality of the target server via tables, graph, etc.
Apache JMeter is open source software, a 100% pure Java desktop application, designed to
load test functional behavior and measure performance of web sites. It was originally designed
for load testing web applications but has since expanded to other test functions.
• Web services - SOAP / XML-RPC.
• Directory - LDAP.
• Service - POP3, IMAP, SMTP.
• FTP services.
JMeter Features:
•JMeter can conduct load and performance test for many different server types.
•JMeter stores its test plans in XML format.
To sum up, JMeter allows you to swarm a web application without thousand virtual
users and measure its performance at the same time.
Class Name: Employee
import java.util.*;
public class Employee {
public String empname;
public String emppassword;
public String date;
public Integer hoursworked;
public void login() {}
public String viewsalary(String id,Stringamt) {
return("a");
}
public void LoginSuccess(){}
}
POSITIVE_OUTPUT
NEGATIVE_OUTPUT
EX.NO:10 IMPROVE REUSABILITY AND MAINTAINABILITY BY
DATE:
factories, since it uses only the generic interfaces of their products. Abstract products
describe interface for every different products of a single product family. Concrete products
implement the abstract product interface which is returned by creational methods of concrete
factories. Abstract factory defines the interface for creating products which is common to all
concrete factories. Concrete factories implement creational methods of the abstract factory
and each concrete factory should correspond to a specific products variant as shown in
Figure.
Figure : 10.1 Design Pattern - Abstract Factory

Purpose of abstract factory design pattern is to provide an interface for creating families of
related objects without specifying concrete classes. The following Figure( )shows the
example of abstract factory design pattern for user login where two concrete factory and
Figure : 10.2 Abstract Factory Design Pattern for User Login

Using proposed method design pattern asses where requirement is well
documented and fixed which is used as input. As step 1 firstly identify the design problem
using alternative design solutions from literature and experience, and solve using abstract
factory design pattern. In step 2 maintainability, reusability, understandability, flexibility,
composability, completeness, stability, simplicity, and expandability are selected as design
objective. Using step 3 appropriate solution is selected as step 4 (tool) and step 5
(mathematical formation). In step 4 maintainability, reusability, understandability, and
flexibility are calculated using parecons design pattern advisor tool. In step 5 composability,
completeness, stability, simplicity, and expandability are measured using mathematical
formation. In step 6, combine step 4 and 5 output to get required quality product. Assessment
of these nine quality attributes are discussed as:
MAINTAINABILITY:
Use of a design pattern essentially complicates design to usually add abstract
classes and additional associations to employ a design pattern. The key advantage of using
design pattern is that the resulting software should be easier to adapt, to modify fewer classes,
to add functionality to software. So, maintenance Client Abstract Factory +doAction1:void
+doAction2:void AbstractProduct+doAction:voidAbstractFactory concreteProduct1
concreteProduct1 +doAction:void concreteFactory2 concreteProduct1: Admin
concreteProduct2: User concreteProduct2 +doAction:void 95 programmers should have to use
less effort to adapt these changes. Every introduced pattern caused an improvement in different
quality attributes.
REUSABILITY:
architecture. Design patterns detain static and dynamic structure and collaborations of
components in successful solutions to problems that occur when developing software like
business data processing, databases, graphical user interfaces, telecommunications, and
distributed communication software. Patterns 96 help development of reusable components
and frameworks by using structure and collaboration of participants in software architecture
at a level higher than source code and object oriented designmodels that focus on individual
objects and classes. Thus, patterns facilitate reuse of software architecture, even when
additional forms of reuse are infeasible. An empirical investigation on reusability of design
patterns and software packages, attempts to empirically investigate reusability of design
patterns, classes, and software packages to identify the most beneficial starting points for
CONCLUSION:
The Software Personnel Management System can help to manage the automation of
salary information based on how well an employee has worked during the business operation.
The system is designed to reduce the human labor and efficiently maintains the generation of
salary slip. The system maintains information on the employee in the company in order to
calculate the payroll. The system generates record and performance report of the employees.
E-BOOK
MANAGEMENT
SYSTEM
1
Ex.No:1 Problem statement

Date:
Aim:
To develop the problem Statement for e-book management. Problem
statement:
E-book management is a well organised web application for reaching and downloading books.
The readers can select the book from various genres we can also add filters like the title of the
book, name of the author and the publications in search engine. The reader has two options where
some of the books are free to download and the rest have to be paid to download it. In case of
downloading it for a cost the mode of payment is through online. While selecting a book to read
or download they have a choice of reading the sample pages. The reader has option to view all the
comments and rating of the book selected and he can leave his own ratings and comment
3
Table of Contents
Table of Contents ............................................................................................................................ 3
Revision History .............................................................................................................................. 4
1. Introduction................................................................................................................................. 5
1.1 Purpose ................................................................................................................................... 5
1.2 Document Conventions .......................................................................................................... 5
1.3 Intended Audience and Reading Suggestions ........................................................................ 5
1.4 Product Scope......................................................................................................................... 5
1.5 References .............................................................................................................................. 5
2. Overall Description ..................................................................................................................... 6
2.1 Product Perspective ................................................................................................................ 6
2.2 Product Functions................................................................................................................... 6
2.3 User Classes and Characteristics ............................................................................................ 6
2.4 Operating Environment .......................................................................................................... 6
2.5 Design and Implementation Constraints ................................................................................ 6
2.6 User Documentation ............................................................................................................3
...................................................................................................................................................... 7
2.7 Assumptions and Dependencies ............................................................................................. 7
3. External Interface Requirements .............................................................................................. 7
3.1 User Interfaces ....................................................................................................................... 7
3.2 Hardware Interfaces .............................................................................................................4

3.3 Software Interfaces ..............................................................................................................4
3.4 Communications Interfaces .................................................................................................4
4. System Features .......................................................................................................................8
5.1 Performance Requirements ..................................................................................................5
5.2 Safety Requirements ............................................................................................................9
5.3 Security Requirements .........................................................................................................9
4
5.4 Software Quality Attributes .................................................................................................9

Revision History
5
1. Introduction
1.1 Purpose
The purpose of Software Requirement Specification document for E-Book Management is to
define and describe all the functional and non-functional requirements. It gives a detailed
process description of the system.This document describes the hardware andsoftware interface
requirements using ER diagram and UML diagram.

CONVENTIONS FONT FACE FONT SIZE
1 Headings Times New Roman 18
2 Sub Headings Times New Roman 14
3 Content Times New Roman 12

The document is used as reference by the developers,project managers,marketing staffs,
readers. Project testers can use this document as a reference for testing purposes. By this way
testing and finding errors becomes easier. Readers use this document to get the clear idea about
what the project is.
1.4 Product Scope

The software provides benefits like reading sample pages,using filters in search-engine,free
download of books.The objective is to reduce the reader’s time for searching books. The
readers receive immediate notification of the books available time to time.
1.5 References
IEEE Software Requirement Specification Format.
Book: Software Requirements and Estimation by Kishore & Naik Publisher:
Tata McGraw-Hill Education First published on:01-jan-2001.
Book: Software Engineering Development by Pankaj Jalote
Publisher: Wiley India Pvt Ltd
Publish Date: 1-07-2010
6
The product is independently developed. It creates a platform for communication between the
e-book administrator and readers. It saves readers time for searching and reading books rather
than doing complex works like searching books manually in library

The reader can read the sample pages first.
Reader has the option of searching books in the search engine using filters.
Reader can leave their own commands and ratings.
Pop up of immediate notification of the newly available books.

E-book management system consists of the following use case
Login:
Enter username and password.
Search books:
Search book based on your need .
Payment:
Pay for books in various methods.
Downloads:
Download the soft copies of the books.
Rating column
Rate the book out of 5 based on your opinion.

Operating environment is windows 7 for 32bit/x86&64-bit/x64 pc
The program are based on GUI
Java for coding purpose
The product can run on any browser

The system is developed using java.
The database is accessed using MS.
7
The system should be reader friendly so that it is easy for the reader to use and also it
should have backup capabilities.
There will be only one ADMIN who has all rights with regards to managing
information such as updating, deleting, inserting the detail of books.

This document is useful for the reader and administrator
Reader:
The reader should be familiar with internet
They should have basic computer knowledge
They are the people who desire to obtain the books and submit the information to the
database
Administrator:
Administrator has certain privileges to add the books and to approve the reservation of
books.
They can give all the relevant documents to the readers reference

The readers should have sufficient computer knowledge.
The administrators should have more knowledge of the internals of the system and is
able to rectify the small problems that may arise due to disk crashes, power failures
and other to maintain the system.

3.1 User Interfaces
The system provides a Graphical User Interface for the front end of the database.
System administrators.
Reader.
System Administrators
The administrator log on to the system by entering his/her name or id and
password.Administrator can do editing such as adding ,deleting a new user similarly adding,
editing,deleting a new item.
8
Readers
Readers are the one who are reading or downloading books.
9
The readers should have to enter the user name and password and click the 'Login'
button .Ifreader makes any mistake the system will ask for correct username and
password until he enters the correct one.

The system should have these hardware requirements:
Screen resolution of atleast 640*480 or above.
Support for printer(doc matrix, deskjet, laserjet).
Computer System will be in the networked environment since it is a multi user
system.

System should interact with the system database to record all transaction data. The
system requires the support of the following softwares for the databases and other
requirements
MS-Windows operating system.
Microsoft visual Basic 6.0 for designing front end.
Ms SQL server 2000 for backend.
Platform: Java language
It is a global data area and it is also multitasking.

As it is a web based application, there are protocols that are needed to directly interact with the
users. It is developed using TCP/IP protocol.
4. System Features
Organize e-book collection using covers, titles, tags, author, publisher.
Advanced e-book search and sorting.
Create custom bookshelves.
Full screen mode.
Printing support.
Adding bookmark such as tags and comments.

The performance of the system is based on the reliability when the system is under load.
10
It is important that sustainable number of customer login to the website at the same
time, the system should not slow down.
No interrupts during downloading of books.
The time for searching a book will not be more than 3 seconds.
The response time for menu changes will not be more than 3 seconds.
The time taken to update the database or to get information from the database will not
be more than 2 seconds

User can use password for their safety purpose. They can create their own User ID.
The system is only accessible to authenticated reader
The main security concern is for readers account hence proper login mechanisms should
be used to avoid hacking.

Personal information of the readers should be protected.
Information transmission should be securely transmitted to administrator without any
changes in information.
If the database of the system get crashed, it is necessary have backup databases.

Reliability: The system is thoroughly tested at the time of selecting the books so
thatmismatched book errors are minimized.
Maintainability: For easy maintainance of the system the user manual and system
manual is provided to the readers.Each module is designed independently so that at any
change of request can be modified easily.
Security: Only the administrators have the authority to edit details in user and item
tables. No one can enter the system without a username and a password. Normal system
users cannot access the Administrators login. All deleting actions are notified by a
message box asking to confirm deletion..
Requirements needed in the expansion of the system.
Changes in the upcoming technologies.
Future aspects of the projects.
Backup: There should be an easy backup feature for entire data.
11
GUI : Graphical User Interface is a form of user interface that allows user to interact with
graphical icons.
Functional Requirements: These are the functionalities provided by the software which
are defined by the users to the developer.
Non-functional Requirements: These are additional functionalities which are not

ordered by the uses and are qualities of a system.
13
Ex.No:3 Identify use cases and develop use case model

Date:
Use case diagram:

shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
System
Use Case
Actors
14
Relationships Brief:
Illustrate relationships between an actor and a use case with a simple line. For relation ships
Usecase diagram:
Use case format:

Search books:
15
The reader can search books in the search engine with the help of the filters present like giving the
author of the book, publications.
He/she can search for any kind of book in any language. There is also an option of related
books based on our recent searches.So it is aeasy way of selecting books to read.While
searching a book various choices pop up in the list of books.
Casual:
The books are the to be searched through the search engine in means of typing the book name we
have plenty of options in the list of books. We can select the books which we need.
Alternate scenario:
If we don’t know the book namewe can search the books by giving the other details and the
author of the book. Publications or based on the genre of the book we can search the books
which we need.
Fully dressed:
Search Books
Use Case Name
Goal Searching books in Search engine
Level Search needed books
Primary Actor Reader
Stake holder Readers
Precondition 1) Search the books by legal author name

book name or publisher name
2)All books should be available at any
time
Success Scenario 1)Place cursor in search engine
2)Type the name of author, name of book to
download
3)Specified book will be displayed
16
Failure Scenario 1)Invalid author name or book name

2)book not found
Extension 1)Proper spelling for author name and book

name
2)Should follow the instruction displaying
in monitor
Special requirement 1)Books should be available at any time

2)provide security
Secondary Actor System Administrator
Use case format:

Download book:
Brief:
User can download the book the book based on the book specification download method (i.e.
Either free or for cost). User can download the book by paying money using credit and debit
card. User should follow the proper instructions for downloading users can read the
downloaded book until the user deletes their account.
Casual:
For downloading books the payment should be made using the cards. If the payment is
successful then the user receives the message. If the payment is not successful the payment is
failed message will reported.
Alternate scenario:
In case of interrupt while downloading the reader should retransfer the amount.
Fully Dressed Format:
Use case name Download book to read
Goal To read a book
Level Downloading book

Primary actor Reader
Stake holder Reader, bank

17
Precondition 1)for payment, card should be recognized

2)pin should be valid
Success scenario 1)download the book either for free or by
payment
2)in case of payment select the transaction
mode
3)make transaction
4)close the system
Failure scenario 1)invalid pin number for card

2)reader's account does not have money
3)unavailability of network for free
downloading
Extension 1)proper account maintenance

2)should follow the instruction displaying in
monitor
Special requirement Authentication during downloading the

book
Secondary actor Bank
Use case format:

Update:
Brief:
After downloading the book, the system administrator has to make a change that is system
administrator should update the systemif new books are available then admin should add that
book into the system. If the continuation of the particular book is published as a part then admin
update that book. If particular book is no longer viewed (or) downloaded, admin can remove
it. Admin can remove the book if the edition is too old. Admin should maintain these changes
properly.
Casual:
For maintaining changes, if admin not update the books properly then readers cannot download
the books. If the currently trending books are not added then it is not possible to download that
books. If admin maintain the changes properly it is easy to download (or) read the books.
Alternate scenario:
18
Some books are not available means admin should add that books into the system and maintain the
changes properly.
Fully Dressed Format:
Use Case Name Update changes in e book system
Goal Maintain the changes properly
Level Add, update, remove books
Primary Actor System Administrator

Stake Holder System admin, Reader
Precondition System should be proper condition

1)Admin's login should be valid
2)Make a change
3)logout from the system
Success Scenario 1)Add books if any books are new

2)Remove if edition is too old
3)Update the system after reader's
downloading
4)Logout from the system
Failure Scenario 1)Invalid password or username for Admin

2)Changes are not proper
Extension 1)proper maintenance
2)Aware of newly arrival books
Special Requirement Provide more authentication for system
admin login
Secondary Actor Readers

19
Ex.No:4 Identify conceptual classes and develop the domain model

Date: with UML class diagram
Class diagram:
Class diagram is a static diagram. It represents the static view of an application. Class diagram
systems because they are the only UML diagrams, which can be mapped directly with
objectoriented languages.

Analysis and design of the static view of an application.
Describe responsibilities of a system.
Base for component and deployment diagrams.
Forward and reverse engineering.
Members:
Visibility:
+ Public
- Private
# Protected
~ Package
20
Derived property:
Scope:
Classifier members are commonly recognized as “static” in many programming languages.

o Attribute values are equal for all instances o Method invocation
does not affect the classifer’s state Instance members are scoped to a
specific instance.
o Attribute values may vary between instances o Method
invocation may affect the instance’s state (i.e. change instance’s

attributes)
Relationships
Class Notation:
The top section is used to name the class.
The second one is used to show the attributes of the class.
21
The third section is used to describe the operations performed by the class.
The fourth section is optional to show any additional components.
Object Notation:
22
Domain model:
23
Class diagram:
The class diagram consists of eight classes namely, students, reader, downloadbooks,
otherusers, searchbooks, admin, transaction, cart. The associations between the classes are as
follows:
One reader can search many books at the time
For searching book, we have to upload the book into portal
One reader can download many books
Bank sends the acknowledgment to the readers regarding payment
Admin can update the portal
One reader can add many books to the cart
Ex.No:5
24
Date: Using identified scenarios find interaction between objects

and represent them using UML sequence diagram
SequenceDiagram:

system and its objects. It is important to note here that an actor is always outside the
scope of the system we aim to model using the UML diagram.

25

in UML for naming a lifeline follows the following format – Instance Name : Class
Name
Figure: lifeline
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
model an unnamed instance, we follow the same pattern except now the portion of
the system whereas actors are used to depict objects external to the system.
The following is an example of a sequence diagram:
Figure: a sequence diagram

26
Figure: a sequence diagram with different types of messages

receiver has processed the previous message i.e. it receives a reply message. A
large number of calls in object oriented programming are synchronous. We use
a solid arrow head to represent a synchronous message.
Figure: a sequence diagram using a synchronous message

processing the previous message or not. We use a lined arrow head to represent
an asynchronous message.
27

labelled on it to specify that it is the create Message symbol. For example – The
creation of a new order on a e-commerce website would require a new object of
Order class to be created.
Figure: a situation where create message is used

• Delete Message: We use a Delete Message to delete an object. When an object is deallocated
occurrence of the object in the system.It is represented by an arrow terminating with a x.
For example: In the scenario below when the order is received by the user, the objectof order
Figure: a scenario where delete message is used

28
Figure: self message

For example: Consider a scenario where the device wants to access its webcam. Such a
Figure: a scenario where a self message is used

Figure: reply message

For example: Consider the scenario where the device requests a photo from the user. Here the
29
Figure: a scenario where a reply message is used

Figure: found message

30
Figure: a scenario where found message is used

Figure: lost message

interracting with. Since the destination is not known before hand, we use the Lost
Message symbol.
31

• Used to model and visualise the logic behind a sophisticated function, operation or procedure.
32
Sequence diagram:
The reader logins to the portal by entering a valid password. The system admin verifies the
password and sends password is ok if it isvalid otherwise try again. Then the reader can request
the portal to search the books. The books status is displayed by the portal. The reader can also
download the books by paying the amount, the payment is made by the reader. Reader request
the bank for transaction. After transaction is confirmed the download of the book is completed
and displayed.
33
Ex.No:6 Using the identified scenarios, find the interaction between

Objects and represent them using UML communication
Date: diagram
(UML). These diagrams can be used to portray the dynamic behavior of a particular use case
1. Objects: Objects are shown as rectangles with naming labels inside. The naming label follows
2. Actors: Actors are instances that invoke the interaction in the diagram. Each actor has a name
3. Links: Links connect objects with actors and are depicted using a solid line between two
4. Messages: Messages between objects are shown as a labeled arrow placed near a link. These
between.
34
35
Ex.No:7 Draw relevant state charts and activity diagrams

Date:
Activity diagram:
for:
36
Activity diagram:
This activity diagram consists of four swimlanes namely, reader, portal, system admin, bank.
The initial process is the login done by the reader. The parallel behaviours such as branch and
merge operations are used for password validation purposes. The structural behaviours such as
fork and join operations are used for checking the availability of books. The final process is
the logout done by the reader.
37
State Machine Diagram:

diagram) is a behavior which specifies the sequence of states an entity (or object) visits
during its lifetime in response to events, together with its responses to those events.
Key concepts:
State
A state is a condition during the life of an object during which it satisfies some condition, performs
some activity, or waits for some external event.
• State transitions connecting the states Example:

38
State chart diagram:

39

Date:
Class name: admin

public class admin {
public string adminid;
public string pw;
public Vector *;
public void update() {

}
}
Class name: cart import
java.util.Vector;
public class cart extends reader {
public string bname;
public integer bprice;
public integer totb;
public Vector 1;
public void add() {

}
40
public void update() {

}
public void remove() {

}
}
Class name: download books import
java.util.Vector;
public class downloadbooks {
public integer price;
public integer noofbooks;
public date date;
public Vector 1;
public void download() {

}
}
Class name: otherusers public class
otherusers extends reader {
}
Class name: reader import
java.util.Vector;
public class reader extends faculty, faculty { public string id;

41
public string name;
public string phno;
public Vector *;
Vector 1; public Vector
myfaculty; public Vector
*;
public void rdetails() {

}
}
Class name: searchbooks import
java.util.Vector;
public class searchbooks {
public string author;
public string pub;
public string lan;
public Vector 1;
public Vector 1;
public void search() {

}
42
}
Class name: students public class
students extends reader {
public void newOperation() {

}
}
Class name: transaction import
java.util.Vector;
public class transaction {
public char transid;
public integer amount;
public integer accno;
public Vector 1;
public void payment() {

}
Ex.No:9
43
Date: Test the software system for all the scenarios identified as
per the usecase diagram.
Class name: reader import

java. util. Vector; public class
admin{ public String adminid(
public String pw; public String
update(String in){ if(in.
equals("ishu")) return true; else
return false;
}
}
Test the software system for all the scenarios identified as per the usecase diagram
44
45
Ex.No:10
46
Date: Improve the reusability and maintainability of the software

system by applying appropriate design patterns
Figure : design pattern - abstract factory

of related objects without specifying concrete classes. The following Figure( ) shows the example
47
of abstract factory design pattern for user login where two concrete factory and concrete product
used for execution.

fixed which is used as input. As step 1 firstly identify the design problem using alternative
In step 2 maintainability, reusability, understandability, flexibility, composability,
parecon’s design pattern advisor tool. In step 5 composability, completeness, stability,
are discussed as:
Maintainability:
additional associations to employ a design pattern. The key advantage of using design pattern
is that the resulting software should be easier to adapt, to modify fewer classes, to add
functionality to software. So, maintenance Client
abstractfactory+doaction1:void+doaction2:void abstractproduct+doaction:voidabstractfactory
48
concreteproduct1 concreteproduct2 concretefactory1 concreteproduct1: Admin

concreteproduct2: User concreteproduct1 +doaction:voidconcretefactory2 concreteproduct1:
Admin concreteproduct2: User concreteproduct2+doaction:void 95 programmers should have
to use less effort to adapt these changes. Every introduced pattern caused an improvement in
different quality attributes.
Reusability:
Design patterns are reusable micro architectures that add to overall software architecture.
Design patterns detain static and dynamic structure and collaborations of components in
successful solutions to problems that occur when developing software like business data
communication software. Patterns 96 help development of reusable components and
level higher than source code and object oriented design models that focus on individual objects
of reuse are infeasible. An empirical investigation on reusability of design patterns and
software packages, attempts to empirically investigate reusability of design patterns, classes,
and software packages to identify the most beneficial starting points for white box reuse, which
is pretty popular among OSS.
Conclusion:
49
The e-book management system can help to read or download books. The system is designed
to reduce the time by searching books in library. The main advantage of the system is, the e-
books can download and stored for later use. The e-book management system is user friendly.
E-book can be updated any time. Including interactive features in system makes the reading
experience a more engaging one.
RECRUITMENT
SYSTEM
1
Expno:1
Date:
ProblemStatement
Aim:
Todeveloptheproblemstatement.
Problemstatement:
Therecruitmentsystemallowsthejobseekerstoviewthejobopportunitythrough
advertisementandhelpstoapplyforthejob.Theorganisationshortlistthe
applicationfortheinterview.Theshortlistedapplicationundergoaprocessoftest
andinterview.TheHRselectstheapplicantbasedontheperformance.Finallythe
reducesthetimeconsumptionforthejobseekerandorganisation.Thecandidate
mustentertheirpersonal,educationalqualificationandexperienceddetails(ifany) whileapplying.
Copyright©B.Janani,R.Jeevadharshini,K.Jothikadevi
8
R.JEEVADHARSHINI
K.JOTHIKADEVI
1.Introduction
1.1 Purpose
Thisdocumentisbasedfortherecruitmentsystem.Themainpurposeofthisdocument
istoexplaintheprocesswhichtakesplaceintheselectionofcandidatesforaninterview.
TheSRSdocumentconsistsofallnecessaryrequirementsforprojectdevelopment.It
provideseasyunderstandingfordeveloperstobuildupthesoftware.
1.2DocumentConventions
ThisdocumentfollowsIEEEformattingrequirements.
Category Font Size
Title TimesNewRoman 18
Subtitle TimesNewRoman 14
9
Text TimesNewRoman 12
1.3IntendedAudienceandReadingSuggestions
Thedifferenttypesofreadersthedocumentisintendedforsuchassoftware
developers,projectmanagers,users,testercandidateswhoareapplyingforthe
jobanddocumentationwriter.Thesequentialorderofthisdocumentfor
recruitmentsystemisintroductionabouttheprojectoveralldescriptionincludes
perspectiveandfunctionsofthesystem.Thisisfollowedbyusecaseand
characteristicsofthesystemsoftwareandthendesignandimplementationand
alsoabouttheinterfaces,systemfeaturesandfinallyotherallrequirements
neededforthissoftwaredevelopment.
1.4 ProductScope
Thissoftwaredevelopmentisabouttherecruitmentsystem.Toanalyzetheknowledge
andtoobtainthebestcandidatefororganizationandthecandidatewereselectedby
interviewsorbyonlinetestanditalsocoverscorporateoffices,sites.Thescopeof
recruitmentandselectionisverywideanditconsistsofvarietyofoperations.
Everycompanyhasitsownpatternofrecruitmentaspertheirrecruitment policiesandprocedures.
Themajorscopeofrecruitmentandselectionincludesfollowingoperations.
Dealingwiththeexcessorshortageofresources.
Analyzingtherecruitmentpolicies,processesandproceduresofthe organization.
Identifyingtheareaswheretherecouldbeascopeofimprovement.
1.5 References
10
https://www.ieee.org/conferences/publishing/templates.html
ObjectOrientedSoftwareConstruction(Secondedition)byBertrand Meyer.
Softwarerequirement(Secondedition)byKarlE.Wieger.
2.OverallDescription
2.1ProductPerspective
Theoriginoftheproductbeingspecifiedinthissoftwarerequirement
specificationisanewselfcontainedproduct.Theproductisnotacomponentof
anysystem.Thesystemisanopensourceandwebbasedmodelandprovides
aninterfacebetweentheHRandthecandidate.
2.2ProductFunctions
TheHRandcandidatesplaysamajorroleinthissoftwaredevelopment.
Thecandidatesshouldsubmittheirinformationdetailsforverification.
Verificationofthecandidatelisthasbeendone.
Theselectedcandidateshouldbecallfortheinterview.
HRinterviewedtheselectedcandidate.
Finallytheresultswereannounced.
Thisrecruitmentsystemwouldbeabletosearchforeligiblecandidates
andcompanywithrespecttotheirspecificationandrequirements.
Theeligiblecandidatewouldreceiveanemailincludingthedetailsof
companyrecruitmentprocedureanddetails.
2.3UserClassesandCharacteristics Candidate:
Newcandidateneedtosignupgivingcompletedetails.
11
Theycansubmitresumeandupdateprofileinformation.
Theycanregisterforaparticularcompany.
Administrator:
Adminprovidesapprovaltothecandidateandthecorporateregistration.
Adminisresponsibleformaintainingandupdatingthewholesystems.
Adminhasaresponsibilitytonotifythecompanyforanyapplicationfroma candidate.
Adminhastonotifythecandidatesregardinganychangesinthe procedureorselection.
Company:
Thecompanyhastonotifytheadminifanychangeintheirrecruitment method.
Thecompanymayshortlistthecandidateswhoappliedsendthe notificationtotheadmin
2.4OperatingEnvironment
Operatingsystem isWindows732-bit/x86and64-bit/x64PC architectures.

Theprogramsarebasedongraphicaluserinterface.
Thesoftwareisplatformindependent.
MSAccessfordatabase. Javaforcodingpurpose.
2.5DesignandImplementationConstraints
Arecruitmentplanisastrategydesignedtostreamlinethehiringprocessesand
actasaguidelineforsourcing,qualifyingandinterviewingjobseekers.Itactsas
atimelineofeventsandactionstofindqualifiedapplicantswhileminimizing
12
downtimeforthecompany.TheproductisdevelopedusingHTMLandthe
backendisdevelopedusingSQL.Theproductisprovidedwithaloginfacilityso
thateachcandidatecanviewtheirdetails.Theinformationofallcandidatesmust
bestoredinadatabasewhichisconnectedtotheparticularcompanysystem
runningall24hrsaday.Thecandidateshouldhavetheircorrectusernameand
passwordtoentertherecruitmentsystem.
2.6Userdocumentation
Userdocumentationcomponentssuchasusermanualson-linehelpare
providedinthesystem.Asimplehowitworkspagewillbeincludedinpackage
staticpageformat.Theuserdocumentationreferstothedocumentationfora
productorserviceprovidedtotheendusers.Theuserdocumentationis
designedtoassistenduserstousetheproductorservice.Thisisoftenreferto
asuserassistants.Theuserdocumentationisthepartoftheoverallproduct
delivertothecustomer.Userdocumentationisimportantbecauseitprovidesa avenueforusestolearn:
1.howtouseyoursoftware
2.featuresofyoursoftware
3.Tipsandtricksofyoursoftware
4.Howtoresolvecommonproblemswithyoursoftware
Withoutuserdocumentationtheusermaynotknowhowtodotheabovethings.
2.7 AssumptionandDependencies
Weareassumingthattheusershouldhavesomebasicknowledgeof computer.
Candidatescanbefromanyfields.
Externalfactors:
13
Externalfactorsincludesocioeconomyfactors,supplyanddemandfactors, employmentrate,
labormarketcondition,marketcompetition,informationsystem.
Internalfactors:
Internalfactorsincludecompanypay’spackage,worktype,organization culture,carrierplanning
company’ssize,company’sproduct,company’s growthrate,costofrecruitment.
14
3.ExternalInterfaceRequirements
3.1UserInterfaces
Inuserinterfacetheuserusesittocreatetheirsignupaccount.Thecandidates
aresupposedtouploadtheirresumeinthispage.Incaseanyvacanciesinany
notificationwillbesendtotheadministrator.
3.2HardwareInterfaces
Theusercancommunicatethroughbrowserusingkeyboardanddisplaythrough
graphicalinterfacedisplayedonuser’sscreen.
3.3SoftwareInterfaces
Softwareinterfacesincludesthelanguagesthatareusedtocommunicatewith
eachother.Inthisrecruitmentmanagementsystemincludesoperatingsystem,
MacOS.Thefirewallwillbeusedtoprotectunauthorizedusertosignuporlogin tothesystem.
3.4CommunicationsInterfaces
Communicationinterfacesisusuallydesignedtocommunicateonemachinewith
anothermachine.Intherecruitmentmanagementsystemitisconnectedto
WorldWideWebforcommunicationinterface.Therequirementsassociatedwith
anycommunicationsfunctionsrequiredbythissystemincludingemail,web
browser,networkservercommunicationprotocol,electronicformsandsoon.
CommunicationstandardthatwillbeusedsuchaswwworHTTP.
4.SystemFeatures
Itprovidessearchingfeaturesbasedonvariouscompaniesvisitingthe campusforrecruitment.
Oncampusselectionprocessalsomanageonlinedetailsofcollege
15
students,companieswhicharevisitingthecolleges
Itmanagestheinformationofthecandidate.
Itshowstheinformationanddescriptionofthecompany.
Itincludesaddingandupdatingofrecordswhichresultsinproperresource management.
Thesystemshouldstorealltheinformationaboutthecandidateandthe organization.
Thesystemshouldallowadministratoroverfullauthorityofthesystem.
Thesystemshouldallowproviding,feedbackaboutthesystem.
5.OtherNonfunctionalRequirements
5.1PerformanceRequirements
Theperformanceofthissystemisbasedonreliabilitywhenthesystemisunder
load.Itisimportantthatasustainablenumberofcandidatesbeabletoaccess
thewebsites.Atleastmorethan100candidatesshouldbeabletologintothe websitesatthetime.
5.2SafetyRequirements
Varioussafetymeasuresaredevelopedinthissystemtomaintainthepersonal
detailsofthecandidates.
5.3SecurityRequirements
Anyonewhomeetsourbasicapplicationrequirementsisencouragedtoapply.
Securityofficertrainingisdeliveredthrougheffectiveonthejobtrainingand
monitoring.Itshouldbemadesurethatonlycandidatewhoisgivenspecific
rightscanaccessdataandallactionarelogged,thusprovidingandextensive
rolearebasedauthorization.
5.4Softwarequalityattributes
-Availability:
16
ThesoftwarewillbeavailableonlytoauthorizecandidatesoftheindustrylikeHR
touploadthecandidatedetails,candidatestoviewtheirdetailsuploaded.
-Maintainability:
Candidateinformationstoredinthedatabasewasmaintainedwithoutany backups.
-Portability:
ThissystemisdevelopedusingMYSQLsoitisplatformindependentandis
independentofoperatingsystem.
6.Appendix:Glossary
Candidate
Thecandidateisanactorwhoappliedforthejobvacancy.Ifhe/she
selectedthenhrdepartmentsendstheinterviewcallletter.
HR
HRisanactorwhoinformsaboutthevacancyoftheorganization.HR recruitsthecandidates
basedontherequiredskillsforthevacantpositionandshortlistthem. Organization
Organizationisanactorwhoannouncedtheadvertisementforthe vacancy.
HTTP
HyperTextTransferProtocolisagenericandstatelessprotocolwhichcan
beusedforotherpurposesaswellusingextensionsofitsrequestmethods,
errorcodesandheaders.
17
HTML
HypertextMarkupLanguageisamarkuplanguageusedforcreatinga webpage.
MYSQL
MYSQLisfreeandopensourcesoftwareunderthetermsoftheGNUand
isalsoavailableunderavarietyofproprietarylicenses.
Platformindependent
Platformindependencemeansthatthesameprogramworksonany
platform(operatingsystems)withoutneedinganymodification.
Hiringprocess
Hiringprocessistheprocessofreviewingapplications,selectingtheright
candidatestointerview,testingcandidates,choosingbetweencandidates
tomakethehiringdecisions.
Authorization
Authorizationisthesecuritymechanismusedtodetermineuser/client
privilegesoraccesslevelsrelatedtosystemresourcesincludingcomputer
programs,files,services,dataandapplicationfeatures.
18
Expno:3
Date:
Identifyusecasesanddevelopusecasemodel
Usecasediagram:
A usecasediagram atitssimplestisarepresentationofauser'sinteractionwith
thesystemthatshowstherelationshipbetweentheuserandthedifferent use cases
inwhichtheuserisinvolved.Ausecasediagramcanidentifythedifferent
typesofusersofasystemandthedifferentusecasesandwilloftenbe
accompaniedbyothertypesofdiagramsaswell.Theusecasesarerepresented
byeithercirclesorellipses.
PurposeofUseCaseDiagrams
Thepurposeofusecasediagramistocapturethedynamicaspectofasystem.
However,thisdefinitionistoogenerictodescribethepurpose,asotherfour
diagrams(activity,sequence,collaboration,andStatechart)alsohavethesame purpose.
BasicUseCaseDiagramSymbolsandNotations
System
Drawyoursystem'sboundariesusingarectanglethatcontainsusecases.Place
actorsoutsidethesystem'sboundaries.
UseCase:
Drawusecasesusingovals.Labeltheovalswithverbsthatrepresentthe system'sfunctions
19
Actors
Actorsaretheusersofasystem.Whenonesystemistheactorofanother
system,labeltheactorsystemwiththeactorstereotype.
Relationships
Illustraterelationshipsbetweenanactorandausecasewithasimpleline.For
relationshipsamongusecases,usearrowslabeledeither"uses"or"extends."A
"uses"relationshipindicatesthatoneusecaseisneededbyanotherinorderto
performatask.An"extends"relationshipindicatesalternativeoptionsundera certainusecase.
UsecaseDiagram:
20
Usecasemodelling:
Verifythecandidateprofile:
Briefformat:
21
Theorganisationannouncedabouttheinterviewintheirwebpage.The
candidatewhoarewishingtoapplyforthisjobmustcreateaprofilewhich
containsthefollowingdetailsofcandidate(i.e)nameofthecandidate
qualification,age,areaofinterestandinwhichdomaintheyareverywellversed
initetcandtheyhavetoregistertheiraccount.Thereforetheprofileisverifiedby
theadminwhetherthegiveninformationordetailsofthegiveninformationor
detailsofthecandidatearetruetotheirknowledge.Thecandidatequalification
shouldbevalidtothisjobwhichareverifiedbytheadminoftheorganisation
.thustheprocessofverificationisdone.
Casualformat:
Profilemanagementcontainsthepersonalinformationandacademicdetailsof
thecandidate.Thefailurescenariooftheverificationprocessincludesthatthe
qualificationofthecandidateshouldbevalidtothejobofferedbythe
organisation.Theacademicdetailsofthecandidatemaybewrongorsomeother
detailsofthecandidatemaybeinvalid.Inthiscaseofinvaliddetailsofthe
candidate,theapplicantmayberejectedduetothisreason.Inordertoavoidthis,
thecandidateshouldgivethecorrectinformationdetailsabouttheirqualification
andpersonalinformation.Bythis,theadminoftheorganisationcanbeableto selecttheapplicant.
Fullydressed:
Usecasename Verifythecandidateprofile
Goal Toverifytheinformationordetailsof
thecandidate.
Level Verificationprocess.
22
Primaryactor Candidate,HR
Stackholders HR,candidate,admin
precondition Theinformationordetailsofthe
candidategivenintheprofileshouldbe true.
Mainsuccessscenario Information about personal and

academicweregivenbythecandidate
andtheirinformationwereverifybythe
adminoftheorganisation.Thegiven
furnishedinformationaretrueand correct.
Secondaryactor Admin
Failurescenario Theinformationgivenbythecandidate
maybewrongorinvalid
Alternativescenario Thecandidateshouldhavemore
concernedandgivetheproperdetails
fortheverification.
Specialrequirement Thecandidateshouldgivetheclear
andprecisedetailabouttheirpersonal
andacademicdetails.
Selectionprocess:
Briefformat:
Theshortlistedapplicantswerecalledforattendingainterview.Theadminofthe
organisationmailedtheinformationdetailsabouttheinterview.Theselectionof
thecandidatemaybetakesplacesbytwoprocess.Theoneisonlinetestandthe
23
otherisattendinginterview.Onlinetestmayreducethetime.
Casualformat:
Theselectionprocessmaybetakesplacebytwomethodsonlinetestand
interview.Itcontainscertaintechnicalandnontechnicalrounds.Itcantakes
moretimeforselectingthecandidate.Itcanbeovercomebytheonlinetest
whichmaybeconductedinthecomputerandthecandidatetakepartitfrom
theirplacesandnoneedtothecompanyanditreducesthetimedelay.
Fullydressed:
Usecasename Selectionofthecandidate.
goal Toselecttheequippedcandidatefor
theirorganisation.
Stackholders HR,candidateandadmin.
Primaryactor HRandthecandidate.
precondition Selectionprocessmaybetakesplace
byeitheronlinetestoraninterview
Mainsuccessscenario The shortlisted candidates were

allowedtoattendtheinterview.The interview
maybe online testor
interview.Onlinetestforthecandidate
reducesthetimedelay.
24
Failurescenario Theselectionofcandidatemaybe
takesplacebyeitheronlinetestor
attendingainterview.Theselection
processcontainsmoretechnicaland
nontechnicalroundtheinterview
methodtakesmoretimeforthe
selectionprocess.
Alternativescenario Onlinetestreducestimeandeasyfor
selectingthecandidate.
level Selectthecandidate
Specialrequirement Morenumberofcandidatescanbe
takepartinsametimetoreducethe
timedelayanditiseasyforthe selectionprocess.
Login:
Briefformat:
Theloginpagecanbeusedbythecandidateandtheadmin.Inloginpage,the
usernameandthepasswordshouldbeusedandthepagewillbeopened
successfully.Moreuserscanusetheloginpageatthesametime.Thislogin
pageisalsousedforauthenticationsothatnootherinvalidusercanusethis information.
Casualformat:
Theloginpagecanusedbymanypeople,thepagehasusernameandpassword.
Incase,thepasswordisincorrectforgetitdisplaysinvalid.Ifthecandidate
forgetsthepasswordwecangiveforgetpasswordandchangethepassword.
Fullydressed:
25
Stakeholders Admin,HRandcandidate.
Precondition Theloginpagemustopen.
Mainsuccessscenario Iftheusernameandpasswordisvalid
itmustbeopen.
Failurescenario Ifthecandidategivesthewrong
usernameorpassword,itdisplays invalid.
Alternativescenario Thecandidateshouldtheusername
andthepasswordcorrectly.
Specialrequirement Providemoreauthentications.
Usecasename Login
Goal Applyforjob.
Level Applyingforjob.
Primaryactor CandidateandHR.
,
26
Expno:4 Identifyconceptualclassesanddevelopthedomain
modelwithUMLclassdiagram
Date:
Classdiagram:
Classdiagramisastaticdiagram.Itrepresentsthestaticviewofanapplication.
Classdiagramisnotonlyusedforvisualizing,describing,anddocumenting
differentaspectsofasystembutalsoforconstructingexecutablecodeofthe softwareapplication.
Classdiagramdescribestheattributesandoperationsofaclassandalsothe
constraintsimposedonthesystem.Theclassdiagramsarewidelyusedinthe
modelingofobjectorientedsystemsbecausetheyaretheonlyUMLdiagrams,
whichcanbemappeddirectlywithobject-orientedlanguages.
Classdiagram showsacollectionofclasses,interfaces,associations,
collaborations,andconstraints.Itisalsoknownasastructuraldiagram.
PurposeofClassDiagrams:
Analysisanddesignofthestaticviewofanapplication.
Describeresponsibilitiesofasystem.
Baseforcomponentanddeploymentdiagrams.
Forwardandreverseengineering.
Members:
UMLprovidesmechanismstorepresentclassmembers,suchasattributesand
methods,andadditionalinformationaboutthem.
Visibility:
Tospecifythevisibilityofaclassmember(i.e.anyattributeormethod),these
notationsmustbeplacedbeforethemember'sname.
+ Public
-Private
# Protected
27
~ Package
Derivedproperty:
Isapropertywhichvalue(orvalues)isproducedorcomputedfromother
information,forexample,byusingvaluesofotherproperties.
Derivedpropertyisshownwithitsnameprecededbyaforwardslash'/'.
Scope:
TheUMLspecifiestwotypesofscopeformembers: instance and classifier,and

thelatterisrepresentedby underlinednames.
• Classifiermembers arecommonlyrecognizedas“static” inmany

programminglanguages.Thescopeistheclassitself.
o Attributevaluesareequalforallinstances o
Methodinvocationdoesnotaffecttheclassifer’sstate Instancemembers
arescopedtoaspecificinstance.
o Attributevaluesmayvarybetweeninstances
o Methodinvocationmayaffecttheinstance’sstate(i.e.change instance’sattributes)
Toindicateaclassifierscopeforamember,itsnamemustbeunderlined.
Otherwise,instancescopeisassumedbydefault.
Relationships
28
ClassNotation:
UML class isrepresentedbythefollowingfigure.Thediagramisdividedinto fourparts.
• Thetopsectionisusedtonametheclass.
• Thesecondoneisusedtoshowtheattributesoftheclass.
• Thethirdsectionisusedtodescribetheoperationsperformedbytheclass.
Thefourthsectionisoptionaltoshowanyadditionalcomponents.
Classesareusedtorepresentobjects.Objectscanbeanythinghaving propertiesandresponsibility.
ObjectNotation:
It isrepresentedinthesamewayastheclass.Theonlydifferenceisthename
whichisunderlinedasshowninthefollowingfigure.
Astheobjectisanactualimplementationofaclass,whichisknownasthe
instanceofaclass.Hence,ithasthesameusageastheclass.
29
Domainmodel:
30
Classdiagram:
TheclassdiagramconsistsofsixclassesnamelyCandidate,Job,Portal,Admin,
HR,Result.Theassociationoftheclassaregivenaccordingtohowtheclasses
areassociatedtootherclasses.(i.e)theassociationarespecifiedwithaname
andthetypeofassociationswhether,onetoone,onetomany,manytooneor manytomany.
Expno:5 Usingidentifiedscenariosfindinteractionbetweenobjects
andrepresentthemusingUMLsequencediagram:
Date:
Sequencediagram:
Asequencediagramsimplydepictsinteractionbetweenobjectsinasequential
orderi.e.theorderinwhichtheseinteractionstakeplace.Wecanalsousethe
31
termseventdiagramsoreventscenariostorefertoasequencediagram.
Sequencediagramsdescribehowandinwhatordertheobjectsinasystem
function.Thesediagramsarewidelyusedbybusinessmenandsoftware
developerstodocumentandunderstandrequirementsfornewandexisting systems.
SequenceDiagramNotations:
1.Actors– AnactorinaUMLdiagramrepresentsatypeofrolewhereitinteracts
withthesystemanditsobjects.Itisimportanttonoteherethatanactorisalways
outsidethescopeofthesystemweaimtomodelusingtheUMLdiagram.
1.Weuseactorstodepictvariousrolesincludinghumanusersandother
externalsubjects.WerepresentanactorinaUMLdiagramusingastick
personnotation.Wecanhavemultipleactorsinasequencediagram. Forexample–
Heretheuserinseatreservationsystemisshownasan
actorwhereitexistsoutsidethesystemandisnotapartofthesystem.
32
Figure– anactorinteractingwithaseatreservationsystem
Lifelines– Alifelineisanamedelementwhichdepictsanindividual
participantinasequencediagram.Sobasicallyeachinstanceinasequence
diagramisrepresentedbyalifeline.Lifelineelementsarelocatedatthetop
inasequencediagram.ThestandardinUMLfornamingalifelinefollowsthe followingformat–
InstanceName:ClassName
33
Figure– lifeline
Wedisplayalifelineinarectanglecalledheadwithitsnameandtype.The
headislocatedontopofaverticaldashedline(referredtoasthestem)as
shownabove.Ifwewanttomodelanunnamedinstance,wefollowthe
samepatternexceptnowtheportionoflifeline’snameisleftblank.
Differencebetweenalifelineandanactor– Alifelinealwaysportraysan
objectinternaltothesystemwhereasactorsareusedtodepictobjects
externaltothesystem.Thefollowingisanexampleofasequencediagram:
Figure– asequencediagram
Messages– Communicationbetweenobjectsisdepictedusingmessages.
Themessagesappearinasequentialorderonthelifeline.Werepresent
messagesusingarrows.Lifelinesandmessagesformthecoreofa sequencediagram.
Messagescanbebroadlyclassifiedintothefollowing categories :
34
Figure– asequencediagramwithdifferenttypesofmessages
1.Synchronousmessages– Asynchronousmessagewaitsforareply
beforetheinteractioncanmoveforward.Thesenderwaitsuntilthereceiver
hascompletedtheprocessingofthemessage.Thecallercontinuesonly
whenitknowsthatthereceiverhasprocessedthepreviousmessagei.e.it
receivesareplymessage.Alargenumberofcallsinobjectoriented
programmingaresynchronous.Weuseasolidarrowheadtorepresenta
synchronousmessage.
Figure– asequencediagramusingasynchronousmessage
2.AsynchronousMessages– Anasynchronousmessagedoesnotwaitfora replyfromthe
receiver.Theinteractionmovesforwardirrespectiveofthe
receiverprocessingthepreviousmessageornot.Weusealinedarrowheadto
representanasynchronousmessage.
35
Createmessage– WeuseaCreatemessagetoinstantiateanewobjectinthe
sequencediagram.Therearesituationswhenaparticularmessagecallrequires
thecreationofanobject.Itisrepresentedwithadottedarrowandcreateword
labelledonittospecifythatitisthecreateMessagesymbol.
Forexample–Thecreationofaneworderonae-commercewebsitewould
requireanewobjectofOrderclasstobecreated.
Figure– asituationwherecreatemessageisused
DeleteMessage– WeuseaDeleteMessagetodeleteanobject.Whenan
objectisdeallocatedmemoryorisdestroyedwithinthesystemweusetheDelete
Messagesymbol.Itdestroystheoccurrenceoftheobjectinthesystem.Itis
representedbyanarrowterminatingwithax.
Forexample–Inthescenariobelowwhentheorderisreceivedbytheuser,the
objectoforderclasscanbedestroyed.
Figure– ascenariowheredeletemessageisused
SelfMessage– Certainscenariosmightarisewheretheobjectneedstosenda
messagetoitself.SuchmessagesarecalledSelfMessagesandarerepresented withaUshapedarrow.
36
Figure– selfmessage
Forexample–Considerascenariowherethedevicewantstoaccessits
webcam.Suchascenarioisrepresentedusingaselfmessage.
Figure– ascenariowhereaselfmessageisused
• ReplyMessage– Replymessagesareusedtoshowthemessagebeing
sentfromthereceivertothesender.Werepresentareturn/replymessage
usinganopenarrowheadwithadottedline.Theinteractionmovesforward
onlywhenareplymessageissentbythereceiver.
37
Figure– replymessage Forexample–

Considerthescenariowherethedevicerequestsaphoto
fromtheuser.Herethemessagewhichshowsthephotobeingsentisa replymessage.
Figure– ascenariowhereareplymessageisused
• FoundMessage– AFoundmessageisusedtorepresentascenariowhere
anunknownsourcesendsthemessage.Itisrepresentedusinganarrow
directedtowardsalifelinefromanendpoint.Forexample:Considerthe
scenarioofahardwarefailure.
38
Figure– foundmessage
Itcanbeduetomultiplereasonsandwearenotcertainastowhatcaused thehardwarefailure.
Figure– lostmessage
Thewarningmightbegeneratedfortheuserorothersoftware/objectthat
thelifelineisinterractingwith.Sincethedestinationisnotknownbefore
hand,weusetheLostMessagesymbol.
39
Guards– TomodelconditionsweuseguardsinUML.Theyareusedwhenwe
needtorestricttheflowofmessagesonthepretextofaconditionbeingmet.
Guardsplayanimportantroleinlettingsoftwaredevelopersknowtheconstraints
attachedtoasystemoraparticularprocess.Forexample:Inordertobeableto
withdrawcash,havingabalancegreaterthanzeroisaconditionthatmustbe metasshownbelow.
Usesofsequencediagrams:
• Usedtomodelandvisualisethelogicbehindasophisticatedfunction, operationorprocedure.
• TheyarealsousedtoshowdetailsofUMLusecasediagrams.
• Usedtounderstandthedetailedfunctionalityofcurrentorfuturesystems.
• Visualisehowmessagesandtasksmovebetweenobjectsorcomponentsin asystem.
SequenceDiagram:
Thecandidateloginstotheportal,sothecandidatemustgivethelogindetailsto the
portal.Theportalverifiesthepasswordandsendstheauthenticationto
thecandidate.Thecandidateappliesthejobtothecompanyandthecompany
conductsonlinetesttotheapplicant.Thecandidateattendstheonlinetestand
thecompanyshortlistedthecandidatebytheonlinetest.Thecompanycallfor
interview.ThecandidateattendstheinterviewtotheHRdirectly.TheHRmails
40
theinterviewdetailstothecompanyandthecompanyupdatetheresultson
portal.Thecandidatescancheckstheresultsontheportal.
41
• Usedtomodelandvisualisethelogicbehindasophisticatedfunction, operationorprocedure.
• Visualisehowmessagesandtasksmovebetweenobjectsorcomponentsin asystem.
Expno:6
42
Date: Usingtheidentifiedscenarios,findtheinteraction
betweenobjectsandrepresentthem usingUML
Collaborationdiagram
Collaborationdiagram:
Acollaborationdiagram,alsoknownasacommunicationdiagram,isan
illustrationoftherelationshipsandinteractionsamong software objects inthe
UnifiedModelingLanguage(UML).Thesediagramscanbeusedtoportraythe
dynamicbehaviorofaparticular usecase anddefinetheroleofeachobject.
Collaborationdiagramsarecreatedbyfirstidentifyingthestructuralelements
requiredtocarryoutthefunctionalityofaninteraction.Amodelisthenbuiltusing
therelationshipsbetweenthoseelements.Severalvendorsoffersoftwarefor
creatingandeditingcollaborationdiagrams.
Notationsofacollaborationdiagram:
A collaborationdiagram resemblesa flowchart thatportraystheroles,

functionalityandbehaviorofindividualobjectsaswellastheoveralloperationof thesystemin
realtime.Thefourmajorcomponentsofacollaborationdiagram are:
1.Objects-Objectsareshownasrectangleswithnaminglabelsinside.The
naminglabelfollowstheconventionofobjectname: classname.Ifanobject
hasapropertyorstatethatspecificallyinfluencesthecollaboration,this shouldalsobenoted.
2.Actors-Actorsareinstancesthatinvoketheinteractioninthediagram.Each
actorhasanameandarole,withoneactorinitiatingtheentireusecase.
3.Links-Linksconnectobjectswithactorsandaredepictedusingasolidline
betweentwoelements.Eachlinkisaninstancewheremessagescanbesent.
4.Messages-Messagesbetweenobjectsareshownasalabeledarrowplaced
nearalink.Thesemessagesarecommunicationsbetweenobjectsthat
conveyinformationabouttheactivityandcanincludethesequencenumber.
Themostimportantobjectsareplacedinthecenterofthediagram,withallother
participatingobjectsbranchingoff.Afterallobjectsareplaced,linksand
messagesshouldbeaddedinbetween.
43
Expno:7
Date:
Drawrelevantstatechartsandactivitydiagrams
Activitydiagram:
Activity diagram describe activities which involve concurrency and
synchronization,whichareavariationofstatediagramsthatfocusesontheflow
ofactionsandevents.Theycanbeusedfor:
• Tomodelahumantask(abusinessprocess,forinstance).
• Todescribeasystemfunctionthatisrepresentedbyausecase.
• Inoperationspecifications,todescribethelogicofanoperation.
44
Activitydiagram:
TheactivitydiagramconsistsofthreeswimlanesnamelyPortal,candidate,HR.
Thecandidateloginstotheportal,sothecandidatemustgivethelogindetailsto
theportal.Theportalverifiesthepasswordandsendstheauthenticationtothe
candidate.Thecandidateappliesthejobtothecompanyandthecompany
conductsonlinetesttotheapplicant.Thecandidateattendstheonlinetestand
thecompanyshortlistedthecandidatebytheonlinetest.Thecompanycallfor
interview.ThecandidateattendstheinterviewtotheHRdirectly.TheHRmails
theinterviewdetailstothecompanyandthecompanyupdatetheresultson
portal.Thecandidatescancheckstheresultsontheportal.
45
StateMachineDiagram:
AstatemachineDiagram(orstartdiagram,alsocalledstatechartofstate
transitiondiagram)isabehavior whichspecifiesthesequence ofstatesan entity(orobject)visits
duringitslifetimeinresponse toevents,togetherwith its responsestothoseevents.
46
Keyconcepts: State
Astateisaconditionduring thelifeofanobjectduring whichitsatisfiessome

condition,performssome activity,orwaitsforsome externalevent.
Astatemachinediagramisagraphconsistingof:
• States(simplestatesorcompositestates)
• Statetransitionsconnectingthestates Example:
InitialandFinalStates:
• The initialstate
ofastatemachinediagram,knownasaninitialpseudostate,isindicatedwithasolidcircle.Atra
nsitionfromthisstatewillshow thefirstrealstate
• The finalstate ofastatemachinediagramisshownasconcentriccircles.
Anopenloopstatemachinerepresentsanobjectthatmayterminate
beforethesystemterminates,whileaclosedloopstatemachinediagram
doesnothaveafinalstate;ifitisthecase,thentheobjectlivesuntilthe
entiresystemterminates.
Statechartdiagram:
47
Expno:8 Implementthesystemasperthedetaildesign
Date:
Classname:Candidate
importjava.util.Vector;
48
publicclassCandidate{
publicStringname;
publicStringemail;
publicintcontact;
publicVectorsearch;
publicVectorselects; publicVectorshortlist;
publicVectorregister;
privatevoiduploadResume(){
publicvoidsearchJob(){
publicvoidapplyJob(){
}
49
publicvoidgetcandidateinformation(){
publicvoidupdatecandidateinformation(){
}
Classname:Admin
publicclassAdmin{
publicStringname;
publicStringemail;
publicVectorshortlist; publicVectorview;
publicHRsenddetails;
publicvoidviewcandidate(){
}
50
publicvoidmanageinterview(){
}
Classname:HR
publicclassHR{
publicStringname;
publicStringemail;
publicVectormyJob;
publicVectorselects; publicVectorcreate;
publicAdminsenddetails; publicVectorannounces;
publicvoidselect(){
publicvoidreject(){
51
}
publicvoidsendresult(){
publicvoidviewnotification(){
Classname:Job
publicclassJob{
publicStringjobname;
publicStringjobDescription; publicVectorsearch;
publicVectormyHR; publicVectorcreate;
publicVectordescribes; publicvoidgetJoblist(){
}
52
publicvoidupdateJoblist(){
Classname:Portal
publicclassPortal{
publicStringname;
publicStringaddress;
publicStringqualification; publicVectorregister;
publicVectordescribes; publicAdminview;
publicvoidgetdetails(){
}
53
publicvoidstore(){
Classname:Result
publicclassResult{
publicStringname;
publicStringemail;
publicVectorannounces; publicvoidviewresult(){
}
Expno:9
54
Date: Testthesoftwaresystemforallthescenariosidentifiedas
pertheusecasediagram.
Packagejjj;
Importjava.util.Vector;
publicclassPortal{ publicStringname;
publicStringaddress;
publicStringqualification;
publicStringgetdetails(Stringin){
if(in.equals(“jo”)) return“true”; else
return“false”;
} Testthesoftwaresystemforallthescenariosidentifiedaspertheusecase diagram:
55
56
Expno:10 Improvereusabilityandmaintainabilityofthesoftwaresystem
byapplyingappropriatedesignpattern
Date:
Forillustrationpurposeabstractfactorypatternisusedtodescribetheproposedmethod.
Abstractfactorypatternknownasacreationalpattern,providesamethodto
encapsulateagroupofindividualfactoriesthathaveafamiliarthemewithoutspecifying
theirconcreteclasses.Inusualcase,theclientsoftwarecreateaconcrete
implementationoftheabstractfactorythenusinggenericinterfaceofthefactoryto
createtheconcreteobjectswhichispartofthetheme.Theclientdoesn‟tknowwhich
concreteobjectsgetsfromalloftheseinternalfactories,sinceitusesonlythegeneric
interfacesoftheirproducts.Abstractproductsdescribeinterfaceforeverydifferent
productsofasingleproductfamily.Concreteproductsimplementtheabstractproduct
interfacewhichisreturnedbycreationalmethodsofconcretefactories.Abstractfactory
definestheinterfaceforcreatingproductswhichiscommontoallconcretefactories.
Concretefactoriesimplementcreationalmethodsoftheabstractfactoryandeach
concretefactoryshouldcorrespondtoaspecificproductsvariantasshowninFigure.
Figure:DesignPattern-AbstractFactory
Purposeofabstractfactorydesignpatternistoprovideaninterfaceforcreatingfamilies
ofrelatedobjectswithoutspecifyingconcreteclasses.ThefollowingFigure()showsthe
exampleofabstractfactorydesignpatternforuserloginwheretwoconcretefactoryand
concreteproductusedforexecution.
57
Figure :
AbstractFactoryDesignPatternforUserLogin
Usingproposedmethoddesignpatternasseswhererequirementiswelldocumented
andfixedwhichisusedasinput.Asstep1firstlyidentifythedesignproblemusing
alternativedesignsolutionsfromliteratureandexperience,andsolveusingabstract
factorydesignpattern.Instep2maintainability,reusability,understandability,flexibility,
composability,completeness,stability,simplicity,andexpandabilityareselectedas
designobjective.Usingstep3appropriatesolutionisselectedasstep4(tool)andstep5
(mathematicalformation).Instep4maintainability,reusability,understandability,and
flexibilityarecalculatedusingperceronsdesignpatternadvisortool.Instep5
composability,completeness,stability,simplicity,andexpandabilityaremeasuredusing
mathematicalformation.Instep6,combinestep4and5outputtogetrequiredquality
product.Assessmentoftheseninequalityattributesarediscussedas:
Maintainability:Useofadesignpatternessentiallycomplicatesdesigntousuallyadd
abstractclassesandadditionalassociationstoemployadesignpattern.Thekey
advantageofusingdesignpatternisthattheresultingsoftwareshouldbeeasiertoadapt,
tomodifyfewerclasses,toaddfunctionalitytosoftware.So,maintenanceClient
AbstractFactory+doAction1:void+doAction2:voidAbstractProduct+doAction:void
AbstractFactory concreteProduct1 concreteProduct2 concreteFactory1
concreteProduct1:AdminconcreteProduct2:UserconcreteProduct1+doAction:void
concreteFactory2concreteProduct1:AdminconcreteProduct2:UserconcreteProduct2
+doAction:void95programmersshouldhavetouselessefforttoadaptthesechanges.
Everyintroducedpatterncausedanimprovementindifferentqualityattributes.
58
Reusability:Designpatternsarereusablemicroarchitecturesthataddtooverallsoftware
architecture.Designpatternsdetainstaticanddynamicstructureandcollaborationsof
componentsinsuccessfulsolutionstoproblemsthatoccurwhendevelopingsoftware
likebusinessdataprocessing,databases,graphicaluserinterfaces,telecommunications,
anddistributedcommunicationsoftware.Patterns96helpdevelopmentofreusable
componentsandframeworksbyusingstructureandcollaborationofparticipantsin
softwarearchitectureatalevelhigherthansourcecodeandobjectorienteddesign
modelsthatfocusonindividualobjectsandclasses.Thus,patternsfacilitatereuseof
softwarearchitecture,evenwhenadditionalformsofreuseareinfeasible.Anempirical
investigationonreusabilityofdesignpatternsandsoftwarepackages,attemptsto
empiricallyinvestigatereusabilityofdesignpatterns,classes,andsoftwarepackagesto
identifythemostbeneficialstartingpointsforwhiteboxreuse,whichisprettypopular amongOSS.
Conclusion:
Therecruitmentsystemallowsthejobseekerstoviewthejobandthe
organisationshortlisttheapplicationfortheinterview.Theshortlistedapplication
undergoaprocessoftestandinterview.Itisusedto reducesthetime
consumptionforthejobseekerandorganisation.
FOREIGN
TRADING
SYSTEM
10
Ex.No:3 Identify use cases and develop use case model

Date:
Use case diagram:
system that shows the relationship between the user and the different use cases in which the user
is involved. A use case diagram can identify the different types of users of a system and the
However, this definition is too generic to describe the purpose, as other four diagrams (activity,
sequence, collaboration, and State chart) also have the same purpose.
System:
11
UseCase:
functions.
Actors:
Actors are the users of a system. When one system is the actor of another system, label
the actor system with the actor stereotype.
Relationships:
Illustrate relationships between an actor and a use case with a simple line. For
relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship
indicates that one use case is needed by another in order to perform a task. An "extends"
relationship indicates alternative options under a certain use case.
12
Use case Modeling:

Use case name: Transaction
Brief:
13
If the customer order the products, then based on that amount ,the
transaction in card will be perform, customer’ s bank account is greater than the
minimum balance ,then customer can perform transaction ,if customer wish to cancel
the products, then the amount will be refund to the customer’ s account
Casual:
Success scenario:
The transaction is done successfully and the products are delivered to
customer’ s address.
Failure scenario:
If transaction was failed, then the product will not deliver to customer’ s
address.
Fully Dressed:
Use case Name Transaction
Goal To sell products
Level To perform transaction.

Primary actor Customer, organization
Secondary actor Bank.
Stack holders Customer, organization, bank.
Pre-conditions Enter correct user name & password
Main success scenario First order the products, then you can perform
transaction in card, cash, online payment based
On that transaction will perform
Extension Check the balance

Special requirements Provide user authentication.
Use case name: view products

14
Brief:
If the user id and password are correct ,customer can view the products.
Casual:
Success scenario:
Customer must want to login into their account and view the products.
Failure scenario:
If the user id and password are incorrect , customer can’ t view the products.
Fully Dressed:
Use case Name View products
Level To sell products

Primary actor customer
Secondary actor Organization
Stack holders Organization, customer.
Pre-conditions Login into the website & view products.

Main success scenario If the user id and password are correct,
customer can view the products.
Extension Enter correct user id and password
Special requirements Efficient network facilities.
Use case name: order product

Brief:
15
You can order any products, which you are like and perform transaction using credit
card or online payment.
Casual:
Success scenario:
The customer can login and order any products to their address.
Failure scenario:
If the user id and password are incorrect, they can't order any products.
Fully dressed:
Use case Name Order products
Level To sell any products
Primary actor Customer.
Secondary actor Organization.
Stack holders Organization, customer.
Pre-conditions Login into your account.
Main success • To order the products first view the

Scenario products, then add the required items into the
cart, then order the products by giving your
details.
Extension The notification will be send to the

customer's mobile number.
Special requirements User authentication.
Ex.No:4
16
Date: Identify Conceptual class and develop the

from them
Domain model:
Finding Conceptual class:

1.Reuse or modify existing conceptual models
2.Use category list.
3.Identify noun phrases.
Category list:
3.Product or service Credit card or debit card.
5. Role of people or organization related to Customer, bank, organization.
transaction:
6.Place of transaction: Online
17
8.Physics objects: Credit card, Money.

9.Description of things: Product description.

Success scenario:
❖ Customer can login into the website.
❖ Customer can view the products.
❖ customer can add the items into their cart.
❖ customer can perform transaction.
❖ The transaction is done after checking whether the credit limit is greater than the amount
❖ Successful transaction sends a notification to the customer and the details are updated in
database
❖ Customer gets their products.
❖ customer can also return or cancel their products.
❖ amount are refund to their account.
NOUNS:
• Customer
• Payment
• Credit card
• organization
• Bank
• cart
• Product
• Credit limit
• database
• account
18
• transaction
Class Diagram:
➢ Class diagram is a static diagram. It represents the static view of an application. Class diagram
➢ Class diagram describes the attributes and operations of a class and also the constraints
oriented languages.
➢ Class diagram shows a collection of classes, interfaces, associations, collaborations, and
 Analysis and design of the static view of an application.

 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
Members:
Visibility:
+ Public
- Private
# Protected
19
~ Package
Derived property:
It Is a property which value (or values) is produced or computed from other information, for
Scope:
Classifier members are commonly recognized as “static” in many programming languages. The
scope is the class itself.
➢ Attribute values are equal for all instances

➢ Method invocation does not affect the classifer’s state
Instance members are scoped to a specific instance.
➢ Attribute values may vary between instances

➢ Method invocation may affect the instance’s state (i.e. change instance’s attributes)
To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance scope is
assumed by default.
Relationships
Class Notation:
20
❖ The top section is used to name the class.

❖ The second one is used to show the attributes of the class.
❖ The third section is used to describe the operations performed by the class.
❖ The fourth section is optional to show any additional components.
responsibility.
Object Notation:

21
22
Classes:
1. Customer
• user_id: String
• password: String
2. Customer_details
23
• Name: String
• Address: String
• Phno: Integer
3. Products
• Productname: String
• Product_id: Integer
• Amount: Integer
4. Transaction
• T_password: String
• T_user_id: String
• Amount: Integer
5. Bill
• Product_name: String
• Amount: Integer
• Tax: Integer
• Total: Integer
Ex.No:5 Using the identified scenarios find the

interaction between objects and represent them
Date: using UML sequence and collaboration
diagram
24
Sequence diagram:
A sequence diagram simply depicts interaction between objects in a sequential order i.e.
the order in which these interactions take place. We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order the
objects in a system function. These diagrams are widely used by businessmen and software
Actors :
An actor in a UML diagram represents a type of role where it interacts with the system and
its objects. It is important to note here that an actor is always outside the scope of the system we
aim to model using the UML diagram.
We use actors to depict various roles including human users and

other external subjects. We represent an actor in a UML diagram using
a stick person notation. We can have multiple actors in a sequence
diagram.
25
Lifelines:
A lifeline is a named element which depicts an individual participant in a sequence
elements are located at the top in a sequence diagram. The standard in in UML for naming a lifeline
26
follows the following format – Instance Name : Class Name
Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head
is located on top of a vertical dashed line (referred to as the stem) as shown above. If we
want to model an unnamed instance, we follow the same pattern except now the portion of
Difference between a lifeline and an actor

A lifeline always portrays an object internal to the system whereas actors are used
to depict objects external to the system. The following is an example of a sequence diagram:
27

Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline. We represent messages using arrows. Lifelines and messages form
the core of a sequence diagram.
28
Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The
sender waits until the receiver has completed the processing of the message. The caller continues
only when it knows that the receiver has processed the previous message i.e. it receives a reply
message. A large number of calls in object oriented programming are synchronous. We use a solid
Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction
moves forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.
29
Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented with
a dotted arrow and create word labelled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would require a new object
of Order class to be created.

Delete Message
We use a Delete Message to delete an object. When an object is deallocated
30
Self Message
messages are called Self Messages and are represented with a U shaped arrow.

31

Reply Message
Reply messages are used to show the message being sent from the receiver to the
sender. We represent a return/reply message using an open arrowhead with a dotted line. The

32

Found Message
33


34
Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the system.
It is represented using an arrow directed towards an end point from a lifeline. For example:
Consider a scenario where a warning is generated.

symbol.
Guards
To model conditions we use guards in UML. They are used when we need to restrict the flow
of messages on the pretext of a condition being met. Guards play an important role in letting
35
Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
They are also used to show details of UML use case diagrams.
Used to understand the detailed functionality of current or future systems.
Visualise how messages and tasks move between objects or components in a system.
36
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of
individual objects as well as the overall operation of the system in real time. The four major components
of a collaboration diagram are:
Objects- Objects are shown as rectangles with naming labels inside. The naming label follows
Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a name
Links- Links connect objects with actors and are depicted using a solid line between two
Messages- Messages between objects are shown as a labeled arrow placed near a link. These
37
38
Flow of messages:
• Customer can login into the website.
• Customer can view the products.
• customer can add the items into their cart.
• customer can perform transaction.
• The transaction is done after checking whether the credit limit is greater than the amount
• Successful transaction sends a notification to the customer and the details are updated in
database
• Customer gets their products.
• customer can also return or cancel their products.
• amount are refund to their account.

39

collaboration diagram
Date:
40
Ex.No:7 Draw relevant state chart diagram and

activity diagram
Date:
Activity diagram:
To model a human task (a business process, for instance).
To describe a system function that is represented by a use case.
41
The activity diagram consists of three swim lanes namely customer, organization and bank.
First Customer must want to login into the website, then Customer can view the products and
customer can add the items into their cart and customer can perform transaction. The transaction
is done after checking whether the credit limit is greater than the amount, if it is a Successful
42
transaction, then it sends a notification to the customer and the details are updated in database,
after that Customer gets their products, then customer can also return or cancel their products and
the amount are refund to their account.

behavior which specifies the sequence of states an entity (or object) visits during its lifetime in
Key concepts:
State: A state is a condition during the life of an object during which it satisfies some condition,
States (simple states or composite states)
State transitions connecting the states

Example:
➢ The initial state of a state machine diagram, known as an initial pseudo-state, is

43
➢ The final state of a state machine diagram is shown as concentric circles. An

open loop state machine represents an object that may terminate before the system
States:
❖ Login
❖ View_products
❖ Add to cart
❖ Cancel products
❖ Order product
❖ Transaction
❖ Payment
❖ Check and pack product
❖ Deliver to customer's address
44
Ex.No:8
IMPLEMENT SYSTEM AS PER DETAILED
Date: DESIGN
Class Name : Bill
public class Bill {
public String product_name;
public int amount;
public int Tax;
public int Total;
}
45
Class Name : Customer
public class Customer {
public String userid;
public Vector fill;
public Vector perform;
public Vector view;
public void login() {

}
}
46
Class Name : Customer_Details
public class Customer_details {
public String name;
public int phno;
public void get_details() {

}
public void view_details() {

}
Class Name : Products

47
public class Products {
public String product_name;
public int product_id;
public int amount;
public Vector leads to;
public Customer view;
public void Add_to_cart() {

}
public void order_products() {

}
public void cancel_products() {

48
public void deliver_products() {

}
Class Name : Transaction
public class Transaction {
public String T_userid;
public String T_password;
public int amount;

49
public void cashpayment() {

}
public void cardpayment() {

}
public void onlinepayment() {

}
}
50
Ex.No:9
TEST SOFTWARE SYSTEM FOR ALL SYSTEM
Date: AS PER USE CASES
51
52
Ex.No:10
Improve the reusability and maintainability of the
software system by applying appropriate design
Date: patterns.
For illustration purpose abstract factory pattern is used to describe the

proposed method. Abstract factory pattern known as a creational pattern, provides
a method to encapsulate a group of individual factories that have a familiar theme
without specifying their concrete classes. In usual case, the client software create
a concrete implementation of the abstract factory then using generic interface of
53
the factory to create the concrete objects which is part of the theme. The client
doesn‟t know which concrete objects gets from all of these internal factories, since
it uses only the generic interfaces of their products. Abstract products describe
interface for every different products of a single product family. Concrete products
implement the abstract product interface which is returned by creational methods
of concrete factories. Abstract factory defines the interface for creating products
which is common to all concrete factories. Concrete factories implement
creational methods of the abstract factory and each concrete factory should
correspond to a specific products variant as shown in Figure.
Purpose of abstract factory design pattern is to provide an interface

for creating families of related objects without specifying concrete classes. The
following Figure( ) shows the example of abstract factory design pattern for user
login where two concrete factory and concrete product used for execution.
54
Using proposed method design pattern asses where requirement is

well documented and fixed which is used as input. As step 1 firstly identify the
design problem using alternative design solutions from literature and experience,
and solve using abstract factory design pattern. In step 2 maintainability,
reusability, understandability, flexibility, composability, completeness, stability,
simplicity, and expandability are selected as design objective. Using step 3
appropriate solution is selected as step 4 (tool) and step 5 (mathematical
formation). In step 4 maintainability, reusability, understandability, and flexibility
are calculated using percerons design pattern advisor tool. In step 5
composability, completeness, stability, simplicity, and expandability are measured
using mathematical formation. In step 6, combine step 4 and 5 output to get
required quality product. Assessment of these nine quality attributes are
discussed as:
Maintainability:
55
Use of a design pattern essentially complicates design to usually add

abstract classes and additional associations to employ a design pattern. The key
advantage of using design pattern is that the resulting software should be easier
to adapt, to modify fewer classes, to add functionality to software. So,
maintenance Client AbstractFactory +doAction1:void +doAction2:void
AbstractProduct +doAction:void AbstractFactory concreteProduct1
concreteProduct2 concreteFactory1 concreteProduct1: Admin concreteProduct2:
User concreteProduct1 +doAction:void concreteFactory2 concreteProduct1:
Admin concreteProduct2: User concreteProduct2 +doAction:void 95
programmers should have to use less effort to adapt these changes. Every
introduced pattern caused an improvement in different quality attributes.
Reusability:
Design patterns are reusable micro architectures that add to overall

software architecture. Design patterns detain static and dynamic structure and
collaborations of components in successful solutions to problems that occur when
developing software like business data processing, databases, graphical user
interfaces, telecommunications, and distributed communication software.
Patterns 96 help development of reusable components and frameworks by using
structure and collaboration of participants in software architecture at a level higher
than source code and object oriented design models that focus on individual
objects and classes. Thus, patterns facilitate reuse of software architecture, even
when additional forms of reuse are infeasible. An empirical investigation on
reusability of design patterns and software packages, attempts to empirically
investigate reusability of design patterns, classes, and software packages to
identify the most beneficial starting points for white box reuse, which is pretty
popular among OSS.
56
CONCLUSION:
Thus using the Foreign trading system, we can easily exchange the goods and
services across international borders and we can easily purchase any products through out
the world and the main benefit is, we can easily return the products and the amount will
be refund immediately, because of the direct dealers the amount is less, when compared
to the shop, by using this system we can also save the time and money.
CONFERENCE
MANAGEMENT
SYSTEM
1
EX.NO:1 PROBLEM STATEMENT
Date:
AIM
To develop a problem statement for the Conference Management System.
PROBLEM STATEMENT
Conference management system is a system used for maintaining meeting, Site

Selection, email marketing, event management and online event registration. Here the Event
organizer creates the events and the notifications send to the users. Where users can register
for the events by paid or unpaid. The System admin maintains the event organizers and users
account.
Software Requirements Specification for Conference Management System
Table of Contents
Table of Contents ............................................................................................ iii

Revision History .............................................................................................. iii
1. Introduction ................................................................................................ 4
1.1 Purpose ............................................................................................................. 4
1.2 Document Conventions .................................. Error! Bookmark not defined.
1.3 Intended Audience and Reading Suggestions. Error! Bookmark not defined.
1.4 Product Scope ................................................. Error! Bookmark not defined.
1.5 References......................................................................................................... 4
2. Overall Description .................................................................................... 4
2.1 Product Perspective .......................................................................................... 4
2.2 Product Functions ............................................................................................. 4
2.3 User Classes and Characteristics ...................................................................... 5
2.4 Operating Environment .................................................................................... 5
2.5 Design and Implementation Constraints........................................................... 5
2.6 User Documentation ......................................................................................... 5
2.7 Assumptions and Dependencies ....................................................................... 5
3. External Interface Requirements ............................................................. 6
3.1 User Interfaces .................................................................................................. 6
3.2 Hardware Interfaces.......................................................................................... 6
3.3 Software Interfaces ........................................................................................... 6
3.4 Communications Interfaces .............................................................................. 6
4. System Features ......................................................................................... 7
4.1 System Feature 1 .............................................................................................. 7
4.2 System Feature 2 (and so on)............................................................................ 7
5. Other Nonfunctional Requirements ......................................................... 9
5.1 Performance Requirements............................................................................. 10
5.2 Safety Requirements ....................................................................................... 10
5.3 Security Requirements.................................................................................... 10
5.4 Software Quality Attributes ............................................................................ 10
5.5 Business Rules ................................................................................................ 10
6. Other Requirements ................................................................................ 11
Appendix A: Glossary.................................................................................... 12
Appendix B: Analysis Models ....................................................................... 12
Revision History
4
1. Introduction
1.1 Purpose
The main purpose of the conference management system document is to build a web-
based software for meeting, site selection, email marketing, event management and online event
registration.
1.2Document Conventions
CONVENTIONS FONT FACE FONT SIZE

1 Headings Times New Roman 18
2 Sub Headings Times New Roman 14
3 Content Times New Roman 12
Developers can review the project capabilities more easily and understand the efforts
targeted to improve (or) add more features to it. End users of this application who wish to can
read this project.
1.4 Product Scope
• This software is mainly used for conducting and managing the conference in efficient
manner.
• The main goal is to reduce the work of the organizers.
1.5 References
IEEE software requirement system format
Links: https://en.wikipedia.org/wiki/Conference_management
Conference management system manages all administrative and organizational tasks

of a conference. The system is based on both client and server side web application that uses
document-oriented database. Every user of this only a web browser to the system and connects to
it. The system will also be able to host multiple conferences and their all web based activities.
5
1. Organizer/Client
→Login/Sign in with provided id and pass code.
2. Registration
→Select the event whatever client/organizer wants.
3. Submission
→Submit the presentation with the selected topic/event according to the given abstract.
4. Shortlist
→Submitted abstracts will be shortlisted by the organizer.
5. Pre-Notifications
→This function notify the selected users with organizer details
6. Payments
→This function provide a secure payment way for the user.
7. Post-Notification
→Notify the paid users with e-tickets.
The user of this software is an organizer. They are uses this software to provide an event details
to the client users. The organizer act as the administrator for the event and they handle all the
other requirements.
This software runs on Mozilla Firefox, Google chrome and Safari web browsers only.
Time limit is given to the organizer by system. If times goes long then pay per use.

The user documentation can be found in this SRS.
The organization and client must have basic knowledge of computers and English Language.
Provide privacy and security for the organizer and client information
6

3.1 User Interfaces
This requirement will come along with a basic user interface tool with GUI along with
simple and easy to navigate icons thus avoiding any complexity which may not be understandable
for novice users. The interfacing will contain arrow marks, text boxes and some different shaped
boxes reduce complexity.
a) Server side
The web application will be hosted on a web server which is listening on the web
standard port, port 80.
b) Client side
➢ Monitor screen – the software shall display information to the user via the
monitor screen.
➢ Mouse – the software shall interact with the movement of the mouse and the
mouse buttons. The mouse shall activate areas for data input, command buttons
and select options from menus.
➢ Keyboard – the software shall interact with the keystrokes of the keyboard. The
keyboard will input data into the active area of the database.
➢ Mobile based Web browsers.
a) Server side :- An Node.js server will accept all requests from the client and forward it
accordingly. A database will be hosted centrally using MongoDB.
b) Client side :- An OS which is capable of running a modern web browser which supports
JavaScript and HTML5 , CSS3 and Front-End Framework Bootstrap 4 and Library React.
The HTPP or HTTPS protocol(s) will be used to facilitate communication between the
client and server.
7
4. System Features
Mandatory features:
 Single login authentication
 Periodical announcements
 Conference Requests
 Conference rooms and presentation scheduling
 Webpage and announcements
 Registration
 Multiple conference management
4.1 System Feature 1 Registration

In this phase, the user information is put into database. After registration, users
will be able to sign in and have access to system's features. Registration process consists of
following step:
Providing Personal Data: In this step, users will have to fill their personal
data. Personal data will include the following:
1. First Name
2. Last Name
3. Gmail ID
4. Contact info
5. Password
6. Secret Question

User must login with the system. System should provide a home page of the
user account.

REQ-1: Server should not accept a g-mail that was registered before.
4.2 Feature 2: Single login Authentication
G-mail Field: Users will need to put their g-mail addresses in this field. G-mail address is
used for identification of a user.
Password Field: Users will need to put their passwords in this field. User will be able
to change their passwords after logging in.
8
REQ-01: Server should check if the e-mail and password entered by the user are valid
or not.
4.3 Feature 3: Conference Request
Required Information: Following information is requested by this feature:
1. Name of event
2. Description
3. Start Time
4. End Time
5. Date
6. Conference rooms
Send Request: User will send his/her request to the server by clicking "Request
Conference" button after filling in the required fields.
4.4 Feature 4: Periodical Announcements
Description
➢ This feature will include sending remainders to all users of a conference about
their responsibilities and conference details. This process will be done by emails
periodically sent to users. Conference administrator will be able to manage time
intervals of remainders.
➢ This is can be done by using SMTP protocol. SMTP is part of the application of
a TCP/IP protocol. Using a process called “store and forward”, SMTP moves your
email on and across networks. SMTP provides a set of codes that simplify the
communication of email messages between email servers. SMTP is able to transfer
only text – it isn’t able to handle fonts, graphics, attachments, Etc.
➢ Our Internet Service Providers typically have a limit to the no.of.emails we can
sent over a certain amount of time. The Email limit varies by ISP. For example, the
typical Cable Internet customer is limited to 1,000 emails per day.(Their business
customers have a limit of 24,000 emails daily.) Verizon and AT&T do it differently,
They put a limit of 100 on the no.of.recipients you can have on one sent email.
9
4.5 Feature 5: Conference Rooms and Presentation Scheduling
Description
The system should be able to determine the conference rooms and schedule the
presentations using the information provided by conference administrator while filling in the
conference request form. This process will be done automatically. Scheduling process consists of
the following:
Conference Rooms Panel: User will need to give information about number and capacity
of the rooms.
Conference Time Panel: User will need to give information about time requirements of
conferences.
4.6 Feature 6: Web Page Announcements
This is the process which will announce all the updates and details about conference.
Conference admin will be able to make announcements for their conferences. Web Page
Announcements consist of the following:
➢ My Conferences Page: A user will be able to view all conferences that he/she is
participating in this page.
➢ View Conference Page: Properties, Schedule and announcement of a selected

conference will be viewed in this page.
➢ Make Announcement Page: A conference admin will be able to make

announcements for a selected conference using this page.
4.7 Feature 7: Multiple Conference Management
➢ A user will be able to create and manage multiple conferences. Each conference
will have its own page for participants and other necessities.
➢ My Conference Page: A user will be able to view the conferences he/she created
using this page. On this page, by simply clicking on “view conference” link under
one of the conferences, he/she will be redirected to that conference’s page and will
be able to edit and view its components.
➢ Request New Conference: A user will be able to create a new conference simply
by clicking “Request New Conference” link on My conference Page. After putting
in the necessary information, the conference will be launched and ready to view.
REQ-1: All users will be able to create and manage their own conferences by
subscription method.
10
5. Other Non-functional Requirements

Performance of the system depends on the response time and the speed of the data
submission. The response time of the system is direct and the application is considered real-time.
System should have a fast response time, which depends on the efficiency of implemented
algorithm. The first version of the system will have a limited file submission speed, that is why
there will be no need for large network. However, it may grow up depending on the increase in
usage.
• System has to check:
• If HTML content is syntactically well-formed,
• If Web forms with the services processing form input are consistent,
• Referential integrity of hyper-links in both static and dynamically generated

content,
• Statically safe binding of the code of session operations to variables defined with
session scope.
• In case of error it should provide users with appropriate help messages.
For security of the system the technique known as database replication should be used so
that all the important data should be kept safe. In case of crash, the system should be able to
backup and recover the data.
The system will have a simple and user friendly graphical interface. Users will be able to
understand and use all the features of the website easily. Any action will be performed with just
a few clicks.
5.5 Business Rules
➢ Users need a account to login.
➢ User must be logged in to send request for registration.
➢ The admin should be notified about user requests.
➢ The admin can accept or decline user requests.

11
6. Other Requirements –GNU GPL License

➢ The project is released under the GNU General Public License. The philosophy of
this license implies some basics principles which apply to the project.
➢ The GPL is a free software license, and therefore it permits people to use and even
redistribute the software without being required to pay anyone a fee for doing so.
➢ The freedom to run the program, for any purpose.
➢ The freedom to study how the program works, and adapt it to your needs.
➢ Access to the source code is a precondition for this.
➢ The freedom to redistribute copies so you can help your neighbour.
➢ The freedom to improve the program, and release your improvements to the public,
so that the whole community benefits. Access to the source code is a precondition
for this.
12
• Node.js is an open source development platform for executing JavaScript code server-side.
• MongoDB is a cross-platform document-oriented database program. Classifies as a NoSQL
database program, MongoDB uses JSON-like documents with schema.
• CSS(Cascading Style Sheets) is a style sheet language used for describing the presentation
semantics(the look and formatting) of a document written in a markup language.
• HTML (HyperTextMarkup Language) is the main markup language for displaying web
pages and other information that can be displayed in a web browser.
• Bootstrap is an open source toolkit for developing with HTML,CSS and JS.
• React is a JavaScript library for building user interfaces.
• SRS Software Requirement Statement
• GUI Graphical User Interface
• SMTP (Simple Mail Text Protocol)
• HTTP (Hypertext Transfer Protocol)
• HTTPS (Hypertext Transfer Protocol Secure)
Appendix B: Analysis Models

Use case model, Object model, Dataflow model and SADT model, Dynamic model.
EX.NO:3
13
DATE: IDENTIFY USE CASES AND

DEVELOP USE CASE MODEL
USE CASE DIAGRAM:

user is involved. A use case diagram can identify the different types of users of a system and
the different use cases and will often be accompanied by other types of diagrams as well. The
use cases are represented by either circles or ellipses.

However, this definition is too generic to describe the purpose, as other four diagrams (activity,
sequence, collaboration, and State chart) also have the same purpose.
SYSTEM
USE CASE
functions.
ACTORS
Actors are the users of a system. When one system is the actor of another system,
label the actor system with the actor stereotype.
RELATIONSHIPS
Illustrate relationships between an actor and a use case with a simple line. For
relationships among use cases, use arrows labeled either "uses" or "extends." A "uses"
14
relationship indicates that one use case is needed by another in order to perform a task. An
"extends" relationship indicates alternative options under a certain use case.
USECASE DIAGRAM:
15
USE CASE MODELLING

LOGIN
BRIEF FORMAT
The users in the conference management system should need to login to access the
service provided by the system. User need to enter the username and password to enter into the
site. Then only he/she are able to access the service.
CASUAL FORMAT
SUCCESS SCENARIO
In the login page of the site, the users enters the username and password, if the login
credentials is valid then the user can access the CMS service.The user can able to register for
any events available in the system.
ALTERNATE SCENARIO
If the entered user credentials is invalid, then the user cannot able to access the
services. So user must check the credentials again.
Use case name User Login

Goal To login successfully into the system
Level Enter the Username and password
Primary actor Users
Secondary/Supporting Admin
actor
Stake holders User plays the important role in the
system. The user logins the system to
access the service.
Precondition The user must have an account to login
Main success scenario Click on the login page
Enter the login credentials to access
the service
Exception Incorrect password
Forget password
Extension Unauthorized person can’t able to
access the system
Third party auth is provided
CONFERENCE REQUEST
16
BRIEF FORMAT
The conference request service is provided by the user to join the

event/meeting.Event orgainzer create the event and then the user request the organizer to join.
CASUAL FORMAT
SUCCESS SCENARIO
The user request the event then the organizer accept the request. The conference
requests contains the conference details the user can able to see the details.
ALTERNATE SCENARIO
If one event is unavailable then the user cant request the event. The user should be
wait for event to join. Else user can able to request the other events.
Use case name Conference request

Goal The Conference request maintains the user
request and the conference details
Level To View multiple conference details
Primary actor User
Secondary actor Event organizer, Admin
Stake holders The users in the system requests the
conference/events what he/she wants to
join.
Precondition The user must have an account to request
Main success The Conference request contains the
scenario multiple conference details and the user can
request the conference.
Exception User can select a conference based on their
flexible.
Extension Organizer can pay within 24 hours from
post their conference in the system.
Special requirements User and organizer must provide a validate
communication address to system.
17
EX.NO:4 IDENTIFY CONCEPTUAL CLASSES AND DEVELOP

THE DOMAIN MODEL AND ALSO DERIVE A
CLASS DIAGRAM FROM THAT
DATE:
CLASS DIAGRAM:
imposed on the system. The class diagrams are widely used in the modelling of object oriented
oriented languages.
•
Analysis and design of the static view of an application.
•
Describe responsibilities of a system.
•
Base for component and deployment diagrams.
•
Forward and reverse engineering.
Members:
UML provides mechanisms to represent class members, such as attributes and
methods, and additional information about them.
Visibility:
To specify the visibility of a class member (i.e. any attribute or method), these
notations must be placed before the member's name.
+ Public
- Private
# Protected
~ Package
Derived property:
➢ Derived property is a property which value (or values) is produced or computed
from other information.Derived property is shown with its name preceded by a
forward slash '/'.
18
Scope:
The UML specifies two types of scope for members: instance and classifier, and the latter
is represented by underlined names.
➢ Classifier members are commonly recognized as “static” in many programming
Attribute values are equal for all instanceso Method invocation does not affect the
classifier’s state
➢ Instance members are scoped to a specific instance.
Attribute values may vary between instanceso Method invocation may affect the
instance’s state (i.e. change instance’s attributes)
➢ To indicate a classifier scope for a member, its name must be underlined. Otherwise,
Relationships
Class Notation:
➢ UML class is represented by the following figure. The diagram is divided into four
parts.
19
responsibility.
Object Notation:
It is represented in the same way as the class. The only difference is the name
which is underlined as shown in the following figure.
20
DOMAIN MODEL
➢ As the object is an actual implementation of a class, which is known as the instance of a

class. Hence, it has the same usage as the class.
21
CLASS DIAGRAM
The class diagram consists of four classes namely, User, Event Organizer, Payment,
System Administrator.
The Associations between the classes are as follows:
• One User view many event details.
• One Event Organizer generates many Events.
• One Administrator manages many Payments.
22

BETWEEN OBJECTS AND REPRESENT
USING UML SEQUENCE DIAGRAM
DATE:
SEQUENCE DIAGRAM:
A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place. We can also use the terms event
diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how and
in what order the objects in a system function. These diagrams are widely used by businessmen
and software developers to document and understand requirements for new and existing systems.
1.Actors
An actor in a UML diagram represents a type of role where it interacts with the system
and its objects. It is important to note here that an actor is always outside the scope of the
system we aim to model using the UML diagram.
23
Figure 5.1: An actor interacting with a seat reservation system

sequence diagram. So basically, each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in UML
for naming a lifeline follows the following format – Instance Name: Class Name
Figure 5.2: Lifeline
located on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
model an unnamed instance, we follow the same pattern except now the portion of lifeline’s
name is left blank.
24
Difference between a lifeline and an actor:
Figure 5.3: A sequence diagram
4. Messages – Communication between objects is depicted using messages. The messages

and messages form the core of a sequence diagram. Messages can be broadly classified into
the following categories:
Figure 5.4: A sequence diagram with different types of messages

25
1.Synchronous messages
receives a reply message. A large number of calls in object-oriented programming are
Figure 5.5: A sequence diagram using a synchronous message
2.Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver processing the previous message or not.
We use a lined arrow head to represent an asynchronous message.
Figure 5.6: A sequence diagram using a Asynchronous message
3.Create message
We use a Create message to instantiate a new object in the sequence diagram. There
are situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.
For example – The creation of a new order on an e-commerce website would require a new
26
Figure 5.7: A situation where create message is used

Delete Message
We use a Delete Message to delete an object. When an object is deallocated
memory or is destroyed within the system, we use the Delete Message symbol. It destroys the
occurrence of the object in the system. It is represented by an arrow terminating with a x. For
example:
In the scenario below when the order is received by the user, the object of
Figure 5.8: A scenario where delete message is used
Self-Message
messages are called Self Messages and are represented with a U-shaped arrow.
Figure 5.9: Self message
For example – Consider a scenario where the device wants to access its webcam.
Such a scenario is represented using a self-message.
27
Figure 5.10: A scenario where a self-message is used
Reply Message
Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line. The
Figure 4.11:Reply message
Figure 5.12: A scenario where a reply message is used
Found Message
28
Figure 5.13: Found message
failure.
Figure 5.14: A scenario where found message is used
Lost Message
➢ A Lost message is used to represent a scenario where the recipient is not known to the
Figure 5.15: Lost message
➢ The warning might be generated for the user or other software/object that the lifeline is
symbol.
29
Guards
flow of messages on the pretext of a condition being met. Guards play an important role in
Figure 5.16: A Guard

➢ Used to model and visualize the logic behind a sophisticated function, operation or
procedure.
➢ They are also used to show details of UML use case diagrams.
➢ Used to understand the detailed functionality of current or future systems.
➢ Visualize how messages and tasks move between objects or components in a system.
30
SEQUENCE DIAGRAM
31
➢ The Users logins to the system by entering a valid ID and password then he will be able
to view events on successful login.
➢ The Event Organizer logins to the system and will be able to view user details and
generate events on a successful login
➢ The Payment generation process flow follows admin privileges to generate payments.
➢ The User will be able to view only after the payment is generated by the organizer.
32
EX.NO:6 USING THE IDENTIFIED

SCENARIOS,FIND THE
DATE:
INTERACTION
BETWEEN OBJECTS AND
REPRESENT THEM USING UML
A collaboration diagram, also known as a communication diagram, is an illustration

of the relationships and interactions among software objects in the Unified Modelling Language
(UML). These diagrams can be used to portray the dynamic behaviour of a particular use case
diagrams.
4. Messages- Messages between objects are shown as a labelled arrow placed near a link.
between.
33
34
EX.NO:6 DRAW STATE CHART

1 DIAGRAM AND ACTIVITY
DATE: DIAGRAM
ACTIVITY DIAGRAM:

be used for:

35
ACTIVITY DIAGRAM
36
➢ The Activity diagram consists of four swim lanes, the user, organizer and the
admi , System and Bank.
➢ The initial process is done by the login of the user.
➢ The user may be the event organizer. In case of user being organizer, they can
view their event details and view their payment details.
➢ In case of the user being the User, he also must login and can view the event
details and also initiate the process of generating the payment and also view the
generated payment detail.
➢ The User can view the payment once generated.
diagram) is a behavior which specifies the sequence of states an entity (or object) visits during
its lifetime in response to events, together with its responses to those events.
Key concepts:
State
performs some activity, or waits for some external event. A state machine diagram is a graph
consisting of:

Example:
37

➢ The initial state of a state machine diagram, known as an initial pseudo-state,
is indicated with a solid circle. A transition from this state will show the first
real state.
➢ The final state of a state machine diagram is shown as concentric circles. An
open loop state machine represents an object that may terminate before the
system terminates, while a closed loop state machine diagram does not have a
final state; if it is the case, then the object lives until the entire system
terminates.
STATECHART DIAGRAM
38
EX.NO:8 IMPLEMENT SYSTEM AS PER

DETAILED DESIGN
DATE:
Class Name: Registration
package kcube;
public class Registration {
public String username;
public String eventid;
public Payment Handles;
public ValidateAccount Used_to;
public void eventDetails() {

}
public void eventRegister() {

}
Class Name: ValidateAccount
package kcube;
public class ValidateAccount

{
public String userName;
public AccountDetails Used_for;

/**
*
* @element-type Registration
*/
public Vector Used_to;
39
public void check() {

}
Class Name: Payment
package kcube;
public String paymentid;
public Integer amount;
public Registration Handles;
public void balance() {

}
public void transaction() {

}
public void getReceipt() {

}
Class Name: Netbanking
package kcube;
public class NetBanking extends Payment {
private String bankName;
public void bankDetails() {

}
Class Name: CreditCard
package kcube;
40
public class CreditCard extends Payment {
private String cardName;
public Integer cvv_no;
public void cardDetails() {

}
Class Name: AccountDetails
package kcube;
public class AccountDetails{
public String name;
private Long phno;
private String email;
public ValidateAccount Used_for;
public void getDetails(String fname,String lname) {

name = fname+lname;
}
public void setUserNameAndPassword() {
}
public String displayDetails() {

return name;
}
41
EX.NO:9 TEST SOFTWARE SYSTEM FOR ALL

SYSTEM AS PER
DATE: USE CASES
JMeter:
JMeter can be used to simulate a heavy load on a server, group of servers, network
or object to test its strength or to analyze overall response time under different load types.
JMeter simulates a group of users sending requests to a target server, and returns statistics that
show the performance and functionality of the target server via tables, graph, etc.
Apache JMeter is open source software, a 100% pure Java desktop application,
designed to load test functional behavior and measure performance of web sites. It was
originally designed for load testing web applications but has since expanded to other test
functions.
• FTP services.
JMeter Features:
• Being open source software, it is freely available.
42
Class Name: AccountDetails
package kcube;
public class AccountDetails{
public String name;
private Long phno;
private String email;
public ValidateAccount Used_for;
public void getDetails(String fname,String lname) {

name = fname+lname;
public void setUserNameAndPassword() {

}
public String displayDetails() {
return name;
}
43
POSITIVE_OUTPUT
NEGATIVE_OUTPUT
44
EX.NO:10 IMPROVE REUSABILITY AND

MAINTAINABILITY BY
DATE: APPLYING APPROPRIATE
DESIGN PATTERN

45
of related objects without specifying concrete classes. The following Figure shows the example
of abstract factory design pattern for user login where two concrete factory and concrete
product used for execution.
Using proposed method design pattern asses where requirement is well

documented and fixed which is used as input. As step 1 firstly identify the design problem
using alternative design solutions from literature and experience, and solve using abstract
factory design pattern. In step 2 maintainability,reusability, understand ability, flexibility,
compensability, completeness, stability, simplicity, and expandability are selected as design
objective. Using step 3 appropriate solution is selected as step 4 (tool) and step 5 (mathematical
formation). In step 4 maintainability, reusability, understand ability, and flexibility are
calculated using parecons design pattern advisor tool. In step 5 compensability, completeness,
stability, simplicity, and expandability are measured using mathematical formation. In step 6,
combine step 4 and 5 output to get required quality product. Assessment of these nine quality
46
MAINTAINABILITY:
Use of a design pattern essentially complicates design to usually add an abstract
functionality to software. So, intenance client Abstract Factory +doAction1:void +doAction2:void
AbstractProduct +doAction:void stractFactory concreteProduct1 concreteProduct2
+doAction:void concreteFactory2 concreteProduct1: Admin concreteProduct2: User
concreteProduct2 +doAction:void 95 programmers should have to use less effort to adapt these
changes. Every introduced pattern caused an improvement in different quality attributes .
REUSABILITY:
OSS.
CONCLUSION:
47
The Software Personnel Management System can help to manage the automation of
salary information based on how well an employee has worked during the business operation.
The system is designed to reduce the human labour and efficiently maintains the generation of
salary slip. The system maintains information on the employee in the company in order to
calculate the payroll. The system generates record and performance report of the employees.
BPO
MANAGEMENT
SYSTEM
1.Introduction
1.1Purpose
Thesoftwarerequirementspecificationdocumentcontainstheentiresoftware
requirementforBPOsystemandprovidesthefulldetailsabouttheBPOsystem.The
businessprocessoutsourcingsystemistheinterfacebetweenthecustomerand
5
employee.Itmainlyaimsatclarifyingthequeriesofthecustomer.Thesystemreduces
theworkofthecustomer;theycanclarifytheirdoubtsintheirplaceitself.
1.2DocumentConventions
Conventionfortitle
Fontsize:18
Fontstyle:bold
Fontface:Timesnewroman
Conventionofsubtitle
Fontsize:14
Fontstyle:Bold
Fontface:Time’snewroman
Conventionofbody
Fontface:Timesnewroman
1.3IntendedAudienceandReadingSuggestions
Thesoftwarerequirementspecificationdocumentisintendedfor,
Developer
Reader
Customer
Tester
Projectmanager
Distributer
Transportmanager
1.4ProductScope
Manycustomerscanbemanagedbythesystem.Securityisprovidedsounauthorized
personcannotaccessthedetailsaboutthecustomer.Thescopeofthesystemisto
clarifythequiresofthecustomer.Oneoftheadvantagesistimemanagementsowithin
thetimelimitmorenumberofqueriesfromthecustomercanbeclarified.
7
Muchnumberofcustomerscanclarifytheirdoubtsatthesametime.
1.5References
ThereferenceoftheSRSis,
IEEEsoftwarerequirementsystem
2.OverallDescription
2.1ProductPerspective
TheBPOsystemisactasinterfacebetweencustomerandemployee.this
systemtrytomakeaninterfaceassimpleaspossibleandthesametimenot
riskingthesecurityofthecustomerdata,thisminimizethetimedurationinwhich
thecustomerreceivestheclarificationofthequeries.
2.2ProductFunctions
Themainfunctionofthebusinessprocessoutsourcingistoclarifythequeriesofthe
customeranditallowsthecustomertobuytheproductintheirplaces.Thissystem
provideshighauthenticationinmaintainthecustomerdetails.
2.3UserClassesandCharacteristics
TheactorsinvolvedintheBPOsystemsarecustomerandemployee. Usecases:
Login
Postqueries
Queryclarification Login:
❖Getusernameandpassword
❖Entertheusernameinthesystem
❖Iftheloginidiscorrectquerieswillbeclarified
❖Elsetheywon’trespond Postqueries:
❖Logintotheaccount
❖Constructthevalidqueries
❖Postthequeries
❖Logouttheaccount
Queryclarification:
❖Entertheloginid
❖Ifitisvalidgotothepage
❖Readthequerieswhichthecustomerhasposted
❖Clarifythequeries
❖Posttheclarificationaboutthequeries
8
2.4OperatingEnvironment
❖Operatingenvironmentiswindows7for30bit/x86&64-bit/x64pc
❖TheprogramarebasedonGUI
❖Softwareisplatformindependent
❖Javaforcodingpurpose
2.5DesignandImplementationConstraints
❖TheBPOrequireacomputertosubmittheirinformation
❖Althoughthesecurityisgivenhighimportance,thereisalwaysachanceof
intrusioninthewebworldwebwhichrequiresconstantmonitoring
❖Theuserhastobecarefulwhilesubmittinginformationmuchcareisrequired.
2.6UserDocumentation
Theinputqueriesarecomparedwiththequeriesinthedatabase.Thesolutionforthe
inputqueriesisfounded.Thefinalresult,thereplytothecustomerqueryisobtainedby theend
2.7AssumptionsandDependencies
❖TheorganizationandclientmusthavebasicknowledgeofcomputerandEnglish language
❖Provideprivacyandsecurityforthedocumentandclientinformation
3.InterfaceRequirements
3.1UserInterfaces
Thissystemusedtoclarifythequeriesabouttheproduct.Thissystemprovides
detailedexplanationaccordingoftheproducttothecustomer.Therequirement
presentedinthesectiondescribestheinterfaceoftheBPOsystem.The
requirementsdonotassumeaparticularinterface.Howevertherequirements
aregroupedtothemainfeaturesasdefinedbytheusecaseprovidedbythe system
3.2HardwareInterfaces
❖TheBPOsystemserverisdirectlyconnectedtotheclientsystemviaftpthe
clientsystemhaveaccesstothedatabaseintheserver
9
3.3SoftwareInterfaces
❖Frontendclient-theexporteronlineinterfaceisbuiltusingJSP&HTML
❖Webserver-apachetomcatserver(oraclecorporation)
❖Backend-oracle11gdatabase
❖Thedatabaseserver-MS-ACCESS
❖MSaccessdatabasemaintainbytheBPOcompanytostorequeriespostedby thecustomer
3.4CommunicationsInterfaces
Communicationinterfaceisusuallydesignedtocommunicationonemachinewith
anothermachine.IntheBPOmanagementsystemitisconnectedtoWorldWideWeb
forcommunicationinterface.Therequirementsassociatedwithanycommunications
functionsrequiredbythissystemincludingGmail,webbrowser,networkserver
communicationprotocol,electronicformsandsoon.Communicationstandardsthatwill
beusedsuchaswwworHTTP.
4.SystemFeatures
❖Itprovidessearchingfeaturesbasedonvariousproductsforcustomers.
❖Itshowstheinformationsabouttheproductsandtheirprices
❖Itprovidestheinformationsaboutthebuyingofproducts
❖Andalsodetailsabouttheproducts
❖Thisincludesexceptionalsolutionfeaturessuchasdisplayingqueriesandtheir
solutionintwowaysbycategoryandbyproductrequestnumber
5.OtherNonfunctionalRequirements
5.1PerformanceRequirements
❖Theperformanceofthesystemisbasedonthereliabilitywhenthesystemis
underload.Itisimportantthatsustainablenumberofcustomerlogintothe
websiteatthesametime,thesystemshouldnotslowdown.
❖Withtheclientandserverrunningonthesamemachine,responsetimewillbe
maximumoftwoseconds.
5.2SafetyRequirements
❖Varioussafetymeasuresaredevelopedinthissystemtomaintainthepersonal detailsofthecustomers
10
❖Unauthorizedpersoncannothackthedetailsofthecustomer.
❖Productdelivertothecustomershouldbesafe.
5.3SecurityRequirements
❖Thesystemisonlyaccessibletoauthenticatedmanagement.Thecustomer
detailsshouldbeverysecures.
❖Whenmorenumberofcustomerlogintothesystematthesametime,this systemshouldnotslowdown.
❖Whenthereisasecurityviolationthelogfilewillbeupdatedwiththeperson’s loginidanddateandtime.
5.4SoftwareQualityAttributes
Availability:
Thesoftwarewillbeavailableonlytoauthorizecustomertoknowaboutthedetails
oftheproductandalsocanviewtheproductandtheirprices
Maintainability:
Customerdetailsstoredinthedatabasesaremaintainedwithoutanybackups
Portability:
Thesystemisindependentofoperatingsystem.Thissystemwillrunonthemultiple
platformsinparticularwindows,UNIX.
6.OtherRequirements
AppendixA:Glossary
Authentication:
Toestablishtheauthorshipororiginofconclusivelyorunquestionably
Sustainable:
Abletobemaintainedatacertainrateorlevel
Ftp:
Thetransferofcomputerfilesbetweenclientandserveronacomputernetwork
Ex.no:3 Identifyusecaseanddevelopusecasemodel
11
Date:
Usecasediagram:
A usecasediagram atitssimplestisarepresentationofauser'sinteractionwith
thesystemthatshowstherelationshipbetweentheuserandthedifferent use cases
inwhichtheuserisinvolved.Ausecasediagramcanidentifythedifferent
typesofusersofasystemandthedifferentusecasesandwilloftenbe
accompaniedbyothertypesofdiagramsaswell.Theusecasesarerepresented
byeithercirclesorellipses.
PurposeofUseCaseDiagrams
Thepurposeofusecasediagramistocapturethedynamicaspectofasystem.
However,thisdefinitionistoogenerictodescribethepurpose,asotherfour
diagrams(activity,sequence,collaboration,andStatechart)alsohavethesame purpose.
BasicUseCaseDiagramSymbolsandNotations
System
Drawyoursystem'sboundariesusingarectanglethatcontainsusecases.Place actorsoutside
thesystemboundaries.
UseCase
Drawusecasesusingovals.Labeltheovalswithverbsthatrepresentthe system'sfunctions.
12
Actors
Actorsaretheusersofasystem.Whenonesystemistheactorofanother
system,labeltheactorsystemwiththeactorstereotype.
Relationships
Illustraterelationshipsbetweenanactorandausecasewithasimpleline.For
relationshipsamongusecases,usearrowslabeledeither"uses"or"extends."A
"uses"relationshipindicatesthatoneusecaseisneededbyanotherinorderto
performatask.An"extends"relationshipindicatesalternativeoptionsundera certainusecase.
USECASEDIAGRAM:
13
USECASEMODELLING
POSTQUERIES: BRIEFFORMAT:
Customerentersthevalidusernameandpasswordandlogintothesystem
andenterthequeriesandpostthequeries,checkthequeries,elsecorrectthe
queries.Employeegivethesolutiontothequeriesandthenlogoutofthe system.
CASUALFORMAT:
SUCCESSSCENARIO:
14
Customerentersthevalidusernameandpasswordandlogintothesystem
andenterthequeriesandpostthequeries,checkthequeries,elsecorrectthe
queries.Employeegivethesolutiontothequeriesandthenlogoutofthe system.
ALTERNATESCENARIO:
Customer’susernameandidisinvalid.Queriesarenotcleared
thereforethequeriesbecomeinvalid.Registrationisnotvalid.
FULLYDRESSEDFORMAT:
Usecasename Postqueries
Goal Topostqueriesandgetthesolutionfromthe employee.
Level Postthequeries.
Primaryactor Customer,Employee.
Secondary/Supporting actor BPOmanagementsystem
Stakeholders Customer
Precondition Useridandpasswordshouldbevalid.
Mainsuccessscenario Customerenterthevalidusernameandpassword
Logintothesystem
Enterthequeries
Postthequeries
Checkthequeries,elsecorrectthequeries
Employeegivesolutiontoqueries
Logout
Exception Customerusernameandidisinvalid
Queriesarenotclear
Queriesareinvalid
Registrationisnotvalid
Extension Customermustenterthevalidusernameandid
Validqueriesshouldbeposted
Properlinkshouldbeavailableforthelogin purposes.
Specialrequirements Authenticationisrequired.
LOGIN:
BRIEFFORMAT:
Theemployeegetstheusernameandpasswordofthecustomer.Theyentersthe
usernameandpasswordinthesystem.Ifitiscorrecttheyclarifythequeriesofthe
customerwhichtheyhaveposted.Elsetheywillnotrespondforthequerieswhichthey haveposted.
CASUALFORMAT:
SUCCESSSCENARIO:
Theemployeegetstheusernameandpasswordofthecustomer.Theyentersthe
usernameandpasswordinthesystem.Ifitiscorrecttheyclarifythequeriesofthe
customerwhichtheyhaveposted.Elsetheywillnotrespondforthequerieswhichthey haveposted
ALTERNATESCENARIO:
15
Properlinkisnotavailablefortheloginpurposes.Customerusernameand
passwordisnotvalid.Queriesarenotvalid.
FULLYDRESSEDFORMAT:
Usecasename Login
Goal Logintothesystem
Primaryactor Customer,employee
Secondary/Supportingactor BPOmanagement
Stakeholder Customer,employee
Precondition Systemshouldbeavailableforlogin
Mainsuccessscenario Theemployeegettheusernameand
passwordofthecustomer.
Theyentertheusernameandpassword
inthesystem.
Ifitiscorrecttheyclarifythequeriesof
thecustomerwhichtheyhaveposted
.Elsetheywillnotrespondforthe
querieswhichtheyhaveposted.
Exception Properlinkisnotavailableforthelogin purposes.
Customerusernameandpasswordis
notvalidQueriesarenotvalid.
Specialrequirements Customerdetailsshouldbekeptsafeand secure
GIVESOLUTION:
BRIEFFORMAT
Customerlogintothesystemwiththevalidusernameandpassword.Enterthe
queriesandpostthequeries.Employeemustcheckthequeries.Givesolutiontothe
queriesiftheyaretheregisteredmembers.Elsetheywillnotrespond.
CASUALFORMAT:
SUCCESSSCENARIO:
Customerlogintothesystemwiththevalidusernameandpassword.Enterthe
queriesandpostthequeries.Employeemustcheckthequeries.Givesolutiontothe
queriesiftheyaretheregisteredmembers.Elsetheywillnotrespond.
ALTERNATESCENARIO:
Customerusernameandpasswordisnotvalid.Queriesarenotseenbythe
employee.Queriesarenotvalid.
FULLYDRESSEDFORMAT:
Usecasename Givesolution
Goal Tocheckthequeriesandgivethesolution
tothequeries
Level Givethesolution
16
Primaryactor Customer,employee
Secondary/supportingactor BPOmanagement
Stakeholder Employee
Mainsuccessscenario Customerlogintothesystemwiththevalid
usernameandpassword.
Enterthequeriesandpostthequeries.
Employeemustcheckthequeries.
Givesolutiontothequeriesiftheyarethe
registeredmembers.
Elsetheywillnotrespond.
Exception Customerusernameandpasswordisnot
valid.Queriesarenotseenbythe employee.
Queriesarenotvalid.
Extension Customerpasswordandusernameshould bevalid.

Properlinkshouldbeavailable.
Employeeshouldgivethesolutiontothe
queriescorrectly.
Queriesshouldbevalid.
Precondition Queriesmustbeseenbytheemployee.
Specialrequirements Customerdetailsshouldbekept confidential.
Ex.no:4
Date: Identifyconceptualclassesanddevelopthedomainmodel
withUMLclassdiagrams
Classdiagram:
Classdiagramisastaticdiagram.Itrepresentsthestaticviewofanapplication.
Classdiagramisnotonlyusedforvisualizing,describing,anddocumenting
differentaspectsofasystembutalsoforconstructingexecutablecodeofthe softwareapplication.
Classdiagramdescribestheattributesandoperationsofaclassandalsothe
constraintsimposedonthesystem.Theclassdiagramsarewidelyusedinthe
modelingofobjectorientedsystemsbecausetheyaretheonlyUMLdiagrams,
whichcanbemappeddirectlywithobject-orientedlanguages.
Classdiagram showsacollectionofclasses,interfaces,associations,
collaborations,andconstraints.Itisalsoknownasastructuraldiagram.
PurposeofClassDiagrams:
Analysisanddesignofthestaticviewofanapplication.
Describeresponsibilitiesofasystem.
Baseforcomponentanddeploymentdiagrams.
Forwardandreverseengineering.
17
Members:
UMLprovidesmechanismstorepresentclassmembers,suchasattributesand
methods,andadditionalinformationaboutthem.
Visibility:
Tospecifythevisibilityofaclassmember(i.e.anyattributeormethod),these
notationsmustbeplacedbeforethemember'sname.
+ Public
-Private
# Protected
~ Package
Derivedproperty:
Isapropertywhichvalue(orvalues)isproducedorcomputedfromother
information,forexample,byusingvaluesofotherproperties.
Derivedpropertyisshownwithitsnameprecededbyaforwardslash'/'. Scope:
TheUMLspecifiestwotypesofscopeformembers: instance and classifier,and
thelatterisrepresentedby underlinednames.
• Classifiermembers arecommonlyrecognizedas“static”inmany
programminglanguages.Thescopeistheclassitself.
o Attributevaluesareequalforallinstances o
Methodinvocationdoesnotaffecttheclassifer’sstate
Instancemembers arescopedtoaspecificinstance.
o Attributevaluesmayvarybetweeninstances o
Methodinvocationmayaffecttheinstance’sstate(i.e.change
instance’sattributes)
Toindicateaclassifierscopeforamember,itsnamemustbeunderlined.
Otherwise,instancescopeisassumedbydefault.
Relationships
ClassNotation:
18
UML class isrepresentedbythefollowingfigure.Thediagramisdividedinto fourparts.

• Thetopsectionisusedtonametheclass.
• Thesecondoneisusedtoshowtheattributesoftheclass.
• Thethirdsectionisusedtodescribetheoperationsperformedbytheclass.
• Thefourthsectionisoptionaltoshowanyadditionalcomponents.
Classesareusedtorepresentobjects.Objectscanbeanythinghaving propertiesandresponsibility.
ObjectNotation:
It isrepresentedinthesamewayastheclass.Theonlydifferenceisthename
whichisunderlinedasshowninthefollowingfigure.
Astheobjectisanactualimplementationofaclass,whichisknownasthe
instanceofaclass.Hence,ithasthesameusageastheclass
DOMAINMODEL :
19
CLASSDIAGRAM:
20
TheclassdiagramconsistsoffourclassesnamelyCustomer,Employee,Textile
Company,andBPOsystem.Theassociationbetweentheclassesareasfollows:
Manycustomerscanlogintothesystematanytime.
OneBPOsystemcanmanagemanyemployees.
ManyemployeescanworkforoneTextileCompany.
OnetextilecompanycanhaveoneBPOsystem.
Manycustomercanbuyaproductfromonetextilecompany.
Usingtheidentifyscenariofindtheinteractionbetween
objectsandrepresentthemusingUMLsequencediagram
Ex.no:5
Date:
21
SequenceDiagrams:–
Asequencediagramsimplydepictsinteractionbetweenobjectsinasequential
orderi.e.theorderinwhichtheseinteractionstakeplace.Wecanalsousethe
termseventdiagramsoreventscenariostorefertoasequencediagram.
Sequencediagramsdescribehowandinwhatordertheobjectsinasystem
function.Thesediagramsarewidelyusedbybusinessmenandsoftware
developerstodocumentandunderstandrequirementsfornewandexisting systems
SequenceDiagramNotations:
1.Actors– AnactorinaUMLdiagramrepresentsatypeofrolewhereitinteracts
withthesystemanditsobjects.Itisimportanttonoteherethatanactorisalways
outsidethescopethe.systemweaimtomodelusingtheUMLdiagram.
2.Weuseactorstodepictvariousrolesincludinghumanusers
andotherexternalsubjects.WerepresentanactorinaUML
diagramusingastickpersonnotation.Wecanhavemultiple
actorsinasequencediagram.
Forexample–Heretheuserinseatreservationsystemis
shownasanactorwhereitexistsoutsidethesystemandis
notapartofthesystem
22
Figure– anactorinteractingwithaseatreservationsystem
3.Lifelines– Alifelineisanamedelementwhichdepictsanindividualparticipant
inasequencediagram.Sobasicallyeachinstanceinasequencediagramis
representedbyalifeline.Lifelineelementsarelocatedatthetopinasequence
diagram.ThestandardinUMLfornamingalifelinefollowsthefollowingformat
–InstanceName:ClassName
Figure– lifeline
Wedisplayalifelineinarectanglecalledheadwithitsnameandtype.The
headislocatedontopofaverticaldashedline(referredtoasthestem)as
shownabove.Ifwewanttomodelanunnamedinstance,wefollowthe
samepatternexceptnowtheportionoflifeline’snameisleftblank.
Differencebetweenalifelineandanactor– Alifelinealwaysportraysan
objectinternaltothesystemwhereasactorsareusedtodepictobjects
externaltothesystem.Thefollowingisanexampleofasequencediagram:
23
Figure– asequencediagram
Messages– Communicationbetweenobjectsisdepictedusingmessages.The
messagesappearinasequentialorderonthelifeline.Werepresentmessages
usingarrows.Lifelinesandmessagesformthecoreofasequencediagram.
Messagescanbebroadlyclassifiedintothefollowing categories :
Figure– asequencediagramwithdifferenttypesofmessages
24
Synchronousmessages– Asynchronousmessagewaitsforareplybeforethe
interactioncanmoveforward.Thesenderwaitsuntilthereceiverhascompleted
theprocessingofthemessage.Thecallercontinuesonlywhenitknowsthatthe
receiverhasprocessedthepreviousmessagei.e.itreceivesareplymessage.A
largenumberofcallsinobjectorientedprogrammingaresynchronous.Weusea
solidarrowheadtorepresentasynchronousmessage.
Figure– asequencediagramusingasynchronousmessage AsynchronousMessages–

Anasynchronousmessagedoesnotwaitforareply
fromthereceiver.Theinteractionmovesforwardirrespectiveofthereceiver
processingthepreviousmessageornot.Weusealinedarrowheadtorepresent
anasynchronousmessage
Createmessage– WeuseaCreatemessagetoinstantiateanewobjectinthe
sequencediagram.Therearesituationswhenaparticularmessagecallrequires
thecreationofanobject.Itisrepresentedwithadottedarrowandcreateword
labeledittospecifythatitisthecreatemessagesymbol..
Forexample–Thecreationofaneworderonae-commercewebsitewould
requireanewobjectofOrderclasstobecreated.
25
Figure– asituationwherecreatemessageisused DeleteMessage–

WeuseaDeleteMessagetodeleteanobject.Whenan
objectisdeallocatedmemoryorisdestroyedwithinthesystemweusethe
DeleteMessagesymbol.Itdestroystheoccurrenceoftheobjectinthesystem.It
isrepresentedbyanarrowterminatingwithax.
Forexample–Inthescenariobelowwhentheorderisreceivedbytheuser,the
objectoforderclasscanbedestroyed.
Figure– ascenariowheredeletemessageisused SelfMessage–

Certainscenariosmightarisewheretheobjectneedstosenda
messagetoitself.SuchmessagesarecalledSelfMessagesandarerepresented withaUshapedarrow.
26
Figure– selfmessage
Forexample–Considerascenariowherethedevicewantstoaccessits
webcam.Suchascenarioisrepresentedusingaselfmessage
Figure– ascenariowhereaselfmessageisused
ReplyMessage– Replymessagesareusedtoshowthemessagebeing
sentfromthereceivertothesender.Werepresentareturn/replymessage
usinganopenarrowheadwithadottedline.Theinteractionmovesforward
onlywhenareplymessageissentbythereceiver.
27
Figure– replymessage
Forexample–Considerthescenariowherethedevicerequestsaphoto
fromtheuser.Herethemessagewhichshowsthephotobeingsentisa replymessage.
Figure– ascenariowhereareplymessageisused
FoundMessage– AFoundmessageisusedtorepresentascenariowherean
unknownsourcesendsthemessage.Itisrepresentedusinganarrowdirected
towardsalifelinefromanendpoint.Forexample:Considerthescenarioofa hardwarefailure.
28
Figure– foundmessage
Itcanbeduetomultiplereasonsandwearenotcertainastowhatcausedthe hardwarefailure.
Figure– ascenariowherefoundmessageisused
LostMessage– ALostmessageisusedtorepresentascenariowherethe
recipientisnotknowntothesystem.Itisrepresentedusinganarrowdirected
towardsanendpointfromalifeline.Forexample:Considerascenariowherea warningisgenerated
29
Figure– lostmessage
Thewarningmightbegeneratedfortheuserorothersoftware/objectthat
thelifelineisinteractingwith.Sincethedestinationisnotknownbeforehand,
weusetheLostMessagesymbol.
Guards– TomodelconditionsweuseguardsinUML.Theyareusedwhenwe
needtorestricttheflowofmessagesonthepretextofaconditionbeingmet.
Guardsplayanimportantroleinlettingsoftwaredevelopersknowtheconstraints
attachedtoasystemoraparticularprocess.
Forexample:Inordertobeabletowithdrawcash,havingabalancegreaterthan
zeroisaconditionthatmustbemetasshownbelow
• Usedtomodelandvisualizethelogicbehindasophisticatedfunction, operationorprocedure.
30
• Visualizehowmessagesandtasksmovebetweenobjectsorcomponentsin asystem.
SEQUENCEDIAGRAM:
31
32
Ex.no:6 Usingidentifyscenariosfindtheinteractionbetweenobject
andrepresentthemusingUMLcommunicationdiagram
Date:
Collaborationdiagram:
A collaborationdiagram,alsoknownasacommunicationdiagram,isan
illustrationoftherelationshipsandinteractionsamong software objects inthe
UnifiedModelingLanguage(UML).Thesediagramscanbeusedtoportraythe
dynamicbehaviorofaparticular usecase anddefinetheroleofeachobject.
Collaborationdiagramsarecreatedbyfirstidentifyingthestructuralelements
requiredtocarryoutthefunctionalityofaninteraction.Amodelisthenbuiltusing
therelationshipsbetweenthoseelements.Severalvendorsoffersoftwarefor
creatingandeditingcollaborationdiagrams. Notationsofacollaborationdiagram:
A collaborationdiagram resemblesa flowchart thatportraystheroles,

functionalityandbehaviorofindividualobjectsaswellastheoveralloperationof thesystemin
realtime.Thefourmajorcomponentsofacollaborationdiagram are:
1.Objects-Objectsareshownasrectangleswithnaminglabelsinside.The
naminglabelfollowstheconventionofobjectname: classname.Ifanobject
hasapropertyorstatethatspecificallyinfluencesthecollaboration,this shouldalsobenoted.
2.Actors-Actorsareinstancesthatinvoketheinteractioninthediagram.Each
actorhasanameandarole,withoneactorinitiatingtheentireusecase.
3.Links-Linksconnectobjectswithactorsandaredepictedusingasolidline
betweentwoelements.Eachlinkisaninstancewheremessagescanbesent.
4.Messages-Messagesbetweenobjectsareshownasalabeledarrowplaced
nearalink.Thesemessagesarecommunicationsbetweenobjectsthat
conveyinformationabouttheactivityandcanincludethesequencenumber.
33
34
Drawrelevantstatechartsandactivitydiagram
Ex.no:7
Date:
Activitydiagram:
Activity diagram describe activities which involve concurrency and
synchronization,whichareavariationofstatediagramsthatfocusesontheflow
ofactionsandevents.Theycanbeusedfor:
• Tomodelahumantask(abusinessprocess,forinstance).
• Todescribeasystemfunctionthatisrepresentedbyausecase.
• Inoperationspecifications,todescribethelogicofanoperation.
35
36
performedbythecustomer.
STATEDIAGRAM:
StateMachineDiagram:
AstatemachineDiagram(orstartdiagram,alsocalledstatechartofstatetransition diagram)isabehavior
whichspecifiesthesequence ofstatesan entity(orobject) visits duringitslifetimeinresponse
toevents,togetherwithits responsestothose events
Keyconcepts:
State
Astateisaconditionduring thelifeofanobjectduring whichitsatisfiessome
condition,performssome activity,orwaitsforsome externalevent.
Astatemachinediagramisagraphconsistingof:
• States(simplestatesorcompositestates)
• Statetransitionsconnectingthestates Example:
InitialandFinalStates:
• The initialstate
ofastatemachinediagram,knownasaninitialpseudostate,isindicatedwithasolidcircle.Atra
nsitionfromthisstatewillshow thefirstrealstate
• The finalstate ofastatemachinediagramisshownasconcentriccircles.
37
Anopenloopstatemachinerepresentsanobjectthatmayterminate
beforethesystemterminates,whileaclosedloopstatemachinediagram
doesnothaveafinalstate;ifitisthecase,thentheobjectlivesuntilthe
entiresystemterminates.
STATEDIAGRAM:
38
Implementsystemasperthedetaileddesign
Ex.no:8
Date:
ClassName:Customer
PublicclassCustomer{
Publicintegercustomerid;
PublicStringcustname;
Publicintegerloginid;
Publiclongphoneno;
PublicStringqueries;
PublicVectormytextilecompany;
publicVector1; publicVector1;
Publicvoidaddcustomer(){
}
Publicvoiddelete(){
}
Publicvoidupdate(){
}
Publicvoidpostqueries(){
}
} ClassName:employee
PublicclassEmployee{
publicStringemployeename;
Publicintegerloginid; publicStringpassword;
publicintegernoofclarification;
publicVector1; publicbposystem1;
PublicVector1;
PublicVector*;
Publicvoidadd(){
}
Publicvoiddelete(){
}
Publicvoidupdate(){
}
Publicvoidgivesolution(){
39
}
}
ClassName:Textilecompany
Publicclasstextilecompany{
PublicStringcompanyname;
PublicStringaddress;
Publiclongphoneno;
Publicintegernoofproduct;
PublicVectorhas;
PublicVector*;
PublicVectormycustomer;
PublicVector*;
Publicvoidaddcustomer(){
}
Publicvoidupdate(){
}
Publicvoidservice(){
}
}
ClassName:Bposystem
PublicclassBposystem{
PublicStringempdetails
PublicStringcomdetails;
PublicVectorhas;
Publicemployee*;
PublicVector*;
Publicvoidupdate(){
}
}
Testsoftwaresystemforallsystemasperusecase
Ex.no:9
Date:
Classname:BPOsystem
40
Importjava.util.vector;
PublicclassBPOsystem
{
PublicStringempdetails; PublicStringcomdetails;
PublicStringupdate(Stringin){
If(in.equals(“kavi”))
Return“true”;
Else
Return“false”;
}
}
41
42
Ex.no:10 Improvereusabilityandmaintainabilitybyapplying
appropriatedesignpattern
Date:
Forillustrationpurposeabstractfactorypatternisusedtodescribetheproposedmethod.
Abstractfactorypatternknownasacreationalpattern,providesamethodto
encapsulateagroupofindividualfactoriesthathaveafamiliarthemewithoutspecifying
theirconcreteclasses.Inusualcase,theclientsoftwarecreateaconcrete
implementationoftheabstractfactorythenusinggenericinterfaceofthefactoryto
createtheconcreteobjectswhichispartofthetheme.Theclientdoesn‟tknowwhich
concreteobjectsgetsfromalloftheseinternalfactories,sinceitusesonlythegeneric
interfacesoftheirproducts.Abstractproductsdescribeinterfaceforeverydifferent
productsofasingleproductfamily.Concreteproductsimplementtheabstractproduct
interfacewhichisreturnedbycreationalmethodsofconcretefactories.Abstractfactory
definestheinterfaceforcreatingproductswhichiscommontoallconcretefactories.
Concretefactoriesimplementcreationalmethodsoftheabstractfactoryandeach
concretefactoryshouldcorrespondtoaspecificproductsvariantasshowninFigure.
Purposeofabstractfactorydesignpatternistoprovideaninterfaceforcreatingfamilies
ofrelatedobjectswithoutspecifyingconcreteclasses.ThefollowingFigure()showsthe
exampleofabstractfactorydesignpatternforuserloginwheretwoconcretefactory
andconcreteproductusedforexecution.
43
Figure:AbstractFactoryDesignPatternforUserLogin
Usingproposedmethoddesignpatternasseswhererequirementiswelldocumented
andfixedwhichisusedasinput.Asstep1firstlyidentifythedesignproblemusing
alternativedesignsolutionsfromliteratureandexperience,andsolveusingabstract
factorydesignpattern.Instep2maintainability,reusability,understandability,flexibility,
composability,completeness,stability,simplicity,andexpandabilityareselectedas
designobjective.Usingstep3appropriatesolutionisselectedasstep4(tool)andstep5
(mathematicalformation).Instep4maintainability,reusability,understandability,and
flexibilityarecalculatedusingprescreensdesignpatternadvisortool.Instep5
composability,completeness,stability,simplicity,andexpandabilityaremeasuredusing
mathematicalformation.Instep6,combinestep4and5outputtogetrequiredquality
product.Assessmentoftheseninequalityattributesarediscussedas:
Maintainability:Useofadesignpatternessentiallycomplicatesdesigntousuallyadd
abstractclassesandadditionalassociationstoemployadesignpattern.Thekey
advantageofusingdesignpatternisthattheresultingsoftwareshouldbeeasierto
adapt,tomodifyfewerclasses,toaddfunctionalitytosoftware.So,maintenanceClient AbstractFactory
+doAction1:void +doAction2:void Abstract Product
+doAction:voidAbstractFactoryconcreteProduct1concreteProduct2concreteFactory1
concreteProduct1:AdminconcreteProduct2:UserconcreteProduct1+doAction:void
concreteFactory2concreteProduct1:AdminconcreteProduct2:UserconcreteProduct2
+doAction:void95programmersshouldhavetouselessefforttoadaptthesechanges.
Everyintroducedpatterncausedanimprovementindifferentqualityattributes.
Reusability:Designpatternsarereusablemicroarchitecturesthataddtooverallsoftware
architecture.Designpatternsdetainstaticanddynamicstructureandcollaborationsof
componentsinsuccessfulsolutionstoproblemsthatoccurwhendevelopingsoftware
likebusinessdataprocessing,databases,graphicaluserinterfaces,telecommunications,
anddistributedcommunicationsoftware.Patterns96helpdevelopmentofreusable
componentsandframeworksbyusingstructureandcollaborationofparticipantsin
softwarearchitectureatalevelhigherthansourcecodeandobjectorienteddesign
44
modelsthatfocusonindividualobjectsandclasses.Thus,patternsfacilitatereuseof
softwarearchitecture,evenwhenadditionalformsofreuseareinfeasible.Anempirical
investigationonreusabilitysoftwarepackages,attemptstoempiricallyinvestigate
reusabilityofdesignpatterns,classes,andsoftwarepackagestoidentifythemost
beneficialstartingpointsforwhiteboxreuse,whichisprettypopularamongOSS
CONCLUSION:
TheBPOsystemhelpsinclarifyingthequeriesofthecustomer.Themain
advantagesofusingthissystemisthetimemanagement.ThustheprojectforBPO
managementsystemwasdesignedandcodesaregeneratedandthenitwas successfullyexecuted.
LIBRARY
MANAGEMENT
SYSTEM
1
Ex.No:1
Problem Statement
Date:
Aim:
To develop the problem statement.
Problem Statement:
The purpose of Library Management System is to allow for storing details of

a large number of books, magazines, journals, thesis and allow for add, search,
borrow, return facilities separately to librarian, staff, student and administration.
Different privileges are given to different types of users. This LMS should provide
user friendly access to the users.
Copyright by P. S. KEERTHANA, G .KEERTHANA, P. R. KAVIYASHREE

4
1. Introduction
1.1 Purpose
The main objective of this document is to illustrate the requirements of the project Library
Management System .The document gives the detailed description of the both functional and non-
functional requirements proposed by the client .The purpose of this document is to provide the
detailed objectives and requirements of the system .This document describes the hardware and
software interface requirements using ER diagram and UML diagram.
*Conventions for title:

Font size: 18
Font style: Bold
Font face: Times New Roman
*Conventions for subtitle:
Font size: 14
Font style: Bold
*Conventions for body:
Font size: 12
This document is intended for developers, project managers, marketing staff, users, testers and
document writers. This document starts with introduction that contains purpose, document
conventions, product scope and references followed by the overall descriptions .Which contains
product perspective, product functions, user classes and characteristics, operating environment,
design and implementation constraints, user documentation, assumption and dependencies followed
by external interface requirements.
1.4 Product Scope
Library Management System is basically used to manage the books available in library and the
Details about the books. Library Management System allows for storing the details of large number
of books, magazines, journals, and allow for add, search, borrow, returning facilities separately to
5
administrator or staff and students. Different privileges are given to different types of users .we can
add new features as and when we require. Making reusability as it is possible where there is a easy
flexibility in all the modules
The product is used as a complete user interface for library management process and library usage
from ordinary users.
1.5 References
➢ Books
• Software Engineering: A Practitioner’s approach fifth edition by Roger S. Pressman
• Object Oriented Analysis and Design with Applications (3 rd edition) by Michael W. Engel,
and Bobbi J. Young.
➢ Websites
• http://www.freestudentprojects.com/studentprojectreport/project-srs/library-
management-system-project-srs-document
The proposed Library Management System will take care of current book details at any point of time.
The book issue, book return will update the current book details automatically so the user will get the
update current book details.
Library Management System is basically used to collect the book details, visitor’s details, the book
issued and availability of book in the particular library. In this software there is separate login account
for library administrator, librarian and visitors. The admin provided with access to librarian and
visitors account.
Library Member
Update details of books Register/Login
Library
Manageme
nt
System
6
Issue, search, return, reserve books

LibL
Register/Login
Library Database
We have three levels of users:

• User module: In the user module, user will check the availability of books.
• Issue book
• Reserve book
• Return book
• Fine details
• Library module:
• Add new book
• Remove books
• Update details of book
• Administration module:
• Register user
• Entry book details
• Book issue
The product will be operated in windows environment. The hardware configuration include hard disk: 40 GB,
Monitor: 15”color monitor, Keyboard: 122 keys. The basic input devices required are keyboard, mouse and
output devices are monitor, printer, etc.
7
Any update regarding the book from the library is to be recorded to have update and correct values
and any fine on a member should be notified as soon as possible and should be correctly calculated.
User manual is provided for better understanding of this system. Tutorials are provided along with
this system. So the user may know about the system functionalities clearly.
The assumptions are:

➢ The information of all users, books and libraries must be stored in a database that is
accessible by user and the admin.
➢ The system should have more storage capacity and provide for fast access.
➢ User must have their correct user names and passwords to enter into their online
accounts and do actions.
➢ The coding should be error free.
➢ The system should be user friendly.
The dependencies are:

➢ The specific hardware and software due to which the product will be run.
➢ On the basics of listing requirements and specification the project will be developed
and run.
➢ The information of all users must be stored in a database that should be accessible by
the library system.

3.1 User Interfaces
Library Management System allows user to view reports like book issued/returned in between
particular time. It provides verification and search facility based on different criteria. The user
interface should be able to interact with the user module and it must be dedicated to login/logout
module. The design should be simple and all the different interfaces should follow standard template.
8
Server side:
OS –Windows 9x
Processor: Pentium 3.0 GHZ or higher
RAM: 256 Mb or more
Hard drive: 10 GB or more
Client side:
OS: Windows 9x
Processor: Pentium 2.0 GHZ or higher
RAM: 256 MB or more
➢ Database SQL server

➢ Platform: Java language
➢ MS- windows operating system
3.4Communications Interfaces
Windows
4. System Features
4.1System Feature 1

The users of the system should be provided the surety that their account is secure. For that user
authentication and validation of members using their unique member ID can be used.
4.1.2 Functional Requirement
Proper monitoring by the administrator which includes updating the status, showing the details of
books and member’s account, assigning fine to the members who do not return the book before due
date should be done. Only administrator will see and manage the account of member.
Actors
9
• Administrator
• Member
• Librarian
Req-1: Functional requirement for users such as members
Precondition- The member should have valid user ID.
Post condition- If the user successfully logged into the system they may further interact with the
system, otherwise the system shows an error message.
Req-2: Functional requirements for administrator
Precondition- The administrator should have valid system ID and password for administration login.
Post condition- If admin successfully logged into the system then he/she can be made updates on the
system.

The performance of the system should be fast and accurate. Library Management System shall
handle expected and unexpected errors in way that prevents loss in information. The system should
be able to handle large amount of data. Thus it accommodates high number of books and user’s
details.
The database may get crashed at any certain time due to virus or operating system failure. Hence, it
is required to take the database is not lost. Proper UPS/inverter facility should be provided in case
of power supply failure.
System should use secured database. Normal users can just read the information but they cannot
edit or modify anything expect their personal and some other information. Proper user
authentication must be provided. No one should be able to hack the user’s password. There should
be different accounts for administrator and user.
10
All the administrators have the rights to create changes to the system. But the members or other
users cannot do changes. The quality of the database is maintained in such a way so that it can be
very user friendly to all the users of the database. The user be able to easily download and install the
system.
5.5 Business Rules
This includes the rules and regulations that the system users should follow. This includes cost of the
project. Neither admin nor member should cross the rules and regulations.
There are different categories of users namely staff, librarian, admin, students, etc. Depending upon
the category of users the access rights are decided. All the users except the librarian only have the
rights to retrieve the information about database.
11
➢ Administrator: Who updates the record
➢ User/member: A general login ID is provided to most users

➢ Use case: A diagram of the project showing a basic overview.
➢ Interface: It is used to communicate with a database.
12
Ex.No:3
Identify use cases and develop use case model
Date:
Use case diagram:

A use case diagram at its simplest is a representation of a user's interaction with the system that shows
the relationship between the user and the different use cases in which the user is involved. A use case
diagram can identify the different types of users of a system and the different use cases and will often
be accompanied by other types of diagrams as well. The use cases are represented by either circles or
ellipses.
The purpose of use case diagram is to capture the dynamic aspect of a system. However, this definition
is too generic to describe the purpose, as other four diagrams (activity, sequence, collaboration, and
Statechart) also have the same purpose.
System
Use Case
Actors
Relationships
use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use
13
case is needed by another in order to perform a task. An "extends" relationship indicates alternative
options under a certain use case.
The main use cases are maintain log, issue book, returned books, search book, borrow book.
Maintain log:
Brief format:
The librarian is responsible for maintaining the log details. The details consists of several actions like
adding books, removing books and updating the details. If new books are arrived the complete details
of the books should be updated in the catalog. The borrowed books should be removed from the
catalog. After the books are returned the log should be updated.
Casual format:
The details of the added and borrowed books should be updated periodically. If these are not done
properly then it leads to complexity in searching the books for users. If the borrowed books are not
removed from the catalog then it leads to unavailability of books after the users search. It leads to
inconsistency.
Alternate scenario:
The available book details should be properly updated by the librarian. It should be checked
periodically.
14
Fully dressed format:
Use case Section Comments
Use case name Maintain the log
Scope To maintain the details of the available books
Level Adding new books, removing books
Primary actors Librarian, system database
Stakeholders and Interests Library administration
Preconditions The details of the books
Main success scenario All the details are periodically updated
Failure scenario Any details of the available books are not there
in the catalog
Extensions Periodically update the database
Special requirement The catalog which contains the complete details

of available books
Secondary actors Library administration

15
16
Ex.No:4
Identify the conceptual classes and develop a
Date: domain model with UML class diagram
Class diagram:
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not
only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on
the system. The class diagrams are widely used in the modelling of object oriented systems because
they are the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints.
It is also known as a structural diagram.
Members:
Visibility:
+ Public
- Private
# Protected
~ Package
Derived property:
Is a property which value (or values) is produced or computed from other information, for example,
by using values of other properties.
17
Scope:

To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance scope
Relationships
Class Notation:

18
Object Notation:
As the object is an actual implementation of a class, which is known as the instance of a class. Hence,
it has the same usage as the class.
The main classes of Library management system are Book, Librarian, Member, Bill. The Book class
consists of the attributes book id, author, price, publisher and the methods display and location. The
Librarian class consists of the attributes name, password and the methods issue book, return book,
update book, calculate fine, verify number. The Member class consists of the attributes member id,
number of books, name, mail id, phone and the methods search book, increase book, pay fine. The
Bill class consists of the attributes bill number, date, member id, amount and the method create bill.
19
Class diagram:
20
Ex.No:5 Using the identified scenario find the interaction between

objects and represent them using UML sequence
Date:
diagram
Sequence Diagrams: –
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order in
which these interactions take place. We can also use the terms event diagrams or event scenarios to
refer to a sequence diagram. Sequence diagrams describe how and in what order the objects in a
system function. These diagrams are widely used by businessmen and software developers to
1. Actors – An actor in a UML diagram represents a type of role where it interacts with the system
we aim to model using the UML diagram.
21

3. Lifelines – A lifeline is a named element which depicts an individual participant in a sequence
elements are located at the top in a sequence diagram. The standard in UML for naming a
Figure – lifeline
22
We display a lifeline in a rectangle called head with its name and type. The head is located on
top of a vertical dashed line (referred to as the stem) as shown above. If we want to model an
blank.
the system whereas actors are used to depict objects external to the system. The following is an
example of a sequence diagram:

23

1. Synchronous messages – A synchronous message waits for a reply before the
interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver
has processed the previous message i.e. it receives a reply message. A large number
of calls in object oriented programming are synchronous. We use a solid arrow head
to represent a synchronous message.

2. Asynchronous Messages – An asynchronous message does not wait for a reply from
the receiver. The interaction moves forward irrespective of the receiver processing the
previous message or not. We use a lined arrow head to represent an asynchronous
message.
24
3. Create message – We use a Create message to instantiate a new object in the

sequence diagram. There are situations when a particular message call requires the
creation of an object. It is represented with a dotted arrow and create word labelled
on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would require a
new object of Order class to be created.

• Delete Message – We use a Delete Message to delete an object. When an object is deallocated
For example – In the scenario below when the order is received by the user, the object of order
25

• Self Message – Certain scenarios might arise where the object needs to send a message to itself.
Such messages are called Self Messages and are represented with a U shaped arrow.

26
For example – Consider a scenario where the device wants to access its webcam. Such a scenario
is represented using a self message.

• Reply Message – Reply messages are used to show the message being sent from the receiver
to the sender. We represent a return/reply message using an open arrowhead with a dotted line.
The interaction moves forward only when a reply message is sent by the receiver.

For example – Consider the scenario where the device requests a photo from the user. Here the
27

• Found Message – A Found message is used to represent a scenario where an unknown source
sends the message. It is represented using an arrow directed towards a lifeline from an end point.
For example: Consider the scenario of a hardware failure.
28


• Lost Message – A Lost message is used to represent a scenario where the recipient is not known
to the system. It is represented using an arrow directed towards an end point from a lifeline. For

symbol.
Guards – To model conditions we use guards in UML. They are used when we need to restrict the
29
• Used to model and visualize the logic behind a sophisticated function, operation or procedure.
The sequence diagram represents the interactions between Member, LMS system and Librarian.
The interactions starts with log in. Member enters the user name and password in the system.
The system verifies the username and password with the database. If it is valid it shows the
catalog. Otherwise it shows error message. The member searches books in the catalog. If the
searched books are available then it provides book. Otherwise it shows error message. After
getting book the member log outs the system. When the books are returned it calculates fine if
the due date is exceeded. Then member pays the bill.
30
Sequence diagram:
31
Ex.No:6 Using the identified scenario find the interaction between

objects and represent them using UML collaboration
Date:
diagram
These diagrams can be used to portray the dynamic behavior of a particular use case and define the
role of each object.

A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of
individual objects as well as the overall operation of the system in real time. The four major
1.Objects- Objects are shown as rectangles with naming labels inside. The naming label follows the
convention of object name: class name. If an object has a property or state that specifically influences
the collaboration, this should also be noted.
2.Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a name and
a role, with one actor initiating the entire use case.
3.Links- Links connect objects with actors and are depicted using a solid line between two elements.
Each link is an instance where messages can be sent.
4.Messages- Messages between objects are shown as a labeled arrow placed near a link. These
32
33
Ex.No:7
Draw relevant State chart and activity diagram
Date:
Activity diagram:
34
Activity diagram shows the flow of activities that the system carries out. The activities are login,
authenticate, show books, search books, issue book, remove book, receive book, return book,
calculate fine, add book and log out. These actions are sequentially takes place in the system. Activity
diagram has swim lanes. This system consists of Librarian, Member, LMS system.
35
Activity diagram:
36
State Machine Diagram:
behaviour which specifies the sequence of states an entity (or object) visits during its lifetime in
Key concepts:
State
Example:

closed loop state machine diagram does not have a final state; if it is the case, then the object
lives until the entire system terminates.
37

38
Ex.No:8 Implement the system as per the detailed design

Date:
The system is implemented by forward engineering. That is the code for the system is created by
converting the class diagram into the code using Argo uml.
Book:
Public Class Book{
Public bookid;
Public author;
Public price;
Public publisher;
Public void display(){};
Public void location(){};

}
Librarian:
Public class Librarian{
Public name;
Public password;
Public void issuebook(){};
Public void returnbook(){};
Public void updatebook(){};
Public void calculatefine(){};
Public void verifynumber(){};
Bill:
39
Public class Bill{
Public billno;
Public date;
Public memid;
Public amount;
Public void createbill(){};}
Public class Member{
Public memid;
Public noofbooks;
Public name;
Public mailed;
Public phone;
Public void searchbook(){};
Public void increasebook(){};
Public void payfine(){};
Student:
Public class Student extends Member{
Faculty:
Public class Faculty extends Member{}

40
Ex.No:9 Test the software system for all scenario identified as per the use
Date:
case diagram
Success scenario:
41
Failure scenario:
42
Ex.No:10 Improve reusability and maintainability by applying

Date: appropriate design pattern
factory pattern known as a creational pattern, provides a method to encapsulate a group of individual
factories that have a familiar theme without specifying their concrete classes. In usual case, the client
software create a concrete implementation of the abstract factory then using generic interface of the
factory to create the concrete objects which is part of the theme. The client does not know which
concrete objects gets from all of these internal factories, since it uses only the generic interfaces of
their products. Abstract products describe interface for every different products of a single product
family. Concrete products implement the abstract product interface which is returned by creational
methods of concrete factories. Abstract factory defines the interface for creating products which is
common to all concrete factories. Concrete factories implement creational methods of the abstract
factory and each concrete factory should correspond to a specific products variant as shown in Figure.
objects without specifying concrete classes. The following Figure( ) shows the example of abstract
execution.
43

Using proposed method design pattern asses where requirement is well documented and fixed which
is used as input. As step 1 firstly identify the design problem using alternative design solutions from
literature and experience, and solve using abstract factory design pattern. In step 2 maintainability,
reusability, understandability, flexibility, composability, completeness, stability, simplicity, and
expandability are selected as design objective. Using step 3 appropriate solution is selected as step 4
(tool) and step 5 (mathematical formation). In step 4 maintainability, reusability, understandability,
and flexibility are calculated using percerons design pattern advisor tool. In step 5 composability,
completeness, stability, simplicity, and expandability are measured using mathematical formation. In
step 6, combine step 4 and 5 output to get required quality product. Assessment of these nine quality
Maintainability:
additional associations to employ a design pattern. The key advantage of using design pattern is that
the resulting software should be easier to adapt, to modify fewer classes, to add functionality to
software. So, maintenance Client AbstractFactory +doAction1:void +doAction2:void
AbstractProduct +doAction:void AbstractFactory concreteProduct1 concreteProduct2
+doAction:void concreteFactory2 concreteProduct1: Admin concreteProduct2: User
concreteProduct2 +doAction:void 95 programmers should have to use less effort to adapt these
Reusability:
patterns detain static and dynamic structure and collaborations of components in successful solutions
44
to problems that occur when developing software like business data processing, databases, graphical
user interfaces, telecommunications, and distributed communication software. Patterns 96 help
development of reusable components and frameworks by using structure and collaboration of
participants in software architecture at a level higher than source code and object oriented design
models that focus on individual objects and classes. Thus, patterns facilitate reuse of software
architecture, even when additional forms of reuse are infeasible. An empirical investigation on
reusability of design patterns and software packages, attempts to empirically investigate reusability
of design patterns, classes, and software packages to identify the most beneficial starting points for
Conclusion:
The SRS for Library management system is created and the use cases are implemented using use
case diagram. The class diagram, sequence diagram, collaboration diagram, State chart and activity
diagrams are implemented for library management system. The detailed design of the system is
implemented and tested. Reusability and maintainability are improved by appropriate design
patterns.
STUDENT
INFORMATION
SYSTEM
1
EX.NO:1 Problem statement
DATE:
Aim:
To develop a problem statement.
Problem Statement:
Student information system is an automated and use friendly. It is used for managing the student
date. This system deal with all kinds of details such as academic record, college details, course
details, curriculum and placement details. It track the attendance percentage, exam details,
project details and exam results. It can be accessed only by the authorised user. The purpose of
this system is the reduction of time spend on maintaining and organising the student record. The
student profile gives the overview and performance details in all fields.
3
Table of Contents
Table of Contents ii
Revision History ii
1. Introduction 5
1.1 Purpose 5
1.2 Document Conventions 5
1.3 Intended Audience and Reading Suggestions 5
1.4 Product Scope 5
1.5 References 5
2. Overall Description 6
2.1 Product Perspective 6
2.2 Product Functions 6
2.3 User Classes and Characteristics 6
2.4 Operating Environment 6
2.5 Design and Implementation Constraints 6
2.6 User Documentation 7
2.7 Assumptions and Dependencies 7
3. External Interface Requirements 8
3.1 User Interfaces 8
3.2 Hardware Interfaces 8
3.3 Software Interfaces 8
3.4 Communications Interfaces 8
4. System Features 9
4.1 System Feature 1 9
4.1.1 Description and Priority 9
4.1.2 Stimulus/Response Sequences 9
4.1.3 Functional Requirements 9
4.2 System Feature 2 11
5. Other Nonfunctional Requirements 11
5.1 Performance Requirements 11
5.2 Safety Requirements 11
5.3 Security Requirements 11
5
Introduction
Purpose
The Software Requirement Specification document is to provide a detailed overview of the
software products. It contains the complete software requirements for online student
information system and provides the full details about the individuals.
Document Conventions
● The font style used in this complete document is Times New Roman.
● The size of content is 12.

● The Sub headings are of size 14.
Intended Audience and Reading Suggestions
The different types of readers are students, teachers, parents and it includes the whole
administration. For knowing about this system in details read the descriptions of below given
headings such as product scope and references.
Product Scope
Student information system efficiently provides the mechanism to edit the student
information form which makes the system flexible. This gives better feedback to the users.
References
The References of this SRS are,

1. IEEE Recommended practice for software requirements specification-
IEEE std 830-1998.
2. “Software Engineering”-By K.K.Aggarwal and Yogesh Singh.New
agepublishing house 2nd edition.
6
Overall Description
Product Perspective
The Student Information System which is being developed is on-line student information
system. The proposed system will be compatible with Microsoft Windows Operating System. This
system is a new self contained and a replacement for all traditional and outdated means of tracking
student information. The components of this system are students, staff and database administrator.
This system is used instead of databases using manual or outdated hardcopy.
Product Functions
The student information management system is used to maintain and manage the
information of students. This helps the user to easy access the information of students. This
software is also helpful for the administrator because he can easily update and delete the records
of the students.
User Classes and Characteristics
The various actors of this system include students, teachers, parents and administrators.
Use case of this system are login, logout, academic details, events, attendance, time table. The
functions of login and logout are security and privacy purpose. Whenever any events or functions
take place the use case event gives the notification and alert the users. Academic details gives the
overall academic performance of the student. Every day’s schedule is provided by timetable. The
attendance status gives us the presence or absence of the student.
Operating Environment
The student information system runs on Windows 7, for 32 bit/x86 and 64 bit/x64 PC
architectures. The software will be written in java. This system is GUI based. The system will run
off a cloud based platform. The cloud based server will utilize SQL database running on the cloud.
The product can run on any browser.
Design and Implementation Constraints
● The system is developed using java.
● The backend is MY SQL.
● Items and issues that may limit the options are ethical and legal constraints with
regard to student information management systems.
● The system should be user friendly so that it is easy for the user to use and also
it should have backup capabilities.
7
● There will be only one ADMIN who has all rights with regards to managing
information such as updating, deleting, inserting the details of students.
● The student should have correct username and password so that they can login
successfully.
● The information of all students are stored in the database which is connected to
the university computer.
User Documentation
This document is helpful for students, admin and parents.
● Students – They can be able to view their attendance status, timetable, internal marks.
As a whole, this document paves the way for the student to evaluate themselves.
● Parents – They can easily analyze the behavior of the student in all aspects.
● Admin – They can easily retrieve the details of the particular student when it is needed.
Assumptions and Dependencies
● The users have sufficient knowledge of computers.
● The University computer should have an Internet connection and Internet server
capabilities.
● The administrators should have more knowledge of the internals of the system and is
able to rectify the small problems that may arise due to disk crashes, power failures and
other to maintain the system.
External Interface Requirements
User Interfaces
The student information system will have the following user friendly and menu driven
interfaces
● Login: to allow the entry of only authorized users through valid id and password.
● Faculty details: to maintain faculty details.
● Academic details: to maintain students marks and their evaluation reports.
● Profile: to maintain students personal records and information.

It will also display error message when password was incorrect and when the server page
not loaded or it will display the message that the site was incorrect.
8
Hardware Interfaces
● Screen resolution of at least 640*480 or above.

● Support for printer ( doc matrix, desk jet , laser jet ).
● Computer System will be in the networked environment since it is a multi user system.
Software Interfaces
● MS-Windows operating system.

● Microsoft visual Basic 6.0 for designing front end.
● MS SQL server 2000 for backend.
● Platform: Java language
● It is a global data area and it is also multitasking.
Communications Interfaces
As it is a web based application, there are protocols that are needed to directly interact with
the users. It is developed using TCP/IP protocol.
System Features
System Features is broadly classified into two. They are
1. Administrator
2. User
System Feature 1
Administrator – The only person who is responsible for the activities of the whole system.
The administrator knows everything in detail about the system and he/she is the only authority to
update , delete, and retrieve information of a particular student or a group of students even in case
of emergency.
Description and Priority

The Student Information System maintains the personal and academic information of every
student. The project is of high priority. Because it is very difficult to maintain such a details of
thousands of students.
Stimulus/Response Sequences
9
● User can enter the login id and password.

● Displays the personal and academic information.
● If any error, inform to the admin.
● Logout safely.
Functional Requirements
● This system can manage day to day attendance of all the students.
● This system manages all the details of the exam and result notifications faster than
SMS and email.
● This system should be provided to the companies so that they can overview and offer
projects, internships to the students.
REQ-1:Actors:
● Administrator
● Student
● Faculty
Functional requirements for users such as students and faculties.
Pre Condition – The user must have valid user ID and password.
Post Condition – If the use case is successful, the actor logged into the system. If
not, the system state remains unchanged.
Basic Flow: Starts when actors wishes to login to the system.

● The system request that the actor specify the function user would like to
perform.
● Once the actor provides the required information, one of the following is
executed.
● If the actor selects “Login”, the login sub flow is executed.
● If the actor selects “Change password”, the change password sub flow is
executed.
REQ-2:
Functional requirements for administrator.
Pre Condition – The administrator must have valid system id and password for
administration login.
10
Post Condition – if the use case is successful, the administrator will be logged into
the system. If not, the system state remains unchanged.
Basic Flow: Starts when administrator wishes to login to the system.

● The system request that the administrator specify the function user
would like to perform.
● Once the administrator provides the required data, one of the
following will be executed.
● If the administrator selects “login”, the login will be executed.
● If the administrator gives “change password”, the change password
will be executed.
System Feature 2
The user is the person who has benefited from the system. He/she plays a major role in the
behavior and aspects of the system. The system or document is mainly based on the student and
parents.
Other Nonfunctional Requirements
Performance Requirements
The important aspects of this software is time constraint. This system is real time and hence
should be performed in minimum requirements.The system must be interactive and the delays
involved must be less. As the system is easy to handle and navigates in the most expected way
with no delays. In that case the system program reacts accordingly and transverses quickly between
its states. Since this system has multiple users, it should the simultaneous usage of almost 1000
users at a time. This system should also be reliable.
Safety Requirements
The main security concern is for users account hence proper login mechanism should be
used to avoid hacking. It should be made sure that only those who are given specific rights can
access data and all actions are logged. Hence, security is provided from unwanted use of
recognition software. Power is a significant feature and the power supply should be always taken
care of. An Uninterrupted Power Supply is always recommended.
11
Security Requirements
Personal Information of the users should be protected and information transmission should
be securely transmitted to server without any changes in information. If the database of this system
gets crashed, it is necessary to have backup database.
Software Quality Attributes
● Availability: The System should be available at all times so that the users can access it any
time.
● Maintaining: MY SQL is used for maintaining the database and incase of failure re-
initialization of the program is needed.
● Portability: This system should be compatible with any other systems.
Business Rules
No specific business rule.
Other Requirements
● Usability: The users can use this system as much as it required
● Backup: There should be an easy backup feature for entire data.

12
● Functional Requirements: These are the functionalities provided by the software

which are defined by the users to the developer.
● Non-functional Requirements: These are additional functionalities which are not

ordered by the uses and are qualities of a system.
● GUI: Graphical user Interface.
● SQL: Structured Query Language.
● ADMIN: A Person who is responsible for managing the student information.
● Disk crash: It is the process of computing the failure of disk storage system and
causing mechanical damage.
● Doc matrix: Document matrix is a mathematical matrix that describes the

frequency of terms that occur in a collection of documents.
● TCP/IP: Transmission Control Protocol / Internet Protocol

13
EX.NO:3 Identify usecases and develop usecase model
DATE:
USE CASE DIAGRAM:
A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the different
use cases and will often be accompanied by other types of diagrams as well. The use cases are
represented by either circles or ellipses.
PURPOSE OF USE CASE DIAGRAMS :
The purpose of use case diagram is to capture the dynamic aspect of a system. However,
this definition is too generic to describe the purpose, as other four diagrams (activity, sequence,
BASIC USE CASE DIAGRAM SYMBOLS AND NOTATIONS :
SYSTEM :
USE CASE :
14
ACTORS:
Actors are the users of a system. When one system is the actor of another system, label the
actor system with the actor stereotype.
RELATIONSHIPS:
15
IDENTIFY USE CASES AND DEVELOP USE CASE MODEL
USE CASE DIAGRAM:
USE CASE MODELLING
BRIEF FORMAT (login):

In case of login usecase student, staff and admin are the users. It includes username or user
id and password. If the username and password are valid then the user can successfully login to
the page where the information of students are available. The login page is the first visible and
16
mandatory page for the users. Many users can login at a time. This page is used for security and
authentication purposes.
CASUAL FORMAT:
SUCCESS SCENARIO :
Considering the login page, the username and password is necessary. In case if the details
are valid the user can successfully login to the page. The user can view or update or remove the
details of the students.
ALTERNATE SCENARIO :
If the details are invalid the user cannot login to the page which he/she desired to open.
They can give forget password or otp generation to the registered mobile number.
USECASE SECTIONS COMMENTS
Usecase name Login page of student information system
Scope To login to the page where student details are

stored.
Level Getting the username and password from the

user.
Primary actor User, admin
Secondary actor Student information database
Stakeholders Database administrators, users(faculty/student)
pre-conditions To check that internet access is available before

logging in to the system
Main success scenario Successfully opening the login page , getting

valid username and password and getting into
the student details page.
Extension In case of valid username and password the

user can login whereas invalid details will
extend to the forget password
17
Special requirements Security is the most important requirement
BRIEF FORMAT (profile):

The use case profile will provide the users/ admin to view the personal details as well as
academic details. The personal details include student name , date of birth, parent’s details etc. in
case of this usecase many users can be able to view the details.
CASUAL FORMAT:
The profile in the student information system is divided into two phases.
(ie) personal and academic details. Alternative scenario for this is giving the wrong details of the
student instead of giving the correct information.
FULLY DRESSED:
Use case sections Comments
Use case name Profile page of student information system
Scope To view the profile page of student with correct

information
Level Giving appropriate information to the database
Primary actor user/admin
Stakeholders Database administrators,

users(faculty/student)
Preconditions Proper login and internet access
Main success scenario Successfully login to the page
Extension Incorrect / wrong information about the student
Special requirements Internet access , username and password
BRIEF FORMAT (update):

18
The use case update student details is done by the staff/admin. Updating of information
requires proper login, knowing the correct details about the student. The main success scenario is
updating the student’s correct information in the profile page.
CASUAL FORMAT:
Updating the student details which includes personal and academic details. The update
process is possible only when the admin knows proper and correct information about the students.
Use case sections Comments

Use case name Update student details in the information
system
Scope To update the correct details of the student in

the database.
Level Giving the personal and academic details of the

student , login to the page
Primary actor user, admin
Stakeholders Database administrators, user
Preconditions Proper login and internet access
Main success scenario Successfully login to the page .getting the

personal and academic details.
Extension incorrect/ wrong information about the student
Special requirements Internet access , username and password

19
EX.NO:4 Identify conceptual class and develop the domain model

With UML class diagram
DATE:
CLASS DIAGRAM:
on the system. The class diagrams are widely used in the modelling of objectoriented systems
languages.

PURPOSE OF CLASS DIAGRAMS:
MEMBERS:
UML provides mechanisms to represent class members, such as attributes and methods,
and additional information about them.
VISIBILITY:
To specify the visibility of a class member (i.e. any attribute or method), these notations
must be placed before the member's name.
+ Public
- Private
# Protected
20
~ Package
DERIVED PROPERTY:
SCOPE:
UML specifies two types of scope for members: instance and classifier, and the latter is

RELATIONSHIPS:
21
CLASS NOTATION:

responsibility.
OBJECT NOTATION:
22
IDENTIFY CONCEPTUAL CLASSES AND DEVELOP DOMAIN MODEL
DOMAIN MODEL:
23
CLASS DIAGRAM:
The class diagram consist of five classes namely webpage, admin, student, faculty, update
details. The association between these classes are as follows:
● One admin can create many students portal

● Many students can authenticate or use webpage.
24
EX.NO:5 Using identified scenarios find interaction between

Between objects and represent them using UML
DATE: sequencediagram
SEQUENCEDIAGRAMS:
SEQUENCE DIAGRAM NOTATIONS :
1. Actors – An actor in a UML diagram represents a type of role where it interacts with the
25

lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in
26
Figure – lifeline
is left blank.
Difference between a lifeline and an actor – A lifeline always portrays an object internal
to the system whereas actors are used to depict objects external to the system. The following
is an example of a sequence diagram:

27
1. Synchronous messages – A synchronous message waits for a reply before the

2. Asynchronous Messages – An asynchronous message does not wait for a reply

28
3. Create message – We use a Create message to instantiate a new object in the

sequence diagram. There are situations when a particular message call requires the
creation of an object. It is represented with a dotted arrow and create word labelled
on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would require
a new object of Order class to be created.
• Delete Message – We use a Delete Message to delete an object. When an object is

deallocated memory or is destroyed within the system we use the Delete Message symbol. It
destroys the occurrence of the object in the system.It is represented by an arrow terminating
29
• Self Message – Certain scenarios might arise where the object needs to send a message to

30
• Reply Message – Reply messages are used to show the message being sent from the receiver
31
• Found Message – A Found message is used to represent a scenario where an unknown

32

failure.
• Lost Message – A Lost message is used to represent a scenario where the recipient is not

symbol.
33
Guards – To model conditions we use guards in UML. They are used when we need to
restrict the flow of messages on the pretext of a condition being met. Guards play an important
role in letting software developers know the constraints attached to a system or a particular process.
USES OF SEQUENCE DIAGRAMS :
procedure.
USING IDENTIFIED SCENARIO FIND INTERACTION BETWEEN

OBJECTS AND REPRESENT THEM USING UML SEQUENCE DIAGRAM
AND COLLABORATION DIAGRAM.
34
SEQUENCE DIAGRAM:
1. Admin creates the database.

2. Student opens the webpage.
3. using the alt combined fragment the webpage request the username and password to the student
.
4. Student gives the login details.
5. The details are loaded to the server.
6. If the information is valid the user can login to the system.
7. If not invalid login and extends to forget password.
8. Admin can update the database.
9. Student or the usercan view the updated details.
35
EX.NO:6 Using the identified scenarios,find the interaction between

Objects and represent them UML communication
DATE: diagram
Collaboration diagrams are created by first identifying the structural elements required to
carry out the functionality of an interaction. A model is then built using the relationships between
NOTATIONS OF A COLLABORATION DIAGRAM:

behavior of individual objects as well as the overall operation of the system in real time. The four
major components of a collaborationdiagram are:
36
37
EX.NO:7 Draw relevant state chart diagram and activity

diagram
DATE:
DRAW STATE CHART DIAGRAM AND ACTIVITY DIAGRAM:
ACTIVITY DIAGRAM:
Activity diagram describe activities which involve concurrency and synchronization, which
are a variation of state diagrams that focuses on the flow of actions and events. They can be used
for:
38
ACTIVITY DIAGRAM :
The activity diagram consist of three swimlanes namely student, system, staff. The parallel
behaviors such as join and fork is used for user authentication. The conditional behaviors such
branch and merge are used for view profile, update details etc…
The final process is log out done by the users.
STATE MACHINE DIAGRAM:

A state machine Diagram (or start diagram, also called state chart of state
39
transition diagram) is a behavior which specifies the sequence of states an entity (or
object) visits during its lifetime in response to events, together with its responses to
those events.
KEY CONCEPTS:
STATE:

Example:
40
INITIAL AND FINAL STATES:


41
EX.NO:8 Implement system as per detailed design
DATE:
Class name: Admin
Import java.util.Vector;
Public class Admin {
Public Integer username;
Public Integer staff-id;
Public Integer student-id;
Public Vector does;
Public Vector *;
Public void getdata() {

}
Public void display() {

}
Class name: management quota
Public class Management quota extends Student {
Public Integer ref_no;
Public Integer fees;
Public void get_mstu() {

}
}
42
Class name : government quota
Public class Government quota extends Student, Student {
Public Integer c_no;
Public Integer fees;
Public void get_gstu() {

}
Class name:faculty
Public class Faculty {
Public Integer name;
Public Integer department;
Public Integer experience;
Public Student *;
Public Vector *;
Public void display_details() {

}
Class name: student
Public class Student {
Public Integer name;
Public Integer course;

43
Public Integer year;
Public Integer department;
Public Vector verify;
Public Vector 1;
Public Faculty *;
public Vector *;
public void view_display() {

}
Public void display_details() {

}
Class name:update details
Public class Update details {
Public Integer student_details;
Public Integer faculty_details;
Public Integer result_details;
Public void update_info() {

}
Public void get_details() {

}
Class name: webpage
44
Public class Webpage {
Public Integer username;
Public Integer password;
Public Vector verify;
Public void authenticate() {
}
45
EX.NO:9 Test the software system for all the scenario identified
As per the usecase diagram
DATE:
Class name : Admin

Import java.util.vector;
{
Public class admin
{
Public String adminid;
Public String pw;
Public String update(String in)
{
If(in.equals(“kk”));
Return true;
Else
Return false;
}
]
46
47
EX.NO:10 Improve the reusability and maintaining of the software

System by applying appropriate design patterns
DATE:
products variant as shown in figure.
48
objects without specifying concrete classes. The following Figure ( ) shows the example of abstract
execution.
fixed which is used as input. As step 1 firstly identify the design problem using alternative design
maintainability, reusability, understandability, flexibility, compos ability, completeness, stability,
49
5 composability, completeness, stability, simplicity, and expandability are measured using
mathematical formation. In step 6, combine step 4 and 5 output to get required quality product.
Assessment of these nine quality attributes are discussed as:
functionality to software. So, maintenance Client AbstractFactory +doAction1: void +doAction2:
void AbstractProduct +doAction: void AbstractFactory concreteProduct1 concreteProduct2
concreteFactory1 concreteProduct1: Admin concreteProduct2: User concreteProduct1 +do
Action: void concreteFactory2 concreteProduct1: Admin concreteProduct2: User
concreteProduct2 +doAction: void 95 programmers should have to use less effort to adapt these
OSS.
CONCLUSION:
The student information system is a software or application which is used to
manage studentinformation/student's data. The main purpose of choosing this project idea is that
you can see available real time Student Information System that will help you to design something
and add to your student information system. It also helps to avoid manual work and time
consumption.

Ooad Record Full

Uploaded by

Copyright:

Available Formats

Ooad Record Full

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ooad Record Full

Uploaded by

Copyright:

Available Formats

PASSPORT

1.2 Document Conventions

Paragraph Times New Roman 12 Normal

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

2.2 Product Functions

2.3 User Classes and Characteristics

2.4 Operating Environment

2.6 User Documentation

2.7 Assumptions and Dependencies

3. External Interface Requirements

3.1 User Interfaces

3.2 Hardware Interfaces

3.4 Communications Interfaces

4.1.1 Description and Priority

4.1.2 Stimulus/Response Sequences

4.1.3 Functional Requirements

USE-CASE NAME: LOGIN

Requirements Traceability – Online Interface

Preconditions – User account must be exists

Actors –Registered User

USE-CASE NAME: REGISTRATION

Preconditions – Fill the form with details.

Post conditions - The user is successfully registered with the system

The user, if new, requests to registers himself with the system.

USE-CASE NAME: VERIFICATION

USE-CASE NAME: CHECK STATUS

USE-CASE NAME: DISPATCH PASSPORT

The requirements needed to be fulfilled are specified below:

4.2.2 Stimulus/Response Sequences:

5. Other Nonfunctional Requirements

5.2 Safety Requirements

5.3 Security Requirements

5.4 Software Quality Attributes

5.5 Business Rules

USE CASE DIAGRAM

PURPOSE OF USE CASE DIAGRAMS

BASIC USE CASE DIAGRAM SYMBOLS AND NOTATIONS

FULLY DRESSED FORMAT

Precondition Enter the Username and Password to Login

Exception Incorrect password.

USE CASE MODELLING

FULLY DRESSED FORMAT

Special requirements Security is important.

5.6 Class Notation:

• The top section is used to name the class.

Sequence Diagram Notations

Figure 1.4 – lifeline

Figure 1.5 – a sequence diagram

Figure 1.7– a sequence diagram using a synchronous message

Figure 1.9– a situation where create message is used

Figure 1.10 – a scenario where delete message is used

Figure 1.12– a scenario where a self message is used

Figure 1.13 – reply message

Figure 1.15 – found message

Figure 1.16 – a scenario where found message is used

Figure 1.17 – lost message

Notations of a collaboration diagram:

Initial and Final States: