The University of British Columbia

EECE 419 Software Engineering Project Pod 2 Final Report

November 28, 2008

Ryan Barr Andrei Horga Stanley Shang Robin Roy Timotius Margo Russell Kramer Chris Pang

40184053 60593043 24491037 33699059 75112045 29685054 16212037

TABLE OF CONTENTS 1 INTRODUCTION 4 4 4 5 5 5 5 6 6 7 7 7 7 8 8 8 9 15 15 16 16 17 17 18 18 19 21 21 24 24 25

1.1 VISION 1.2 MAIN FEATURES OF BOARDROOM 2 REQUIREMENTS

2.1 ACTORS 2.2 NON-FUNCTIONAL REQUIREMENTS 2.2.1 2.2.2 2.2.3 2.2.4 USABILITY RELIABILITY PERFORMANCE SUPPORTABILITY

2.3 MEETING THE FEATURED REQUIREMENTS 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 LOGIN AND REGISTRATION FILE INPUT AND OUTPUT SYNCHRONIZED TEXT EDITING AND DATA CONSISTENCY BOARDROOM CHAT PROJECT MANAGEMENT

2.4 USE CASES 2.5 INTERFACE DESIGN FOR KEY USE CASES 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 INTERFACE 1 MAIN PROJECT VIEW INTERFACE 2 DOCUMENT EDITOR VIEW INTERFACE 3 LOGIN/LOGOUT VIEW INTERFACE 4 PROJECT SELECTION VIEW INTERFACE 5 PROJECT MANAGEMENT VIEW INTERFACE 6 CHAT SESSION VIEW INTERFACE 7 NEW PROJECT SETUP VIEW

2.6 INTERACTION FLOWCHART FOR KEY USE CASES 3 ARCHITECTURE & DESIGN

3.1 BOARDROOM SERVER 3.2 BOARDROOM CLIENT 3.2.1 3.2.2 APPLET ORGANIZATION APPLET COMPONENT ARCHITECTURE

3.3 SYSTEM COMPONENTS IN DETAIL 3.3.1 MAIN GRAPHICAL USER INTERFACE 3.3.2 USER/PROJECT MANAGEMENT 3.3.3 FILE TREE MANAGEMENT 3.3.4 DOCUMENT EDITING MANAGEMENT 3.3.4.1 TEXT EDITOR FEATURES 3.4 CHAT MANAGEMENT 4 TESTING

25 26 29 31 33 38 42 44 44 44 44 44 44 45 45 50 51 52 52 52 52 53 54 54 55 __________ _____________56 58 _ 64

4.1 OVERVIEW 4.2 RESOURCES 4.2.1 4.2.2 HUMAN HARDWARE

4.3 SOFTWARE 4.4 SCOPE AND TESTING APPROACH 4.5 UNIT TESTING (FUNCTIONAL AND UI) 4.6 GROUP TESTING 4.7 COMPONENT TESTING 4.8 ACCEPTANCE TESTING 4.9 FEATURES NOT TO BE TESTED 4.10 TESTING PROGRESS 4.11 ISSUES, RISKS AND ASSUMPTIONS 4.12 SIGNOFF 5 HUMAN RESOURCES

5.1 TEAM ORGANIZATION 5.2 WORKLOAD DISTRIBUTION APPENDIX A: INDIVIDUAL TIME SHEETS _ APPENDIX B: BOARDROOM BOX DESIGN ____ APPENDIX C: BOARDROOM USER GUIDE

1 Introduction
Boardroom, the cross-platform multi-user collaboration tool sets out to connect people. With Boardroom, the online application improves the productivity of your project work and efficiency of your collaboration in an easy way.

1.1 Vision
In a world, which increasingly demands teamwork in order to drive productive results, online collaboration is the only viable solution for many teams scattered across the globe. However, with todays common software applications, simple document collaboration can entail a chaotic exchange of emails, chat messages and un-versioned files. Teeing off this reality, Boardroom, a new multi-platform tool serves to bring order to its users online collaboration sessions. By integrating the features of a text editor, instant messenger and document management system into a single, cohesive program, Boardroom frees up desktop space and eliminates the need for cumbersome file exchanges. Boardroom is planned to be a Java based web applet, maximizing cross platform compatibility, and allowing projects and documents to be available from anywhere in the world. Through organizing collaborations into team-owned Projects, Boardroom simulates a true conference room environment where multiple users can read and edit the same file in a systematized way. Editing access is shared amongst users in a controlled manner, allowing for conflict-free compositions. Brainstorming new ideas can also be easily facilitated using an integrated chat system designed to ensure that group editing session go smoothly. Our web server technology also ensures that users data is not lost and that editing sessions can be continued at a later date. By leveraging its features, users from all walks of life including students and business professionals will be better able to write and share documents. At its core, Boardroom delivers a seamless team environment so that users can simply concentrate on composing their documents.

1.2 Main features of Boardroom

Create, edit and manage text documents from anywhere in the world Collaborate on a project with a number of users in different locations Secure and reliable storage of all of your important documents Integrated chat system for real-time communication with all of your team members Robust, user-friendly environment for maximum productivity Compatible with all modern computer platforms

2 Requirements
2.1 Actors
Boardroom makes the distinction only between two types of users: General Users and Managers. Since any sort of administration is handled outside of the Boardroom interface, we have no need for any sort Administrator actor. General User All users fall under this category. A General User has access to nearly the entire feature of Boardroom. The only limit is to some of the project specific maintenance commands, such as adding and removing users to a project. Project Manager A Project Manager is a subtype of a General User, and can do anything a General User can. Furthermore, a Project Manager is a special project specific user type. That is, a user can be a Project Manager for many different projects or none at all. Typically a General User becomes a Project Manager for a project when they create a project. Additionally, a project can have one to many Project Managers. Project Managers gain special commands for maintaining a project that General Users cannot, such as adding new users to a project.

2.2 Non-Functional Requirements

2.2.1 Usability Hours of Usage The Boardroom servers are available 24/7, except with a minimum 24 hour notice of scheduled down time. Exception and Notification Boardroom makes clear any exception or error that occurs during a user session. These notifications clearly state what went wrong or not as planned, and possibly suggestions for the user to take to remedy or deal with any problems. Concurrent Access Boardroom is capable to handle at least 7 users in any single project, and the boardroom server should be able to handle at least 10 projects simultaneously.

Interface Boardroom offers an interface that is as similar as possible to other file management programs users can have been expected to use such as Eclipse and Visual Studio. This feature facilitates the ease of new users learning to use Boardroom. Compatibility Boardroom works on any operating system capable of running Java Virtual Machine, and on any browser compatible with Java applets.

2.2.2 Reliability Maximum Down Time Since boardroom is aimed at business and education, it should not be down for more than 16 hours straight. Moreover this downtime should correspond nonbusiness hours. Client Failure Recovery If a Boardroom client connection is lost while active in a project, then all other users in the project is notified in the chat room. If the lost client was currently editing a document then the document is saved with the current changes and the editing privilege to the document is released to let other user edit the document.

2.2.3 Performance Login Logging-in takes no longer than five seconds. Editing a Document Changes to a document in Boardroom are just as fast as if the document was being edited offline. Users should see no noticeable difference in text editing performance between Boardroom and the text editors on their own computer. Chat Chat performance is similar to any other popular online chat software. Opening a Document Opening a document takes no longer than 0.5 second per page of text, and a progress bar displays the status of this operation.

Saving a Document Saving a document takes no longer than 0.5 seconds per page of text, and a progress bar displays the status of this operation.

2.2.4 Supportability Maintenance Since Boardroom uses a Java applet, whenever a client connects to the Boardroom server they download the applet. Thus, for maintenance, the file the web site uploads to the user can be changed at anytime. Once changed all users connecting to the Boardroom web site receive the new applet. Similarly for the server, updating the server code takes effect immediately for all subsequent server commands issued by clients.

2.3 Meeting the Featured Requirements

2.3.1 Login and Registration User account is stored on server side database. The options of registering a new account or signing in an existing one are required to take part in Boardroom. In the case of registration, account registration form and information fields are validated and made sure the username has yet been taken. In the case of login, the server simply checks the inputs for the matching pair of username and password recorded in the database. If and when a user creates a new project, the user id is simultaneously associated with the project manager field of the project recorded in the database.

2.3.2 File Input and Output File manipulation routines allow for files and directories sitting in the remote server to be created, read from, moved, deleted and dragged and dropped in a dynamic UI manner. Using Java servlet that accepts and processes instructions through HTTP connection, the manipulation of and communication between file data are made possible.

2.3.3 Synchronized Text Editing and Data Consistency To prevent concurrent document editing between different users, each document has a header which stores the status of which if the file is being edited or viewed. A file already in edit mode prevents modification of the same file from another user unless edit mode is released or if inactive timeout is invoked. Lock and unlock functionality in Boardroom text editor prevents accidental deletion of an important file resource. A file with lock on is not allowed to be deleted unless the lock is released.

2.3.4 Boardroom Chat Our chat system uses the same technology as the rest of the Boardroom program. Each project on the server contains a list of chat text and a list of users online. When a user logs into a project, a file identifying the user is added to a folder on the server. When any user enters text in their applet, the applet sends this string to the server which appends to a file. Later the server checks for how many characters have been added and sends those new ones to everyone in that projects list of online users. In both cases, all communication is done using HTTP.

2.3.5 Project Management Project manager specific classes provide an interface to manipulate a project in a separate panel. User privilege is checked at every instance of login, and configuration properties of a project can be read only or modified depending on the privilege level of the user. In short, on the server side, each project maintains a member list and a properties text files used to validate the extent of project accessibility.

2.4 Use Cases

Name: Create Account Actor: General User Preconditions: None Postconditions: New user account is created on server Input: 2. User ID (unique) 3. Password 4. Email Address Output: 1. Account Created 2. User ID Already Exists 3. Cancelled Basic Case 1. 2. The system checks the given username and it does not already exist. The system creates a new entity in the user database and returns OK.

