Acknowledgement

The development of Project is a very hard work and is not possible without proper guidance and
suggestions and this project report itself is an acknowledgement to the sincere efforts of all individuals
who have contributed to it for its completion. I take this opportunity to express my sincere gratitude to all
those who have helped me in various ways in the successful completion of my project report.
First of all I pay my sincere gratitude to honorable Ms. Vijeta Kumawat (HOD CS and IT
Department) and all the respectable members of Uttam Devi Mohan Lal College of Engineering, Jaipur.
I want to give my deep appreciation and regards to my guide Mr. Kanak Kumar Kanak for his
great efforts, helpful suggestions, and proper guidance. He has been always a great source of inspiration
to me and under his guidance I have done my work better.
Also, I extend my heartfelt gratitude towards my family and my friends, who also helped me to
boost my spirit, giving me unending support during the tough times and lending me helping hands
whenever needed. I also express my indebtedness to my friends for their great suggestions and hints. I
want to thank my Parents and family members who were by my side for every wrong move I made, for
moments I felt disgusted or unable to solve my problem, I thank them for having so much confidence in
me.
And above all I am thankful to God who gave me the inspiration and power to complete my
work.

INDEX

1. Introduction..................................................................................... 1
1.1.

Goal....................................................................................... 2

1.2.

Objective 2

1.3.

Features ......................3

1.4.

Scope..................................................................................... ..4

1.5.

Platform Specifications Deployment....4

1.5.1 Hardware Specification...................................................4

1.5.2 Software Specification ....................................................4
2. System Requirement Analysis .......................................................5
2.1.

Information Gathering.................................................................. ..7

2.2.

System Feasibility ....8

2.2.1 Economic Feasibility .......................................................8
2.2.2 Technical Feasibility ........................................................8

2.3.

Behavioral Feasibility ..........................................................8

3. Software Requirement Specification.....9

3.1.
3.2.
3.3.

SRS Fundamentals..9
Users of SRS ..10
SRS Principles 11

4. System Analysis................................................................................ ..12

4.1.

Data Flow Diagram..............................................................12

4.2.

Unified Modeling Language .................................................13

4.2.1
4.2.2
4.2.3
4.2.4

Use Case Diagram ..14

Sequence Diagram ..16
Class Diagram .21
Activity Diagram 22

5. System Design & Development.............................................................. ..24

5.1.

Input Design ............................................................................

5.2.

Output Design .........................................................................25

5.3.

Code Design ..........................................................................26

6. Language and Tools Used ..27

7. System Testing ........................................................................31
7.1.

Unit Testing ..33

7.2.

Integration Testing 33

7.3.

Validation Testing .33

7.4.

Output Testing ..34

8. System Implementation ...................................................................35

9. System Maintenance 38
10.User Interface and Design 40
11.Conclusion ....42
11.1. Limitation ........................................................................42
11.2. Scope of Future Work ................................................................................................................

....42

24

12.Bibliography .................................................................................... ..44

INTRODUCTION

FunChat Server is an online system developed for the group of members to communicate with each other
over the internet. This system solves almost all the limitations of the conventional system. Both the
students and teachers and the company are equally benefited by the proposed system. The system saves a
lot of time and effort for both. We are introducing new software called FunChat Server for chatting
purpose. We can say thoroughly that this software is very useful for the college. It is mainly designed for
the college to reduce the communication gap between the different peoples in a college.

1.1. Goal
Chatting has long been considered a recreational activity by many. C h a t t i n g online is no exception.
The FunChat Server is ideally suited for passing the messages from one user/client to other
user/client with animated smilies also. The goal of this application is to develop a API based
interface for online chatters. The system would be easy to use and hence make the chatting experience
pleasant for the users. The goal of this application is
To develop an easy to use API based interface where user can interacts with other persons.
To make a multi-threaded Client Chat server.

 To be easy to use as possible.

To relieve the developers of clients and bots of the intricacies of the Direct Connect protocol.
To provide a better environment for discussion on any thing using message passing from one to
other.

1.2.

Objective

Functional : Firstly, a system design should be functional in that may successfully support the user
requirements.
Efficient : A system must be able to meet the functional requirements within a specified time frame.
A user of the system will quickly become disillusioned if delays were unacceptable, and agreed time
scales were not achieved.
Flexible : All organisational systems should be dynamic and should be designed to be dynamic. They
are affected by internal growth and politics, staff resignations and appointments. Consequently
information systems designed to support the operational requirements to meet new needs as they
become apparent.
Portable : Portability is closely linked to independence rate of technological changes means that
investment in existing systems would only be preserved if the designer takes effective measures to
ensure that only a minimum of conversion work is required to transfer a system from one computing
environment to another.
Secure : Data are costly and hence, valuable organisational asset and so, any system that collects and
processes them must be resistent to breachesof provace and confidentiality.
Reliable : Integrity is another feature of a good design. A system is said to be having good integrity
when all the desired data are accurately recorded, without omission and stored on the computer safely
so that they are not accidently or deliberately corrupted or lost.Thus a system must be trustworthy and
accurate and it must wxhibit these qualities.
Economical : The need for a design, which demands minimum storage for data and programs is
probabely a feature, which has become less important, hardware costs rapidly decline. Nevertheless,
minimiizing the amount of redundant data stored by a system reduces problems associated with
amendment, insertion and deletion of data.

