prepared for cen-5011 advanced software engineering professor: s. masoud sadjadi cen 5011 – fall...

Prepared for CEN-5011 Advanced Software Engineering

Professor: S. Masoud Sadjadi

CEN 5011 – Fall 2006 – Term Project Presentation

Health CareHealth CareForms and GUIForms and GUI

Team Members:Team Members:

With Coordination by:With Coordination by:Yingbo Wang, Yaz HernandezYingbo Wang, Yaz Hernandez

Mahitha Aitharaju, Mahitha Aitharaju, Yixis Cejas, Yixis Cejas,

David Delgado, David Delgado, Yeshwanth Reddy Ganta,Yeshwanth Reddy Ganta,

Wilnigue Joseph, Wilnigue Joseph,

Soumya Kallem, Soumya Kallem, Xiaoli Liang, Xiaoli Liang,

Mario J Lorenzo, Mario J Lorenzo, Srivalli Meka, Srivalli Meka,

Matthew L Parets, Matthew L Parets,

Anna Shen, Anna Shen, Uma Sundari Sista, Uma Sundari Sista,

Lian Song, Lian Song, Dinesh Babu Tenneti, Dinesh Babu Tenneti,

Yali WuYali Wu

3CEN 5011 – Fall 2006 – Term Project Presentation - Health Care Forms and GUI

AgendaAgenda

Introduction Proposed System System Models System Architecture Subsystem Services Packages Testing Demo


IntroductionIntroduction

The current health care system produces massive amounts of data in a wide variety of separated and incompatible data types. While an elusive goal, heath care information exchange promises to better educate patients, and reduce preventive medical errors.

With the technology available today, a medical professional can share with patients and other medical professionals virtually any kind of media file. Take the following scenario for instance. A patient is about to undergo surgery. The doctor will then need to send the patient a document with the results of all the diagnostic tests, a video describing the pre-surgery procedures to be performed, and a brochure detailing the steps the patient must take before and after surgery. What can the doctor do to remedy the situation? The answer is a form!

Forms allow a doctor to send information in a collection of media types, and to package all the media up into one structure. There are two types of forms: generic, allowing the doctor to group any collection of media types together as needed; specific, where the doctor fills in a pre-made form with the appropriate information. In addition, a form will allow a doctor to suggest the best application for viewing the media within the form.


IntroductionIntroduction

The GUI project will solve two key issues. First, it will make the CVM interface voice capable. This will allow the doctor or patient to make any combination of complex commands without the use of a keyboard interface (via voice commands). The patient or doctor should also be able to disable the voice functionality when they want to interact with the system via a keyboard interface. In addition, the first task should also resolve the issue of voice commands conflicting with the voice to be recorded for the patient to prevent any misbehavior of the system.

The second goal of this project is to improve the GUI of the CVM interface. This will make the existing GUI more specific for Doctor and Patient communications. That is, it will make the features and commands more relevant to the medical scenarios so that doctors and patients will find it easier to use. In addition, the GUI of the CVM will be given a more unique appearance and style.


Purpose of the SystemPurpose of the System

The system will be developed as part of the healthcare Communication Virtual Machine (CVM) used by doctors in a hospital environment for patients who are children and have been discharged from the hospital after their heart surgery. The purpose of the system is to provide smooth interface to facilitate communication between doctors and patients using forms with the help of CVM. The system allows the doctors to know about the current condition of the patient and make sure that the patient is in good health. CVM also allows the discharged patients to know about their health and the precautions and steps they should take to for a fast recovery and to maintain good health.


Scope of the SystemScope of the System

The system will allow communication between patients and doctors, after the discharge of the patient from the hospital. The communication will be synchronous. The patients considered are children suffering from heart problems. The system introduces the use of forms with the help of CVM. Forms allow the doctors and patients to communicate regarding the health of the patient which include suggestions of the doctor regarding medication and exercises, clarifying the patients doubts regarding the post discharge precautions, any change of medication if required, further tests if needed to be done and many more. The system thus allows mutual communication between the doctor and the patient, which gives each of the parties involved complete knowledge about the current phase and maintaining future progress of the patient’s health.