ID: UC1

Exceptions 1. 2. 3. If the username already exists, the system returns User ID already exists. The system continues to ask for a new username until a unique username is entered or a "cancel command is entered. If a "cancel" command is entered the account creation is aborted and "Cancelled" is returned.

Name: Login Actor: General User Preconditions: User has already created an account Postconditions: User is logged into system Input: 1. User ID 2. Password Output: 1. Login Successful 2. Login Failed 3. Cancelled Basic Case 1. 2. 3. The system authenticates the given username and password. The system returns Login Successful. The system brings the user to the main workspace screen.

ID: UC2

Exceptions 1. 2. 3. If the username and password combination do not match, the system returns Login Failed. The system continues to prompt the user until a correct combination or a "cancel" command is entered. If a "cancel" command is entered, the login is aborted and "Cancelled" is returned.

Name: Create Project

ID: UC3

Actor: General User Preconditions: User is logged into Boardroom. Postconditions: New project folder with an associated members and properties file are created on the server. Input: 1. Project Name (unique) 2. Project Description 3. Project Members Output: 1. Project Created 2. Project Creation Failed 3. Cancelled Basic Case 1. 2. 3. 4. 5. 6. The system checks that the project name does not already exist within the system. The system creates a new project folder with the supplied project name The system creates a members file with the list of selected project members The system creates a properties file that will include the entered description of the project. The associated user becomes the Project Manager. The system returns Project Created.

Exceptions 1. 2. 3. If the user already has project with the same project name, the system returns Project Creation Failed. The system continues to prompt the user for a new project name until a unique project name or a "cancel" command is supplied. If a "cancel" command is selected, the transaction is aborted and "Cancelled" is returned.

Name: Delete Project

ID: UC4

Actor: Project Manager Preconditions: User is logged into Boardroom and is the project manager of the project Postconditions: Project is deleted off the server. Input: 1. User selects delete project for selected project Output: 1. All active and saved server-side project document, user permission lists and project information are deleted from the system. Basic Case 1. 2. 3. 4. 5. 6. User initiates delete request by selecting delete project. The system prompts the user for confirmation of delete request. User confirms their intention to delete the project. System verifies that no user is currently accessing project documents. System deletes project (and associated documents) and removes all references to the project, i.e. project no longer appears in the projects directory. System sends a delete confirmation notice to the user.

Exceptions 1. If another project member is currently accessing project documents, then the delete process fails and the user requesting the delete is prompted with a list of users currently accessing project documents.

10

Name: Add/Remove Users to/from a Project

ID: UC5

Actor: Project Manager Preconditions: User is logged into Boardroom and is the project manager of the project Postconditions: Selected users are added or removed from the project. Input: 1. Existing Boardroom User ID Output: 1. User Added to Project 2. Invited User Already Exists for Project 3. Cancelled Basic Case 1. 2. 3. The system checks that the invited user ID is not already associated with the project (project manager can choose from a list of active users or manually enter a name). The system associates the user with the project. The system returns User added to Project.

Exceptions 1. Notes 1. Remove user follows the same process. If a "cancel" command is selected, the transaction is aborted and "Cancelled" is returned.

Name: Create Document Actor: General User Preconditions: User is logged into a project. Postconditions: A new document is added to the project. Input: 1. User selects proper Project. 2. User selects create new document and gives it a unique name. 3. User selects upload existing document. Output: 1. Source file created. 2. Source file uploaded successfully. 3. Source file creation failed. 4. Upload failed. 5. Cancelled. Basic Case 1. 2.

ID: UC6

The system checks that a file with the same name does not appear under the current Project. The system either creates a new, blank, ASCII plain text file or uploads an existing ASCII plain text file to the Project under the name given.

Alternatives 1. 2. A new blank document can be created A new document can be created as a copy of a users uploaded file

Exceptions 1. 2. 3. A file with the same name already exists in the project, in which case the system prompts the user for a different name. The file selected to be uploaded is not plain text ASCII, in which case the system does not allow it to be uploaded. The Cancel command is selected, in which case the transaction is aborted and a cancel value is returned.

11

Name: Delete Document

ID: UC7

Actor: General User Preconditions: User is logged into a project and there is an existing document. Postconditions: The selected document is deleted. Input: 1. User selects proper Project. 2. User selects the proper source file. 3. User selects File -> Delete Current Source File Output: 1. A message stating Really delete the current source file? is displayed, with options for Yes and No 2. If No is chosen, the source file is not deleted and the prompt disappears. 3. If Yes is chosen the current source file is deleted. Basic Case 1. 2. 3. The user selects a source file in the project tree by clicking on it. The user selects Delete Current Source File and clicks Yes The document is deleted.

Exceptions 1. The user tries to delete a source file without the proper permissions. In this case, the button is grayed out (disabled).

Name: Edit Document Actor: General User Preconditions: User is logged into a project and there is an existing document. Postconditions: The selected document is edited. Input: Document Name Output: Updated Document Basic Case 1. 2. 3. Click Edit Document button on the text editor window Edit (modify) the text in the document (add/remove/change). Click View Document button to end edit mode.

ID: UC8

Exceptions 1. The document is being edited by someone else. a. The Edit Document button is unavailable. b. Wait for the other user to select View Document. c. The Edit Document option becomes available. The user wants to open the file in read only mode from edit mode. a. Select View Document option for a particular document from edit mode. b. Document text is displayed, but the User cannot edit the text. c. The Edit Document option for this document is available for anyone to select.

2.

12

Name: Manual Save

ID: UC9

Actor: General User Preconditions: User is logged into Boardroom and is a member of the project group. Postconditions: Document is saved to the server and/or a local copy is saved. Input: 1. User selects save while working on a document. Output: 1. A local copy of the project document is saved to the users computer. 2. A system request is issued to save a copy to the server at the next available time. Basic Case 1. 2. 3. 4. 5. 6. User initiates save request by selecting save for a project document. System initiates save file process in coordination with users operating system. User selects directory and file name to save document. System transfers document to users computer. System initiates a save of the document on the server-side, recording versioning information and a timestamp. System sends a save confirmation notice to the user.

Alternatives 1. User selects save all for all documents within the project. a. System transfers all documents associated to a project to local disk drive (user must select local directory to save in).

Exceptions 1. Not enough disk space exists for document to be saved either on the system server or on the users local disk drive. a. The save process fails and user is prompted with a failure notice.

Name: Chat with Group Members

ID: UC11

Actor: General User Preconditions: 1. User is logged in to the Boardroom system (signed into Chat Server) 2. User is associated with a project or projects 3. User is accessing a project Postconditions: User exchanges instant message (chat) with other project members Input: 1. Text message Output: 1. Text Message is broadcasted to all project members currently online and accessing the same project Basic Case 1. 2. 3. The user sends messages to and receives messages from other project members Each member types in the text field and sends it to all online members that belong to the same project Each member receives all messages sent by other online members that are logged into the same project

Exceptions 1. 2. A user attempts to transfer string data that exceeds the buffer size by design A user attempts to send a message while not currently accessing a project

13

Name: Logout

ID: UC13

Actor: General User Preconditions: 1. User has an authenticated system account 2. User is logged in Boardroom Postconditions: User signs off Boardroom securely and the latest change is saved persistently both on database and on local drive Input: 1. User selects to sign off the system, or 2. System counter hits 30 minutes for a particular user in an inactive session Output: 1. Copies of document with modification are produced and stored locally Basic Case 1. 2. 3. 4. Copies of document with modification are stored on database for later retrieval automatically System prompts user or manager for local save for files with modification made If no modification is made, the system takes no operation for file handling The user or manager is signed off the system securely

Exceptions 1 IO conflict - User specified location is not found or is full

14

2.5 Interface Design for Key Use Cases

2.5.1 Interface 1 Main Project View

UC5 - Project Management See Interface 5

Project Selection See Interface 4

UC2, UC13 Login/Logout See Interface 3

UC8 Edit Document See Interface 2

UC6 Create Blank Document UC6 Upload New Document UC7 Delete Document UC10, UC11, UC12 Project Chat See Interface 6

15

2.5.2 Interface 2 Document Editor View

UC9 Manual Save (Local)

UC8 Edit Document Synchronization

UC9 Manual Save (Server)

2.5.3 Interface 3 Login/Logout View

UC1 Create Account

UC2 Login

16

2.5.4 Interface 4 Project Selection View

UC3 Create Project

UC4 Delete Project

UC5 Manage Project

UC13 Logout

2.5.5 Interface 5 Project Management View

UC5 Add User to Project (manual) UC5 Add User to Project (from list)

UC5 Remove User from Project

17

2.5.6 Interface 6 Chat Session View

UC11 Chat with Project Group Members

2.5.7 Interface 7 New Project Setup View

UC3 Create New Project Members

18

2.6 Interaction Flowchart for Key Use Cases

19

20

3 Architecture & Design

3.1 Boardroom Server
The cornerstone of Boardroom is its server. As one of our earliest design choices was to use Java Applets launched from a browser, it made sense for us to use a Java friendly server. As such, a decision was made to use Apache Tomcat 6.0. Apache Tomcat 6.0 is an open source implementation of Java Servlet and JavaServer Pages. Apache is easy to setup and to maintain, and provides solid support for our Java Servlet and Java Applets. The Boardroom applet is stored on a web server and run from inside of a web browser, so to a casual observer the applet appears to be inside of the web server. In reality a web browser executes an applet by downloading it then running it using the host CPU, so the applet does not truly run from inside the web server. If the applet were running on the web server, IO routines (load save, etc) would act on the files stored on the web server, but this is not the case. IO routines performed by the applet, act on files that reside on the users computer. There is no direct link that the applet can use to perform IO routines on the servers files. This is no trivial problem for a program intended to manage files using client-server architecture. The solution to the problem was to implement an HTTP Servlet, which handles IO routines in response to HTTP commands sent by the applet. A servlet is a program which the server runs, and therefore can perform IO routines on the files residing on the server. The advantage of a servlet over CGI is that a servlet can handle multiple requests simultaneously. In addition, a servlet can be written in Java, which reduced the complexity of Boardrooms development phase. The servlet is sparsely written; it only accepts IO commands, executes them, then sends a response back to the applet. The majority of the program exists within the applet, with the servlet only acting as a bridge, allowing the applet to perform IO on the server. The applet contains a class named ComClass, which provides functions for communicating with the servlet. The inner-workings of the IO connection are invisible to programmers adding functionality to the applet.