1.3.

Features
It can work with or without internet connection.

 It provides public or private chat.

It has room facility.
Provides chatting facility.
Transfer Smilies with text
User status (Available, Busy, Away)
Great look and feel

1.4.

Scope

Our project can be used in any organization, schools, colleges, companies and anywhere where a network
(LAN) is present. The user who wants to use this software should know the IP address of the server
computer (by whom he/she wants to connect). User enters the IP address of the server computer and
his/her nick name by a click on the connect button he can connect to the chat server, where he/she can
change his/her room and chat with other users who are online at that time in same room.

1.5.

Platform Specifications Deployment

1.5.1.

Hardware Specification
Minimum Requirement
Intel Pentium Class
600 MegaHertz
128 MB
100 MB
VGA

Processor
RAM
Minimum Disk Space Required
Monitor

1.5.2. Software Specification

Operating Environment

- Win 2000/XP/VISTA

Platform.

- Java Runtime Environment

Database

- XML

Recommendation
Higher
256 MB
200MB
Super VGA

1.

SYSTEM REQUIREMENT ANALYSIS

The purpose of System Requirements Analysis is to obtain a thorough and detailed understanding of the
business need as defined in Project Origination and captured in the Business Case, and to break it down
into discrete requirements, which are then clearly defined, reviewed and agreed upon with the Customer
Decision-Makers. During System Requirements Analysis, the framework for the application is developed,
providing the foundation for all future design and development efforts.
System Requirements Analysis can be a challenging phase, because all of the major Customers
and their interests are brought into the process of determining requirements. The quality of the final
product is highly dependent on the effectiveness of the requirements identification process. Since the
requirements form the basis for all future work on the project, from design and development to testing
and documentation, it is of the utmost importance that the Project Team create a complete and accurate
representation of all requirements that the system must accommodate. Accurately identified requirements
result from effective communication and collaboration among all members of the Project Team, and
provide the best chance of creating a system that fully satisfies the needs of the Customers.
The primary goal of this phase is to create a detailed Functional Specification defining the full set
of system capabilities to be implemented, along with accompanying data and process models illustrating
the information to be managed and the processes to be supported by the new system. The Functional
Specification will evolve throughout this phase of the SDLC as detailed business requirements are
captured, and as supporting process and data models are created, ensuring that the eventual solution
provides the Customers with the functionality they need to meet their stated business objectives.

2.1.

Information Gathering

As the goal of the application is ease of use and to provide an interactive interface, extensive
research has been done to gain an insight into the needs and behaviors of various users. The working of
the application is made convenient and easy to use for the end user. Dr Andresen, Associate Professor,
CIS provided regular feedback on the project.
Users can be classified into two types based on their knowledge of the products that suit their
needs. They can be classified as users who know about the product that would satisfy their needs and
users who have to figure out the product that would satisfy their needs. Users who know about the
product should be able to find the product easily with the click of a button. Such users can search for the
product by using the product name as the search term. Users who have to figure out the product that
would satisfy their needs could use a search term to find a list of products and then should be able to
filter the results based on various parameters like product type, manufacturer, price range, platform
supported etc.
The users should be able to view the complete specification of the product and various images
at different Zoom levels. The user should be able to read the customer reviews for the product and the
ratings provided. They should be able to write their own reviews. They should be able to print out the
specifications for a product or email the product page to a friends etc.
To increase the ease of use the user should be able to add a product to the shopping cart by
dragging a product and dropping it in the shopping cart. A user should able to edit the contents of a
shopping cart. They should be able to update the quantities of the products added to the cart and remove
the products from the cart. The user should be able to remove the product from the shopping cart by
dragging the product and dropping it outside the cart.
The application can be made interactive by pop up messages when a product has been dropped
in to the shopping cart or out of the shopping cart. The user can be notified if the cursor enters a drop
area and the object that could be dropped. Also users are impatient making it important to load pages
soon.
Other than this, I did a lot of research on various other methods of building this application
which and was able to incorporate a few stronger features into the application. The tools and controls
used in the application are recommended HTML controls and PHP which improves the navigation and
usability and interactivity.

2.2.

System Feasibility

The system feasibility can be divided into the following sections:

2.2.1.

Economic Feasibility
The project is economically feasible as the only cost involved is having a computer with the

