Rebel Messenger Service Software Architecture Document

Version 1.1 – Elaboration Milestone Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010 Revision History Date Version Description Author 26 November, 2010 1.0 Initial SDD Beauchamp, Samuel Carter, Greg Conradi, Jeff Le, Tri Roberts, Gary Thomas, Rainee Uzowihe, Kenna Watkins, Charles 04 December, 2010 1.1 Complete SDD Beauchamp, Samuel Carter, Greg Conradi, Jeff Le, Tri Roberts, Gary Thomas, Rainee Uzowihe, Kenna Watkins, Charles

Page 2 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010 Table of Contents

1. Introduction 4 1.1 Purpose 4 1.2 Scope 4 1.3 Definitions, Acronyms, and Abbreviations 4 1.4 References 4 1.5 Overview 4

2. Architectural Representation 5

3. Architectural Goals and Constraints 5

4. Use-Case View 5 4.1 User Interfaces 6 4.2 System Inputs and Outputs 8 4.2.1 Inputs 8 4.2.2 Outputs 8 4.3 Use-Case Realizations 8 4.3.1 Risk ranking of Use Cases 8 4.3.2 Use Case Diagram 8 4.3.3 Use Case Descriptions 9 4.3.4 State Chart Diagram 9

5. Logical View 11 5.1 Overview 11 5.2 Architecturally Significant Class Specifications 11 5.3 Risk Rank of classes 16 5.4 Sequence Diagram 17 5.5 Collaboration Diagram 19

6. Performance 20

7. Quality 20

Page 3 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010 Software Architecture Document 1. Introduction

1.1 Purpose The purpose of this document is to collect, analyze, and define high-level needs and features of the Rebel Messenger service for UNLV students. It focuses on the capabilities needed by the Rebel Messenger users. The details of how the Rebel Messenger system fulfills these needs are provided in the Software Requirements Specification. 1.2 Scope The Rebel Messenger client software will be installed and used on individual user PCs. The server software that will connect clients will be installed and used on a single machine. The server will be designed to be used by the system administrators from a dedicated server. The Server has been written to be infinitely scalable and able to accommodate multiple infrastructure configurations for the service. Both the server and client will use the TCP Protocol.

The Rebel Messenger system will enable the users to register for an account, log in, send friend requests, reject friend requests, send messages, receive messages, the saving of a buddy list, viewing of the buddy list, request new user password, and log out of the client.

The Rebel Messenger system will enable the administrators to log in, send messages, receive messages, view buddy list, confirm user requests, delete accounts, reset passwords, query users, broadcast announcements, and log out. 1.3 Definitions, Acronyms, and Abbreviations (UNLV) – University of Nevada, Las Vegas

(TCP) Transmission Control Protocol – An internet protocol that uses retransmission to ensure all data is received. This choice is ideal over other less reliable protocols for smaller transmissions that require reliability.

(IM) Instant Messaging - A form of real-time direct text-based communication between two or more people using personal computers or other devices. The user's text is conveyed over a network, such as the Internet. 1.4 References None. 1.5 Overview Rebel Messenger provides online instant messaging to any student enrolled at the University of Nevada at Las Vegas. The Rebel Messenger service offers an online community for users to participate in instant messaging and general online chatting services. Each student of UNLV will have access to a Rebel Messenger account free of charge. The software will also be scalable to meet the needs of individual departments within the UNLV network, allowing departments to have private chat servers that are independent from the UNLV general Rebel Messenger server for the departments use.

The remainder of this Vision document will identify Product Features, Other Product Requirements and Documentation Requirements.

Page 4 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

2. Architectural Representation

InitializationClass student

(f rom Actors)

database controlClass interfaceClass

administrator

(f rom Actors) userRecord

buddyRecord

convsRecord Rebel Messenger 2010 client user admin

Figure 1 Architectural diagram of the product

3. Architectural Goals and Constraints The “Rebel Messaging System” server software will run on a dedicated platform with access to the internet, and an SQL database. The client will run as a standard service on any Windows PC, and the machine must have access to the internet. Both the client and the server will also be connected to some form of standard graphical output (monitor), and some way of receiving standard input (keyboard). Neither of these has to be physical connections to devices. In fact, the server should ideally be network-accessible through some remote connection to the shell.

The SQL database will be used to store and manage user credentials and buddy records. All other information will be stored in local main memory without the aid of the database interface.

