2. Requirements Specification

SINGLE

1. Background

We started off our project in the course Software Engineering where we made requirementsspecification of a chatting program. A 'chat' is within our definition a virtual room, operated by a main computer, the so called 'Server'. Other computers are then allowedto enter the room and talk to each other. These computers are called 'clients'.

In this course, Network Programming, we have written the actual code and the languagewe have used is Java. The chat program will be text-based, meaning that the user will typeusing the keyboard to send messages to other users. On the other hand, everything else isdone with a graphical interface.

2. Requirements Specification

When starting up the project we made the following requirements. This was before we knew exactly what kind of program we were going to create.

General descriptions

The main purpose of the software is to enable fast and easy communication between its users. The communication is divided into two parts, messaging and real-time chat. The software shall also support two other functions, file-transferring and blind-date setup. Apart from the file-transferring, which can be seen as a bonus, all functions aim towards letting its users find an appropriate partner for a “real-life” relationship.

Functional requirements

Upon install the user will be required to either resume an already active account or create a new account.
Upon creating a new account the user will be required to submit the following personal information: Name, nickname, age, sex, marital-status and occupation. The users will also be able to submit a text about themselves as well as a photo, however it is not required to create an account. All accounts is to be assigned a unique account-number, identifying the account.
The software will allow a user to send messages to another user without anybody else than the intended receiver receiving it.
When a user chooses to send a message to another user he/she will be presented to a writable area where he/she can type the message. The message will be sent when the user presses a button “send”. The user will also be able to cancel the action by pressing a button “cancel”.
The software shall support at least 1000 characters in a message.
When a user receives a message he/she will be notified about the event visually. If a user wishes he/she can also assign audio files to be played when a message is received from a particular user, enabling different sounds to be played depending on the sender of the message. The sound will only be played the first time in a conversation, when the writeable area pops up.
The software allows the user to chat, user-to-user, with up to 20 other users simultaneously.
The software is to support real-time chat rooms with up to at least 10 users participating in it. The creator of the room is to have the ability of kicking and banning users from the room.
The software is to make it possible for users to save a reference to other users in a contact list.
The contact list will show each contact and also showing the status of the user. The contact list will meet the following requirements:
There will be several statuses of the users to choose from, “Available for flirt”, “Available for chat”, “Away”, “Online” and “Not online”. Not online is the mode when a user is not connected to the server.
A user will be able to set the current status him/herself, choosing from the list described in 4.1
From the contact list a user will be able to send messages to a user, invite the user for a chat, ignore the user, send a file to the user or view the user’s information.
When a user select a contact on the contact list he/she will be presented to the different options described in 6.3
If a user double-click on a contact on the contact list the default action, sending a message, will be performed.
A user of the software shall be able to add contact to his/her contact list by searching on either their account-number or any part of their personal information, described in 2.
If a user chooses to ignore a user, as described in 3.1.3, he/she will not be presented to any action the ignored user performs.
A user can send messages to someone on his ignore list but will receive a message that the user will be unable to reply.
The software will allow a user to perform a personality test, for used in the blind-date function described in 5.1.
The software will support a “blind-date” function. This function will find the user a suitable date, who has performed the personality test, based on geography and the results of the personality tests. The software will only search dates among those who has performed the personality test and have the results saved.
The results of the personality test described in 5 will be saved, if the user so wish, and will be used for future blind dates.
The software will store all the information of the user on a server, so that the user can reinstall the program and resume where he left.
The information on the server, described in 6, will be protected by a password, selected by the user when he created his account.
The software shall allow a user to change his/hers personal information at any time he/she is connected to the server. All information but the account-number is to be changeable.

Non-functional requirements

The software is to have a fast and responsive interface on all platforms supporting Java.
The program will not require more than 20Mb of RAM when running
The program will not consume more than 20% of the CPU-cycles of a Pentium-3450 MHz when running, other than occasionally during short periods of time.
The program is to require a maximum of 50Mb of permanent storage capacity.
The program is to be easy to install and the installation will not require more technical information from the user than where the program is to be installed.
All information between the server and the clients will be sent in an effective way, not require more than 0.5kb/s when idle.
The system shall not disclose any information send between two users to the operators of the system.
The software shall be easy to use and have a user-friendly graphical user interface
The software shall be reliable on all windows-based platforms released after windows-98.

3. Model

Server:

These are the classes on the server-side.

CServer:

This is the main program of the server. The class starts up the MultiCastServerand the ServerAssistant. When this is done the server waits for new connections.

MultiCastServer (thread):

This class is responsible for reporting the server IP-address to the client. It does so by joining a multicast group (all-systems.mcast.net) and start listen for request at a specific port(3735). When a request is send to this group and to the designated port, the class will reply to the sender of the request with the IP-address of the server. This way the client doesn’t have to know the address of the server when it’s launched.

MessageBase:

MessageBase handles the messages from all the clients, when a message is received the ServerAssistant will request the content of the message from this class.

ClientCon (thread):

ClientCon handles the connection to a specific client once it’s established. Everything sent to or received from a client is processed by a ClientCon thread. When a connection is established ClientCon continuously listen for data coming from the Client, unless busy sending data to it.

ServerAssistant (thread):

The ServerAssistant keep track of the users connected to the server. As of now, both the number of userObjects that can be stored and the number of connections that can be processed is limited to 100, but this could easily be change if need be. Since the ServerAssistant have knowledge of all the connected users it has been made responsible for determining on what connection the outgoing messages should be sent on. When the determination has been made the appropriate method is called at the ClientCons dedicated for serving the connection to the receiver of the message.