minimum requirements mentioned earlier. For the users to access the application, the only cost involved
will be in getting access to the Internet.
2.2.2.

Technical Feasibility
To deploy the application, the only technical aspects needed are mentioned below: Operating

Environment Win 2000/XP/VISTA

Platform .Java Runtime Environment
For Users:
Java Runtime Environment
Internet Connection may be may not be
2.2.3.

Behavioral Feasibility

The application requires no special technical guidance and all the views available in the application are
self explanatory. The users are well guided with warning and failure messages for all the actions taken.

3. SOFTWARE REQUIREMENT SPECIFICATION

Software requirement specification is essential as this is the only lasting impression of the
requirements elicitation and analysis process that is available to the development team, the users and the
customer as the system progresses to the later parts of the software development life cycle. A one line
definition of SRS is given as:
SRS is a vital piece of documentation that is crucial to the success of any software development
project.
If one cannot precisely state what the system should do, how can we develop the software with
any confidence, and how can we hope to check that the end product meets its need? The specification is
the reference document against which all subsequent development is assessed.

3.1.

SRS Fundamental

Why SRS is required?

There are number of reasons why SRS is needed:
1. SRS is the support needed to maintain the records about all the work done during
requirement analysis.
2. SRS is often a major element of legally binding contract. So, it serves as a contract
between client and the developer.
3. SRS specifies the final system or product, its subsystems and components that will be
used to make the system.
4. The more attention given to the SRS document and the more accurate and precise SRS
document will improve the quality of the final product.
5. SRS supports maintenance; because any work can be passed from one person to another.
6. SRS can be used to manage change by using cross-references between documents to find
documents that are affected by changes to earlier documents.

SRS is a Communication Tool

SRS is a communication tool because it contains a repository of all work done to date and makes
it available to all persons working on related parts of a large project. Such repository can prevent
unnecessary repetitions.

SRS is a Management Tool

SRS is also a management tool. It supports management in two ways:
1. It gives access to the latest work to all project personnel and thus reduces the chances of
repetition of work.
2. It is the only project deliverable, especially in the early project phases, and thus serves to
determine project status and progress.

3.2.

Users of SRS
The SRS is typically used by the following entities:

Customers and users for understanding what they are expected to get,
Project managers to estimate and plan the project to deliver the system,
Designers and programmers to know what to build,
Testers to prepare for testing activities,
Maintenance teams for understanding the system that they will maintain,
trainers to prepare training material for training the end users,
Users to understand the proposed system and prepare for the change over.

3.3.

SRS Principles

1) Separate functionality from implementation.

2) Develop a model of the desired behavior of a system that encompasses data and the functional
responses of a system to various stimuli from the environment.

3) Establish the context in which software operates by specifying the manner in which other system
components interact with software.
4) A system specification in which the system operates and indicates how a highly intertwined
collection of agents react to stimuli in the environment.
5) A specification must be operational.

Characteristics of SRS
1) Completeness

6) Ranking

2) Clarity

7) Modifiability

3) Correctness

8) Traceability

4) Consistency

9) Feasibility

5) Verifiability

Components of SRS
1) Functional Requirements
2) Performance requirements
3) Design Constraints
4) External In interface Requirements

4. SYSTEM ANALYSIS
After carefully analyzing the requirements and functionality of the application, I had one important
diagram by the end of the analysis phase. They are the ER diagram and data flow diagram which were
the basis for finding out entities and relationships between them, the flow of information.

Data Flow Diagram

Message

Client

Server

Figure 3.2: A Context Level Diagram

Message
Username &
Server name
User

Login
ss
Me
e
ag

Mess
ag
e

Receive
Message

Send
Message

g
sa
s
e
M
e

4.1.

Client

Figure 3.3: A First Level Diagram

g
sa
s
e
M
e

4.2.

Unified Modeling Language

The UML has become the de-facto standard for building Object-Oriented software and is widely used in
the software industry. It is a notation for expressing object-oriented analysis and design and is
independent of the language, or languages, that are used to implement a system. It provides a means to
write systems blue prints outlining system functionality and describing programming language
statements, database schemas and reusable software components.
The project team has chosen the UML to outline the design of the system for several reasons.

The system will be developed using several programming languages such as Java, ASP, HTML,
so it is important that the design notation used is language independent.

By using a modeling language, the system is specified before coding begins, and the team
members have a clear understand of how the system will work and the responsibilities involved in
developing the various parts of the system.

Using the UML can be a means of avoiding design errors. Bad design can cause a lot of problems
when coding begins, especially with a strongly Object Oriented language like Java.

Another benefit to using the UML is that it stops the system design documentation from
becoming too detailed and confusing. During coding it is easy to become weighed down with
detail making it difficult to identify the main components of the system, relationships between
objects, and how they communicate with each other. Making design changes becomes more
difficult time progresses. The UML allows the definition of a precise, yet high level, design
before coding begins.
The project team has used UML diagrams to describe the overall system design and the various