The program is currently implemented for any NT-based Windows OS, but it can be ported to Linux and Mac-based systems in the future.

Page 5 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

4. Use-Case View

4.1 User Interfaces

Figure 2 Initial screen

Figure 3 Screen when a client/user logs in

Page 6 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

Figure 4 Screen when a message is sent to another client/user

Page 7 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

4.2 System Inputs and Outputs

4.2.1 Inputs User Input – input from the user shall be provided via the keyboard and the mouse 4.2.2 Outputs Graphical – output from the program shall be displayed via the standard output, typically the user's monitor. Database – user account changes, transactions, and other information shall be stored within the database of Rebel Messenger. 4.3 Use-Case Realizations

4.3.1 Risk ranking of Use Cases Use Case Risk list is ranked from the highest to the lowest risk use case.

Use Case Risk List Manage User Accounts High Manage Buddy List Handle Messages Moderate Register accounts Broadcast Message Low Request New Password Log In / Log Out

4.3.2 Use Case Diagram

Register Account Handle Messages Manage User Accounts (from Use-Case Model) (from Use Case View) (from Use Case View)

Log In / Log Out Client Administrator (from Use Case View) (f rom Use Case View) (f rom Use Case View)

Request New Password Manage Buddy List Broadcast Announcements (from Use Case View) (from Use Case View) (from Use Case View)

Figure 5 Use Case Diagram

Page 8 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

4.3.3 Use Cases Descriptions

1) Login/Logout - Details the process by which the user is able to create and destroy his or her session to the Rebel Messenger server 2) Manage Buddy List - Details the process by which the user is able to add, remove, and rank buddies 3) Handle Messages - Details the process by which the user is able to send and receive messages from users on his or her buddy list 4) Register Account - Details the process by which the user first creates his or her account on the Rebel Messenger service 5) Request New Password - Details the process by which the user is able to request his or her password to be reset by an administrator 6) Manage User Accounts - Details the process by which an administrator is able to perform managerial tasks on registered users, such as listing and resetting their passwords 7) Broadcast Announcements - Details the process by which an administrator is able to send a message to all currently logged in users and administrators

4.3.4 State Chart Diagrams

Rebel Messenger 2010

System Entry Error Display

entry/ Display Login Screen exit/ Report the Errors

Get Username and Password Error in Input entry/ Verify Username and Password do/ Verify User Status exit/ Administrator Verified

Save Display Options exit/ Save to Selected User File entry/ Display Options for User

Save Button More Inputs from User Manage Users Selected

Manage User Menu Manage User Accounts entry/ Get User Choice do/ Check Input exit/ Update Fields

Figure 6 State chart showing the dynamic behavior of the Manage User Accounts use case

Page 9 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

Rebel Messenger 2010 System Entry Error Display

entry/ Display Login Screen exit/ Report the Errors

Get Username and Password Error in Input entry/ Verify Username and Password do/ Verify User Status exit/ User Verified

Save Display Options exit/ Save to Buddy Record File entry/ Display Options for User

Save Button More Inputs from User Manage Buddy List Selected

Manage Buddy List Menu Manage Buddy List

entry/ Get User Choice do/ Check Input exit/ Update Fields

Figure 7 State chart showing the dynamic behavior of the Manage Buddy List use case

Page 10 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5. Logical View

5.1 Overview

controlClass interfaceClass

controlClass() interfaceClass() Initialization Class ~controlClass() ~interfaceClass() registerAccount() registerAccount() sendMessage() sendMessage() recieveMessage() receiveMessage() updateFriends() updateFriends() requestPassword() requestPassword() database friendRequest() friendRequest() deleteFriend() deleteFriend() database() saveConvs() saveConvs() ~database() changePassword() changePassword() getUser() issuePassword() login() updateUser() verifyLogin() logout() getBuddy() updateBuddy() getConvs() deleteConvs() updatePasswd()

buddyRecord userRecord buddyName : :client userName : :user friendRank : :int lastOnline : :date isAdmin : :boolean buddyRecord() ~buddyRecord() userRecord() ~userRecord() isAdmin()

user firstName : :string convsRecord client lastName : :string handle : :string convs : :*string rebelMail : :string admin timeStamp : :date client() password : :string hostClient : :client ~client() standing : :int admin() guestClient : :client friendRequest() ~admin() registerAccount() user() broadcastMsg() convsRecord() requestPasswd() ~user() ~convsRecord() changePasswd() sendMessage() recvMessage() Rebel Messenger saveConvs() 2010

