LAN MESSENGER Response to Request for proposal CS455 TERM PROJECT
Dilip Kumar Kola (Y5169) Virajith Jalaparti (Y5510) 1. Introduction
This document proposes a solution which addresses the requirements proposed for the Lan Messenger. It describes the approach used to solve the problem through architectural diagrams, which offer different views to the software system to be developed. It further goes on to estimate the cost and effort that might be required to develop this software.
2.
Design of the Software
The software will consist of two different components, one of which will be deployed on a central server and the other will be used by the people who want to use the messaging system. The server side software will be responsible for maintaining the registration details of the various users, checking the passwords of the users who intend to log in using the client side software and maintaining the details of the online users. The client side software will allow the user of it to register with the server, log in and send text messages, files and perform voice chat with other users who are online. The server has to be a pre-specified entity. The client will have to acquire the software by downloading from a server or through a CD. In order to allow software to run on both Linux and Windows, it will be written in JAVA. The server is involved only in the registration process and the log-in process. After that the clients directly communicate with each other 2.1 An architecture of the system in the Deployment View
Figure 1 describes the architecture of the software system in the allocation view. The client side software is deployed on the user’s computer and the server side software is deployed on the pre-decided server. In the client side software, the network handler is used to communicate and send various messages over the network. The text message handler is to handle the text messages sent between the users. The voice chat handler and the file transfer handler, similarly, handle the voice chat and the file transfer between the clients. The temporary message store is used to store the messages temporarily when the user disables the message receiving on his software. The friend list manager is used to manage the friends of the user, which includes deciding whether a
particular user is a friend or not, whether the user wants to receive messages from a particular user or not. On the server side, the network handler functions similarly. It is used to send and receive various messages. The registration process handler is used to handle the registration of new users and make sure that the same user-id is not registered for more than one user. The log in process handler helps in the log in process of the user. It checks whether the user-id is registered or not and the validity of the password entered. The list of all the online users is maintained by the online user information handler.
Client Side Software
Friend List Manager Voice Chat Hander
GUI
Text Message Handler File Transfer Handler
Temporary Messages Store Control Messages Handler
Network handler
L o c a l A r e a N e t w o
Server Side Software
Registration Process Handler Online User Information handler Log In process handler
Network handler
Figure 1
2.2 2.2.1
An Architecture of the software in the Module View Architecture of Client Side Software
Figure 2 describes the architecture of the client side software using the logical view. It describes how the various modules communicate. All the modules which receive and handle the various types of messages receive and send these messages through the network handler. The message handling modules also depend on the GUI to receive different user messages like send a text message, send a file etc. The GUI depends on the friend list manager for display of the various online users, the user’s friends and to decide whether a particular message must be displayed to a user. It further uses the message store module in order to display messages that are received by the user’s software when the user had decided that he does not want the messages temporarily.
Figure 2
2.2.2
Architecture of Server Side Software
Figure 3 describes the architecture of the server side software using the logical view. It shows the interdependence between the various modules. The network module is the main base for the other modules and is used by them to receive and send messages from and to the network. The registration module is the one which checks whether the user-id that a particular user is using to register already exists or not. If the user-id is new, it stores the password corresponding to that id. The log in process module is the one which is used whenever a user wants to log in into the software. It checks with the registration module if the username exists and determines whether the user must be allowed to be logged in with that user-id or not depending on the password entered. It also handles the messages regarding the logging out of a user. The online user module maintains a list of all the users who are currently online. It gets the information from the log in process module.
Registration Module
Log‐In Process Module
Network Module
Online User Information Module
Figure 3
3.
Cost and Effort Estimates
The following is an estimate of the amount of person days that would be required in designing and implementing the various modules involved in this software: Module Name Network Module on client + server Voice Chat Module File Transfer module Text Transfer module Control Message handling module Message Store module Friend List manager Graphical User interface 5 3 2 2 2 1 1 5 Number of person days
Registration module Log-In Process Module + Online user Information module
1 1
Apart from the design and implementation, the testing may require about 3 person days. Thus, on the whole the project may require about 30 person days.