smaller components included in the system.

4.2.1.

Use Case Diagram

The purpose of the UML use case diagram is to illustrate the interactions between users and the main
parts of a system. It is generally the first step in project design and is particularly useful in planning
and controlling an iterative system.

Use case diagrams consist of actors, depicted by stickmen, which represents the end-user of the
system. These actors may be people, or other systems, which require some functionality from the
system. The use cases are represented by ellipses and capture a particular area of system functionality.
Arrows represent relationships between use cases and between the actors and use cases.
The complexity of the use case diagram depends on the level of granularity employed during its
creation i.e. the level of detail encompassed with in each use case. It is advised that the diagram
should be kept as simple as possible. It should describe the functionality of the system from the user
point of view.
1. Login
FunChat Server allows users to login via the login window using their username/nickniame. Users
also give the server name. An error message will result if invalid details are entered.

2.1.

2.2.

A Valid Scenario
User in Login Window.
User inputs Username/Nickname and Server name/Server IP address.
FunChat Server authenticates user.
User is logged into FunChat Server.
An Invalid Scenario
User in Login Window.
User inputs Username/Nickname and Server name/Server IP address.
FunChat Server authentication for user failed : Wrong Server name or IP
address.
FunChat Server sends error message.

2. General Room
The user enters the General room once successful login into FunChat has occurred.

2.1. Chat/Post Messages in General room

The user will have the ability to communicate with other users in the general room.

2.2. Logout
The user is able to logout of FunChat Server via the General Room.

2.3. Private Room

The user enters the Project Room once they choose to enter/continue an active user.

4.2.2.

Sequence Diagram

Sequence diagrams are used to model the way a system may potentially be used. They are generally
based on a particular use case or on part of that use case. Sequence diagrams model the flow of logic
within the system in a visual manner, and are commonly used for both analysis and design purposes.
The boxes or rectangles across the top of the diagram represent classifiers or their instances i.e.
typically use cases, objects, classes, user interfaces, or actors. Actors initiate and take an active part in
usage scenarios and therefore are also included in sequence diagrams.
Vertical dashed lines, connected to the classifiers, depict lifelines and these represent the life span
of the object during the scenario being described. Long, thin boxes on the lifelines are called methodinvocation boxes and they indicate that processing is being performed at that time, by the target
object, to fulfil a function. Messages are indicated as labelled arrows, where the labels contain brief
text describing the information being communicated between the classifiers.
The following sequence diagrams that depict the sequence of control flow between modules of
FunChat Server when actions are performed by users as portrayed in the Use Cases.

1. Server Startup
The sequence diagram illustrated in figure shows how the server loads at runtime.

1.
2.
3.
4.

The Server Application first creates a new instance of the logger.

The Logger initiates the authentication.
The Logger returns.
The Server Application Creates an instance of a General Room, and sends a reference of the

logger to the General room.

5. TheGeneral Room Returns.
2. Login
The sequence diagram illustrated in figure shows the sequence of events that occur when a user logs
into FunChat Server and enters the General room.

Figure Shows :
1. The user enters his nickname and server name through the Client Application. The Client
Application sends a reference of itself to the Server Application.
2. The Server Application verifies the username with the logger.
3. The Logger Validates the username with the temporary database, and retrieves the user
4.
5.
6.
7.
8.
9.
10.

information.
The Database returns the information to the logger.
The Logger returns the information to the Server Application.
The Server Application creates a Client Interaction Thread to be associated with the client
The Client Interaction Thread returns control to the Server Application.
The Server Application sends a reference of the Client Interaction Thread to the General Room
The General Room Returns.
The Server Returns a reference of the General Room to the Client Application.

3. General Room Chat

The sequence diagram illustrated in figure below shows the sequence of events that occur when a user
sends a chat message in the General room.

Figure shows:

1. The user sending the message inputs the message to the Client Application. The client application
sends the message to the General Room.

2. The General Room Sends the message to all client interaction threads for clients currently in the
General Room. The General Room returns to the Client Application.

3. Each Client Interaction thread sends the chat message to their associated client.
4. Each Client Interaction thread returns.
4. Private Room Chat

The sequence diagram illustrated in figure below shows the sequence of events that occur when a user
sends a message to chat in the private Room Chat.

Figure shows:
1. The User (Sender) sends the chat message through the Client Application. The Client Application
sends this message to the Private Room.
2. The Private Room sends the chat message to the logger to enter it into the database.
3. The Logger Returns
4. The Private Room sends the message to all Client Interaction threads currently in the Private
Room. The Private Room returns to the Client Application of the sender.
5. The Client Interaction Threads send the chat message to their Client Application.
6. The Client Applets return.

4.2.3

Class Diagram

