AN

INTERNSHIP REPORT
ON
WEB CHATTING APPLICATION MANAGEMENT
SYSTEM PROJECT
BY
KAMAL ACHARYA
(Tribhuvan University)

Date: 2022/04/25

1|Page
 PHASE 1

INTRODUCTION

In this chapter we are going to deal with the major points behind choosing a chat server as project and
why java is the programming language we choose, with a general overview about the project and how it
works.

1.1. Why Voice chat?

One year ago we was reading an article about Teleconferencing / chatting, which as we said it is a method
of using technology to bring people and ideas “together” despite of the geographic barriers. From that
time and on we started wondering if we can participate in that technology and how?
The idea of creating a chat server was initiated and it has two dimensions, one to have an experience in
network programming and the other is to let people conduct meetings with others in different locations.
Such that it crosses time zones, can reach many people, and reduce the paper flood.

1.2. General Overview

As a matter of fact there are several varieties of chatting. The simplest computer chatting is a method of
sending, receiving, and storing typed messages with a network of users. And other one is through the
voice or vocal. This network could be WAN (Wide Area Network) or LAN (Local Area Network). Our
chatting system will deal only with LAN’s (static IP address) and it is made up of two applications one
runs on the server side (any computer on the network you choose it to be the server) while the other is
delivered and executed on the client PC. Every time the client wants to chat he runs the client application,
enter his user name, host name where the server application is running, and hits the connect button and
start chatting. The system is many-to-many arrangement; every–one is able to “talk” to anyone else.
Messages may be broadcasted to all receivers (recipients are automatically notified of incoming
messages) and they can directly talk with other and this voice is broadcasted to all, here during this
operation all messages are encrypted at the sender side and decrypted at the recipient to disallow any
hackers to the server from reading these messages.
For this system to be physically realized you should be familiar with programming and networking. Java
is our programming language, TCP/IP is our network protocol, and finally “Sockets programming of

2|Page
java” is our programming interface to have access to network functionality. This is a first glance at our
senior project and the rest of explanations and ideas are eagerly waiting for you in the next chapters.

1.3. Project Structure

Since we are using the TCP/IP facilities, we are obliged to divide the project into two applications. In the
next few sections we are going to explain how these applications works and how they are synchronized
with each other.

1.3.1. Control Strings

A set of “Control Strings” was created, such that whenever the client or the server receives one of these
control strings, it should do a certain task. To distinguish these strings from normal strings (chatting
sentences) they are given the following format: “Control Command “+ massage +breaker constant.
For example if the client sends to server the string “Mute”, the server upon receiving this message, the
message parsing operation starts. It looks at the first four character if it is a “ Mute ” immediately it
recognizes that this is a control string. It continues parsing until it reads the control command which is in
this case username (such as ‘admin’). It matches this control to the group of commands it has.
Where it finds out that this client (valid) is trying to disconnect himself, so the function “onExit” is called
where the disconnection operation is completed. Else if the string does not begin with any command, then
it is a normal string and therefore it should be broadcasted to other connected users to be displayed in
their public window. In fact there are many controls in both server and client where each has its own job
and some of these controls are common between both server and client.

Table 1.1: Control Strings

Constant Description
TXT Text message
NC Remove nickname
Bye Logoff
NN Add nickname
NT Not Taking
ST more then two people in chat someone talking
MUTE admin mutes you
UNMUTE admin un-mutes you

3|Page
PT one on one chat someone is talking
SS Server status
No command string Received voice data