21

The servlet intercepts HTTP commands directed at the web server by overloading the servers post command. Using HTTP POST commands to carry the wide range of functions that the servlet must perform, the ComClass compiles all of the variables needed to perform an instruction into a single string. The servlet then extracts the variables at the other end. After executing the command the servlet sends a response back to ComClass, again in the form of a string over HTTP. The responses can be simple true/false to indicate the success of an operation such as deleting a file or more complex expressions such as the contents of a file or the date of the last modification to a file. The ComClass and servlet provide the following functions to the applet: Create a file Delete a file Create a folder Delete a folder Read contents of a file Get the size of a file Get the date of the last modification to a file Get the contents of a folder Check of a folder exists Check if a file exists 22

 Check if a specified object is a folder or file Rename a file Rename a folder Copy a file Copy a folder and its contents Get the present date according to the server Lock a file Unlock a file The servlet and ComClass were the first section of Boardroom to be developed because they provide the server-client foundation. A simple GUI was created to test the functions of ComClass and the servlet from an applet running within a web browser. A screenshot of the simple GUI is shown below.

23

3.2 Boardroom Client

3.2.1 Applet Organization The Boardroom applet architecture can be logically separated into 6 main system groupings: the GUI and Server Communications Class and components groupings based on User/Project Management, File Management, Document Editing Management, and Chatroom Management functionalities.

The responsibilities of these 6 groupings are listed below. Component Groupings Graphical User Interface User/Project Management File Management Editing Management Chat Management Server Communications Responsibilities Provide interface for user to interact with Boardroom application and server Organize user registration, profiles and project groupings Organize project-specific files Organize multi-user document editing Provide chat-room services for each project group Interface other application code with Boardroom server

24

3.2.2 Applet Component Architecture The diagram below shows all major classes in the Boardroom application organized within their main system component groupings. Some classes have responsibilities between more than one grouping and are shown as overlapped between two system groupings.

3.3 System Components in Detail

The following sections detail the class structure, interfaces and the internal workings of the applets main system components. Note that on class diagrams, attributes and methods shown vary depending on the discussion being presented and arent necessarily fully representative of the class.

25

3.3.1 Main Graphical User Interface To interact with the Boardroom application, the applet presents a graphical user interface for the user to use through their client web browser. This main user interface is initiated through the DefaultGUI class, an extension of the JPanel class. A class diagram for this system component is shown below, followed by the main working user interface it generates marked with the names of the classes utilized to generate each section.

Each of the four marked areas provides interfaces and containers for the applets four main logic components. The buttons located on the top bar of the interface are used for calling further interfaces for handling user and project management, the left-hand Hierarchy Panel handles file management within a project, the top-right Graphing Panel holds Text Editor windows used for document editing, and the

26

bottom-right Chat window provides an interface for chatting with other users. The three panel interfaces are all re-sizeable. The specific interfaces and functionality for these four logic components will be discussed within the upcoming component sections. Before reaching the main working interface shown earlier, the user must successfully log into the Boardroom system and then select a project. After its initialization, the DefaultGUI class will call a method that triggers the opening of the Login class, an extension of the JDialog class that provides the interface used for logging in users. This is interface is shown below.

The Login class interfaces with the Boardroom server to confirm that the user has entered a valid user name and password using the communications class ComClass before allowing entry to the next interface. User data on the Boardroom server is stored in a users folder, which must be accessed through ComClass. If the user is not currently registered, a new registration can be requested using another interface shown below implemented by the EditProfile class.

The EditProfile class is responsible for collecting the name, password and email of the user. Additionally it must confirm that the entered passwords are exactly the same as well as ensuring that no special characters that the Boardroom application utilizes for keyword operations are entered. 27

The EditProfile class is able to generate both a Register and Edit Profile window with similar functionality (modifying user account details). For local file storage, the class also utilizes a private LocalLocEditor class to provide an interface for collecting the location the user wishes to store documents on their hard drive. Once a user has successfully logged in, their login data will be stored in a User class for future use and they will be prompted with an interface for selecting the project they would like to work on. This interface is implemented using the ProjectSelect class.

The ProjectSelect class will be passed variables associated only to the projects that the user is currently allowed access to (by virtue of being a project member). This information is found by querying the members text files located in each project folder for the users name. This class will then display these projects, their associated project manager and the number of users currently listed in a selectable list. A private CustomCellRenderer class is utilized to provide the highlighting effect of each project. The class will monitor the users selection and provide feedback to the main DefaultGUI class for the next action depending on the button selected by the user. To open the main working project interface described at the beginning of this section, a project must be selected and the Open button must be clicked. The other buttons provide functionality for Project Management actions implemented by the ProjectManager class, which will be described further in the next section.

28

3.3.2 User/Project Management To help organize and coordinate users and projects within the Boardroom server and application, four user and project management interface classes were designed. All of these classes can be utilized during the login/registration process, but are also readily accessible through four corresponding buttons within the main working project view contained in the DefaultGUI class. The class diagram for this system component is shown below as well as the corresponding GUI buttons that each initiates one of these classes.

The functionality and interface for three of these classes was described in the previous section. Change User, will log the user out of the Boardroom server, and then prompt the user with another Login window. Selecting My Account Setting, will initiate an EditProfile class that allows the user to edit their registration data. Change Project will exit the user from the project and prompt them with a Project Selection window implemented by the ProjectSelect class exactly as described above. The Project Selection interface provided buttons for adding a new project, editing a project and deleting a project. The Manage Project button also provides an interface for editing a project. These functionalities are implemented by the ProjectManager class (which is an extension of the JDialog class). Projects on the Boardroom server are each allocated their own folder within the main Projects directory. Within this folder are text files for storing the list of

29

project users, metadata properties such as the project description, issued chat messages and a data folder for holding all the documents created within the project. The ProjectManager provides an interface for managing the user and properties text files as well as setting up new project directories.

This interface can be utilized for creating new projects and modifying existing projects. Users are able to select the users allowed to participate in each project if they are the project manager of the project. The users can be selected from a list of all users registered on the Boardroom server or manually entered. The interface also provides a mechanism for changing the project manager. The ProjectManager class will either generate the necessary files and folders on the Boardroom server for a new project or update the existing members and properties file for an existing project after a create or update request is submitted. Only project managers will be able to access an editable window through the ProjectManager class, all other users will see a read-only window of the above interface. Boardroom is set up such that a project can only have one project manager at a time, who will be listed at the top of the users file for the project. An initiated ProjectManager class will check the accessing user against the listed project manager before providing project editing privileges. All of the user and project management system classes utilize the communications class ComClass to read from and write to the user and project files stored on the Boardroom server.

30

3.3.3 File Tree Management Whenever a user enters into a project, a file tree representing the current view of the data folder for that project is displayed within the left-hand Hierarchy Panel on the main working project GUI. This file tree is implemented through significant extensions to the JTree class used to display hierarchal data. The file tree provides an interface for the user to easily make changes to the structure of the projects files on the Boardroom server through point and click functionality alongside four buttons located at the bottom of the Hierarchy Panel used to create and delete project objects. Each interface action is translated into file structure modifications or queries that are issued via the ComClass. The class diagram and interface view of an example file tree are shown below.

The classes within the File Tree Management system component provide for additional functionality in addition to those already existing within the JTree class. These additions include customized tree icons that serve to represent the current status of each object (ProjectType class), drop and drag functionality (DndTree class) and real-time synchronization (HierarachyThread class) with the Boardroom server structure.

31

To populate the file tree, the project directory is pulled from the Boardroom server and translated into DefaultMutableTreeNodes that are further extended in the ProjectType class. Instances of this extended class retain data on the type and status of the server object it represents. By defining tree node objects as a project, folder or file, a stronger organizational structure can be created simulating a typical operating system file system. Additionally for editable files, by referencing the header field of the file which stores metadata, the ProjectType instance can be utilized to show different status icons for instance when a file is being edited by another user or is currently locked. The DndTree class invokes listener classes that respond to when users initiate a drag action on a project file, when a file is dragged over another file, and when a drag is ended or dropped on a target file. By referencing the type of each ProjectType node object, the listeners can ensure valid object movement restrictions such as files only being able to be dropped on folders and not on other files (representing file moves). For instance, by comparing the type of a dragged object to the type of the node it is hovered over, a highlighting effect can be called to show that a drop at this target spot would be valid or not. Since these conflict checks are conducted within the applet, this ensures that no invalid structure modifications will be passed on to the Boardroom server. When a file-type node is also double clicked, a Text Editor window is also opened in the Graphing Panel of the main working GUI which functionality will be described in the next component section. A user may open as many text windows they would like corresponding to the project files listed on the server. Since Boardroom is a multi-user application, an updated view of the projects file tree structure must be presented in order to ensure that invalid modifications are not issued as to avoid synchronization conflicts. To accomplish this, the Hierarchy Panel has a HierarchyThread class thread running that pulls the latest file structure from the Boardroom server three times a second. Therefore if another user updates the file structure, these changes will be updated within the file tree quickly, as to prevent unsynchronized views. At the bottom of the Hierarchy Panel are four interface buttons used for creating new folders, files (blank or loaded from the users local drive) and to delete tree objects. The current user selection on the file tree is utilized to specify the target of each action. Therefore files and folders will be created at the location of the selection, while the selected object will be targeted for deletion by the delete button. Name conflict checks are implemented within the HierarchyPanel class to prevent folders from having duplicate names or files within the same folder from have the same name so that there are no corresponding errors generated on the Boardroom server.