Class diagrams are generally thought of as the backbone to any system. They describe the objects or
classes of a system and their relationships with other classes. In class diagrams the classes are
represented by rectangles divided into three compartments. The top compartment contains the name
of the class. The middle compartment contains a list of important attributes (variables) and the bottom
compartment contains a list of the main operations (functions) of that class.
The purpose of class diagram may be to highlight a particular part of the system, or to represent
the system in general. Associations/Relationships represent static relationships between classes. They
are symbolized by arrows connecting two or more classes. A key aspect of an association between

classes is its cardinality or multiplicity. This corresponds to relationships in the ER diagramming. The
multiplicity of an association indicates the number of instances of one class, which are linked to one
instance of the other class.
This class diagram shows the classes that make up the chat server system, currently under
development. The diagram explains how each class with in the program relates to another. The Chat
Interface represents the Chat Room Window on which the Chat Application will run. Each time an
application is activated by a user i.e. logging in to chat room, an instance of the ChatAppletThread is
created. This in turn creates a socket and communicates with the chat server so that messages can be
sent. There can be multiple instances of the ChatApplicationThread. These instances represent the
multiple users of a particular chat room. The ChatApplicationThread communicates with one instance
of the ChatServerThread class. The ChatServerThread represents a particular chat room. There may
be many instances of this class at any one time i.e. there may be many different chat rooms to choose
from. The diagram shows how there is one main ChatServer class and can be called on by many
ChatServerThread classes.

4.2.4

Activity Diagram

An activity diagram forms the visual "blueprints" for the functionality of the system, as described and
detailed in the use cases. The threads of execution throughout the Activity Diagrams enable the
developers to understand and monitor the development of system. Activity diagrams are useful when
it is necessary to show how the behaviors in several use-cases interact with each other or to describe
parallel behaviors. It is similar, to a certain extent, to a flow chart but it differs however, in that it
expressly supports parallel activities and their synchronization.
The activity diagram notation consists of rectangular boxes, which contain the activity name. This
name should be descriptive of the actual activity it represents. Action flow lines, represented by
arrows show the order in which the activities are carried out. If an activity can be carried out several
times an asterix is inserted beside the activity to signify this iteration.

The activity diagram shows the sequence of activities during a chat room session. The user
enters his user-name (nickname) in the log on process and select the chat room. These are verified
and, if valid, a socket connection with the Chat Server is established. If for some reason the
connection with the server is not successful, an error message is displayed. Once the connection is
successfully established, the user may begin chatting. The server receives the input strings and
displays them in the chat room. This is an iterative process and may continue until the user decides to
leave the chat room.

5.

SYSTEM DESIGN & DEVELOPMENT

The design phase focuses on the detailed implementation of the system recommended in the feasibility
study. The design phase is a transition from a user oriented document to a document oriented to the
programmers or database personnel. Systems design goes through two phases of development:
Logical Design
The DFD so far are known as logical data flow diagrams. They specify various logical processes
performed on data, ie the type of operations performed. A logical DFD does not specify who does the
Operations, whether it is done manually or with a computer and also where it is done. A physical DFD
specifies these.
Physical Design
A physical DFD is easily drawn the fact gathering stage. A physical DFD is a good starting point in
developing logical DFD; it is some times useful to depict physical movement of materials.
The data flow diagram shows the logical flow of a system and defines the boundaries of the
system. For a candidate system, it describes the inputs (source), outputs (destination), database (files)
and procedures (data flow), all in a format that meet the user's requirements.

5.1.

Input Design

Input design is the process of converting user-originated inputs to a computer based format, Input data
are collected and organized into a group of similar data. Inaccurate input data is the most common cause
of data processing errors. Effective input design minimizes errors made by data entry operators. The
goal of designing input data is to make data entry as easy, logical and free from errors as possible. In
addition to the general form considerations such as collecting only required data, grouping similar or
related data, input design requires consideration of the needs of the data entry operator, m entering data,
an operator needs to know the following: -

5.2.

Output Design

Computer output is the important and direct source of information to the user. Efficient, Intelligible
Output design should improve the system's relationships with the user and helps in decision making.
They also provide a permanent hard copy of these results for later consultation.
The various types of outputs required by the system are given below:

External Output: whose destination is outside the concern and requires special attention.
Internal Output: whose destination is within the concern and requires careful design because
they are the user's main interface within the computer.

Operation Outputs: whose use is purely within the computer department.

Interactive Outputs: which involves the user in communicating directly.
Before you sit down to design the database, gather all the information you want to include in
the database. I mean everything. Go around to each department of the company (or just write it out
yourself if this is just for you) and find out what everyone wants in the database. Once you have
everything, bring it back, and create one huge table.
From there, break that table down to 1NF, then 2NF, and so on. Go back over each table, and
make sure they all work together, and are all 4NF tables. If they aren't, then it can be assured the tables
will suffer problems in the future. Quality is in the design. And for those people who know, this helps
comply with Codd's first 2 rules for a truly relational database system.