Objective and Success CriteriaObjective and Success Criteria

The main objective of the system is to make the process of communication between the doctor’s and patients easy. Nothing will be accomplished if the system makes this process harder. The user should be able to navigate through the entire system, perform the desired communication and find the information they seek with no difficulty.


Current SystemCurrent System

The Miami children hospital (MCH) at Miami is a hospital specially treating children with congenital heart diseases. Patients with complex congenital heart problems often require multiple staged procedures over their lifetime. Early detection, complete repair, continuous feedback, and continuity of care are necessary to improve their quality-of-life and chance for survival. Consequently, these patients require extensive monitoring, continuous testing, long hospital stays and care from various multidisciplinary specialists often geographically dislocated from one another.

Medical diagnosis requires that the right information reach the right doctors at the right time. But today there is no common model, architecture, or systematic method to specify communication services that are reconfigurable, and network and device independent. In addition, there has been little or no attention paid to how the end-users specifies his/her communication needs using the current system. Currently we use the CVM to establish communication, but CVM is too generic.


Current SystemCurrent System

Users are not allowed to have multiple simultaneous connections. The communications can not be logged. It is not domain-specific for doctor and patient communications in a healthcare environment. It is not unique and user-friendly. In addition, it does not offer voice command capabilities, which consequently restrict the users to use a mouse and keyboard interface. Furthermore, there are several features that are not implemented like for instance, the logout, which prevents the system from being deployed to the client. Furthermore CVM does not currently incorporate forms and thus is limited in the information formats that can be transferred between the end users.

Doctors at MCH are looking for a system that keeps track of patient information before and after the patients operation. Current healthcare processes results in massive amounts of data in various multimedia formats with a high degree of separation and incompatibility. Improving medical information exchange, properly informing and educating patients, and reducing preventative medical errors remain an elusive goal.


Proposed SystemProposed SystemOverview

Forms: Health-Care Forms deal with, Forms, used with the help of the CVM. The communication between a doctor and a patient, after the patient is discharged from the hospital after a heart surgery is considered. A form is composed of various types of synchronous communication. A form allows a doctor and a patient, sending a collection of media information, to package it all up into one complex data type. Also, the expert user is able to restrict what information certain user groups can see and what actions are allowed on certain files.

Thus, with the help of forms, a doctor is able to package all the medical details needing to be available to a patient who is discharged from the hospital. The patient can know about the details regarding his/her health, and package his feedback/requests and send them to the doctor, reducing the need for return hospital visits.

Forms allow a doctor to send information in a collection of media types, and to package all the media up into one structure. There are two types of forms: generic, allowing the doctor to group any collection of media types together as needed; specific, where the doctor fills in a pre-made form with the appropriate information.


Proposed systemProposed system

GUI: The goal of the proposed GUI subproject is to make the existing CVM user interface more easy-to-use and more healthcare-specific. According to common healthcare communication scenarios, some communication templates are identified, making it more convenient for patients and doctors to use the system. Also, with the addition of voice commands, doctors would free their hands and be able to engage in other tasks while communicating with the system.


Functional Requirements

To provide a specific tool for doctor and patient communications that provides the flexibility for users to define their own communications as need arises. The functional requirements describe the interactions between actors and the system

• Communication:The system allows a better and synchronous communication between a patient and a doctor, initiated either by the doctor or the patient.

•Synchronous communication: Synchronous communication allows the users to partake in real-time video and audio chatting. While communicating the doctor or the patient can send a file to each other by selecting the type of media they wish to send.


Functional Requirements

• Roles:Different types of users based on roles assigned to them by the system administrator are supported (e.g. doctor role, patient role, etc.).

• Multiple connections:Several connections will be allowed to take place simultaneously.

• Voice command featureUsers of the system will be able to issue complex voice commands. This feature could be disabled if it is not desired.


Non-Functional Requirements

Non-Functional Requirements describe user-visible aspects that are not directly related with the functionality of the system.