User:

This is an object storing attributes such as sex,age and hostadress of a client. This object is created at the client and is transferred to the server when a connection has been made. Whenever a client is changing it’s userdata it’s User-object is resent to the server which in turn distribute it to all connected clients. This way, the server and all users has access to the userObjects of all the users in the chat.

ClientList:

ClientList is a ghost of the past in this program, made for the times when the information about the user’s was string-based and not structured in objects as of today. If we hadn’t called a complete stop for changes in the program, the first thing we would do is to remove this class, since it fill no purpose and complicate the code.

Client:

These are the classes on each client-side.

SingleClient:

This is the main program of the client. All it does it to start up the GUI by creating a ClientGUI object.

ClientGUI:

The ClientGUI is the graphics you see when you start the application. When created it created an ActionHandler object to handle the actions performed by the user in the GUI.

GetServers:

When the ActionHandler class is created, it create and launch a GetServers object. This is the client for the MultiCastServer object on the serverside. It will connect to the same group as MultiCastServer and send a string (“singleserver request”) to port 3735 to all servers in that group. If a MultiCastServer has been created by the server it will reply with the IP-address of the server. When the user select “Connect” from the menu, ActionHandler will request this IP-address and use it to connect against.

ActionHandler:

The ActionHandler is a central class in the client application. It gets inputs from ClientGUI, PrivateConversations, EditProfile and profile. Actionhandler connects with the CServer and then sends messages from ClientGUI on the client side to the ClientCon on the server side. Every message and all user information is sent through the ActionHandler.

Listen:

Listen receives the messages from the server. It also receives the files in a file transfer but the directly from the other client.

PrivateConversation:

PrivateConversation is like ClientGUI, and sends the private messages to the actionhandler.

FileTransfer:

FileTransfer is responsible for both the receivement and sending of a file. The file is read byte by byte with a fileInputStream and send over a regular outputStream to the receiver of the file which does the same thing, but reverse. The file is transferred between the clients only, and never through the server.

EditProfile:

The EditProfile object creates a window where the userinfo is displayed. In the same window the info can be changed by the user.

Profile:

The Profile object is identical to the EditProfile object except that the user isn’t allowed to change any data. This is used for displaying other user’s information.

4. User manual

This software is programmed in java and can run on any operating system.

4 .1. Getting Started using Single

Before starting chatting with a beautiful man or a woman, make sure you have all class files included for the client. (ActionHandler.class, ClientGUI.class Listen.class, SingleClient.class, GetServers.class) Then start the program by initiating the SingleClient.class file.

4.2. Connection

When initiating the software it automatically connects to the server. It is also possible to connect by selecting "Connect", or disconnect by selecting "Disconnect" in the File menu.

4.3. Your Profile

The first step to a successful Single Chat is to make sure your user profile is up to date. Select Edit Profile in the Edit menu and a window with profiles will appear. Here you can easily fill in your nickname, gender, age, hair colour, length, weight and interests.

4.4. Change Nickname

It's possible to change nickname simply by selecting the "Change nick" bar in the Edit menu. Make sure to choose a unique nickname. In this version of Single it is possible to have the same nickname as other users.

4.5. Send Messages to all

To send messages simply write the message in the textbox at the bottom of the chat window and press the "Send" button to send the message.

4.6. Send Private Messages

Select a user in the user list and right click on the nickname and choose "Send Private messages" from the options list. A new window will appear and private chat is now possible.

4.7. File Transfer

To send a file to another user simply select the user in the nickname list and right click. Select File transfer in the menu and select the file you want to send. Then press the Send button.

4.8. View other user’s profiles

Right click on the user in the nickname list. Select View Profile from the menu.

4.9. Clear Console

To clear the console, simply select the "Clear console" bar in the Edit menu.

4.10. Help

Select the Help bar in the Help menu for help.

5. Evaluation

Our project came out very successfully even though we didn’t implement all the requirements. Whenthe requirements were made, we had no knowledge about how this course was planned and how much available time we had. When writing the requirements in the previous course, we were very much into making some sort of ICQ-client, but after starting up this course we found out that it was more of a mIRC-client that was required.

Since the requirements were changed the final outcome is more of a IRC-client with a couple of ICQ-related functionalities such as private chat, file transfer and personal profiles. The client has no compatibility with either IRC or ICQ though, it is based on a protocol developed solely for this project.

Although we are very satisfied with the program there are still plenty of things that could be improved if we were given more time. Those improvements include, among other things:

Permanent storage of userdata.
Improved stability of the server.
Improved reliability of the filetransfer.
Possibility to show a photo in the userinfo
Possibility to chat with a person of the opposite sex by clicking a button.

There are two known bugs in the software. The first is a bug occurring, as it seems, at random occasions when a client disconnect from the server. For some reason the server doesn’t acknowledge the disconnection and continues it’s work as if the client was still connected. The second bug is within the file-transfer operation. For some reason the fileinputStream doesn’t correctly read files that are not string based, such as .class files.

Unfortunately we didn’t have the time to find and correct these bugs within the time limits of the project.

If we were to redo the project we would spend more time planning for programming solutions before starting writing the code. As it now turned out, we started with one solution and then, when we realized it could be done better in another way, we switched and started to redesign the program. Of course, the result is something of a mess with code remaining that was optimized for a whole different solution than the one we later chose to pursue. Given a little more time, or dedication from our side, the code could be made much cleaner and easy to read.