5.3.

Code Design

The purpose of coding is to express the program logic in the best possible way and to the check it. The
main reasons for coding are:

1. Unique Identification - Each item in a system should be identified uniquely and correctly.
2. Cross referencing - Diverse activities in an organization give rise tiaras actions in different sub
systems but affect the same item, efficient storage. Code is a concise representation it reduces data
entry pme and improves reliability, Code as a key reduces storage space required for the data,
Retrieval based on a key search is faster in a computer.

Requirements of coding scheme

The number of digits/characters used in a code must be minimal to reduce storage space of the code and
retrieval efficiency. It should be expandable, that is it must allow new items to be added easily. It should
be meaningful and convey to a user some information about the characteristics of the item to enable
quick recognition and identification of the item.
Type of Codes

1. Serial Numbers. This method is that it is concise, precise and expandable. It is however not
meaningful.

2. Block Codes. The block codes use blocks of serial numbers. This code is Expandable and more
meaningful than the serial number coding. It is precise but not comprehensive.

3. Group classification code. This is an improvement on the block code and is more meaningful.

Code Efficiency: It is often said that readability of a program is much more important than the
intricacies of its code. Steps, which can be taken at the coding stage, will include:

Use of meaningful data names

Inclusion of commentary
Layout of code
Avoidance of tricks (straight forward code)

6.

LANGUAGES AND TOOLS

METHODOLOGY
When you are designing distributed applications, you must consider availability and performance. A
common solution is to include a data store on the client system. Typically, the client will require a
lightweight data store as a result of limited resources. This approach poses a challenge for data
synchronization between heterogeneous data stores. One resolution to this problem is a Java-based
approach using JDBC. Distributed databases use a client/server architecture to process information
requests.
Server Side:
Server controls, manages the entire system and stores the complete details regarding their client.
And when request arises, authentication is done and the server provides the details for the
corresponding ones. The server will do the entire work as a background process. The user does not
have any interaction with servers. In this system the data request once arrived, is accepted from
client and. according to the client's request and sent the data.
Client Side:
This Client-side software will always interact with users working as the front-end. First of all a
connection is established with server. Then make appropriate request for data. Display the data in
the user requested format. Getting specification from the user is the main functionalities of the client
side and passes it to server side for processing.
Java Socket Programming
In client/server applications, the client and server components usually do not reside on the same computer
(i.e., the client could be installed on a computer that is different from the one hosting the server
installation); yet logically they are components of the same application. To enable the client and server
components to communicate with each other over a network, systems often rely heavily on sockets.

Because Java provides the required capabilities for developing socket-based applications
relatively easily and hides all the complexity involved, Java developers have an advantage in providing
quick solutions to networking problems.

ServerSocket and Socket Classes

Java supports socket development through the java.net package. In particular, ServerSocket and
Socket are the socket-related classes. They provide infrastructure for server and client development,
respectively. This article explores these classesand how to use themin more detail.
We use the ServerSocket class on the server component, where it listens for incoming requests.
ServerSocket generally is bound to a port, always active, and non-blocking. This means that it
immediately transfers or hands over any incoming request to a different component and then continues
listening for new incoming requests.
To connect with the server component, the client component simply requests a connection to the
computer where it expects the server to be running. It includes the computer name and the port to which
the server is bound in this request. The resulting connection is permanent for the client; it will not be
shared with any other instance of the client software running on the same machine.
1.

The server listens on the port to which it is bound and waits for incoming requests.

2.

When it receives a connection request, it creates a socket and associates the new connection to
that socket.

3.

From then on, the client will communicate with the server via this newly created socket
(although it is not aware of it).
Imagine achieving this setup using native code. It would be a lot of work, and if you weren't

aware of the low-level constraints (like many developers), you would end up producing poor quality code.
Luckily, the Java socket APIs are well tested and used by a large group of developers, which ensures that
all possible hidden issues are caught and addressed. That is why developers using Java can produce highquality client/server applications based on sockets.

7.

SYSTEM TESTING

Software testing is a critical element of quality assurance. Software testing is a process of

running with intent of finding errors in software. Software testing assures the quality of software and
represents final review of other phases of software like specification, design, code generation etc.