• Usability (simple to use): The system will be easy to use and provides the user with an interface through which the user can access all of the system’s functionality. The forms in the CVM allow the end users to send and receive files of various formats simultaneously. The system is user friendly and easily understood. The user just has to login into the CVM and he will be able to establish communication.

• Reliability (robust): The system used is very reliable. It is used to send information from one end to the other. It will either be received synchronously if the receiver is present at that time. The data received will be in predefined format and can be relied on to be correct.



• Performance (responsive): The performance of the system will be very efficient. The messages sent from one end will be received in the other end in fraction of a second. The data received will be at a level of detail such that the receiver will have no problem understanding it. The data will be transferred immediately. However, the amount of time taken to receive data shall also depend on the speed of the user’s network connection and the available bandwidth at the time of the transfer.

• Supportability (maintainable):The system shall be adaptable and easily changed. It will be designed to facilitate the addition of new functionality and allow changing/removing existing system functionality.

• Implementation (technology):The implementation constraints with the proposed system are the use of technologies such as XML, AJAX, JAVA, JAVASCRIPT and the use of middleware represented by the CVM.



• Interface (exceptional):The interface should be understandable at first view, specialized for the doctors and patients and offer a unique look and feel. The sub-systems shall interface with the other sub-projects (GUI and the NAT Resolution).

• Packaging (environment):Web based through the opera browser, the system shall be divided into two packages; client side of the software is taken as one package which can be easily downloaded and installed by the client and server side software package which can be easily installed by an administrator.

• Legal (©):The information that the system will use is copyrighted material. The system will contain disclaimers specifying that the information provided may be used only for providing better healthcare.


ScenariosScenarios

Synchronous Communications - Doctor to Patient

Scenario: Doctor contacts patient to change the dosage in a patient medication.

Actors: Doctor Burke, Patient Louis.

Precondition: A six year old boy, Louis, was discharged from the Miami Children's Hospital after a surgery.

Description: Dr. Burke establishes a real time chat with Louis’ mom using CVM. Dr. Burke explains that he has reviewed Louis' case and wishes to change the dosage of the medicines that Louis is taking. The doctor explains the reason the dosage must be changed. Louis’ mother asks a few questions about the frequency and the possible reactions Louis may have. Dr. Burke sends Louis' mom a health care form containing text detailing dosage and interaction possibilities, as well as pictures detailing what the symptoms would look like if Louis were to have a negative reaction to the drugs.

Post condition: Louis starts with the new dosage in his medication.


ScenariosScenarios

Synchronous Communications - Patient to Doctor

Scenario: Patient contacts doctor concerning change in behavior.

Actors: Burke: Doctor, John’s Father (Mike): Patient

Precondition: John’s father (Mike) has noticed that John (3 years of age who hasrecently undergone heart surgery) has been behaving differently after the surgery.

Description: Mike gets very concerned and logs into CVM from his laptop. After beingauthorized, Mike establishes a synchronous connection with Dr. Burke. Since Mike’slaptop doesn’t have a microphone audio can not be added to the communication.Therefore, they communicate using the chat feature of CVM. After they greet each other, Mike informs Dr. Burke about John’s (his son) situation. Dr. Burke then asksMike a series questions to determine if John’s change in behavior is normal afterheart surgery. Based on Mike’s responses Dr. Burke concludes that the behavior isnormal. Mike is then instructed to bring in John, if after the two weeks John’sbehavior remains the same.

Post condition: After two weeks Mike contacts Dr. Burke via CVM to follow up on John’s behavior.


High Level Use Case Model: FormsHigh Level Use Case Model: Forms

Form Management

SynchronousCommunication

Synch. Comm.Doctor to Patient

Synch. Comm. Patient to Doctor

« extends»« extends»

CreateForm Modify FormDelete Form

Doctor

Expert

Patient

<< includes >> << includes >> << includes >>

Form Management

SynchronousCommunication

Synch . Comm .Doctor to Patient

Synch . Comm . Patient to Doctor

« extends»« extends»

CreateForm Modify FormDelete Form

Doctor

Expert

Patient

<< includes >> << includes >> << includes >>

SynchronousCommunicationRepostiory

Administrator

