SIMPLECHAT

The Little Caesars

Cory, Sean, Seth, James, Madison

Domain Analysis

Instant messaging Expanding Simplechat Adding to the existing classes Adding commands for users

Domain Analysis

Customers and Users Quick Messaging (physical speed and

time saved) Networked Users (Internet, LAN, etc…)

Domain Analysis

Original Tasks and Procedures: Send a message

How it was

What we did

Commands LoginID and passwords Blocking Private Messages Forwarding Channels Observer Layer

Platform/Process Requirements

Java 1.2.0 or higher

Used SVN

Costs lots of hours and pizza

Transmission Control Protocol / Internet Protocol (TCP/IP) network

Quality Requirements Usability

The system is very user friendly with help menus, clear output when errors occur, and consistent notation.

Users should not worry about case sensitivity for certain aspects of the program (e.g. usernames, channel names, commands)

Reliability SimpleChat shouldn’t fail due to problems in the implementation

of the program Maintainability

SimpleChat is designed to be flexible and easy to change Reusability

SimpleChat is designed to work across a variety of systems Simple Consistent

Command Requirements

Client should be able to perform special functions

How?Client program checks user input.

Check for what?Starting with ‘#’ will be command

Then what?Each function will have a command name

Some Commands

#quitTerminate Client gracefully

#logoffDisconnect from Server

#sethost<host>If client is logged off, sets host to connect to

#stopServer stops listening for connections

Some Additional Requirements Only appropriate users should be

informedEach method makes decisions

User should know status of command callMethods will display error messages

Informed if usage is incorrectReferred to help functionCase-insensitive.

Command Use Cases

Use case: Commands - #logoff Actors: client Goal: allow client to logoff from the server, but not quit.  Preconditions: Client must be logged on and connected to the server Summary: when a user types the #logoff command they log off from the server they are connected to but do not quit the program. Steps: Actor actions System responses1) client types #logoff command 2) Client side logs off from server but does not quit the program.

Command Use Cases cont.

Use case: Commands - #stop Actors: Client using server Goal: Cause the server to stop listening for new clients. Preconditions: client using server must be connected to the server. Summary: When the user of a server types in the #stop command, the server will stop allowing new clients to be added. Steps: Actor actionsSystem responses1) The client using server types in the 2) the server changes the #stop command.

respective

variable to false 3) the server stops listening to new connections.

Command Implementation Each command starts with a ‘#’ and case doesn’t matter

‘#login’ is the same as ‘#LoGin’ Any message that starts with a ‘#’ is considered a

command ‘Invalid command’ is displayed if command isn’t valid

Performs checks – such as a client needs to be disconnected to change port displays error if the command cannot be carried out or

verification if it is ClientUI commands are sent to a method clientCommand() ServerUI commands are sent to serverCommand() Commands checked using if statements #help [command] available

Command Diagram

Login Requirements

Username’s needed to be password protected

Username’s needed to be stored Passwords should be case sensitive Usernames should NOT be case

sensitive Must store and retrieve username and

password very quickly

Login Use Cases

Use case: Password – returning user, correct password Actors: client Goal: to login successfully Preconditions: The user must specify the password in the command line Summary: when a user wishes to login they must specify the correct password in the command line and login. Steps: Actor actions System responses 1) Start the client by typing ClientConsole, 2a) check loginID in hashmap then the loginID and password 2b) check password in

hashmap

Login Use Case cont.Use case: Password – new user Actors: client Goal: to sign in successfully to a server for the first time Preconditions: user must specify a loginID that has not been taken and a password Summary: when a user wishes to log on to the server, they must specify a new username and declare a password Steps: Actor actions System responses1) Start the client by typing Client Console, 2a) check loginID in

then the loginID and passwordhashmap

2b) add loginID and

password to hashmap

Login ImplementationFirst specified as command line args when starting Client

program

Username is case insensitive & password is case sensitive

handleLogin is passed #login <username><password> and:

-checks if username exists

-if no, add username and password to hashmap, then text file

-else check password against stored password

-if same connect user

-else client gets error message and disconnects client

*on server startup, text file is loaded into hash map

Login Diagram

Channel Requirements Functional

#joinchannel<channel> allows a user to join a channel if it exists

#createchannel<channel> [password] allows a user to create a channel with an optional password if the channel doesn’t already exist

#channellist lists the names of all channels that have been created

#channel returns the name of the channel the user is currently on

Messages sent by a user are received by other users on the same channel

Displays appropriate messages to the user (e.g. incorrect usage, successufully joined/created a channel)