1. Detection of Error
If a code is designed which is able to detect the two types of common errors namely single transcription
and transposition errors, It will be reasonably good. Such code is called modules-11 code. In this check
a set of codes they are transformed to another set of codes with error detecting property and represents
the ultimate previews of specifications, design and coding. Testing represents an interesting anomaly for
the software. Doing the earlier definition and development phase it was attempted to build software
from an abstract concept to a tangible implementation
The main objectives of testing are: Testing is a process of executing a program with the intent of finding an error. A good test case
is one that has a high probability of finding an as yet undiscovered error. A successful test is one that
uncovers as yet undiscovered error. The above objectives imply a dramatic change in view point. They
move counter to the commonly held view that a successful test is one in which no errors are found. Our
objective is to design tests that systematically uncover different classes of errors and do so with a
minimum amount of time and effort.
If testing is conducted successfully it will uncover errors in the software. As a secondary
benefit, testing demonstrates that software function appears to be working according to specification and
that performance requirement appears have to been met. In addition, data collected as testing is
conducted provides a good indication of software reliability and some indication of the software quality
as a whole, but there is one thing that testing cannot do.
The various steps of testing the system can be listed as given below.

Running the program to identify any errors (whether syntax or semantic) that might have
occurred while feeding the program into the system.

 Applying the screen formats to regulate users to gauge the extend to which the screens are
comprehensible to the user.

Obtaining the results/responses from user and analyzing it for improvement.

Check the data accessibility from the data server and whether any improvements are needed or
not.

2. Testing correctness
The following ideas should be part of any testing plan :

1. Preventive Measures
2. Spot checks
3. Testing all parts of the program
4. Test Data
5. Looking for trouble
6. Time for testing
7. Re-testing

The entire testing process can be divided into three phases :

1. Unit testing
2. Integrated Testing
3. Final/System testing

7.1.

Unit Testing

As this system was partially GUI based Web application, the following were tested in this phase

1. Tab Order
2. Reverse Tab Order
3. Field Length

4.

Front end Validations

In our system, unit testing has been successfully handled. The test data was given to each and

every module in all respects and got the desired output. Each module has been tested found working
properly.

7.2.

Integration Testing
Test data should be prepared carefully since the data only determines the efficiency and

accuracy of the system. Artificial data are prepared solely for testing. Every program validates the input
data.

7.3.

Validation Testing
In this, all the code modules were tested individually one after the other. The following were

tested in all modules

1. Loop Testing
2. Boundary Value analysis
3. Equivalence Partitioning Testing
In our case all the modules were combined and given the test data. The combined module works
successfully without any side effect on other programs. Everything was found fine working

7.4.

Output Testing
This is the final step in testing. In this the entire system was tested as a whole with all forms,

code, modules and class modules. This form of testing is

popularly known as Black Box testing or

system testing
Black Box testing methods focus on the functional requirement of the software. That is, Black
Box testing enables the software engineer to derive sets of input conditions that will fully exercise all
functional requirements for a program. Black Box testing attempts to find errors in the following
categories; incorrect or missing functions, interface errors ,errors in data structures or external database
access .performance errors and initialization error and termination errors.

8. SYSTEM IMPLEMENTATION
Implementation is one of the most important tasks in project. Implementation is the phase, in which one
has to be cautions, because all the efforts undertaken during the project will be fruitful only if the
software is properly implemented according to the plans made.
The implementation phase is less creative than system design. It is primarily concerned with
User-Training, Site Preparation and File conversation. When the Manager's system is linked to terminals
on remote sites, the telecommunication network and tests of the network along with system are also
included under implementation.
Depending upon the nature of the system, extensive user training may be required. Programming
itself is a design work. The initial parameters of the management information system should be modified
because of programming efforts; programming provides a reality test for the assumptions made by the
analyst. System testing checks the readiness and accuracy of the system of the system access update and
retrieve data from new files. Once the program becomes available, the test data are read into the computer
and processed. In most conventions, parallel run was conducted to establish the efficiency of the system.
Post Implementation Review
Post implementation review means changing from one system to another. The objective is to put
the tested system in to operation while holding cost's risks and personal irritation to a minimum involves.
1. Creating computer compatible files.
2. Training the operating staff.
3. Installing terminals and hardware.
The definition of software maintenance can be given by describing four activities that are under
taken after the program is released for use. The first maintenance activity occurs since it is unreasonable
to assume that software testing will uncover all errors in a large software system. The process of including
the diagnosis and correction of one or more errors is called Corrective maintenance.
The second activity that contributes to a definition of maintenance occurs since rapid change is
encountered in every aspect of computing .There for adaptive maintenance modifies software properly
interface with changing environment.