21CEN 5011 – Fall 2006 – Term Project Presentation - Health Care Forms and GUI 21

High Level Use Case Model: GUIHigh Level Use Case Model: GUI

Synchronous Communication

Doctor Patient

Doctor To Patient

Patient To DoctorDoctor Patient

Synchronous Use Case


Object model : Collection of objects or classes through which a program can examine and manipulate some specific part of its world.

Class diagram: It is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Object ModelObject Model


Object ModelObject Model

Application

UserNameApplicationListApplicationNameApplicationSchema

getApplicationByUserName()getApplicationSchemaByUserNameAndApplicationName()

Form

UserNameFormTypeSchemaFormInstanceSchemaFormTypeNameFormID

getFormTypeSchemaByUserName()getFormInstanceSchemaByUseName()getFormTypeSchemaByUseNameAndFormTypeName()getFormTypeSchemaByUseNameAndFormID()

PMFacade DMFacade

Gateway

User

userNamepasswordfirstNamelastNamevoiceEnableprofilePic

getUsreByUserName()updateUserByUserName()

ContactList

userNamecontactUserName

getContactListByUserName()addContactToContactList()deleteContactFromContactList()

Session

userNameloginStamp

addUserToSession()logoutUserByUserName()

RoleList

userNameroleType

getRoleListByUserName()

AdminClient


Object ModelObject ModelGateway

Dispatcher

Response

UCIControllerAuthorizationController UserManagementController

DBFacade

UCI

CVMAdapter

ResponseQueue

ModuleController

JobQueue


Dynamic ModelDynamic Model

The dynamic model is used to express and model the behavior of the system over time.

It includes support for activity diagrams, state diagrams, sequence diagrams

Sequence diagrams are used to display the interaction between users, screens, objects and entities within the system.

It provides a sequential map of message passing between objects over time.


Sequence DiagramSequence Diagram

Doctor to Patient Communication using CVM voice feature.

: Doctor : VoiceBoundary : SynCommControl

: Patient : VoiceBoundary1: Assign command

2: create connection

3: send invitation

4: prompt invitation

5: accept invitation6: establish connection

7: connection notification

8: prompt notification 9: connection notification

10: prompt notification


Sequence DiagramSequence Diagram

Sequence diagram : Interaction between UI and UCISequence diagram : Interaction between UI and UCI

Sequence diagram : Interaction between UI and UCI

Actor1

UI Gateway Job Queue Dispatcher Module Controller UCI Controller UCI

Request

Sends Request

Stores as job

Retrieves job

Dispatches job

Sends job

Up calls to NS

Response Handler

Down calls to UCI

Send Response

Sends Responses to UI

Response to user

Response Queue

Store Response

Retrieve Response

Send Response


Screen Mockups: FormsScreen Mockups: Forms


Screen Mockups: GUIScreen Mockups: GUI

Collapsed State – Before Login

Collapsed State – After Login

Note: Voice Enabled changes to Voice Disabled when

clicked on.

Login Window

Voice Enabled



Voice Enabled Voice Enabled

Dashboard Window – Default State

Dashboard Window – Voice Suggestions Panel Expanded



Voice Enabled Voice Enabled

Collapsed State – Voice Suggestions Panel Expanded

Dashboard Window – Contacts ExpandedDashboard Window – Contacts Expanded



Side Panel



Voice Enabled

Dashboard Window – Side Panel Expanded



Voice Enabled

Window - Side Panel Collapsed with 2 Calls


System ArchitectureSystem Architecture

Deployment View:

Peer2CVM

Native Server

UI

Peer1

SIP Server(bobcat.cs.fiu.edu)

STUN Server Audio Mixer(asfecisk.cs.fiu.edu)

Audio StreamVideo Stream

UI

Native Server

CVM

Response

Response

Request

Request

SIP Message

SIP Message

Audio Stream

Video Stream

1

2

3a

4a

3b 3c

5

6 7

8

3d

4b4c

9a 9b 9c

9d

10c

11

12

10a 10b


Gateway

Native Server

Job Queue

Dispatcher

Module Controller

