Design and Implementation Document for Chat Application

This document outlines the design and implementation of a client/server chat application that allows clients to chat with each other, while also allowing a given client to send a message to all other clients. The server uses threads to manage client connections. Clients are required to first register with the server; the registration details of a client are persisted in an xml file, which acts as the database for the application.

Chat Application
Design and Implementation Document
[Name]

Table of Contents
1.0 Application design.....................................................................................................................2
2.0 Software Development..............................................................................................................3
2.1 Server Design.........................................................................................................................3
2.2 Client Design..........................................................................................................................4
3.0 Application Walkthrough...........................................................................................................6
4.0 Software Testing......................................................................................................................10
TEST CASE 1: SUCCESSFUL LOGIN....................................................................................................10
TEST CASE 2: Invalid Login Details...................................................................................................10
TEST CASE 3: CHECK IF THE APPLICATION PERSISTS DATA..............................................................11
TEST 4: Test Various Modes of Chatting..........................................................................................11
Chat between : Admin and Department......................................................................................12
Test Group Chat...........................................................................................................................12

1.0 Application design
The application developed is a Client/Server chat application, that allows clients to chat with
each other, while also allowing a given client to send a message to all other clients. The
server uses threads to manage client connections. Clients are required to first register with the
server; the registration details of a client are persisted in an xml file, which acts as the
database for the application. A client is only required to register once. Before chatting, a
client has to login. The server receives a client's login request which has a username and
password. The server then opens the xml file which contains list of registered users and their
credentials, and verifies if the client's credentials are correct. Each client connected to the
server can see all other connected clients. By selecting a another client, one can directly chat
with only the given client.
The General flow of the Server start up is as follows;
Figure 1.0 General operation of the server
The client has a more detailed graphical user interface. When a client is started, it checks for
the server and automatically creates a connection to the server. The connection is performed
by the ClientSocket class which also listens for any messages forwarded by the server.

2.0 Software Development
2.1 Server Design
The server is implemented using five classes;
 ChatServer: this is the graphical user interface for the GUI, which creates a simple
interface to show connection status.
 ServerThread: the class creates the threads that control each client connection
 Message: an object that holds the received message or message to be sent
 Database: this class interacts with the XML file, which acts as the database for this
application. The file stores details of registered clients.
 SocketServer: this class performs the bulk of the processing for the server. It creates
the server and listens for client connections using threads.
Figure 2.0 Server class UML diagram

2.2 Client Design
The classes that makes up the client are;
 ChatClient: this class creates the GUI for the chat client.
 ClientSocket: it creates a connection to an existing server, sends messages to the
server, and listens for incoming messages
 Message: an object that holds the message to be sent or message received.
Figure 2.0 Chat Client UML class diagram
The developed chat application is higly efficient due to the use of threads. As the code
snippet below shows, each connection from a client is handled by a new thread. The chat
server is multi-threaded to ensure multiple chat clients can operate. The server is also
designed to handle multi-part communication, where a chat client can send out a message to
multiple receipients. The recepients can choose to reply to all or just reply to one given

receipient. The design also enables clients to chat with all the active clients. As shown in the
code snippet below, the functionalities are enabled by use of threads.
public SocketServer(ChatServer frame, int Port){
clients = new ServerThread[50];
ui = frame;
port = Port;
db = new Database(ui.filePath);
try{
server = new ServerSocket(port);
port = server.getLocalPort();
ui.txtServerConsole.append("Server startet. IP : " +
InetAddress.getLocalHost() + ", Port : " + server.getLocalPort());
start();
}catch(IOException ioe){
ui.txtServerConsole.append("\nCan not bind to port " + port + ": " + ioe.getMessage());
}
}
Another feature of the application is the persistence of data. Users who sign up with the chat
app are persisted in a file database. An XML file is used for this purpose.
Figure 5.0 Basic chat operation

3.0 Application Walkthrough
To start the application, the server has to be started first. The server displays a message if it has
successfully started, as shown below.
Figure 6.0 Chat server after starting up.
With the server up and running, a client can be started and connected to the server. By default, the
username and password field are field with the test user that is already in the database;
admin/admin. A user has to enter own credentials and register on the application.
Figure 7.0 Chat client application

When the client is started, the server accepts the connection request and display a message to
indicate that a connection has been made.
Figure 8.0 Server showing successful connection of a client. A thread was created to handle the
client operations
Figure 9.0 Client Successful Login

Starting another Chat Client.
When another client is started, the server creates another thread to handle the new client, as shown
below.
Figure 10. New thread to handle another client.
Registering a new User
 Username: school
 password: school
To create a new user, the username and password have to be typed into the respective fields and
then press the Sign Up button.
Figure 11.0 Chat Client after a successful signup

Figure 12.0 Two chat clients exchanging messages
4.0 Software Testing
TEST CASE 1: SUCCESSFUL LOGIN
Test User Login
Data: Pre-registered default user [ admin/admin]
Test Result
The test was successful, a user who already exists in the database can successfully login
TEST CASE 2: Invalid Login Details
Data
 username: admin
 password: admin3

With the wrong password, the login was unsuccessful, therefore the test was a success.
TEST CASE 3: CHECK IF THE APPLICATION PERSISTS DATA
Test Data: Register a new user with credentials department / department
then restart the server and try to login with the credentials.
The new user was able to login even after restarting the server; indicating that the data were saved
into the database successfully.
TEST 4: Test Various Modes of Chatting
 Chatting with a given user
 group chat
Procedure: start 3 chat clients and test the chatting modes.

Chat between : Admin and Department
The test for the chat between Admin and Department was successful. The messages were delivered
to the right recipients; the school did not receive the messages as expected.
Test Group Chat
The group chat messages were delivered to all the active users, as expected . The test was therefore
successful.