Figure 8 Class diagram

5.2 Architecturally Significant Class Specifications

5.2.1 Initialization Class

5.2.1.1 Brief Description A control class which will load all the required components into memory during the execution lifetime of the RebelMessenger program CLASS A/M Type Name Description intializationClass This method is used for initialization.

Page 11 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.2.2 User Class

5.2.2.1 Brief Description

An entity acting as a virtual class that will be invoked by either the client and admin class in the RebelMessenger application. This class will hold the majority of attributes associated with the two levels of user, both a standard client and administrator.

CLASS A/M Type Name Description User M Void user This method is the constructor for the user class. M Void ~user This method is the destructor for the user class. M Void sendMessage This method is used to sending message to other users M Void recvMessage This method is used receive message from other users M Void saveConvs This method saves a conversation to a conversation record A String firstName This attribute is the first name of the user. A String lastName This attribute is the last name of the user. A String handle This attribute is the user’s identification or nickname A String RebelMail This attribute is the user’s RebelMail address, required for registration A String Password This attribute is the password of the user A Int Standing This enumerated integer describes the users standing within the university 5.2.3 Client Class

5.2.3.1 Brief Description

An entity class inherited from the user class. This class represents a standard user with extended method such as friend request, register account and requesting and updating their personal password

CLASS A/M Type Name Description Client M Void client This method is the constructor the client class. M Void ~client This method is the destructor of the client class. M Void friendRequest This method is used to request another client to become friends M Void registerAccount This method complies information of user for a new account creation M Void requestPasswd This method M Void changePasswd This method will allow a client to set a personalized password once a default password has been issued by an admin

Page 12 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.2.4 Admin Class

5.2.4.1 Brief Description

An entity class inherited from the user class. This class represents an administrative user with extended method such broadcast message to all user on the system.

CLASS A/M Type Name Description Admin M Void admin This method is the constructor the administrator class. M Void ~admin This method is the destructor of the administrator class. M Void broadcastMsg This method allows an admin to send messages to every client for system announcements

5.2.5 Database Class

5.2.5.1 Brief Description

A boundary class, the database will stores all the records involved in the application. Records such a userRecord, buddyRecord, and convsRecord will all be held within the database class, and any time data is stored or fetched from the database will be handled within this class.

CLASS A/M Type Name Description Database M Void database This method is the constructor of the database class M Void ~database This method is the destructor of the database class M Void getUser This method returns a user record from the database M Void updateUser This method updates a user record to the database M Void getBuddy This method returns a buddy record from the database M Void updateBuddy This method updates a buddy record to the database M Void getConvs This method returns a conversation record from the database M Void deleteConvs This method removes a conversation record from the database M Void updatePasswd This method assigns a new password to a user

Page 13 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.2.6 BuddyRecord Class

5.2.6.1 Brief Description

This entity class is responsible storing data associated with a user’s buddy. CLASS A/M Type Name Description buddyRecord M Void buddyRecord This method is the constructor of the buddyRecord M Void ~buddyRecord This method is the destructor of the buddyRecord A client buddyName This client attribute stores the information of the buddy held within the record A Int friendRank This attribute stores the rank of the buddy within a clients buddy list

5.2.7 ConvsRecord Class

5.2.7.1 Brief Description

This entity class stores a conversation if one is saved by a user, if desired CLASS A/M Type Name Description convsRecord M Void convsRecord This method is the constructor of the convsRecord M Void ~convsRecord This method is the destructor of the convsRecord A String* convs This string pointer references the conversation buffer A Date timeStamp This date attribute stores the time and date when the conversation was saved A client hostClient This attribute references the client which initiated the conversation A client guestClient This attribute references the client that accepted the conversation

5.2.8 UserRecord Class

5.2.8.1 Brief Description An entity class which contains information associated with registered users on the Rebel Messenger network. CLASS A/M Type Name Description userRecord M Void userRecord This method is the constructor of the userRecord M Void ~userRecord This method is the destructor of the userRecord M Void isAdmin This method checks is the user within the record is an administrator A User userName This attribute stores a users data, either client or administrator A Date lastOnline This attribute holds the date in which was last online A Boolean isAdmin This attribute is a Boolean flag that determines if a user is a client or administrator