32

3.3.4 Document Editing Management The crux of the Boardroom application is to provide a means of editing text documents in a collaborative online environment. With the possibility of multiple users accessing a file at once, mechanisms for editing synchronization are carefully implemented within the document editing system components. Boardroom allows only a single user to modify a document at a time, but an unlimited number of users may view the document as it is being modified, and they will see any modifications occur in real time. A screenshot of the text editor window is provided below.

The early prototypes of BoardRoom stored a file as a block of text in the same way SimpleText handles a document. This however was an inefficient way to handle documents. In order for changes to a document to be seen by other users in real time the revised text of the document must be sent back to the file each time the editing user makes a keystroke. After the update all users viewing the document must reload the contents of the file. This means that for a ten page document ten pages must be transferred to or from the server by each user viewing or editing the document each time the editing user changes a character. This causes delay for users with slow Internet connection, slows down the server, and eats up the servers bandwidth limit. The solution to this problem was to implement Boardrooms as a sequence of instructions rather than plain text. When a user is modifying a document new instructions are appended to the document instead of completely rewriting the document, and users viewing the document load these new instructions rather than downloading the entire document. These instructions describe a document be recording a history of insertions of text and deletions of text. The class diagram for this system component is shown below.

33

In the diagram ProjectType is the documents container. A ProjectType element is a representation of the file which can be viewed from the project hierarchy and provides a link to a file on the server. When the user opens a file by double clicking on the ProjectType context the ProjectType will spawn a TextEditorWindow and place it in the GraphMaserWindow. The TextEditorWindow will create an instance of InstructionSequence, which is a class used to convert the sequence of instructions stored in the file into a block of text. An InstructionSequence holds an array of FileInstruction objects, which hold the actual data of the instruction. A TextEditorWindow will also create an instance of the class InstructionHandler and link it to its text field. An InstructionHandler is a KeyStroke listener that turns the users typing into new instructions and writes them to the servers file so that everyone can see them. There is a double link between every TextEditorWindow and the ProjectType which created it. ProjectTypes store pointers to the TextEditorWindows they created, and TextEditorWindows store pointers to the ProjectType that created them. When a projectType is asked to instantiate a window it checks if its pointer to a TextEditorWindow is null. If the pointer is null a new TextEditorWindow is genarated, otherwise the TextEditorWindow which is already open is brought to the front. The link from the ProjectType to Texteditor window also allows

34

ProjectTypes to change the text of the EditorWindow if the EditorWindow is being used to view a document which is updating. The link allows a TextEditorWindow to interact with the servers file through the ProjectType instead of accessing ComClass directly when the TextEditorWindow is being used to modify a document. The advantage of this is that if a TextEditorWindow held its own link to the servers file and that file was moved or renamed an error would occur. The hierarchy thread keeps ProjectTypes in the project pointed at the files which they represent when the files are moved or renamed, so by linking a TextEditorWindow to a file through the files ProjectType the link will not be broken if the file is renamed or moved. Each editable document consists of two parts: a header containing metadata and a body containing encoded instructions. The header stores information on who is currently editing the document if any. This is the mechanism that prevents multiple users from editing a document at the same time. The format of the bodys encoded instructions is shown in the table below.

Instruction Insert Delete Save Undefined

Description Records text insertions. Records text deletions. Records save calls. Unknown instructions.

Format I * User Name * Insert Index * Inserted Text * D * User Name * Start Index * End Index * S * User Name * Server Timestamp * N/A

In the above table, the * character represents non-printing characters which are used to separate the variables in an instruction when the instruction is written to a file. If printing characters were used it would be possible for the Inserted text of the insert command to contain one of these characters, which would confuse the interpreter. An undefined instruction is a special definition, which is used internally by the FileInstruction class and never written to a file. An example of how a sequence of these instructions can be used to generate a block of text is shown in the diagram below.

35

An explanation on how these instructions are generated during editing and interpreted while viewing the document is followed. When a text editor window is opened for a document, the body of the document is parsed into separate instructions as represented by instances of the FileInstruction class. These instructions are further aggregated into an InstructionSequence class instance. These instructions are then interpreted and converted into a corresponding text string, which is loaded into the text area field of the text editor window. Therefore, even though the document consists of encoded instructions of previous text insertions and deletions, the user will only see a constructed plaintext representation. The text editors text area field has an extension of a documentListener called InstructionHandler listening to it. If a user makes changes within the text area field (only allowable if they are in edit mode), the listener will fire an event that will trigger the InstructionHandler to generate a new FileInstruction instance recording of the change (insertion or removal). New FileInstruction are appended to the servers instruction-encoded document. For users that are viewing the document, changes made by the editing user will cause updates to the text in their TextEditorWindows and is initiated by the HierarchyThread. The following figure shows the sequence of instructions, which the HierarchyThread uses to perform these updates. The Hierarchy thread also

36

keeps the contents of the HierarchyPanel up to date, but these steps have been omitted from the diagram.

The argument to check if a file is being viewed is done be seeing if the ProjectType which represents the file is linked to a TextEditorWindow and if that TextEditorWindow is in view mode. It is possible to check if a file has been modified because ComClass allows the applet to check the date of the most recent modification to a file. When a files modification date is observed to increase the file is known to have modified. The Comclass provides a method which extracts a specific range of bytes from a text file as well as a method, which returns the number of bytes in a file. When a modification is detected it is possible to load only the new instruction by asking ComClass to return the bytes from the end of the file, which make up the difference in the length of the file. A diagram of how a ProjectType, HierarchyThread, and the components of a TextEditorWindow are used to transfer instructions from an editing user to viewing users is illustrated below.

37

3.3.4.1 Text Editor Features Above the main text editor field is a set of button, which provide functionality to the text editor. Some of these are standard save, cut, copy and paste functions which are present in all modern text editors and some provide functionality unique to Boardroom.

The buttons are represented by icons, and a text description of the button appears when the user moves their mouse over them. A description of the functions of the buttons follows: Enter view mode Enter edit mode

To prevent conflicts between users editing the same document at the same time, Boardroom uses the header of each document to record if the file is being edited, and which user is editing the file if that is true. If the user enters into a text editor for a file that is currently not being edited, they can enter edit mode at any time by selecting the Enter edit mode button. Once the user has entered edit mode they are

38

free to modify the document, and they may release control of the document by pressing the Enter view mode button. The Enter edit mode button and Enter view mode button are enabled and disabled by the status of the file. The Enter edit mode button will only be enabled if the document is not already being edited by the current user, or any other users of the system. The Enter view mode button is only enabled if the file is in edit mode, and the present user is the files designated editor. A timer monitors the amount of time that an editing user is inactive (not making changes), and if five minutes progresses without a change, the system forces the current editor to release control of the document. This forced release can occur while the editing users computer is not connected to the Boardroom server, so a file will not remain uneditable if a user disconnects unexpectedly without releasing the file. The remaining time until a user is forced to release control of a document is displayed on the TextEditors button bar. Lock File Unlock File

These buttons instruct the server to add or remove a lock on a file. When a file is locked no user is permitted to modify the files text, move the file, rename the file, or delete the file. This is different from the edit and view modes because a locked file is completely inaccessible to all users including the one who decided to lock it. Additionally any user can unlock a file even if they are not the one who locked it. The purpose of the lock and unlock buttons is to allow users to prevent important files from being deleted. The edit file button is disabled if a file is in lock mode. The unlock and lock buttons are enabled and disabled to allow the user to view the locked status of a file. The Lock file button will be enabled and the unlock button will be disabled if the file is currently unlocked, and vice versa if the file is locked. Undo Redo

Undo and redo functions are common features of document editor programs. These buttons are only enabled if the text editor is in edit mode. These buttons operate by undoing or redoing the instructions, which are stored in the files instruction sequence. Cut Copy Paste

Cut, copy, and paste are standard features of text editors. These buttons move the text which the user has selected to the Operating Systems clipboard and move the contents of the clipboard into the text field. By using the Operating Systems Clipboard it is possible to copy and paste text from a boardroom document into another program such as notepad. The cut-copy-paste functions can also be called

39

by using the standard control-x, control-c, control-v button commands. The Copy button is enabled all of the time, but the cut and paste buttons are only enabled if the TextEditorWindow is in editing mode because they cause a change to the contents of the file. Make copy of file on local computer Boardroom stores its files on the server, and can be set up to keep a copy of the entire contents of a project in specified directory on the users computer automatically. In addition to these functions the user can quickly save a single file to their own computer by pressing this button. When pressed a save file dialog box appears asking the user to specify where they would like to save the file to. The resulting text file is not the instruction sequence which is stored on the server, but the resulting text produced by processing the sequence of instructions. Save File A user never truly needs to save a file because the file is updated during typing. However computer literate individuals are not accustomed to this model and feel more secure with the open-save-close model of Notepad, Microsoft Office, and others. To provide a better user experience it was necessary to hide the text editors instruction sequence model behind the mask of an open-save-close model. The save instruction acts as a placeholder in the sequence of instructions. The save button, will inserts a save placeholder into the end of the files instruction sequence. When a user closes a TextEditorWindow a check is made to see if new commands have been added to the instruction sequence since the last save placeholder was placed in the sequence. If new unsaved instructions exist the GUI will ask the user if they would like to save the changes to the document before closing it. If the user chooses not to save the changes the system will remove all commands in the sequences that succeed the most recent save instruction. If the user chooses to save a document before closing it a new save instruction is added to the end of the documents instruction sequence. Revert file to previous save state Document editor programs also typically provide a revert feature which permanently undoes any changes made to a document since the last time the user chose to save it. Boardroom implements this feature through a button in the text editor, which allows the user to remove any instructions in the files instruction sequence that succeeds the most recent save command. View the history of this file