Channel Requirements cont. Quality

SimpleChat has increased usability since users can create their own channels and performance will be minimally affected

The additional memory and cpu requirements won’t adversely affect the operation of SimpleChat

Channel Use CaseUse case: Channels – user establish Actors: clients Goal: to establish separate channels on the server so that messages can be sent to only the users in said channel and not the global session. Preconditions: users must be online Summary: if a user wishes to join a channel they must type the channel command and then the channel name Steps: Actor actions System responses1) the user types the channel command 2) System sets channel to and specifies channel. specified channel

Channel Implementation The channels are stored in a hashmap

The channel name is the key and an instance of ChannelInfo is the value

Class ChannelInfo holds all information about the channels Includes name, list of clients on the channel, and password

(optional) #joinchannel and #createchannel commands check

to see if channel has been created Displays whether user connected to channel or problem

(such as incorrect password or channel has already been created)

Sends message to everyone on the channel when a user joins the channel

Channel names are NOT case sensitive however channel passwords are

Channels names can contain any character except spaces

Channel Implementation cont.

Users are automatically put into channel ‘default’ when they first log in

If no users are connected to a channel it is removed (except ‘default’)

Messages are only sent to other users on the same channel

#channellist calls method getChannels() which returns an array of channel names in use (Strings) All of the channel names are displayed to the user

Server can send a message to all users on a channel using the command #channel <message>

Channel Diagram

Private Msg Requirements Users may want to send message to a

single other user Previously, Server echoed all msgs How?

Add #private commandServer delegates to special methodChecking for connected usersTell recipient it is a private message from:

Additional Requirements User should not send PM’s to self

Server may send PM’s

User can send PM’s to Server

Should be case insensitive

Private Message Use CaseUse case: Private messaging - unblocked Actors: client1 and client2 Goal: to successfully send a private message from client to client Preconditions: both users must be logged on and unblocked Summary: When a user wishes to private message another user, they must type the private message command, specify the loginID they wish to send a private message to and then the message they wish to send. Steps: Actor actions System responses1) user types #private command, loginID 2) the message is displayed to the and message to send. recipient with the PM from

<username> : <message>

Private Message Use Case cont.Use case: Private messaging - blocked Actors: client (blocked) Goal: Clients blocked by a user receive an error message when trying to PM them Preconditions: the clients must both be logged in and the sender must be blocked by the recipient Summary: when a user tries to send a private message to a user they are blocked by, they receive an error message and the PM is not sent. Steps: Actor actions

System responses1) client types pm command and tries to send msg. 2) system checks

loginID is blocked

3) system sends error

message to user

Private Message ImplementationUser types #private <username><message> //username is desired recipient

name

sendPrivateMethod receives command and:

-Checks that user is not trying to send a message to himself

Checks if recipient is the sever, if so display on serverUI

If not, loops through threadlist of Clients to see if recipient is connected

If the recipient is found, check if the sender is blocked by the recipient

-If not, send message to recipient

-if so, send error message to sender

-If recipient not found, error message sent to sender

Private Message Diagram

Observable Requirements Functional

ChatClient is an observer of ObservableClient EchoServer is an observer of

ObservableOriginatorServer Quality

Doesn’t affect usability (how SimpleChat is used by users both client side and server side remains the same)

SimpleChat is more maintainable due to increased flexibility (separation of framework from implemented code)

Increase reusability and expandability since there can be multiple observers on both the client and server sides

Observable Class Diagram

Observable Implementation ChatClient implements Observer Instantiate ObservableClient addObserver Replace HandlemessageFromServer with

update In the same way change EchoServer

With ObservableOriginatorServerChange HandleMessageClient to updateGet connectiontoclient thru .getOriginator()

Testing

Determined what test cases to run by following control structure of methods.

Each If statement created a different test case

Not all possible routes tested – too time consuming

Also did an intensive test on user logins

Lotsofusers.sh Script

#!/bin/bash for ((i=1;i<=400;i+=1)); do echo $i echo `java ClientConsole cory$i cory` & sleep .1 done

Testing Conditions Computer 1 OS: Apple OSX 10.5.2 Leopard CPU: 2.4 GHz Intel Core 2 Duo Memory: 2GB 667MHz Java Version: 1.5.0_13 Computer 2 OS: Windows Vista SP1 CPU: 2.2Ghz AMD X2 4200 Memory: 4GB 400Mhz Java Version: 1.6.0_04

Some Tests Done

Server and Client setup on one single computer

Server on one computer Client on another

Tested over 40 different scenarios

Some Examples