Third activity involves recommendations for new capabilities, modifications to the existing
functions and general enhancements when the software is used. To satisfy request perspective
maintenance is performed.
The fourth maintenance activity occurs when software is changed to improve future
maintainability or reliability .this is called preventive maintenance.
A computer system is secure if neither its ability to attain its objective nor its availability to
survive can be adversely affected by an unwanted events. A computer-based security is a combination of
many assets or resources design to perform some function or to provide service.
System Security
In this system, which is, web based, several measures have been taken to provide some security.
Loss of confidentiality is reduced to a great extent. The facility to impose strict authorization is
completely vested in the hands of the system administrator. He/She has the full authority to add or delete
user to and from the system respectively. Only valid users can enter the system. They have to provide a
valid user id and password, to prove that they are valid users .If any one of this is wrong, access is denied
to the system. Forced change of password can be imposed after a period as specified by the system
administrator. Also the password is made to contain alphanumeric characters. If any unauthorized person
tries to enter the system, then also preventive measures can be taken. For e.g. after four consecutive trails
that result in failure, provisions should be made such that the process terminates and the exits from the
program.
Education and User Training
The purpose of training is to ensure that all the personnel who are associated with the system
should possess the necessary knowledge and skills. The end users must know in detail what their rules
will be, how they can use the system and what system will or will not do. Before the initialization of
training program, materials are prepared.-The reference manuals are mainly based upon the system
specification. Both the system operators and users need the training.

9. SYSTEM MAINTENANCE
Software maintenance is the process of modifying a software system or component after delivery to
correct false, improve performance and other attributes, or adapt to change environment. Maintenance
covers a wide range of activities including correcting coding and design errors, updating documentation
and test data and of hardware and software. Maintenance is always necessary to keep the software usable
and useful. Hardware also requires periodic maintenance to continue to bring a new system to standards.
Software maintenance activities can be classified into :
Corrective Maintenance
Adaptive Maintenance
Perceptive Maintenance
Corrective maintenance removes software faults. Corrective maintenance should be the
overriding priority of the software maintenance team.
Perceptive maintenance involves recommendations for new capability modifications to the
existing functions and general enhancements when the software is used. To satisfy this request, perceptive
maintenance is performed.
Adaptive maintenance modifies the software to keep it up to date with its environment. Adaptive
maintenance may be needed because of changes in the user requirements, changes in the target platform,
or changes in external interfaces. Minor adaptive changes may be handled by normal maintenance
process. Major adaptive changes should be carried out as a separate development project.
QUALITY ASSURANCE
The quality of an information system depends on its design, development, testing and implementation.
One aspect of system quality is its reliability. A system is reliable if, it does not produce failures. Although
it is virtually impossible to develop software that can be proven to be error free, software development
strive to prevent the occurrence of errors, using methods and techniques include error detection,
correction and error tolerance. Both strategies are useful for keeping the system operating and preventing
failures. Unlike hardware with which there can be manufacturing and equipment failures with software

failures are the result of design errors that were introduced when specifications were formulated and
software written.
An error avoidance, developers and programmers make every attempt to prevent errors from
occurring at all. The scientific methods and techniques are used in the analysis and design phases are
aimed at meeting this objective. This emphasis on early and careful identification of user equipments is
another way this objective is pursued. Still analysis must assume that it is impossible to fully achieve this
objective.
Error Detection and Correction
This method uses design features that detect errors and make necessary change to correct either
the error while the program is in use or the effect on the user so that a failure does. Not occurs. Even
though the error may not happen for several years after the system is installed, the error is there from the
day of development. The failure occurs later.

10. USER INTERFACES DESIGN

1. Chat Server Window

2. Client/User Login Window

3. Client/User Chat Window

4. Private Chat Conversation Window

11. CONCLUSION
We can conclude that this project enables easy decision making with the support of correct and precise
information, Accurate and timely reports as there would be less chance for errors in transactions. The new
system can lead to increase in transactions i.e., more billing, more booking as the computerization speeds
up operations, Increase in revenue due to increase in transactions and prevents loss of revenue.
Management authorities can collect reports at any point of time from software. They need not worry
about the delay in reports from finance and other departments. Computers can handle large volume of
data without any frustrations.
As the software is totally integrated, there is no question of increased data entry problems. As the
software comes with very flexible user interface, users will feel very comfortable with new environment.

11.1.

Limitations
This application does not have a built in check out process. An external checkout package has

to be integrated in to this application. Also users cannot save their information so that they can access
later i.e. they cannot create wish lists which they can access later. This application does not have features
by which user can set client/user list and receive alerts.

11.2.

Scope of Future Work

The current application developed is in accordance with the requirement that has been provided by the
organization. On regarding the future enhancement, the application can be further expanded in accordance
with the changing scenario in the applications that need frequent changes in the changing environment
and expansion of the organization. Since the change in technology and user needs arises frequently in
certain short intervals of time, the application can be further upgraded to meet the requirements that may
arise in the far or near future. With regarding to the needs that arises, more and more features can be
included by adding it as separate modules and integrating it with the existing system. In future we can add
voice based chatting which is very useful in communication and also we can add or modify in video chat
also.

12. BIBLIOGRAPHY

Wikipedia for various diagrams & testing methods http://www.wikipedia.org/

Smart Draw for drawing all the Diagrams used in this report. http://www.smartdraw.com/
The Java Complete Reference
www.javazoom.com

Herbert Schildt