40

The instruction sequence of a file grows as the users keystrokes generate new instructions. By progressing backwards in the instruction sequence it is possible to see the file as it existed at points in history. Boardroom allows its users to view a files text at these points in history, and revert a file to these points if they so choose. It is possible to find the contents of a file at any points in history, but to make the users experience less confusing the GUI only allows the user to see the contents of the file at the points in history marked by the save placeholders. The information which is stored in a save placeholder is the name of the user who issued the save command and the server date at the time of the command. This information is shown to the user to assist in decisive thinking. In the text editor there is a button called History. When activated this button brings up a view of the files history in a separate window. The window is shown below.

On the left of the window is a table displaying the dates of the save commands, and which user issued the commands. This table is generated by reading the contents of all save placeholders within a files instruction sequence. When the user selects a row of the table, the files instruction sequence moves to the position of the selected save placeholder. The text generated by this operation is placed in the text box on the right side of the window. All users can open the history window at any time because it is primarily used for observing a file not editing it. The history window does contain a revert button, which is only enabled if the user has placed the file into edit mode. When the revert button is pressed the user is asked to confirm the operation. The revert operation erases all instructions in the files instruction sequence which proceed the save placeholder which the user has selected. The result of this operation is that the file becomes permanently as it was at the point in history selected by the user. It is not possible to revert a file forwards in time to placeholders which were made after the revert point because these are erased along with all other instructions proceeding the revert point.

41

3.4 Chat Management

Whenever a user enters into a project, the bottom-right chat panel will house a chat session that will allow all users currently participating in the project to communicate with each other. In addition to seeing messages from other users, a list of all online and participating project users is also shown. This feature is implemented through the Chat class, which is initiated whenever a new project is entered, in coordination with the projects chat file on the Boardroom server through the use of the ComClass. The class diagram and interface for this system component is shown below.

Each project has a chat text file within the projects folder on the Boardroom server. This file is used for storing all chat messages sent through the application. Each time a user submits a message, the message will be appended to the end of this chat text file. The Chat class implements an Updater class thread that will check for changes in length of the chat file and if a change is detected, it will load the newly appeared bytes into the chat message box. To provide a mechanism for viewing who else is currently participating in the project session, a Whos Online box displays the currently active project users. This is feature is implemented through the use of an OnlineStatus folder within each project folder. Whenever a user enters into a project, the Chat class will create a blank file with their name on it and place it into the OnlineStatus folder. If the user leaves the project, this generated file will automatically be deleted. While the

42

user is participating within the project, the implemented Updater class thread will modify the users generated file every four minutes resulting in an update of the files modification date. To generate the list of online users, the Chat class will read the contents of the OnlineStatus folder for which users files have been modified within the last five minutes and display the corresponding users. The required within-five minute modification check is implemented to provide a mechanism for handling users that may have unexpectedly disconnected from Boardroom without exiting the project normally. In this scenario, the user will no longer have a thread issuing update commands to the users generated file in OnlineStatus and so the users file will be ignored after five minutes and they will no longer appear in the Whos Online display box.

43

4 Testing
4.1 Overview
This initial test plan documents the scope of test coverage, test strategy, test cases, test results, resource requirements, and features to be tested for the Boardroom. The document is produced on the basis of assuring quality and robustness of Boardroom and planning and executing testing approaches the project team has taken. Test cases with conditions are introduced and expected results are documented, along with actual results. The QA team will use this document to help validate the quality of the product iteratively throughout the project phases until release. Related Documents Requirements Document Architecture Document

4.2 Resources
4.2.1 Human There are two QA managers in our team, Ryan Barr and Andrei Horga. Every member is expected to test his own developed code and report, document any bug found or fixed. 4.2.2 Hardware Any stand-alone PC, Mac or Linux system is required for environment set up and initial phase of testing. A web server and reliable connection to the web server is required to examine interactive data between Boardroom and the web storage.

4.3 Software
Manual white-box testing demands Boardroom being properly run on all browsers enabled by Java Runtime Environment version 1.6 and up. Modern OSs such as Windows XP+, Mac O/S 9+, Ubuntu 7+ have all been tested to be acceptable for use, and any other modern OS supporting Java and web browsing should work. Functional testing in the forms of unit and UI testing will be carried out in Eclipse debug perspective. JUnit was initially recommended to assert each test case with expected result. However, due to time constraints, manual testing was conducted instead. 44

4.4 Scope and Testing Approach

Our testing scope will include Unit Testing, Component Testing, and Acceptance testing. JUnit The Quality Assurance analysts of our pod looked into integrating JUnit into our project Test Plan. The initial plan was to use JUnit to quickly run some of critical tests that should be checked often, and which require immediate fixing. We also hoped to use JUnit to automate some of our testing. In particular, create multiple users, projects, folders and files. However, due to time constraints and lack of any experience with JUnit, the team mutually agreed to test Boardroom manually for the tasks described above. SVN We are using SVN for revision control of not only all our code, but also our reports. Moreover, we have implemented SVN policies that have helped our development a great deal. First, everyone must update their code before committing any changes. Once updated, the program is run one more time and some simple tests, as described in our test case section, to ensure that program is still working properly. Only until this is verified can anyone commit their changes. This ensures that our program is always running, and always testable.

4.5 Unit Testing (Functional and UI)

The Unit testing attempted to cover all functional units that make up the source room code. As such, we created the following test cases. These were all run manually. The Actual Outcome has been added to this revised version of the Test Plan.
Login / Registration Summary: Create a new user account. 1. Start Boardroom 2. Select Register. 3. Enter a valid user name and password. 4. Select Submit. Expected Outcome: You're logged in with the appropriate user name. Actual Outcome: Youre logged in with the appropriate user name, the control panel pops up afterwards. Summary: Login to user account 1. Start Boardroom 3. Enter a valid user name and password. 4. Select Login. Expected Outcome: You're logged in with the appropriate user name.

45

Actual Outcome: You're logged in with the appropriate user name, and the control panel pops up. Summary: Verify that password and user name error checking is working. 1. Start Boardroom. 2. Select Register. 3. Leave either or both user name and password blank. 4. Select Submit. 5. Expected and Actual Outcome: Error appears saying This is not a valid username or password 6. Enter a valid user name. 7. Enter two valid passwords, but make them different. 8. Select Submit. 9. Expected and Actual Outcome: Error appears saying You have mistyped your password 10. Make the passwords the same, but put a space in either the user name or password. 11. Select Submit. 12. Expected and Actual Outcome: Error message appears saying that No spaces allowed in password. 13. Replace all the spaces with '/' characters. 14. Select Submit. 15. Expected and Actual Outcome: Error message appears saying Cannot use special character / in your username or password 16. Remove the '/' characters. 17. Select Submit. Expected Outcome: You're logged in with the appropriate user name. Actual Outcome: Youre logged in, and the control panel opens Summary: Verify that only unique user names can be used. 1. Start Boardroom. 2. Select Registration. 3. Create a new user, and be sure to remember the name. 4. Select Submit. 5. Quit Boardroom. 6. Start Boardroom. 7. Select Registration. 8. Enter a valid password, but enter the same user name as before. 9. Select Submit. Expected Outcome: User is informed that the user name is already in use. Actual Outcome: An error message stating This user already exists is shown. Summary: Change passwords 1. Start Boardroom 2. Log in 3. Open a project. 4. Click on My Account Settings. 5. Change your password and hit confirm. 6. Log out. 7. Log back in with new password and same user. Expected Result: You will successfully log in with the new password.

46

Actual Result: You cannot log in with the new password. The old password still works though. MUST FIX

Chat Summary: Log into a project chat room. 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel. Expected Outcome: User is logged into the chat server with user name and project name. a list of Whos Online is also displayed. Actual Outcome: User is logged into the chat server with user name and project name, a list of Whos Online is also displayed. Summary: Send a message to other users that are logged into the same project chat room. 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel. 4. Enter text into the chat window. 5. Click the send button or hit the enter key. Expected Outcome: The message is displayed in the sending user's chat window as well as in the chat windows of all other users that are currently logged into the same project chat room. Actual Outcome: The message is displayed in the sending user's chat window as well as in the chat windows of all other users that are currently logged into the same project chat room. Summary: Log out of a project chat room. 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel. 4. Perform random operations such as creating new documents. 5. Close the current project (return to user control panel) by clicking Change Project. Expected Outcome: User is removed from the project chat room and logged out of the chat server. Actual Outcome: User is logged out of the chat server, and removed from the project chat room, however, the users chat room dialog box is not cleared until he or she joins a new project. Project Management Summary: Create a new project 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select New from the control panel. 4. Enter a valid project name, add members if desired, and choose a project manager. 5. Select Create. Expected Outcome: Project folder is created with the chosen project manager listed as project manager and the new project displayed in the control panel. Actual Outcome: Project folder is created with the chosen project manager listed as project manager and the new project displayed in the control panel.

47

Summary: Add new user members to project 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel (that user is project manager of) and open it 4. Open the Project Settings box from the top toolbar. 5. Add a user either manually or from a list. 6. Enter valid user name. Expected Outcome: Projects members list is updated with new user and the selected user now has access to the project directory and documents. Actual Outcome: Projects members list is updated with new user and the selected user now has access to the project directory and documents. Summary: Ensure that only project managers can manage project properties 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel (that user is not project manager of). 4. Open the Project Setting box and attempt to add a user. Expected Outcome: The User will not have access to add a user. Actual Outcome: The User does not have access to add a user. Summary: Verify that only unique project names are used. 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Create a new project with a unique project name. 4. Select Create. 5. Quit Boardroom. 6. Log into Boardroom with a previously created user account. 7. Create a new project. 8. Enter the same project name as in step 3. 9. Select Submit. Expected Outcome: User is notified that a project with the selected name has already been created. Actual Outcome: The user is given access to the previous project with the same name. The user that initially created the project no longer has access to it. Must FIX. Summary: Change project manager 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Select an existing project from the user control panel (that user is project manager of). 4. Open the Project Properties 5. Enter user name of new project manager in Project Manager field. 6. Hit update Expected Outcome: Projects members list is updated to show the new project manager, the previous project manager no longer has the ability to perform project management activities while the new project manager gains these abilities. Can be verified by using Ensure that only project managers can manage project properties test case.