UCI Controller Authentication Controller

User Management Controller

Response Queue

CVM

CVM Adapter

Repository

DB Facade

Response Handler

SE

…

NCB

…

UCM

…

Neighboring Peer

RepositoryGateway

Data ModuleAdmin Client

Main Panel

UI

Login Form

CVM

( EntryPoint)

Request Model

Side Panel

Voice PanelUser

Application

UCI

…

System ArchitectureSystem Architecture

CVM Overview:


System Architecture OverviewSystem Architecture OverviewSub-System Decomposition:

• User Interface.• Native Server.• User Communication Interface.• Repository.

Access Control and Security:• A user is authenticated for his username and password for him to use CVM.

Boundary Conditions:

Initialization:•Installing: CVM has to be explicitly installed on client system for him to use it.• The user needs to login to be able to use it.

Termination:• User can logout when he wishes to terminate the communication or he could just close the window to stop the communication.• Users are notified when communication is ended.

Failure:• When a system communication link fails the system treats it as if a communication is closed between the users.


Subsystem Services: UISubsystem Services: UI

The place of the UI in the system. The UI is located in the first layer, responsible for providing friendly

interface and sending all requests to Native Server

40



The Technologies used in implementing UI. GWT (Google Web Toolkit)

GWT is an open source Java software development framework that makes writing AJAX applications easier

Ajax Ajax stands for Asynchronous JavaScript and XML. Use the XMLHttpRequest() object to communicate with server-side scripts

41

a set of custom interfaces to create web browser "widgets," like

buttons, text boxes, images, and text.

It contains JavaScript implementations of the most widely used classes in the

Java standard class library

It translates the Java programming language to the JavaScript programming language

it lets you run and execute your GWT applications in hosted mode


The User Interface (UI) was developed using the Google Web Toolkit

What is Google Web Toolkit? Google Web Toolkit (GWT) is an open source Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translates your Java application to browser-compliant JavaScript and HTML.

The components, from bottom to top, are:

• GWT Java-to-JavaScript Compiler: The GWT Java-to-JavaScript compiler translates the Java programming language to the JavaScript programming language. You use the GWT compiler to run your GWT applications in web mode.

• GWT Hosted Web Browser: The GWT Hosted Web Browser lets you run and execute your GWT applications in hosted mode, where your code runs as Java in the Java Virtual Machine without compiling to JavaScript. To accomplish this, the GWT browser embeds a special browser control (an Internet Explorer control on Windows or a Gecko/Mozilla control on Linux) with hooks into the JVM.

• JRE emulation library: GWT contains JavaScript implementations of the most widely used classes in the Java standard class library, including most of the java.lang package classes and a subset of the java.util package classes. The rest of the Java standard library isn't supported natively within GWT. For example, packages like java.io don't apply to web applications since they access the network and local file system.

• GWT Web UI class library: The GWT web UI class library is a set of custom interfaces and classes that let your create web browser "widgets," like buttons, text boxes, images, and text. This is the core user interface library used to create GWT applications.