Page 14 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.2.9 Control Class

5.2.9.1 Brief Description A control class that handles the flow of requests and input from the user provided through the interface class. CLASS A/M Type Name Description controlClass M Void controlClass This method is the constructor of the controlClass. M Void ~controlClass This method is the destructor of the controlClass. M Void registerAccount This method will allow a new client to register an account M Void sendMessage This method allows a user send message M Void receiveMessage This method accepts a new message to establish a conversation between users M Void updateFriends This method will update user’s buddy list and set rankings onto each buddy M Void requestPassword This method will request a new password to be issued to a client M Void friendRequest This method allows a client to request a new friend to be added to buddy list M Void deleteFriend This method removes a client from ones buddy list M Void saveConvs This method saves a conversation with another user into a convsRecord M Void changePassword This method allows a user to change their password M Void registerAccount This method will allow a new client to register an account M Void sendMessage This method allows a user send message M Void verifyLogin This method verifies login.

5.2.10 Interface Class

5.2.10.1 Brief Description A boundary class that represents the visual components connecting the user to the application and system components. CLASS A/M Type Name Description interfaceClass M Void interfaceClass This method is the constructor of the interfaceClass. M Void ~interfaceClass This method is the destructor of the interfaceClass. M Void registerAccount This method will allow a new client to register an account M Void sendMessage This method allows a user send message M Void receiveMessage This method accepts a new message to establish a conversation between users M Void updateFriends This method will update user’s buddy list and set rankings onto each buddy M Void requestPassword This method will request a new password to be issued to a client

Page 15 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

M Void friendRequest This method allows a client to request a new friend to be added to buddy list M Void deleteFriend This method removes a client from ones buddy list M Void saveConvs This method saves a conversation with another user into a convsRecord M Void changePassword This method allows a user to change their password M Void login This method allows login. M Void logout This method allows logout. Table 1 Classes (A/M indicates Attribute or Method, with capital letters indicating Public)

5.3 Risk Rank of classes Class Risk list is ranked from the highest to the lowest risk class.

userRecord Highest user buddyRecord interfaceClass controlClass database convsRecord admin client Lowest

Page 16 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.4 Sequence Diagrams

: Admin : interfaceClass : controlClass : database : userRecord login( )

verifyLogin( ) getUser( )

Return user

isAdmin( )

Return admin status

Return successful login

changePassword( ) Rebel Messenger 2010 issuePassword( )

updatePasswd( )

Return success

Return completion

logout( )

Figure 9 Sequence Diagram of Manage User Accounts Use Case

Page 17 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

: Client : interfaceClass : controlClass : database : buddyRecord login( )

verifyLogin( )

getUser( )

Return user

Return verification

deleteFriend( ) deleteFriend( ) getBuddyRecord( )

Return record

~buddyRecord( )

deleteRecord( )

Return

Return completion Rebel Messenger 2010 logout( )

Figure 10 Sequence Diagram of Manage Buddy List Use Case

Page 18 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

5.5 Collaboration Diagram

1: login() 8: changePassword()

13: logout() : Admin : interfaceClass

12: Return completion 2: verifyLogin()

7: Return successful login 9: issuePassword()

3: getUser() 10: updatePasswd()

4: Return user : controlClass 11: Return success : database

6: Return admin status 5: isAdmin() Rebel Messenger 2010

: userRecord

Figure 11 Collaboration Diagram of Manage User Accounts Use Case

Page 19 of 20 Rebel Messenger System Application Version: 1.1 Software Architecture Document Date: 04 December 2010

1: login( ) 6: deleteFriend( )

:Student 13: logout( ) : interfaceClass 2: verifyLogin( )

5: Return verification 7: deleteFriend( )

12: Return completion 9: Return record 8: getBuddyRecord( )

3: getUser( ) : database 4: Return user : controlClass

10: ~buddyRecord( )

11: deleteRecord( ) Rebel Messenger 2010

: buddyRecord

Figure 12 Collaboration Diagram of Manage Buddy List Use Case

6. Performance Performance of the messenger will be highly dependent on the network latency, to maintain high performance standards across reliable networks, the system has been designed to limit messages to 16kb. The system will require a Windows NT or higher to allow for .net framework. 7. Quality The quality of the product will meet the standard for basic IM services. Given proper hardware conditions and a reliable network connection users should get the sense the message is received instantly.

Page 20 of 20