48

Actual Outcome: Projects members list is updated to show the new project manager, the previous project manager no longer has the ability to perform project management activities while the new project manager gains these abilities. Document Editing Summary: Create and edit a new document. 1. Start Boardroom and enter any project. 2. Select Add Blank File, and give it a name 3. Open it, and hit edit document. 4. Start typing. 5. Save and click on view file. 6.Close the file and open it again. Expected Outcome: The new document was created and has the appropriate data as entered in step 4. Actual Outcome: The new document was created and has the appropriate data as entered in step 4. Summary: Create a new folder. 1. Start Boardroom and enter any project. 2. Select New Folder to create a folder. 3. Give it a name Expected Outcome: A new folder has been created for the project with the given name. Actual Outcome: A new folder has been created for the project with the given name. Summary: Editing an unlocked document. 1. Start Boardroom and enter any project. 2. Select any file, and see if it is locked. 3. If not, select Edit File 4. Edit the file. 5. Save your change and hit View File to unlock the file. Expected Outcome: The changes were saved, and now anyone else can edit the file. Actual Outcome: The changes were saved, and now anyone else can edit the file. Summary: Try and edit a locked document. 1. Start Boardroom and enter any project. 2. Have another user select and lock a document in the same project. 3. Select the same document. 4. Try to lock and edit the document. Expected Outcome: You cannot edit the file, until the other user releases it. Actual Outcome: You cannot edit the file, until the other user releases it. Summary: Exiting Boardroom. 1. Start Boardroom and enter any project. 2. Make some changes to one or more documents. 3. Save the files locally by clicking Make a Local Copy 4. Choose where to save the files on your harddrive. 5. Quit Boardroom. 6. Check your hard drive and locate the files (details TBD) Expected Outcome: User has the latest version of all the project files on their computer Actual Outcome: Not implemented yet. Must FIX.

49

4.6 Group Testing

Group testing was done manually, by having real users working on the same project at the same time. JUnit or any other automation software was not used for group testing. Below are some group-specific test cases.
Summary: Live editing 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Open a project and a specific source document in the project. The first person to open a source document obtains the Lock. 4. Have other users open the same document. 5. Start editing the document Expected Outcome: The other users can see the edits you make, in real time, letter by letter. Actual Outcome: The other users do not see the edits made in real time, unless the initial user editing the file saves it, unlocks its, and closes it, and the other users close and reopen the file. Must FIX. Summary: User requests Lock 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Open a project and a specific source document in the project. The first person to open a source document obtains the Lock. 4. Have other users open the same document. 5. Have a user request the Lock from you. 6. A popup stating User X has requested the key for document Y in Project Z with two options, Accept and Decline appears to the user with the Lock. 7. The user with the lock clicks Accept Expected Outcome: The Lock is passed on to User X, he now has access to edit the source document, while everyone else in the project does not. The document is also automatically saved to the server. Actual Outcome: THIS FEATURE HAS BEEN REMOVED. Summary: User with lock drops out 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Open a project and a specific source document in the project. The first person to open a source document obtains the Lock. 4. Have other users open the same document. 5. Start editing the document. 6. Crash Boardroom, or pull the plug on your modem. Expected Outcome: The source file is unlocked, and any edits that were not manually saved to the server are lost. Actual Outcome: NOT TESTED. Summary: User with lock quits Boardroom or exits the project 1. Start Boardroom. 2. Log into Boardroom with a previously created user account. 3. Open a project and a specific source document in the project. The first person to open a source document obtains the Lock.

50

4. Have other users open the same document. 5. Start editing the document. 6. Quit Boardroom, or exit the project Expected Outcome: The source file is automatically saved to the server, and the source file becomes unlocked. Actual Outcome: NOT TESTED. It should, however, release the key. User Control Panel Summary: Switch to a project via control panel perspective 1. Start Boardroom. 2. User logs in successfully. 3. User selects Change Project button to change current project. 4. Control panel pops up and user sees a list of associated projects currently available. 5. User opens a different project. Expected Outcome: User finds and chooses the intended project; the project and all associated items are loaded onto the main interface. Actual Outcome: User finds and chooses the intended project; the project and all associated items are loaded onto the main interface. Summary: Log in as a separate user via control panel perspective. 1. Start Boardroom. 2. User logs in successfully. 3. User selects Logout button to sign in with a different account. 4.Login panel pops up and prompts user for username and password inputs. 5. Inputs confirmed. Expected Outcome: User automatically logs off previous account securely as in a normal instance. A separate account is signed into the system. The Control Panel opens with a list of the users projects. Actual Outcome: User automatically logs off previous account securely as in a normal instance. A separate account is signed into the system. The Control Panel opens with a list of the users projects. Summary: Log out via control panel perspective. 1. Start Boardroom. 2. User logs in successfully. 3. User selects to log out via control panel pop-up. Expected: User logs out securely. Actual Outcome: User logs out securely.

4.7 Component Testing

As there are only two components to Boardroom, the Applet and the chat program, component testing dealt with just these two. The chat box is tied to a project and user. When testing the chat inside a project, as listed in the above test cases, the chat worked as required, other than some temporary lag updating Whos Online. The user could also use the Applet at the same time as the chat, making changes to text

51

files or creating folders, while still seeing the real time chat associated with that project.

4.8 Acceptance Testing

Acceptance testing by us will be done via the test cases already noted in Unit Testing. As there are no real clients for our program, we implemented client acceptance testing by asking our friends to try out the program. So far, the response from our friends has been good, but there have been complaints that there are no usual menus on the top bar, such as File, Edit, and Help. We would like to implement such a menu in the future, but for the present we do not have enough time to do so. Acceptance testing will also be (done to an extent) by the Professor and T.A. when assessing Boardroom.

4.9 Features Not to be Tested

Component testing with the chat component, and testing of a live group edit of a document have now been done. There are no outstanding features not to be tested.

4.10 Testing Progress

Testing has been ongoing since the very beginning. For example, or servlet code has an applet interface that we can use to check the file structure and file contents on the server. Lately, testing has focused on group simulations of what can actually occur with in real life with multiple users. Some of our expected outcomes were not our actual outcomes, and this is a concern that has to be dealt with before the final demonstration. Bugs have been found, some have been fixed, and some have yet to be fixed.

4.11 Issues, Risks and Assumptions

One of our design assumptions is that since users create private projects and invite users, we are assuming that users will work together. In particular, that they will not try and do any harm to the project or other users. We feel this is a safe assumption, as Boardroom is designed to help people work together, who have relationships (professional or personal) outside of Boardroom. Moreover, any issues that might arise in Boardroom can potentially be handled by users through the chat feature. Finally, in the case where a user disconnects without the server knowing, any documents they have locked will timeout and be freed again.

52

The major risks we were concerned about are that issues around saving data to the users local drive, and keeping the server synchronized with multiple users simultaneously. Fortunately, we have a strong foundation from which Boardroom is built upon, and we have implemented both local and server saving to an extend were happy with. We were also initially concerned with a lack of a reliable server, but this issue has been fixed by having one of Ryans computers converted into a full-time server. There are no outstanding issues at this time, Boardroom is up and running and progressing smoothly.

4.12 Signoff
Ryan Barr, 40184053 Andrei Horga, 60593043 Stanley Shang, 24491037 Robin Roy, 33699059 Timotius Margo, 75112045 Russell Kramer, 29685054 Chris Pang, 16212037

53

5 Human Resources
In this section we will describe how we worked as a team to develop Boardroom and how we setup our pod. Our pod consisted of seven members, fortunately all of whom were present from the beginning to the end of the term.

5.1 Team Organization

While everyone was encouraged to share the work as much as possible, we all accepted primary responsibilities at the beginning of the project. Moreover, as the term progressed we each found our own areas of expertise and authority. Chris Pang - Project Manager Along with helping with the rest of the project, Chris was in charge of handling assignment submissions. This included printing, binding and handing in the hard copies of our assignments. Robin Roy - Analyst Robin was essential in keeping our group focused and organized. Moreover, as the pod's analyst Robin kept abreast of how the project was progressing and would make sure that we were on course to meet our requirements and use cases. Robin also wrote the initial RMI based chat system. Timotius Margo - Designer Tim was in charge of the Graphic User Interface and the Human Computer Interaction. This also entailed finding open source graphics for our buttons and backgrounds. Russell Kramer - Developer Russell was the cornerstone of our project, providing critical technical information throughout the project. He also developed the Servlet and Applet that formed the foundation of Boardroom. With Russell's technical direction Boardroom development went very smoothly. Russell also implemented the third and final version of the Boardroom chat system. Stanley Shang - Configuration Manager Stanley helped Chris and Dan develop the Project classes.

Andrei Horga - Quality Assurance Andrei helped to write test cases and to organize testing of Boardroom. Andrei also worked on the Project Manager class and on the assorted documentation.

54

Ryan Barr - Testing Ryan helped with organizing the pod for meetings, testing sessions and completing assignments. He also wrote the second implementation of the Chat system, using Sockets, and code for creating and logging in users into Boardroom.

5.2 Workload Distribution

Below is our bar chart showing individual time spent working on Boardroom.

Hours Spent Working on Boardroom

Ryan

Robin

Tim
Documentation Programming Meeting

Chris

Stanley

Dan

Russell

50

100

150

200

250

300

350

400

55

Appendix A - Individual Timesheets

