Rebel Messenger Service
Software Design Document
Version 1.1 – Elaboration Milestone
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
Date: 04 December 2010
Revision History
Date
26 November, 2010
Version
1.0
Description
Initial SDD
Author
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
Software Architecture Document
Version:
1.1
Date: 04 December 2010
Table of Contents
1.
Introduction
4
1.1
1.2
1.3
1.4
1.5
4
4
4
4
4
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview
2.
Architectural Representation
5
3.
Architectural Goals and Constraints
5
4.
Use-Case View
5
4.1
4.2
6
8
8
8
8
8
8
9
9
User Interfaces
System Inputs and Outputs
4.2.1 Inputs
4.2.2 Outputs
4.3
Use-Case Realizations
4.3.1 Risk ranking of Use Cases
4.3.2 Use Case Diagram
4.3.3 Use Case Descriptions
4.3.4 State Chart Diagram
5.
Logical View
11
5.1
5.2
5.3
5.4
5.5
11
11
16
17
19
Overview
Architecturally Significant Class Specifications
Risk Rank of classes
Sequence Diagram
Collaboration Diagram
6.
Performance
20
7.
Quality
20
Page 3 of 20
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
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
Software Architecture Document
2.
Version:
1.1
Date: 04 December 2010
Architectural Representation
student
InitializationClass
(f rom Actors)
database
interfaceClass
controlClass
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
Software Architecture Document
4.
Version:
1.1
Date: 04 December 2010
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
Software Architecture Document
Version:
1.1
Date: 04 December 2010
Figure 4 Screen when a message is sent to another client/user
Page 7 of 20
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
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 View)
(from Use Case View)
(from Use-Case Model)
Client
(f rom Use Case View)
Request New Password
(from Use Case View)
Log In / Log Out
(from Use Case View)
Manage Buddy List
Administrator
(f rom Use Case View)
Broadcast Announcements
(from Use Case View)
(from Use Case View)
Figure 5 Use Case Diagram
Page 8 of 20
Rebel Messenger System Application
Software Architecture Document
4.3.3
Version:
1.1
Date: 04 December 2010
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
entry/ Display Login Screen
Error Display
exit/ Report the Errors
Get Username and Password
entry/ Verify Username and Password
do/ Verify User Status
exit/ Administrator Verified
Error in Input
Save
Display Options
exit/ Save to Selected User File
entry/ Display Options for User
Manage Users Selected
Manage User Menu
entry/ Get User Choice
Save Button
More Inputs from User
Manage User
Accounts
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
Software Architecture Document
Version:
1.1
Date: 04 December 2010
Rebel Messenger
2010
System Entry
entry/ Display Login Screen
Error Display
exit/ Report the Errors
Get Username and Password
entry/ Verify Username and Password
do/ Verify User Status
exit/ User Verified
Error in Input
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
entry/ Get User Choice
Manage Buddy List
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
Software Architecture Document
5.
Version:
1.1
Date: 04 December 2010
Logical View
5.1 Overview
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
This method is used for initialization.
intializationClass
Page 11 of 20
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
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
User
A/M
Type
Name
Description
M
M
M
Void
Void
Void
user
~user
sendMessage
M
Void
recvMessage
M
Void
saveConvs
A
A
A
String
String
String
firstName
lastName
handle
A
String
RebelMail
A
A
String
Int
Password
Standing
This method is the constructor for the user class.
This method is the destructor for the user class.
This method is used to sending message to other
users
This method is used receive message from other
users
This method saves a conversation to a
conversation record
This attribute is the first name of the user.
This attribute is the last name of the user.
This attribute is the user’s identification or
nickname
This attribute is the user’s RebelMail address,
required for registration
This attribute is the password of the user
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
Client
A/M
Type
Name
Description
M
M
M
Void
Void
Void
client
~client
friendRequest
M
Void
registerAccount
M
M
Void
Void
requestPasswd
changePasswd
This method is the constructor the client class.
This method is the destructor of the client class.
This method is used to request another client to
become friends
This method complies information of user for a
new account creation
This method
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
Software Architecture Document
Version:
1.1
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
Admin
A/M
Type
Name
Description
M
Void
admin
M
Void
~admin
M
Void
broadcastMsg
This method is the constructor the administrator
class.
This method is the destructor of the administrator
class.
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
Database
A/M
Type
Name
Description
M
Void
database
M
M
Void
Void
~database
getUser
M
M
Void
Void
updateUser
getBuddy
M
Void
updateBuddy
M
Void
getConvs
M
Void
deleteConvs
M
Void
updatePasswd
This method is the constructor of the database
class
This method is the destructor of the database class
This method returns a user record from the
database
This method updates a user record to the database
This method returns a buddy record from the
database
This method updates a buddy record to the
database
This method returns a conversation record from
the database
This method removes a conversation record from
the database
This method assigns a new password to a user
Page 13 of 20
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
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
buddyRecord
A/M
Type
Name
Description
M
M
A
Void
Void
client
buddyRecord
~buddyRecord
buddyName
A
Int
friendRank
This method is the constructor of the buddyRecord
This method is the destructor of the buddyRecord
This client attribute stores the information of the
buddy held within the record
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
convsRecord
A/M
Type
Name
Description
M
M
A
Void
Void
String*
convsRecord
~convsRecord
convs
A
Date
timeStamp
A
client
hostClient
A
client
guestClient
This method is the constructor of the convsRecord
This method is the destructor of the convsRecord
This string pointer references the conversation
buffer
This date attribute stores the time and date when
the conversation was saved
This attribute references the client which initiated
the conversation
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
Software Architecture Document
Version:
1.1
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
M
Void
interfaceClass
This method is the constructor of the
interfaceClass
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
Software Architecture Document
Version:
1.1
Date: 04 December 2010
M
Void
friendRequest
M
Void
deleteFriend
M
Void
saveConvs
M
Void
changePassword
M
M
Void
Void
login
logout
This method allows a client to request a new
friend to be added to buddy list
This method removes a client from ones buddy
list
This method saves a conversation with another
user into a convsRecord
This method allows a user to change their
password
This method allows login.
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
user
buddyRecord
interfaceClass
controlClass
database
convsRecord
admin
client
Highest
Lowest
Page 16 of 20
Rebel Messenger System Application
Software Architecture Document
Version:
1.1
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
Software Architecture Document
: Client
Version:
1.1
Date: 04 December 2010
: controlClass
: interfaceClass
: 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
Software Architecture Document
Version:
1.1
Date: 04 December 2010
5.5 Collaboration Diagram
1: login()
8: changePassword()
13: logout()
: Admin
: interfaceClass
12: Return completion
2: verifyLogin()
9: issuePassword()
7: Return successful login
3: getUser() 10: updatePasswd()
: controlClass
4: Return user
6: Return admin status
5: isAdmin()
11: Return success
: database
Rebel Messenger
2010
: userRecord
Figure 11 Collaboration Diagram of Manage User Accounts Use Case
Page 19 of 20
Rebel Messenger System Application
Software Architecture Document
1.1
Date: 04 December 2010
1: login( )
:Student
Version:
6: deleteFriend( )
13: logout( )
: interfaceClass
2: verifyLogin( )
5: Return verification
7: deleteFriend( )
12: Return completion
9: Return record
: database
8: getBuddyRecord( )
3: getUser( )
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