Simplechat

1. The Little Caesars Cory, Sean, Seth, James, Madison Simplechat

2. Domain Analysis Instant messaging Expanding Simplechat Adding to the existing classes Adding commands for users

3. Domain Analysis Customers and Users Quick Messaging (physical speed and time saved) Networked Users (Internet, LAN, etc…)

4. Domain Analysis • Original Tasks and Procedures: • Send a message

5. How it was

6. What we did • Commands • LoginID and passwords • Blocking • Private Messages • Forwarding • Channels • Observer Layer

7. 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

8. 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

9. 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

10. Some Commands • #quit • Terminate Client gracefully • #logoff • Disconnect from Server • #sethost<host> • If client is logged off, sets host to connect to • #stop • Server stops listening for connections

11. Some Additional Requirements • Only appropriate users should be informed • Each method makes decisions • User should know status of command call • Methods will display error messages • Informed if usage is incorrect • Referred to help function • Case-insensitive.

12. 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 actionsSystem responses 1) client types #logoff command 2) Client side logs off from server but does not quit the program.

13. 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 responses 1) 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.

14. 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

15. Command Diagram

16. 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

17. 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 actionsSystem responses 1) Start the client by typing ClientConsole, 2a) check loginID in hashmap then the loginID and password 2b) check password in hashmap

18. 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 actionsSystem responses 1) Start the client by typing Client Console, 2a) check loginID in then the loginID and passwordhashmap 2b) add loginID and password to hashmap

19. Login Implementation First 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

20. Login Diagram

21. 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)

22. 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

23. Channel Use Case Use 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 actionsSystem responses 1) the user types the channel command 2) System sets channel to and specifies channel. specified channel

24. 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

25. 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>

26. Channel Diagram

27. Private Msg Requirements • Users may want to send message to a single other user • Previously, Server echoed all msgs • How? • Add #private command • Server delegates to special method • Checking for connected users • Tell recipient it is a private message from:

28. 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

29. Private Message Use Case Use 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 actionsSystem responses 1) user types #private command, loginID 2) the message is displayed to the and message to send. recipient with the PM from <username> : <message>

30. 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 actionsSystem responses 1) client types pm command and tries to send msg. 2) system checks loginIDis blocked 3) system sends error message to user

31. Private Message Implementation User 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

32. Private Message Diagram

33. 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

34. Observable Class Diagram

35. Observable Implementation • ChatClient implements Observer • Instantiate ObservableClient • addObserver • Replace HandlemessageFromServer with update • In the same way change EchoServer • With ObservableOriginatorServer • Change HandleMessageClient to update • Get connectiontoclient thru .getOriginator()

36. 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

37. Lotsofusers.sh Script • #!/bin/bash • for ((i=1;i<=400;i+=1)); do • echo $i • echo `java ClientConsolecory$icory` & • sleep .1 • done

38. 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

39. Some Tests Done • Server and Client setup on one single computer • Server on one computer Client on another • Tested over 40 different scenarios

40. Some Examples