Member Ryan Barr Hours Prgm Doc Member Stanley Shang Hours Prgm Doc 1.00 0.50 1.50 0.50 1.00 1.00 3.00 1.50 2.50 4.00 16.50

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall Member

Mtg 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 3.00 12.00

2.00 2.00 6.00 2.00 5.00 3.00 9.00 29.00

2.00 2.00 3.00 2.00 2.00 2.00 2.00 2.00 2.00 4.00 23.00

Total 0.00 1.00 1.00 3.00 5.00 6.00 2.00 9.00 5.00 8.00 2.00 6.00 16.00 64.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall Member

Mtg 1.00 2.00 2.00 1.00 0.00 0.00 1.00 1.00 1.00 1.00 2.00 12.00

1.00 2.00 1.00 2.00 4.00 3.50 2.50 1.00 17.00

Total 0.00 2.00 2.00 2.50 3.50 2.50 2.00 4.00 5.00 6.50 5.00 4.50 6.00 45.50

Robin Roy Hours Prgm Doc

Andrei Horga Hours Prgm Doc 1.00 1.00 4.00 5.00 6.00 4.00 1.00 2.00 0.00 2.00 7.00 2.00 1.00 5.00 3.00 5.00 2.00 5.00 1.00 7.00 5.00 0.00 22.00 47.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall Member

Mtg

1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 3.00 13.00

1.00 2.00 4.00 1.00 3.00 1.00 4.00 16.00

1.00 2.00 3.00 1.00 2.00 2.00 4.00 4.00 5.00 9.00 33.00

Total 0.00 0.00 1.00 2.00 4.00 6.00 6.00 4.00 3.00 8.00 6.00 10.00 12.00 62.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall Member

Mtg 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 12.00

Total 2.00 5.00 6.00 7.00 6.00 3.00 10.00 4.00 6.00 9.00 8.00 9.00 6.00 81.00

Timotius Margo Hours Prgm Doc

Russell Kramer Hours Prgm Doc 25.00 30.00 20.00 20.00 20.00 20.00 15.00 15.00 20.00 25.00 5.00 25.00 10.00 30.00 20.00 40.00 20.00 305.00 55.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall

Mtg 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 3.00 12.00

9.00 2.00 3.00 3.00 2.00 7.00 1.00 7.00 5.00 23.00

16.00

Total 0.00 1.00 1.00 10.00 2.00 4.00 4.00 2.00 8.00 2.00 1.00 8.00 8.00 51.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall

Mtg 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 2.00 14.00

Total 26.00 31.00 21.00 21.00 21.00 21.00 16.00 16.00 21.00 31.00 36.00 51.00 62.00 374.00

56

Member

Christopher Pang Hours Prgm Doc

Member

Team Aggregate Hours Prgm Doc 26.00 1.00 30.00 5.00 20.00 5.00 20.00 19.00 28.00 11.50 31.00 7.00 26.00 12.00 31.00 7.50 37.00 10.00 45.50 22.00 32.50 23.00 39.00 46.50 54.00 49.00 420.00 218.50

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall

Mtg 1.00 1.00 1.00 2.00 1.00 1.00 1.00 1.00

1.00 3.00 4.00 5.00 2.00

1.00 2.00 12.00

15.00

0.50 3.00 0.50 1.00 1.50 1.00 3.00 0.50 3.00 7.00 21.00

Total 0.00 1.00 1.00 1.50 5.00 1.50 3.00 5.50 6.00 8.00 2.50 4.00 9.00 48.00

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 Overall

Mtg 1.00 6.00 8.00 8.00 7.00 6.00 5.00 6.00 7.00 5.00 5.00 7.00 16.00 87.00

Total 28.00 41.00 33.00 47.00 46.50 44.00 43.00 44.50 54.00 72.50 60.50 92.50 119.00 725.50

Mtg = Meeting / Prgm = Programming / Doc = Documentation

57

Appendix B Boardroom Box Design Overall View

Graphics Only View

58

Front Panel

59

Back Panel

60

Left Panel

Right Panel

61

Top Panel

Bottom Panel

62

Full Construction Layout

63

User Guide

64

Contents
3 Chapter 1: Getting Started 3 4 4 4 4 About the Boardroom Software System What You Need to Get Started Setting Up Boardroom Creating an Account Logging In

5 Chapter 2: Using the Control Panel 6 7 8 9 Creating a New Project Adding Users to a Project Open an Existing Project Logging Out

10 Chapter 3: Using the Project Editor 11 Managing Files and Folders Using the File Management Palette 14 Viewing Files 14 Editing Files Using the File Edit Palette 16 Chatting With Other Project Members 16 Viewing Project Settings 17 Changing Projects 17 Editing Your Profile 18 Copying Files to Your Local Computer 19 Chapter 4: Tips and Troubleshooting 19 19 20 20 21 Startup Account Maintenance and Security Project Management Project Files and Edits Boardroom Chat System

Getting Started
Congratulations on making the choice to use Boardroom! The following guide will help you get started and on your way to effective document management as soon as possible.

About Boardroom
In a world that increasingly demands teamwork in order to drive productive results, online collaboration is the only viable solution for many teams scattered across the globe. However, with todays common software applications, simple document collaboration can entail a chaotic exchange of emails, chat messages and un-versioned files. Teeing off this reality, Boardroom, a new multi-platform tool serves to bring order to its users online collaboration sessions. By integrating the features of a text editor, instant messenger and document management system into a single, cohesive program, Boardroom frees up desktop space and eliminates the need for cumbersome file exchanges. Boardroom is a web-based Java applet, maximizing cross platform compatibility, and allowing projects and documents to be available from anywhere in the world. Through organizing collaborations into team-owned Projects, Boardroom simulates a true conference room environment where multiple users can read and edit the same file in realtime. Editing access is shared amongst users in a controlled manner, allowing for conflictfree compositions. Brainstorming new ideas can also be easily facilitated using an integrated chat system designed to ensure that group editing session go smoothly. Our web server technology also ensures that users data is not lost and that editing sessions can be continued at a later date. By leveraging its features, users from all walks of life from students to business professionals will be better able to write and share documents. At its core, Boardroom delivers a seamless team environment so that users can simply focus on producing results. With Boardroom, you can: Create, edit and manage text documents from anywhere in the world Collaborate on a project with a number of users in different locations Secure and reliable storage of all of your important documents Integrated chat system for real-time communication with all of your team members Robust, user-friendly environment for maximum productivity Compatible with all modern computer platforms

What You Need to Get Started

Boardroom is compatible with all modern computer platforms. To begin using Boardroom, you will need: Pentium 3 1.2 GHz or equivalent PC Minimum 256 MB of RAM Windows 98, Windows ME, Windows 2000 (SP4+), Windows XP (SP1 SP2), Windows 2003, Windows Vista, Mac O/S 10, Solaris SPARC, Solaris x86, Red Hat Linux, SUSE Linux, JDS Broadband Internet Connection Internet Explorer 5.5+, Mozilla Firefox 1.4+ Java Runtime Environment 6.0 or later

Setting Up Boardroom
To set up Boardroom, simply ensure you have met the above requirements and enter the following URL into your web browser:

http:// 128.189.132.195

Creating a Boardroom Account

Upon visiting the Boardroom website, you will be met with the Boardroom sign-in window. If you have not used Boardroom before, you will need to register yourself and create an account. To create an account: button 1. Click the 2. Enter the user name and password that you have chosen, along with your email address (optional) in the appropriate fields. Be sure to choose a password that is you know is secure. 3. Click the button.

Note: The user name that you choose must be unique. If you enter a user name that is already taken, you will be prompted to choose another one.

Logging In to Boardroom
If you have already created a Boardroom account, simply enter your username and password and click the button to sign in.

Using the Control Panel

The Control Panel is where you can see all of the projects that you are currently involved with, select a project to work with, create new projects and add users to a project group. The following section will help you discover the Control Panel and its functions.

Creating a New Project

To create a new project, simply click on the New button in the control panel, (highlighted in red in the illustration below).

A new panel will appear, as shown in the following illustration. You must give your project a unique name, and select a Project Manager. A description is optional and can be seen when a user chooses to edit a specific project in the Control Panel. The addition and removal of users is described in the section below.

The project creator doesnt necessary have to be the Project Manager. If more than one user is associated with a project, the Project Manager can be changed by selecting a user from the drop down menu. Once the proper Project Settings have been configured, clicking on will create the required files on the Boardroom server.

Adding Users to a Project

Only Project Managers can add users to the project. Users can be added initially when creating a project, or later in time by clicking on the toolbar. Project Settings icon on the top

There are two ways of adding users to the project, will present you a list of all the current members signed up to Boardroom. Clicking on a name and then will add the user to the project. Make sure you then click Update clicking Properties to see the changes through. This is shown in the following illustration.

Alternatively if the user name is known, the Project Manager can simply click on and input the user name. The manager of a project can also remove users by highlighting the user and clicking .

Open an Existing Project

To open an existing project, simply select the project in the Control Panel and click . Only one project can be opened at any given time for a user. If youd like to switch projects, there is a Change Project icon on the top taskbar.

The Project view will now appear, which includes a hierarchal view of the project on the left hand side, opened text files on the right and the project Chat Panel on the bottom. New text files and folders can be created using the icons on the bottom of the hierarchal view.

Logging Out
A user may log out of his or her current account and into a different account at any time after opening a project by clicking on the Logout Icon on the top taskbar (highlighted in red below).

This will bring the user back to the Login screen, where they can re-enter Boardroom as another user.

If the user wishes to log out of the system entirely, the user should click the right corner of the program.

in the top

Using the Project Editor

The Project Editor is where you will get the job done! Here you can create, manage and edit all of the files and folders that are associated with a project. You can also collaborate in real-time with all of your other group members that are currently logged on.

Once a user has selected a project, they will enter into the Project Editor screen which provides features for managing project files, editing documents, chatting with other group members as well as additional user and project management tasks.