1.3.2. Client
The role of the client is to interface with the user, translate requested operations, and interact with the
server. It is essential for the client to have a GUI, to act as an interface for the user.
To get connected to server you just enter a username, the host name you want to connect to, and finally
hit the connect button, and then enter username.
During this connection operation, the client will send a control “NN” with username indicating to the
server that there is a new chatter. The server will parse this string and call the function which adds this
username to his list and retransmit another identical control string to all connected users containing all the
online usernames in order to update the “connected users list” in the client’s form.
The same thing happens when the user wants to disconnect himself where instead of sending “NN”, “NC”
is sent and “onExit” function is called which disconnects the user and do all the updates.
Clients may initiate voice calls to other clients by having the user give a `call' command and a host name
to call to. Voice communications, between clients are direct, with the server interference. Text
communications should also be possible. Voice communications should occur in real-time.
All voice communications occurs using the UDP protocol. Sound quality is maintained be at least 8000
samples per second, 16-bit sample size and 1 channel.

In case of the client, these steps are followed:

1. Create a socket
2. Specify the address and service port of the server program
3. Establish the connection with the server
4. Send and receive Text massage
5. Send and receive encoded voice.
6. Decoded and play the sound obtained from the server.
7. Record the sound, encode it and send.
8. Close the socket when finished, terminating the conversation.

4|Page
 Fig.1.1: general flow of voice.

1.3.3. Server
Till now it is clear that the server application has dual job, one to receive data and another to transmit
data. In fact it plays the role of a “traffic officer” (putting everything in order the right order). Since all the
chatting operations are passed through the server, then the main job of server is responding to the control
strings sent by clients as we have seen in the “in” and “out” requests.
It plays an important role during the voice chatting as well.
The role of the server is to coordinates all the activities of the clients in such a way that the clients interact
as fast and as possible. The Server is implementing a minimal GUI to give feedback on client activities.
The server will accept connections from multiple clients, but multi-threading is not necessary.
With voice calls, the server's only role is to check and see if the requested user is still active, and then to
initiate the session and then take the sound data from client and broadcast it.
The server side would follow these steps:
1. Create a socket
2. Listen for incoming connections from clients
3. Accept the client connection
4. Send and receive text massage and the command string
5. Send and receive the voice data.
6. Display the list of various users connected and there current status.
7. Close the socket when finished, terminating the conversation

5|Page
1.3.4. Transferring the voice:
When user connected with proper host name and port number, then user can talk with other user privately
(if only two users are present) or can conference with the other member. Users just have to click on talk
button when he wants to talk.
When we click on talk then the connection is open with microphone and recording is start. As well as the
playback of the received sound is also starts. Client notifies the server that user is talking and server
notifies the other client the same using command string and nick name.
For stopping the talking, same process is done but with different control command. Once transferring of
voice is taking place admin can mute and un-mute the client. Encoding and compression of voice is done
at sending client side and decoding and decompression is done at receiver side only. For compression we
are using speex technique.

6|Page
 PHASE 2

ANALYSIS

2.1 SYSTEM REQUIREMENT

The process of deciding on the requirement of a software system, which determines the
responsibilities of a system, is called requirement analysis. Requirement analysis is a software
engineering task that bridges the gap between system level requirements engineering and software design.
Requirement engineering activities result in the specification of software’s operational characteristics,
indicate the software’s interface with other system elements and establish constraints that the software
must meet. The following section presents the detailed requirement analysis of our project.

2.1.1 HARDWARE REQUIREMENT:

 Minimum two computers with two hard drives
o Processor of Pentium or above.
o Minimum of 256 MB RAM.
o Minimum of 20 GB Hard disk.
o Monitor.
o Mouse.
o Key Board.
 Two sound cards that support full-duplex operation
 Working network (LAN)
 Two sets of speakers and microphones

2.1.2 SOFTWARE REQUIREMENT:

 JDK(1.4 or above)
 Operating system (windows xp/Linux etc.)

7|Page
2.2 PROJECT PLAN

Sr. Module Task Date Of Date Of

No. Commencement Completion
1 Requirement Searching of requirement of voice chat
15/07/10 20/07/10
Analysis system in books and net.
Interview with users 22/07/10 26/07/10
Requirement understanding 26/07/10 01/08/10
Making requirement documents 01/08/10 05/08/10
Inspection of requirement documents 05/08/10 10/08/10
Decide the final goal and aim 10/08/10 14/08/10
Feasibility study 14/08/10 18/08/10
Making Specifications 18/08/10 28/08/10
2 Planning Understanding scope of the project 28/08/10 02/09/10
Assigning the activity 02/09/10 08/09/10
Risk analysis 08/09/10 15/09/10
Plan development for avoid the risk and
15/09/10 20/09/10
contingency plan
Inspection of plan documents 20/09/10 25/10/10
3 Design Design of voice transfer module 25/10/10 01/11/10
Design of GUI 01/11/10 04/11/10
Design or reuse a protocol 04/11/10 08/11/10
Review and inspecting the design 08/11/10 10/11/10
Test case generation and review 10/11/10 15/11/10
4 Implementation Read from microphone and play
01/12/10 10/12/10
back through speakers
socket code 10/12/10 18/12/10
Send random data over sockets
18/12/10 24/12/10
between machines
Design basic GUI controls 24/12/10 30/12/10
Merge all code into one code base 02/01/11 12/01/11
Solved Sound Delay Problem 12/01/11 22/01/11
Solved Sound Card Release
22/01/11 25/01/11
Problem
Design Advance GUI controls 25/01/11 01/02/11
5 Testing Unit testing 01/02/11 06/02/11
Integration testing 06/02/11 10/02/11
Verification and validation of
10/02/11 16/02/11
specifications
Live testing of system on LAN 16/02/11 20/02/11
Debugging 20/02/11 27/02/11
6 Documentation Making the documentation 01/03/11 08/03/11
Review the document and correct 08/03/11 10/03/11
Printing and Binding 10/03/11 13/03/11
7 Release 14/03/11 14/03/11

8|Page
2.3 NEED OF THE SYSTEM

1. To use existing computer network:

The system has a capability to use existing computer network for voice and text communication.

2. Reliable communication:
To provide more reliable communication through text chat at the same time voice communication
between users.

3. Portable application:
Robust application is needed which portably used for voice and text communication for diverse
computer network.

4. Distance Communication:
Application needed for long distance communication through network such as Internet.

2.4 SCOPE OF THE PROJECT

The “Multi User Voice Chat System” provides the following facilities:
1. Provide Login facility through Nick-Name :
 Identify different users, which are logged in.

2. Provide text transmission:

 Multi-user Voice Chat System provides text transmission through broadcast technique.

3. Provide voice transmission:

 System provides voice transmission through broadcast technique.

4. Simple and interactive GUI:

 System facilitates simple and interactive Graphical User Interface for the user while handling the
system.

9|Page
2.5 FEASIBILITY STUDY
Feasibility is the measure of how beneficial the development of an information system would be to an
organization. Important outcome of the Preliminary investigation is determination of whether the system
is feasible or not.
There are three aspects of feasibility study:
 Operational Feasibility.
 Economical Feasibility.
 Technical Feasibility.

2.5.1 Operational Feasibility:

The developed system must be simple to use so that there should not be any confusion while
operating it.
Our proposed system for Multi User Voice Chat System can easily meet the needs of the
organization in terms of their working & various operations. System helps in interaction with user
while determining various requirements. It is user-friendly with appropriate error messages to help. The
system offers validations & verifications.
The training is not required to operate the system in user’s environment. One can easily work with the
new system. In this way, the system is operationally feasible.

2.5.2 Economical Feasibility:

This is very important for considering the cost overheads while implementing the system. The cost
overheads include Software cost, Hardware cost, operating cost etc.
The proposed system would provide right type of information, at right time, at right place & in
right format. This will save time in decision making. The system is economically suited to the
organization & the companies will have substantial benefits by the system. As the project is built on
the platform which is regularly used by everyone, so there is no need to spend more amount of
money on it.
Considering all the benefits, the value of the proposed system outweigh the cost of development
of the system. Hence it is economical.

2.5.3 Technical Feasibility:

Technical Feasibility is usually raised during feasibility stage of investigation. Project will provide user
friendly approach & so any person with basic computer knowledge will be able to handle the
system easily. The system is technically feasible, as software and hardware are both easy available

10 | P a g e
by performing proper installation. User friendly features added to improve the performance of the
system.

2. 6 TECHNOLOGY USED
Java is an object-oriented language. Java was designed to be easy for professional programmer to learn
and use efficiently. Java inherits the C/C++ syntax and the object-oriented features of C++. Java can be
used to create two types of programs-applications and applets.
An output of a Java compiler is not executable code. Rather, it is a byte code. Byte code is a
highly optimized set of instruction that is designed to be executing by the Java Run-time system,
which is called the java virtual machine. Translating a java program into bytecode helps makes it
much easier to run a program in a wide variety of environments. Because the execution of every
java program is under the control of JVM, the JVM can contain program and prevent it from
generating side effects outside of the system. The use of bytecode enables the java run-time
system to execute programs much faster.

2.6.1 Benefits of using Java

 Java is Secure. Java achieves the protection by confining a java program to the java execution
environment and not allowing it to places extraordinary demands on a page, because the programs
must execute reliably in a variety of system. The hard-to-track-down bugs are simply impossible to
create in Java.
 Java is multithreaded. Java was designed to meet the real-world requirement of creating interactive,
networked pages. To accomplish this, Java supports multithreading programming, which allows you
to write pages that perform multiple tasks simultaneously.
 Java is dynamic. Java programs carry with them substantial amount of run-time type information
that is used to verify and resolve accesses to objects at run time. This makes is possible to
dynamically link code in a safe and expedient manner.
 Java’s exception handling. Java’s exception handling avoids the problem of checking errors and
handling them manually and brings run time error management into object-oriented world. Access to
other parts of the computer. Java programs can be dynamically downloaded to all the various types of
platform. Thus, it is portable.
 Java is robust. It is a strictly typed language; it checks your code at compile time. However, it also
checks your code at run time. Thus the ability to create robust program was given high priority in the
design of java. The multi-platform environment of the web

11 | P a g e
2.6.2 JAVA’S SUPPORT FOR SOUND:

What is sound?

From a human perspective, sound is the sensation that we experience when pressure waves impinge upon
the small parts contained within our ears. Normally, this is the result of pressure waves being transmitted
in air. However, sound pressure waves are not limited to air. For example, if you are an underwater
swimmer, sound pressure waves may reach your ear by way of water.

What does Sun have to say about the API?

Here is what Sun has to say about the Java Sound API:

"The Java Sound API is a low-level API for effecting and controlling input and output of audio media. It
provides explicit control over the capabilities commonly required for audio input and output in a
framework that promotes extensibility and flexibility."

Sun also tells us:

"Java Sound provides the lowest level of audio support on the Java platform. It provides a high degree of
control over audio-specific functionality. ... It does not include sophisticated sound editors and GUI tools;
rather, it provides a set of capabilities upon which such applications can be built. It emphasizes low-level
control beyond that commonly expected by the end user, who benefits from higher-level interfaces built
on top of Java Sound."

Sampled audio data

Sampled audio data can be thought of as a series of digital values that represent the amplitude or intensity
of sound pressure waves. This will be the primary topic of the first several lessons in this conversation.
This type of audio data is supported by the following two Java packages:

 javax.sound.sampled
 javax.sound.sampled.spi

According to Sun, the first of these two packages "specifies interfaces for capture, mixing, and playback
of digital (sampled) audio."

12 | P a g e
What is sampled audio data?

Sampled audio data is a special case of sampled data in general. For sampled audio data, a series of
digital numeric values is used to represent the intensity of a sound pressure wave. In other words, a set of
numeric values is used to represent the actual waveform of a sound pressure wave. Typically, the sound
pressure wave (or an electronic representation thereof) is sampled at a uniform series of points in time.

An example

For example, the graph in Figure 1 might represent a set of sampled audio data values produced by a
wide-band noise generator, such as the noise at an airport.

Fig.2.1: Sampled audio data

You can think of Figure 1 as the result of connecting a series of dots with short straight lines. The vertical
position of each dot relative to the red horizontal axis would represent the intensity of a sound wave at a
particular point in time. The location of each dot along the horizontal axis would represent the point in
time at which the measurement of intensity was made.

Capturing sampled audio

Typically sampled audio data is captured in two steps:

 Use a microphone to convert the sound pressure waves to electrical voltages that mimic the
waveform of the sound pressure wave.
 Use an analog-to-digital converter to measure the voltage at specific points in time and to convert
that measurement to a digital value.

13 | P a g e
Rendering sampled audio

The rendering of sampled audio data is also typically accomplished in two steps:

 Use a digital-to-analog converter to convert a series of digital values into an analog voltage
whose amplitude waveform reflects the digital values.
 Apply this voltage to a speaker, a set of headphones, or some other similar device that converts
the analog voltage to sound pressure waves that mimic the waveform of the voltage.

Package javax.sound.sampled

javax.sound.sampled Provides interfaces and classes for capture, processing, and playback of sampled
audio data.

Some of interface used:

Clip The Clip interface represents a special kind of data line whose audio data can
be loaded prior to playback, instead of being streamed in real time.
DataLine DataLine adds media-related functionality to its superinterface, Line.
Line The Line interface represents a mono or multi-channel audio feed.
SourceDataLine A source data line is a data line to which data may be written.
TargetDataLine A target data line is a type of DataLine from which audio data can be read.

Table2.2 Sound Interfaces

Some of classes:

AudioFileFormat An instance of the AudioFileFormat class describes an audio file, including

the file type, the file's length in bytes, the length in sample frames of the
audio data contained in the file, and the format of the audio data.
AudioFormat AudioFormat is the class that specifies a particular arrangement of data in a
sound stream.
AudioInputStream An audio input stream is an input stream with a specified audio format and
length.
AudioSystem The AudioSystem class acts as the entry point to the sampled-audio system
resources.

14 | P a g e
DataLine.Info Besides the class information inherited from its superclass, DataLine.Info
provides additional information specific to data lines.
Line.Info A Line.Info object contains information about a line.

Table 2.3 Sound classes

These are some of Exception generated while handling the sound:

LineUnavailableException A LineUnavailableException is an exception indicating that a line

cannot be opened because it is unavailable.
UnsupportedAudioFileException An UnsupportedAudioFileException is an exception indicating
that an operation failed because a file did not contain valid data of
a recognized file type and format.
Table 2.4 Sound Exception
Compression of sound

Speex is based on CELP and is designed to compress voice at bit rates ranging from 2 to 44 kbps. Some
of Speex's features include:

 Narrowband (8 kHz), wideband (16 kHz), and ultra-wideband (32 kHz) compression in the same
bit stream
 Intensity stereo encoding
 Packet loss concealment
 Variable bit rate operation (VBR)
 Voice Activity Detection (VAD)
 Discontinuous Transmission (DTX)
 Fixed-point port
 Acoustic echo canceller
 Noise suppression

2.7. CHALLENGES OF VOICE CHAT SYSTEM

Quality of Service
Due to the underlying unstable IP network, as opposed to the traditional circuit-switch phone networks,
voice chat system suffers from the effects of data packets not arriving in sequential order, or provides
QoS guarantees. This results in problems such as latency and jitter.

15 | P a g e
Delays
Several types of delays could happen in the voice chat system, namely, propagation delay, network delay,
accumulation delay, and processing delay. Propagation delay occurs as the signal requires traveling a
distance. Network delays occur due to the capacity of the network and the processing of the packets as
they travel through the network. Accumulation delay occurs as some amount of time is required to collect
a frame before processing can continue. Processing delay occurs as some time is required to encode and
decode the samples into and from packets.

Latency
Latency occurs when the voice data is queued at the router or other network element, causing delayed
from reaching its destination. It also causes problems such as echo and talker overlap. Generally, the end
to end latency is accepted within the 150ms range for good quality phone calls. To ensure the latency
remains below 150ms range, the primary causes of latency need to be considered.

Packet Loss
Packet loss occurs when packets are lost during transmission or simply arrive too late to be used.
Transmission of data (such as a webpage) makes use of the TCP/IP protocol suite which allows for
retransmission of missing packets, but voice chat system, which uses UDP, does not allow retransmission
and the missing packets are simply left out of the call. Such loss causes voice clipping and skips .This is
less of a problem than latency or jitter, since the codec used in voice processing can cope with a certain
amount: up to 1% is usually undetectable, more than 3% is the maximum permitted within industry
standards

Call Dropping/Blocking
Call dropping refers to the unexpected termination of voice chat system connection. It could be due to an
equipment failure at either end or at the midpoint element, or because of excessive network congestion
and the subsequent dropping of large number of packets.

Evolving Standards and Interoperability

Standards for VoIP and its support are still evolving, hence the device interoperability standards are still
developing.

16 | P a g e
 PHASE 3

DESIGN

3.1 USE CASE DIAGRAMS

Use-cases model the system from the end-user’s point of view. Created during requirements elicitation,
use-cases should achieve the following objectives:
 To define the functional and operational requirements of the system (product) by defining a
scenario of usage that is agreed upon by the end-user and the software engineering team.
 To provide a clear and unambiguous description of how the end-user and the system interact with
one another.
 To provide a basis for validation testing.
During OOA, use-cases serve as the basis for the first element of the analysis model. Using UML
notation, a diagrammatic representation of a use-case, called a use-case diagram, can be created. Like
many elements of the analysis model, the use-case diagram can be represented at many levels of
abstraction. The use-case diagram contains actors and use-cases. Actors are entities that interact with the
system. They can be human users or other machines or systems that have defined interfaces to the
software.
Following are the use-case from our system:
1. Client plug-in the headphone
2. Client enters the IP address and port number to the voice chat system.
3. voice chat system validate the IP address and port number
4. User enters the nick name and voice chat system validates it.
5. User press talk button to speak and start voice chat.
6. User enters the text to chat via text.

17 | P a g e
 Fig. 3.1: Use Case Diagram

3.2 SEQUENCE DIAGRAM

UML sequence diagrams are used to show how objects interact in a given situation. An important
characteristic of a sequence diagram is that time passes from top to bottom: the interaction starts near the
top of the diagram and ends at the bottom
Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence
of the messages instead of the relationships between the objects.
Sequence diagram for voice chat system:
 Client send the request to connect as button connect action performed.
 Server accepts the request, validate it and create the chat handler for client requested the
connection.
 Server continues listening on the port for new client requesting for connection.

18 | P a g e
  Now client writes the text data or voice data to chat handler which broadcast the accepted data.
 All clients accept the data and perform the necessary action, then client and chat handler are
destroyed as their work is done.

Fig 3.2.: Sequence Diagram

19 | P a g e
3.3 DATA FLOW DIAGRAMS

Data flow diagram is also called as ’bubble chart’ is a graphical technique, which is used to represent
information flow, and transformers those are applied when data moves from input to output.
DFD represents the system requirement clearly and identify transformers those become programming
design .DFD consists of series of bubble joint by lines.
DFD may be further portioned into different levels to show detail information flow e.g. Level 0, Level 1
etc.
DFD focuses on the fact ‘what data flow’ rather than ‘how data is processed’.
Level 0:
 Chat client enters IP address port number, voice, text to multi-user voice chat system.
 Chat server starts the server of multi-user voice chat system.
 Multi-user voice chat system sends text voice and chat to the chat client.
 The multi-user chat system sends information about client to Chat Server.

Fig. 3.3.1 Data Flow Diagram (Level 0)

20 | P a g e
Level 1:
 Client enters IP address and nickname to chat client.
 The chat client then sends nickname to the recorder and also sends the IP and nickname to Chat
Server.
 The recorder records the voice and sends the nickname voice to the chat server.
 The server sends the start command to chat server.
 The chat server creates the chat handler with appropriate client socket.
 The chat handler then sends Nickname, voice data to playback which plays the sound.

Fig. 3.3.2: Data Flow Diagram (Level 1)

21 | P a g e
 PHASE 4

IMPLEMENTATION

4.1 GRAPHICAL USER INTERFACE

Run the server. Enter the user name and

Password click login.

22 | P a g e
Run the client

Enter the IP address and port number and click connect

23 | P a g e
Enter the user name and click on submit button.

Server after the submission of username.

24 | P a g e
Now you can chat with other using “chat and talk” tab.
Enter the massage in input text field and press enter

25 | P a g e
You can get help about available command, just enter /help

You can set the compression ratio sound by entering the command as follow
/setmax value

26 | P a g e
You can clear the output window, by just clicking on the clear button.

27 | P a g e
Now you can talk with the other, just click on talk button.

28 | P a g e
If you are admin you can mute and a mute the other, just right click on user and select option.

29 | P a g e
You can also un-mute the other. Click on un-mute.

30 | P a g e
You can see the status of client. Just click on status tab.

If you are admin you can also see the status of server by just clicking on server status tab.

31 | P a g e
Exceptions at server side:

32 | P a g e
Blank password field:

33 | P a g e
Wrong username or password entered Exception:

34 | P a g e
Exception at client side:
Exception related IP address:

35 | P a g e
Exception Related to port number:

36 | P a g e
Server not found Exception:

Exception related to Username:

37 | P a g e
38 | P a g e
Exception related to redundant username:

Exception related to sever connection loss:

39 | P a g e
 PHASE 5

TESTING

5.1 TESTING:

Testing is the set of activities that can be planned in advance and conducted systematically. Numbers of
testing strategies are proposed. All provide software developer with a template for testing and all have
following characteristics.
 Testing begins at component level & works “outward” towards the integration of the entire
computer based system.

 Different testing techniques are appropriate at different points in time.

 Testing is conducted by the developer of the software & independent test group.

 Testing & debugging are different activities, but debugging must be accommodated in any testing
strategy.

5.2 VALIDATION AND VERIFICATION

5.2.1 What is Verification?

The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e.
Verification is a process that makes it sure that the software product is developed the right way. The
software should confirm to its predefined specifications, as the product development goes through
different stages, an analysis is done to ensure that all required specifications are met.
Methods and techniques used in the Verification and Validation shall be designed carefully, the planning
of which starts right from the beginning of the development process. The Verification part of
‘Verification and Validation Model’ comes before Validation, which incorporates Software inspections,
reviews, audits, walkthroughs, buddy checks etc. in each phase of verification (every phase of
Verification is a phase of the Testing Life Cycle)
During the Verification, the work product (the ready part of the Software being developed and various
documentations) is reviewed/examined personally by one or more persons in order to find and point out
the defects in it. This process helps in prevention of potential bugs, which may cause in failure of the
project.
The activities involved in Verification process are:

40 | P a g e
  Requirement Specification verification
 Functional design verification
 Internal/system design verification and code verification
Each activity makes it sure that the product is developed right way and every requirement; every
specification, design code etc. is verified!

5.2.2 What is Validation?

Validation is a process of finding out if the product being built is right? I.e. whatever the software product
is being developed; it should do what the user expects it to do. The software product should functionally
do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is
done during or at the end of the development process in order to determine whether the product satisfies
specified requirements.
Validation and Verification processes go hand in hand, but visibly Validation process starts after
Verification process ends (after coding of the product ends). Each Verification activity (such as
Requirement Specification Verification, Functional design Verification etc.) has its corresponding
Validation activity (such as Functional Validation/Testing, Code Validation/Testing, System/Integration
Validation etc.).
All types of testing methods are basically carried out during the Validation process. Test plan, test suits
and test cases are developed, which are used during the various phases of Validation process.
The phases involved in Validation process are:
 Code Validation/Testing
 Integration Validation/Integration Testing
 Functional Validation/Functional Testing
 System/User Acceptance Testing/Validation.

41 | P a g e
 Fig.5.1: Verification & Validation Model

5.3 TEST CASE DESIGN:

Test case specification has to be done separately for each unit. Test case specification gives, for each unit
to be tested, all test cases, inputs to be used in the test cases, conditions being tested by the test case, and
outputs expected for those test cases.
Test case specification is a major activity in the testing process. Careful selection of test cases that satisfy
the criterion and approach specified is essential for proper testing. Test case specification document gives
plan for testing that evaluates quality of test case.
With the specification of test cases, the next step in the testing process is to execute them. The
steps to be performed to execute the test cases are specified in a test procedure specification
which gives procedure for setting test environment and describes the methods and formats for
reporting the results of testing. Test log, test summary report, and error report are some common
outputs of test case execution.

42 | P a g e
 5.3.1 TEST CASES FOR CLIENT
1 Test cases for Login Info tab

Steps Description Input Data Expected Result Actual Result Status

1 Login info Click on login Login information It shows the login Pass
info tab must be displayed info.

1.1 IP text area Click on connect Must show IP It shows the Pass
button with blank incorrect error appropriate error
or incorrect IP with error cause
text
1.2 Port text area Click on connect Must show Shows the Pass
button with blank appropriate error appropriate error
or incorrect port with error cause
number

1.3 Connect button Click on connect It must change the It changes and Pass
button with button caption to enable the caption
appropriate IP and submit and enable the button and disable
port number user name text area the IP and port
and disable IP , port field.(if
(if connection to connection to
server is successful) server is
successful)
1.4 Username text Click on submit Must show It shows the Pass
area button with appropriate error appropriate error
invalid user name with error cause
1.5 Submit button Click on submit Must disable submit It disables Pass
button with button and username username field,
appropriate field and enable all submit button and
username tabs (server status tab enable all tab
if user is admin) and (server status tab
add user to users if user is admin)
connected list and adds

43 | P a g e
 username to list

1.6 Exit button Click on exit Must close the client It close the Pass
button window window

2. Test cases for ‘chat and talk’ tab

Steps Description Input Data Expected Result Actual Result Status

2 Chat & talk Click on ‘chat and Should show the It shows Pass
talk’ window ‘chat and talk‘ tab

2.1 Talk button Click on talk Should start the Is starts the Pass
button conversation and conversation
change the caption to
‘stop’
2.2 Stop button Click on stop Must stop the It stops the pass
button conversation conversation

2.3 Clear Click on clear Should clear the chat It clears the area Pass
button output area

2.4 Exit Click on exit Must close the client It close the Pass
button window window

2.4 Chat input area Enter the chat data Must broadcast the It broadcasts and Pass
and press enter entered data and show the entered
show in output data
window

44 | P a g e
 2.5 Help Enter the ‘\help’ in Must show command It shows Pass
input area and related to sound
press enter

3 Test cases ‘Popup’ menu

Steps Description Input Data Expected Result Actual Result Status

3 Popup menu Right click on It must show the It shows the menu Pass
‘users connected’ popup menu
list

3.1 Mute Right click on If current user is It mutes the Pass

‘users connected’ admin then mute the selected user.
list and Click on selected user
mute
3.2 Un-mute Right click on If current user is It Un-mute the Pass
‘users connected’ admin then Un-mute selected user.
list and Click on the selected user
Un-mute

4. Test cases for ‘status’ tab

Steps Description Input Data Expected Result Actual Result Status

4 Status tab Click on status tab Must show status tab It shows Pass

4.1 Received status Click on status tab. Must show the It shows Pass
area information related to
received byte

45 | P a g e
 4.2 Transmit status Click on talk Must show the It shows Pass
area button and click on information related to
status tab. transmitted byte

5. Test cases for ‘server status’ tab

Steps Description Input Data Expected Result Actual Result Status

5 server status tab Click on server Must show the server It shows pass
status tab status if current user
is admin
6 window’s close Click on window’s Must close the client It close the pass
button close button window window

5.3.2 TEST CASES FOR SERVER

Steps Description Input Data Expected Result Actual Result Status

1.1 Login button Click on button It must show the It show the pass
with blank error appropriate error
username and
password filed
1.2 Login button Click on button It must validate user It does pass
with valid and show the server
username and status if validated,
password filed else must show
appropriate error.
1.3 Status area Click on login It must show the It shows pass
button with valid status of server with
user name and number of user

46 | P a g e
 password connected and there
activity

2 window’s close Click on window’s Must close the client It close the pass
button close button window window

5.4 SYSTEM TESTING:

5.4.1 Recovery Testing:

Recovery testing is a system test that enforces the software to fail in a variety of ways and verifies that
recovery is properly performed. If the recovery is automatic, re-initialization, check pointing mechanism
and data recovery and restart are each evaluated for correctness. If recovery requires human intervention,
the mean time to repair is evaluated to determine whether it is within acceptable limits.

5.4.2 Security Testing:

Security testing attempts to verify that protection mechanisms built into a system will infract protect it
from improper penetration.

5.4.3 Stress Testing:

Stress tests are designed to handle programs with abnormal situations. Stress testing executes a system in
a manner that demands resources in abnormal quantity, frequency or volume.

47 | P a g e
 PHASE 6

FUTURE SCOPE

 We try to manage the private chat in this system as current system is based on broadcasting of
messages.
 We will try to design more interactive GUI and provide more facility for user e.g. to manage
his/her account separately.
 We will try to record sound of user.
 In future we developed the full fletched database application associate with current system.

48 | P a g e
 PHASE 7

CONCLUSION

As a matter of fact this project took us one year to be completed and this year is divided into two sections,
six months of collecting information and six months of writing java code.
First, the theoretical section, where we have learned lots of things in networking, such as the TCP/IP
protocol (number one in network protocols) and how it works, sockets, and network programming which
is one of the best programming domains in Computers.
Second, the technical section which let me becomes more familiar with a new programming language
such as java and its network components and support to sound package.
Having a voice chat server as a final year project obliged you and indirectly to go into the tiny details in
networking and no one will teach you these details. Lots of experience was gained and another beautiful
face of networking was discovered.
The psychological part we have learned from that project is that, nothing in life comes easily and at the
same time nothing is impossible only it needs time, patience, and hard working.
Finally we would like to thank my College and all my instructors for helping me to reach this level.

49 | P a g e
 PHASE 8

REFERENCES

8.1 REFERENCE BOOKS REFERRED:

 Complete Reference Java-Herbert Schildt
 Java 6 (Black Book)-Kognet Solutions Inc.
 Software Engineering- Roger S. Pressman

8.2 WEB SITE FOR REFERENCES:

 http://www.eol.ucar.edu/software/java/jdk1.5
 http://java.sun.com/j2se/1.3/pdf
 http://download.oracle.com/javase/tutorial

8.3 Resercher References

Acharya, Kamal. "STUDENT INFORMATION MANAGEMENT
SYSTEM." Authorea Preprints (2023).
Acharya, Kamal. "Library Management System." Available at SSRN4807104 (2019).
ACHARYA, KAMAL, et al. "LIBRARY MANAGEMENT SYSTEM." (2019).
Acharya, Kamal. "Online bus reservation system project report." Authorea
Preprints (2024).
Acharya, Kamal. "Online bus reservation system project report." (2024).
Acharya, Kamal. “Online Bus Reservation System.” SSRN ElectroNIC ASIA
Journal (2024): n. pag.
Acharya, Kamal. “Student Information Management System Project.” SSRN
ElectroNIC ASIA Journal (2024): n. pag.
Acharya, Kamal. “ATTENDANCE MANAGEMENT SYSTEM.” International
Research Journal of Modernization in Engineering Technology and
Science (2023): n. pag.

50 | P a g e
Acharya, Kamal. “College Information Management System.” SSRN ElectroNIC
ASIA Journal (2024): n. pag.
Acharya, Kamal, Attendance Management System Project (April 28, 2024).
Available at
SSRN: https://ssrn.com/abstract=4810251 or http://dx.doi.org/10.2139/ssrn.4810251
Acharya, Kamal, Online Food Order System (May 2, 2024). Available at
SSRN: https://ssrn.com/abstract=4814732 or http://dx.doi.org/10.2139/ssrn.4814732
Acharya, Kamal, University management system project. (May 1, 2024). Availableat
SSRN: https://ssrn.com/abstract=4814103 or http://dx.doi.org/10.2139/ssrn.4814103
Acharya, Kamal, Online banking management system. (May 1, 2024). Available at
SSRN: https://ssrn.com/abstract=4813597 or http://dx.doi.org/10.2139/ssrn.4813597
Acharya, Kamal, Online Job Portal Management System (May 5, 2024). Available at
SSRN: https://ssrn.com/abstract=4817534 or http://dx.doi.org/10.2139/ssrn.4817534
Acharya, Kamal, Employee leave management system. (May 7, 2024). Available
at SSRN: https://ssrn.com/abstract=4819626 or http://dx.doi.org/10.2139/ssrn.4819626
Acharya, Kamal, Online electricity billing project report. (May 7, 2024). Available at
SSRN: https://ssrn.com/abstract=4819630 or http://dx.doi.org/10.2139/ssrn.4819630
Acharya, Kamal, POLICY MANAGEMENT SYSTEM PROJECT REPORT. (December 10, 2023).
Available at SSRN: https://ssrn.com/abstract=4831694 or http://dx.doi.org/10.2139/ssrn.4831694
Acharya, Kamal, Online job placement system project report. (January 10, 2023). Available at
SSRN: https://ssrn.com/abstract=4831638 or http://dx.doi.org/10.2139/ssrn.4831638
Acharya, Kamal, Software testing for project report. (May 16, 2023). Available at
SSRN: https://ssrn.com/abstract=4831028 or http://dx.doi.org/10.2139/ssrn.4831028
Acharya, Kamal, ONLINE CRIME REPORTING SYSTEM PROJECT. (August 10, 2022). Available at
SSRN: https://ssrn.com/abstract=4831015 or http://dx.doi.org/10.2139/ssrn.4831015
Acharya, Kamal, Burber ordering system project report. (October 10, 2022). Available at
SSRN: https://ssrn.com/abstract=4832704 or http://dx.doi.org/10.2139/ssrn.4832704
Acharya, Kamal, Teachers Record Management System Project Report (December 10, 2023). Available
at SSRN: https://ssrn.com/abstract=4833821 or http://dx.doi.org/10.2139/ssrn.4833821
Acharya, Kamal, Dairy Management System Project Report (December 20, 2020). Available at
SSRN: https://ssrn.com/abstract=4835231 or http://dx.doi.org/10.2139/ssrn.4835231
Acharya, Kamal, Electrical Shop Management System Project (December 10, 2019). Available at
SSRN: https://ssrn.com/abstract=4835238 or http://dx.doi.org/10.2139/ssrn.4835238

51 | P a g e
Acharya, Kamal, Online book store management system project report. (Febuary 10, 2020). Available at
SSRN: https://ssrn.com/abstract=4835277 or http://dx.doi.org/10.2139/ssrn.4835277
Acharya, Kamal, Paint shop management system project report. (January 10, 2019). Available at
SSRN: https://ssrn.com/abstract=4835441 or http://dx.doi.org/10.2139/ssrn.4835441
Acharya, Kamal, Supermarket billing system project report. (August 10, 2021). Available at
SSRN: https://ssrn.com/abstract=4835474 or http://dx.doi.org/10.2139/ssrn.4835474
Acharya, Kamal, Online texi booking system project report. (March 10, 2022). Available at
SSRN: https://ssrn.com/abstract=4837729 or http://dx.doi.org/10.2139/ssrn.4837729
Acharya, Kamal, Online car servicing system project report. (March 10, 2023). Available at
SSRN: https://ssrn.com/abstract=4837832 or http://dx.doi.org/10.2139/ssrn.4837832
Acharya, Kamal, School management system project report. (July 10, 2021). Available at
SSRN: https://ssrn.com/abstract=4837837 or http://dx.doi.org/10.2139/ssrn.4837837
Acharya, Kamal, Furniture Showroom Management System Project Report (March 21, 2021). Available
at SSRN: https://ssrn.com/abstract=4839422 or http://dx.doi.org/10.2139/ssrn.4839422
Acharya, Kamal, Online Vehicle Rental System Project Report (March 21, 2019). Available at
SSRN: https://ssrn.com/abstract=4839429 or http://dx.doi.org/10.2139/ssrn.4839429

52 | P a g e