(http://code.google.com/webtoolkit/overview.html)


42



Main Panel

UI

Login Form

CVM

(EntryPoint)

Request Model

Native Server

…

Send UI Request

Get Response

Side Panel

Voice Panel

Send Response

Response Model

Voice Module

User

Application


Subsystem Services: Native ServerSubsystem Services: Native Server

The place of the Native Server in the system.– The Native Server is located in the middle layer, below the UI Subsystem

and above the CVM and Repository Subsystems.

44



The role of the Native Server Subsystem.– The Native Server provides two services:

1. Service requests from the UI: These requests are initiated by the user of the system.

e.g. Adding a contact to the contact list

In this case, a request (add the contact to the contact list) is sent down from the UI.

After the Native server handles the request it generates a response (the contact’s

name) and sends it back up to the UI.

2. Route up-calls from the UCI component within the CVM Subsystem to the UI: These up calls are triggered by remote requests and are handled by the UCI. After these requests are handled by the UCI component, the Native Server is responsible for notifying the UI of such events and providing it the appropriate information.

e.g. Notifying the UI that a member has been added to the connection

In this case, peer 1 invites peer 2. Upon acceptance from peer 2, a remote message

is sent to the UCI on the side of peer 1 (UCI-1). UCI-1 adds peer 2 to the

connection and sends a notification (peer 2 has been added to the connection) along

with the user name and session id to the UI through the Native Server.

45



Gateway

Native Server

Job Queue

Store UI Request as a Job

Dispatcher

Retrieve next Job

Module Controller

Dispatch next Job

UCI Controller Authentication Controller

User Management Controller

Send JobSend JobSend Job

Response Queue

CVM

UCI

CVM Adapter

Down Callsto UCI

Up Callsto NS

Repository

…

Call DB Call DB

UI

…Send UI Request

DB Bridge

Call DB

Response Handler

Send Response

Send Response generated from Up Calls

Store/ Retrieve Responses

Get All NS Responses in the queue to UI

Delegate DB Call

1. Get Contact List

2. Add Contact to Contact List

3. Remove Contact from Contact List

4. Edit Profile

…

1. Login

2. Logout

…

1. Login Notify

2. Logout Notify

3. Add User to Connection

4. Remove User from Connection

5. Load Application

6. Save Form Instance

…

UCI Down Calls

1. Party Added Notify

2. Remote Invite Notify

3. Session Created Notify

4. File Added Notify

…

UCI Up Calls

Get Contact List RequestLogin Request

Party Added Notify…


Subsystem Services: RepositorySubsystem Services: RepositoryInternal Structure of the Repository

Repository Gateway: Repository Gateway contains all the methods which are called by other subsystems to complete their requests.

Repository Gateway is connected to two databases:• Presence Database• User Database

Presence Database: contains all the user information like user’s personal details, role list, and contact list.

User Database: contains all the information related to form and application.

Admin Client: small piece which is an interface to communicate with databases.


Subsystem Services: Repository SnapshotSubsystem Services: Repository Snapshot

Repository Gateway

Pre

sen

ce

Da

taba

se

Use

r D

ata

base

Admin Client


Subsystem Services: RepositorySubsystem Services: RepositoryDesign Goals: To make an interaction with other subsystems

Repository interacts with:

UCI AUTHENTICATION USER MANAGER

Tables involved:

Presence Database:• USER• CONTACT LIST• ROLE LIST• SESSION

User Database:• FORM• APPLICATION


Subsystem Services: UCISubsystem Services: UCI

Design Goal:– Adaptability: for other domain-specific communication applications– Flexibility: extend functionalities as new user requirements arise

Schema : specifying communication needs and keeping a snapshot of the current communication



Class Diagram for the UCI package actual implementation

Person

Connection

Schema

IsAttached

Device

FormType FormType

MediumType

public Schema(String xmlString){ //construct by xcml try { connections = new ArrayList(); persons = new ArrayList(); mediumTypes = new ArrayList(); formTypes = new ArrayList(); isAttacheds = new ArrayList(); ……………………… } …………………..}



UCI’s place in the system Interface: CVMAdapter

– Handle user requests from native sever and make necessary changes to the active schema and pass updated schema to the SE layer.

– Make upcalls to the native server when remote requests or responses come

Upcalls to NS

Downcalls to UCI

UCI

CVMAdapter

UCIController

NativeServer

SE and Lower

XCML String

Repository

DB Bridge

Schema Package


Basic Lay-Out for CVMBasic Lay-Out for CVM

The Side Panel has 5 different windows. At any point in time, the user should be able to work only with one of these windows and the rest should be close. The only exception is the Application panel that can be opened while the user plays with the other windows. Of course, in this state, the application panel should be inactive until the other window is closed. Here are the windows:

Application Panel: This is the window that shows all the active applications separated by tabs.

Form Editor: This is the window that shows the form editor.

Form Viewer: This window is basically a browser that shows the contents of a form. This window is used only for viewing the form and not editing.

File Viewer: This window is a browser again that shows a selected file, for example, from My Documents.

Contact Editor: This is the window that allows adding/removing/editing the information/profile about a contact.

Profile Editor: This window allows editing the profile.VOICE SUGGESTIONS

CVM MENU

Conn1 Conn2 Conn3 Conn4

SIDE PANEL

CONTATCS

APPLICATIONS

FORMS

MY DOCUMENTS

PROFILE

Dashboard


High Level State Diagram for voice Module/High Level State Diagram for voice Module/Main States Identified in the SystemMain States Identified in the System

Voice Enable / Disable command is available in all the states of the CVM, even when the user is logged out.

As the user logs in, voice is disabled by default. The user can enable the Voice, by selecting the

corresponding option. Once the voice is enabled, the user can hide or show

the voice suggestions. This is the highest level state chart of CVM and the

rest of the states are the sub states of any of the two states in this state chart.

Voice Disabled

/ Voice EnableVoice Enabled

/ Voice Disable

/ Hide/Show voice Suggestions

Logout/ Log in

Dashboard/ Open first App

App panel

/ Logout / Close last App,

/ Logout

/ Hide/Show Side Panel

/ Open/Close App/ Hide/Show Dashboard

As the user logs in, he will be into the Dashboard state.

When a new connection is to be made, application is opened.

The first application opens the application panel. Closing the last application/connection closes the

application panel and goes to the dashboard. It does not matter if the Application panel is visible or

not, as long as an application is open, CVM is in the App Panel state.


Application PanelApplication Panel Opening the first application and

opening more applications are separate states.

When only one application is open, the user is in ‘One app’ state.

When more than one application is open, the user is in More app state.

Commands in More app that are not there in One app are :

Open / Close app Activate Connection # Commands within the app panel, for

both one app opened and more app opened, contain the following :

Add / Remove <Contact name> from Connection #

Add/Remove Audio to connection # Add/Remove Video to connection # Enable/Disable

Microphone/Loudspeaker Choose Video to connection # Open File Dialogue Open Form Dialogue

Closing the last application will close the side panel and goes to the dashboard state.

One app/ Open first app / Close more app

More app

/ Close all but one app

/ open/close app

/ Activate connection #

/ Close app


DashboardDashboard All the five states can be transited to every other

state by the corresponding command. “Open app list” command goes to App list open state

from the other four states. “Open contact list” command goes to Contact List

open state from the other four states. “Open Form list” command goes to Form List open

state from the other four states. “Open My Documents” command goes to Mydocs

open state from the other four states. “Open Profile” command goes to Profile open state

from the other four states. The states show the transition between the dash

board and the side panel, when the user is in the first application.

As long as user does not log out or does not open the first application, CVM will remain in this state no matter in the dashboard is hiding or not.

There are editors for FormList, ContactList and Profile and File Viewer for My documents.

We do not have an application editor, but if one application is opened, then the CVM state is changed to App Panel.

App list open

Contact List openProfile open

My docs open Forms list open

Profile editor

/ Edit Profile

File viewer

/ Open File

Form viewer

/ View form / Close form

Form editor

/ Edit/Add form

/ Form Edited

Contact Editor

/ Add/Edit/ Save/Cancel

/ Remove contact

/ Save

/ Close file

/ Save/Cancel


Package DiagramPackage Diagram

System Architecture (Package Diagram)

How we organize

module elements

into packages

Dependencies

among themLogic

UI

Repository



• UI Package Specification • 3 Modules • Voice (command) Module • Request Module • Response Module

• Bi-direction Communication

• (1) Down-Calls Sending requests or contents to Logic part via XML (data format)

• (2) Return Receiving responses from Logic part via XML

UI

Voice Module

Request Module

Response Module

Logic

Repository

(1)

(2)



Logic Package Specification

Communication with UI Receiving requests from UI Response to UI via Native Server

Communication with Rep. Sending data enquiry (read) to Rep. Sending data update (write) command to Rep. via Repository Controller

UI

Repository

Native Server

UCI

SE

UCM

NCB

Authentication User Manager

Repository Controller



Repository Package Specification

2 Classes Repository Gateway Admin Client

2 Modules Presence Module Data Module

Function Response for (read) enquiry

of data from Logic package Update data (write)

Repository

Presence Module

Data Module

Repository Gateway Admin Client

Logic

UI


TestingTesting

Procedure– Unit testing

– Integration testing Approach: Modified Sandwich

– System testing


An driver example used in Unit TestingAn driver example used in Unit Testing

/**********************************************************

*The below is used for testing adding mediumtypes

***********************************************************/

Element NewMT;

NewMT = doc.createElement("mediumtype");

NewMT.setAttribute("mediumTypeName","chat");

NewMT.setAttribute("derivedFromBuiltInType","false");

NewMT.setAttribute("suggestedApplication","LeaveToDoubt");

NewMT.setAttribute("voiceCommand","Open Chat");

sm.addMediumType(NewMT, "-1");

System.out.println("Schema with added mediutype is:");

System.out.println(sm.toString());

System.out.println();


An driver example used in Integration TestingAn driver example used in Integration Testing

public void actionPerformed(ActionEvent e) {

if (e.getSource() == login) {a.notifyLogin("yaz", "blah2", "yaz@[email protected]", "", "patient");}

if(e.getSource() == addContact) {note.setText("adding contact");connId = a.createConnection();a.addContactToConnection("selim", "selim@[email protected]", "", "doctor", connId);}

if (e.getSource() == acceptContact) {note.setText("user accepts invitition");a.AcceptParty();ArrayList temp = a.getSchema().getConnections();connId = ((Connection)temp.get(0)).getID();}

if (e.getSource() == addMedium) {a.addMediaToConnectionChat("","", "TextFile", note.getText(), connId);}

if (e.getSource() == item2) {System.exit(0);}

}


System Test Cases: LogIn - 1System Test Cases: LogIn - 1

Test Case ID: HCL_Login_002

Purpose: Verify that when the user leaves the ‘User Name’ field empty and leaves the ‘Password’ field empty, a message is displayed on the screen instructing the user to check his/her user and password and type them again.

Preconditions:-The user is on the login screen.

Input:- The user leaves user name field empty.- The user leaves password field empty.- Click ‘Login’ button.

Expected Output:-The user is not logged in. -The login screen is remains in display.-The message “username and password entered are invalid” in red letters appears on a popup messagebox.


Test Result for HCL_Login_002Test Result for HCL_Login_002

Test Case ID Pass ()Fail ()

Expected Output Actual Output

HCL_Login_002 The user is not logged in. The login screen is remains in display.The message “username and password entered are invalid” in red letters appears on a popup messagebox.

The user is not logged in. The login screen is remains in display.The error messagebox pops up twice.


System Test Cases: LogOut - 1System Test Cases: LogOut - 1

Test Case ID: HCL_Logout_001

Purpose: Verify the normal flow of events of the Logout use case. It ends when the user is redirected to login screen of the CVM.

Preconditions:-User is logged into the CVM.

Input:- Click the “Logout” link.

Expected Output:- User is asked” Are you sure you want to logout”- After clicking on “OK” button, User is redirected to the Login screen- Every action performed by the user is stored to the user record


Test Result for HCL_Logout_001Test Result for HCL_Logout_001

Test Case ID Pass ()Fail ()

Expected Output Actual Output

HCL_Logout_001 User is asked “Are you sure you want to logout”.After clicking on “OK” button, User is redirected to the Login screen.Every action performed by the user is stored to the user

record.

User is asked “Are you sure you want to logout”.After clicking on “OK” button, the messagebox still pops up.


DemoDemo


SummarySummary

Lessons learned!– Define your groups well (everyone needs to know what is expected of each other)– Communication is key (with so many sub-groups, on-going communication is vital for

anything lasting to be accomplished). – In large project more time spent on communicating than coding.

To do and Not to do– Keep your documentation up to date.– Don’t Delay, time can get away from you.

Estimated time spent on each part– Modeling = 50%

RAD SDD ODD

– Development = 30%– Testing = 20%

Estimated percentage of the whole system done by each group member– 15 members, each contributing at roughly the same rate = 7%


Questions?

(Background graphic courtacy of Mike Mesnier from his presentation on Object-based Storage)