Only one Project Editor can be opened per user at any given time, and therefore users can only be participating in a single project at any point in time within the Boardroom server.

10

Managing Files and Folders

Each project within the Boardroom server can contain many different folders and files depending on the needs of the project members. Folders provide for additional organizational hierarchy within the project and can contain created documents as well as other folders in a nested manner. The files and folders associated with a project are managed using the File Management Palette located on the left side of the Project Editor screen.

Using the File Management Palette

Hierarchy Tree At the top of the Palette is a hierarchy tree representing the folders and files associated with the current project. By navigating this tree, you can move and rename files and folders as well trigger the opening of documents in the Editing Palette. While navigating the tree, the currently selected file or folder will be highlighted in light blue. This display updates automatically as other users create changes to the file structure within the project. The appearance of files changes to indicate their current status: Files that are locked show a lock: Files that are being edited show a pencil:

Resizing Dragging the resize bar left and right can change the width of File Management Palette. At the top of the resize bar there are two buttons, which allow the Palette to be quickly hidden, or quickly set to fill the screen. The minimize button is represented by a left pointing arrow and the maximize button is represented by a right pointing arrow.

11

Moving a File/Folder In order to move a file or folder, simply select the object you want to move and drag it to the location within the hierarchy tree where you want to move it. The object will then be moved on the Boardroom server and an updated view of the hierarchy tree will show the object at the new location. If a folder containing files is selected and moved, all files within the moved folder will also be moved. Renaming a File/Folder To rename a file or folder, simply select the object to be renamed until it is highlighted and then click the object once more. The objects name will turn into an editable text field. By editing this text field with the new name of the object and clicking the Enter, the objects name will then be renamed on the Boardroom server. Opening a Folder To expand the view of a folder within the hierarchy tree, simply double-click on the folder. To collapse the view of a folder, simply double-click on it again when it is in its expanded view. Opening a Document To open a project document for editing within the Editing Palette, simply double-click on the document to be opened. This will initiate the opening of the file within the Editing Palette. File Management Buttons Located at the bottom of the File Management Palette are four button used for creating and deleting folders and documents. The functionality and use of each of these buttons is described below. New Folder

In order to create a new folder within the projects hierarchy tree, click on the highlighted button above, a prompt for a folder name will appear. Simply enter in the name of the folder you would like to create, and press Enter. The folder will then appear in the hierarchy tree and can be used to help organize files or other folders.

12

 New File

To create a new blank document that can be edited, click on the highlighted button above, a prompt for the blank files name will appear. Enter in the name of the blank file you would like to create and then press Enter. The file will then appear in the hierarchy tree and is now ready for editing. The file will be blank upon opening it within the Editing Palette. Load File

If you have a file located on your local hard drive that you would like to upload to the Boardroom server for editing, you can do so using the highlighted button above. A dialog box will open up prompting you to select the file to be uploaded. After selecting the file to be uploaded, the file will be loaded into the projects directory on the Boardroom server and will be ready for editing. Delete Selection

If you would like to delete a folder or file within the project, you can use the button highlighted above. First select the object to be deleted within the hierarchy tree and then click on the highlighted button. The object will then be removed from the Boardroom server and the projects hierarchy tree view. Note: Files or folders deleted through this feature will be permanently deleted from the Boardroom server, so please ensure that you are willing to permanently delete the object before using this delete feature.

13

Viewing Files
When a document is opened it is in view mode by default. While in viewing mode it is not possible to alter the contents of a file, but changes other users make to the file appear as they are typed. To return to View Mode after editing a file use the button. (View Document)

Editing Files
Only one user may edit a document at a time. To enter edit mode press the (Edit Document) button on the File Edit Palette. This button will be disabled if another user is editing the document or if the file is locked. If another user is editing the document their name and remaining time is displayed to the far left of the document toolbar. Once you are in editing mode, the document editor window acts as a normal text editor with cut, copy and, paste capability. If no keystrokes are made in the text editor for a period of five minutes the document is automatically sent back to view mode, which allows other users to gain edit privileges. This is to prevent one user from dominating a file. The remaining time is displayed with the name of the editing user in the toolbars status field.

Using the File Edit Palette

Locking a Document The (Lock File) button puts a file into a special lock mode. When a file is locked it cannot be edited, cannot be moved, and cannot be deleted. Unlocking a Document The (Unlock File) button will return a locked file to unlocked status. The permission to unlock a file is available to all users of a project. Saving a Document to the Boardroom Server The (Save) button commits all new changes to the Boardroom server.

14

Copying a Document to Your Computer The (Make Local Copy) button will open a dialog box asking you to select a location on your home computer to save the file. Once a directory is selected a copy of the file will be sent to your home computer where it can be opened with a text editor such as Notepad. Using the Advanced Tools Boardroom provides a set of advanced text editing tools to make your experience more efficient. Cut: Capture the selected (highlighted) text to the clipboard and remove it from the file. Copy: Copy the selected (highlighted) text to the clipboard. Paste: Insert text that is stored in the clipboard. Undo: Restore the text to previous state. Redo: Cancel the undo operation (restore to the state before undo command). Note: The availability of these buttons depends on the state of the system. A button may become not available and not clickable when the corresponding feature or tool is not applicable. For example the locked. Lock File button is not available when the file is already

Button is available.

Button is unavailable.

15

Chatting with Other Project Members

Each project group has its own chat room within the Project Editor. The chat room is located on the bottom right of the Project Editor screen. The chat room provides functionality for sending messages to all currently logged in users of the project as well as the ability to view which members are currently logged in and to receive messages from them. A view of a project chat room is shown below with the chat session on the left hand side and the users currently logged into the project shown on the right hand side panel.

Messages from other users will automatically be received and shown within the chat session. To send messages to other users, simply enter in your message within the message dialog box highlighted in red above, and then click on the Send. Your message will then be broadcasted to all other members with the project session.

Viewing Project Settings

If you are the project manager of a project, you can edit the projects properties at any time. By selecting the highlighted button Project Settings above, which should be located on the top menu bar of the Project Editor, you will be presented with a Project Settings dialog box that will allow you to change the name, description and group members associated with the project. If you are not the project manager, you can still view the current project settings by clicking on the highlighted button. You will then be presented with a dialog box where you can view a read-only version of the projects properties.

16

Changing Projects

To change the project you are working on within the Project Editor, you can click on the highlighted Change Projects button above on the top menu bar of the Project Editor. Your session within the previous project group will be exited and you will be presented with the Control Panel as described in Section 2 where you can then select the next project you would like to work on.

Editing your Profile

Once logged into a Boardroom project, at any time you can edit your profile by selecting My Account Settings. A new window appears with various fields as depicted below.

The Edit Profile window allows you to edit your email address, change your password and edit your local copy save directory location. Any changes require you to re-enter your old password also. If changing your password, don't forget to enter it twice, to confirm and prevent mistyping the new password.

17

Copy Files to Your Local Computer

In order to copy the contents of the project folder you are currently working on to your local computer, select the Copy Files to Local Computer button while working within the Project Editor. If you have set a directory within your user profile to store local copies to, then copies of all files within the project folder will be saved to this location. If you have not set a directory for local saves, this button will not have any action.

18

Tips and Troubleshooting

Having some trouble? Not to worry! The following section will give you some suggestions for resolving many of the issues you might encounter while you are getting to know Boardroom.

Start Up
I typed in the URL in my browser. Nothing pops out and I believe I downloaded Java.

TIP: Boardroom runs on top of Java Applet technology. This requires the most updated version Java Runtime Environment (JRE) running in your Internet browser. Please refer to http://java.sun.com/j2se/1.4.2/download.html and ensure the latest update is applied.

I have followed the above tip. I see the Java loading panel pops up trying to load the application but the browser hangs in that frame. Why is this?

TIP: Boardroom enjoys its most controlled behavior on top of a high-speed Internet connection, however any connection speed should be adequate. In addition, the use of browsers like Internet Explorer and Mozilla Firefox is best suited for expected performance.

Account Maintenance and Security

I forgot my password. What do I do?

TIP: If you forgot your password. Please contact one of the system administrators for Boardroom. Your request for password lookup will be responded within two business days. If you would like to

19

I suspect that someone is using my account without my permission. I would like to close my account.

TIP: For concerns about malicious attacks, please contact one of the system administrators and we will reset your account information while guaranteeing your work and resources are preserved. If then you insist on cancelling your account, we will gladly do so.

Project Management
I tried adding a user to the project. How come hes not shown under the list of members?

TIP: Try to reload Boardroom and observe whether the member has reappeared in the list after the reload.

Project Files and Edits

There is a file residing in the project resource panel that does not open. Why is this?

TIP: Boardroom is a multi-user text-based editing/collaborating application. The files in Boardroom are expected to be text-based (ie. ASCII) extension files such as .txt, .rtf, .c, .java, etc. There remains no guarantee for the opening and working with other file formats within Boardroom.

I am editing multiple files at once and the application acts sluggish comparing to usual. How do I improve this without having to close the editing windows?

20

TIP: Boardroom welcomes multiple editing windows opened for edits as it is one of its dynamic features. One suggestion to improve your user experience under perhaps a slower Internet connection is to always minimize windows that are not currently being worked on. Minimized windows can be retrieved and brought back up anytime from the taskbar.

Boardroom Chat System

A user I suspect of not supposedly a member of our project group is in the chat as a bystander. What do I do?

TIP: Please inquire your project leader regarding the current list of members registered under the project. The project leader holds the authority to remove outside user from the project resources.

During a group chat, messages dont seem to be going through or being received on my end. Whats the problem?

TIP: First, make sure you are signed in to the project you have member privilege with. If you are indeed part of the project, please check whether you are connected on a stable, high-speed Internet connection (ie. DSL LAN). If the above are done yet the problem stays, try rebooting boardroom to allow your station to re-bind to the chat server.

21