Chat Manager Detailed Design

Online Health Monitoring System

Detailed Design: Chat Manager

COP 4331, Fall, 2014

Modification history:

Version	Date	Who	Comment
v0.0	08/15/00	G. H. Walton	Template
v1.0	10/3/14	Jon Carelli	First draft, Title, Team, Design issues
v1.1	10/4/14	Jon Carelli	Added overview diagram, data
v1.2	10/6/14	Jon Carelli	UI Visualization, Operation, Algorithm
v1.3	10/7/14	Jon Carelli	Sequence Diagram, Tracing, Class Diagram

Team Name: Team 14

Team Members:

Jon Carelli - email - web page
Chris McCue - email - web page
Chris Chaffin - email - web page
Ethan Pitts - email - web page
David Gundler - email - web page
James Luke - email - web page

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

Design Issues:

In this module, priority comes down to usability, reliability and security. The chat manager will handle incoming messages and send outgoing messages to the database. Once the database has a new message for another user, the chat manager will update that user’s chat window with the supplied message. Currently, the system will only allow a patient to chat with their scheduled physician. The physician may chat with multiple different users concurrently. From the main website, a patient or physician can click the envelope icon to access the chat manager for that user. This means the interface will be clear, as an envelope is the universal symbol for a message. Once the user has accessed the chat manager interface, they may begin sending and receiving messages. Since this is an online application it must be portable. HTML and JavaScript will ensure this is not a problem. From a user perspective, a user should be able to understand how to use this module in less than 5 minutes. The user interface visualization demonstrates that the user controls are configured in a standard format that users would already be familiar with.

This module will be highly influenced by the database, so we must make sure the integration of the two is easy and quick. Security is also an important risk. We don’t want patient’s information being exposed to anybody but the patient. Encryption will be needed in some form running on the backend to encrypt and decrypt each patient/doctor message. Ensuring that the system isn’t compromised is key in creating a system that is reliable and secure.

When a user sends the message, the message will be encrypted, To, From, and the Message will be sent to the database, the database will then send the message to the corresponding users message manager, a timestamp will be generated, and the information will be displayed on their page.

Detailed Design Information:

Overview

The design of the Chat Manager module is driven by functional requirements. Per the requirements, the physician may only send their physician a message, but the physician can only send messages to his patients.

Data:

Messages can be broken down to as follows:

Message:

To: Dr. Example

From: Jon Carelli

Message: What is going on im not very good at computer

Time Related Attributes (generated by chat manager)

Date: 10/4/2014

Time: 11:31 AM

Encryption of data

Message: What is going on im not very good at computer

Encrypted: edwae wt dwads dw wg hfj dasc diid ks csotmvz

The message data is as follows:

Data: Categories
Message	Time Related Attributes	Encryption of Data
toUserName	dateData	messageString
fromUserName	timeData	messageEncryptedString
messageString

Data Storage Format:

For the example data described above, the data storage format will be as follows:

Jon Carelli Dr. Example What is going on im not very good at computer

2014:10:04 11:54:AM

What is going on im not very good at computer edwae wt dwads dw wg hfj dasc diid ks csotmvz

The top row contains message data, From, To, Unencrypted String. The second row contains date related data. The last row contains encryption data. This is the data storage format for sending and receiving messages between users. Time and date will be calculated by the Chat Manager, once calculated they will be appended to the message string and shown on the page. The database manager should not need to calculate this data.

User Interface Visualization:

Patient:

Physician:

Operation:

See above diagram for operations and descriptions.

There are a few operations that the ChatManager will be performing. It will both send and receive messages, with encryption and decryption support. The ChatManager will also be responsible for generating timestamps and appending them to the message string before showing them on the user’s page. This means the ChatManager will be sending To, From, and encrypted message strings to the database.

Events Generated (example) for sending and receiving messages:

Jon Carelli Dr. Example dwae wt dwads dw wg hfj dasc diid ks csotmvz

Dr. Example Jon Carelli saddsa sad ghhghjdg bbc beet

Jon Carelli Dr. Example fdfd qwt 34 zc fqr jjewx

Dr. Example Jon Carelli sfs few tuif vs

This could be considered four inputs to the database, the string of garbled text represents encrypted text. There should never be unencrypted text being transferred to and from the database, that a packet sniffer or hacker could intercept.

Events Generated (example) for encrypting and decrypting messages:

Encrypt: dwae wt dwads dw wg hfj dasc diid ks csotmvz

Decrypt: What is going on im not very good at computer

Encrypt: asdadas gdgdj df h ew dfhd asgxg

Decrypt: Quit hassling me Doc.

Events Generated for appending date and time to the string.

Jon Carelli Dr. Example Quit hassling me Doc.

getDateAndTime(); à 10/6/2014, 12:46PM

                  Appending: (10/6/2014, 12:46PM): Quit hassling me Doc.
                  Encrypt (String message)
                  SendMessage(String To, String From, String message)

Algorithm:

There would need to be an efficient encryption algorithm, possibly an AES/DES approach. For this project, nothing too sophisticated needs to be implemented, could do a simple Caesar Cipher.

Encryption: $E_n(x) = (x + n) \mod {26}.$

Decryption: $D_n(x) = (x - n) \mod {26}.$

Sequence Diagram:

Class Diagram:

Trace of Requirements to Design:

Item Description	Detailed Design Section	Document of Origin	Sections of Origin
Overall functionality of Chat Manager	Overview	Concept of Operations	Users and Modes of Operation, Operational Features
Send Message	Event Sequence Diagrams	Software Requirements Specification	Event Table, Use Case Descriptions
Receive Message	Event Sequence Diagrams	Software Requirements Specification	Event Table, Use Case Descriptions
Encrypt Messages	Data, Operations	Software Requirements Specification	3.8
Decrypt Messages	Data, Operations	Software Requirements Specification	3.8
Appointment data specifications	Data, Operations	Software Requirements Specification	3.2
Example data and Data format	Data, Operations	Software Requirements Specification	3.6
Quality attributes	Design Issues	Software Requirements Specification	3.9

Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on August 15, 2000

This page last modified by Jon Carelli (jcarelli@knights.ucf.edu ) on 10/7/2014