The Collaborative Tool (CT) is a cross platform application designed to allow a number of people to collectively edit a set of documents stored in a centralized server. The CT is also designed to allow instant messaging between participants and to store these discussions for future reference. The program operation is analogous to a group of people working on a project and recording the minutes of their meetings.

1.1 Purpose of the System

The Collaborative Tool was proposed as a simple yet effective application for managing a collection of documents for collaborative editing by a group of people using various workstations running several different operating systems. In addition to collaborative editing, the CT will also provide instant messaging capabilities to participants to facilitate communication. As companies move away from a centralized business model, there is an increasing demand for software tools that can facilitate project management and communication among people who may work in many different geographical regions. By using the Collaborative Tool and a connection to the internet, these people will be able to hold meetings and edit a set of project documents from anywhere in the world. As transcripts of the discussions are captured automatically, meeting minutes are easy to record and conversations can be quickly recalled for review at any time.

1.2 Scope of the System

The CT is a cross platform document management system which encapsulates instant messaging and document editing capabilities.

The CT system will:

· Allow real time instant messaging among participants in a given project

· Store the text of any discussions of a given project in a transcript

· Allow real time editing of a document on a character by character basis

· Store a record of document changes as part of the transcript

· Manage concurrent active projects among multiple participants

· Limit access to a project to members of that project

· Allow creation and deletion of projects

· Allow addition of documents to a project

· Allow creation and deletion of participants

The CT system does NOT need to:

Interface with database management systems
Handle non-ASCII text documents
Maintain previous versions of documents
Delete user accounts
Delete documents

1.3 Objectives and Success Criteria

The system will meet its primary objectives if:

It is available for deployment in 3 months
It works effectively on all commercial window-capable operating systems
Editing is conducted in real-time character by character
Messaging is conducted in real time line by line
It accurately records the dialogue and document revision history in the transcript

The system will meet its secondary objectives if:

It is available for initial evaluation within 1 month
It is available for preliminary testing within 2 months
It handles multiple concurrent active sessions
The probability of failure is less than 1 in 10,000 sessions

1.4 Overview

The CT is a cross platform document management system which encapsulates instant messaging and document editing capabilities. The functional and non-functional requirements for this system are described in detail in section 2.1 and 2.2 respectively. Pseudo requirements are described in section 2.3.

Section 3 describes the system model. Section 3.1 provides the use case model and diagram for the system. The use cases are further described in the glossary following section 3. The object diagram and data dictionary are provided in section 3.2.

Appendix A, B and C describe the functional requirements of the components which the system will use in its final implementation. Appendix A describes the Asynchronous Multicast Communications Component, Appendix B, the Directory Component and Appendix C describes the Persistent Store Component.

Following the appendices are the minutes for our meetings along with a table showing the contributions by individual team members in regard to this deliverable including the time spent by each person.

2.0 Proposed System

Section 2.1 describes the core functional requirements arranged by the following topics:

Account Information – Requirements pertaining to the management of usernames, passwords, login notifications and maximum number of accounts
System Support – Specific system capacity and data types supported
Project Administration – Management of the projects, session activation, wait queues and dialogue control permission
Edit Control of Session Documents – Management of collaborative document editing and saving

Following this is a description of the responsibilities and abilities of the three actors in the system: Non-participant, Participant and Chair

Section 2.2 Describes the Non-functional requirements including such topics as Error Handling, User Interface, Hardware Considerations, Performance and Quality issues

Finally, Section 2.3 describes the pseudo requirements of the system including the platform on which it is intended, programming language to be used and introduces three components that will be used in the implementation. These are the Asynchronous Multicast Communication, Directory and Persistent Store Components

2.1 Functional Requirements

The functionality of the program can be mainly described according to the following four major components: system, non-participant, participant and chair.

System

The system is a passive actor in this program. It reacts or responds according to the actions of different actors. The following is a list of its functions:

Account Administration

The system shall support at least 5000 user accounts
The system shall create a new account for every new user
Check if the username a new non-participant requests has already been assigned to another participant

2.1 If the username has not been taken, the system should assign the username to the new non-participant

2.2 If the username has been taken, notify the non-participant to choose a different username

The system shall identify a participant by a username
The system should notify a participant of the status of any project(s) he/she is associated with after logging into the system. This includes all of the following:

If the participant is a member of at least one project, the system should provide a list of active and inactive projects that the participant belongs to
The system should provide a list of any documents and transcripts associated with a project
The system should notify a participant if there is any change (added/deleted) in the status of any associated projects

System support

The system shall support simple ASCII text characters
The system shall support multiple concurrent projects
The system shall support a maximum of 50 projects per participant

Project Administration

For each project, the system shall

Allow each project to have only one chair
Allow each project to have at least 100 participants including the chair
Allow each project to store at least 100 associated documents
Allow each project to store at least 100 transcripts
Place transcripts into a queue buffer of size = 60. The first transcript of a project has an index i = 0

10. The system shall initialize/open a new session when a participant creates or activates a project

The system shall allow multiple concurrent active sessions
The system shall allow participants of the project to join the session
During the discussion in a session, the system shall

Allow only one participant to have control of the dialogue at any time
Give the chair control of the dialogue initially
Queue the participants waiting for control of the dialogue in FIFO (First In First Out) order
Switch control of the dialogue to the first participant in the queue when the current controlling participant releases/gives up his/her turn
Allow the chair to pre-empt the queue and gain control of the dialogue at any time (i.e. the chair always has the highest priority)
Update the dialogue control waiting queue whenever a participant requests or releases a turn
Allow each participant in a discussion to see the on-going dialogue, along with an indication of the current speaker
Allow each participant in a discussion to view earlier parts of the current dialogue

Edit Control of Session Documents

For document editing, the system shall

Allow project participants to add documents to any active or inactive projects
Allow project participants to select or open a document in a project for collaborative editing
Allow only one participant to select and edit a shared document at any time. This participant is the current editor
Allow only one document at a time to be active for editing
Allow each participant in a session to see the current document being edited with an indication of the current editor
Allow the current editor to save the document at any time
Provide a waiting queue for participants to gain edit control
Switch edit control to the first participant in the waiting queue when the current editor releases/gives up his/her turn
Update the edit queue whenever a participant requests or releases a turn
Grant the chair edit control initially or whenever the waiting queue is empty
Allow the chair to pre-empt the waiting queue and gain control of editing at any time (i.e. the chair always has the highest priority)
Increment a document’s version number by one each time it is saved
Set the version number to be one when a new document is created and added to the project
Ask a participant if the document should be saved when it is made inactive and it has changed since it was last saved

The system should allow discussion and shared editing to run concurrently
The system should capture the session dialogue
The system should save the start time, end time, and the names of the documents edited during the session in the transcript
The system shall notify other participants when a participant joins/leaves a session
The system shall force all participants to leave a session when the chair leaves

Non-participant

A non-participant is anyone who has not logged into the system

A non-participant shall be able to create a username and password at login time
After obtaining a valid username and password, a non-participant shall be able to log into the system and become a participant from that moment

Participant

A participant is anyone who has already obtained a username and password for the system database and has successfully logged into the system. A participant shall be able to:

Be notified if he/she has been added or deleted from any of the projects, immediately after logging into the system
Be notified of any active projects in which he/she is a participant, immediately after logging into the System
Log out of the System
Get a list of projects in which he/she is a participant
Get a list of project documents
Join a session
Leave a session
Request edit control
Release edit control
Request dialogue control
Release dialogue control
Add a document
Edit a document
Save a document after editing
Inactivate a document
Input dialogue in a discussion
Create a project

Chair

The chair of a project is the participant who created that project. Besides having all the capabilities of a participant, a chair shall be able to:

Delete one or more of his/her own projects
Activate any of his/her own projects and initiate the session
Inactivate any of his/her own projects and close the session, forcing all the participants of the session to depart
Add participants to any of his/her own projects
Delete participants from any of his/her own projects
Gain dialogue control at any time
Move to the front of the waiting queues (editing and dialogue) at any time

2.2 Nonfunctional Requirements

2.2.1 User Interface and Human Requirements

Participants of projects can access the Collaborative Tool (CT) to engage in discussions and to edit project documents through any workstations that have the tool installed. The basic input devices for the tool are the workstation’s keyboard and mouse and the basic output device is the station’s monitor.

The CT requires all users to have basic computer knowledge. Since the users of the program are expected to be novice computer users, the program will have enough instructions in its GUI to provide a step-by-step guide to assist users through every operation and process.

The GUI is also responsible for disallowing any illegal inputs and operations that are applied to the program. It will display error messages if it detects illegal inputs from the user. It would also notify the user if failure occurs as the program is executing its operations.

2.2.2 Documentation

Several documentations are proposed for the CT. The following table lists these documents and their target users.

Document Name	Target Users
Requirements Elicitation Document (RED)	Developers and Clients
System Design Document	Developers
Design Rationale Document	Developers and Clients
Object Design Document	Developers
User Manual	Clients
Online Tutorial	Clients

The RED documents list all the requirements and operations that the clients would like the program to meet and accomplish.

The Design Rationale Document records the design decisions the developer made throughout the development of the program. The DRD also records the reasons behind these decisions

The System Design Document and Object Design Document record the implementation of the program. The SDD documents the overall design and architecture of the program, and the ODD discusses the design in terms of Object Orientated programming and classes.

The User Manual includes installation instructions, GUI and function descriptions, troubleshooting and FAQ. The manual is drafted in the initial phase of the design, and it must be completed before final deployment of the system. The tool will also offer online tutorials that outline some common scenarios and tasks.

2.2.3 Hardware Considerations

The minimal hardware requirement for the collaborative tool’s client is a workstation with a 500 MHz processor and 128 MB of RAM. The minimal requirement for the tool’s server is a workstation with a 1000MHz processor and 512 MB of RAM. Furthermore, a minimum of 100 MB hard disk space is required for installation of the CT client program. The minimum hard disk space for the CT server installation and data storage is 100 GB.

The tool also requires a broadband Internet/network connection for both the client and server. The minimum network bandwidth that is necessary for the client operations is 1.5Mbps. The server must have a network connection with minimum bandwidth of 45Mbps to ensure no networking lagging when it is handling multiple concurrent project sessions.

A keyboard, mouse and color monitor is also necessary for input and output purposes.

2.2.4 Performance Characteristics

The initiation of the CT client must be within 1 minute and the initiation of the CT server must be within 5 minutes under minimum hardware requirements.

The response time to the user’s inputs must be within 5 seconds under minimum hardware requirements.

The delay for a data packet sent over the network from one participant to all other participants in the session must be less than 10 seconds.

2.2.5 Error Handling and Extreme Conditions

The CT should be able to detect input syntax errors such as input of characters where numbers are expected. The tool should ignore the faulty inputs and generate error messages. The tool should be able to detect inputs that violate some preset constraints. For example, an attempt to edit a document without gaining the edit control should be prohibited. Appropriate error messages should be generated and displayed to the user in such cases.

The tool should be able to warn the users if errors occur when the system is saving documents to disk. When a disk error occurs during a document save, the participant who is in control of the document should be offered the option of saving the document onto the participant’s local computer. When a disk error occurs during a transcript save, the chair of the project should be offered the option of saving the transcript onto the chair’s local computer. The CT should be able to warn the users if any documents or transcripts are corrupted and data is unrecoverable.

A participant might lose the connection to a session due to network instability. When a participant loses the connection to a session, the tool should notify all other participants and treat the connection loss as a normal log out.

If the participant loses connection while he/she has dialogue control, control should be given to the next participant in the dialogue queue.

If the participant loses connection while he/she has the edit control and is editing a document, the chair should be given edit control so that he/she can decide whether the active document should be saved.

If the chair loses connection during a session, the participant with edit control will be prompted by the tool for permission to save the active document. The project will then become inactive.

2.2.6 Quality Issues

Program failures should be rare, providing that the computer’s operating system is stable. The order of system failure should be around once per 10000 sessions.

When a failure occurs, a log file is generated to provide diagnostic information to maintainers.

2.2.7 System Modification

The collaborative tool can offer a function, which allows all participants to download all inactive documents and transcripts to their local computers.

The tool can allow participants of a project to continue with their discussion even after the chair of the project leaves the session.

The tool can allow video conferencing in the session provided that all participants of that session are equipment with a web camera, microphone and speakers.

The chair can be given the right to remove any participant from a session and temporarily ban that participant from re-entering the session.

2.2.8 Security Issues

No one can log into the tool without a registered user name and corresponding password.

No other program except the Collaborative tool’s client can be used to log onto the tool’s server.

Some safeguard measures must be provided to protect the tool from DOS attacks and other hacking activities.

2.2.9 Resource Issues

The site at which the tool is located must be provided with a 110V power outlet and broadband internet/LAN connection.

2.3 Pseudo Requirements

The tool should be platform independent; meaning both the client and the server components can execute on any machine regardless of its operating systems. (Ex. Ms Windows, Unix, Linux, MacOS, etc)

To accomplish this, the CT will be developed in Java (JDK 1.3 or above). The object or use cases of the system will be done with Rational Rose.

Communication between participants in a session will be managed by an Asynchronous Multicast Communication Component (AMCC) which manages many separate communication channels. Messages sent on a given channel will be received by any participant listening on that channel.

A Database Management System (DBMS) cannot be used to manage the projects, participants and documents databases within the server. Therefore the CT can search for a specific item in its storage by using a hierarchical lookup service provided by its Directory Component. The Directory Component has a tree structure where each of its nodes can be used to store data and corresponding attributes. A participant can access data in a particular node by specifying a path to that node or by indicating the attribute associated with the data. The Directory Component will work with the AMCC by listening on channel 0 of the AMCC.

Items such as documents, transcripts, project and participant attributes are managed by the Persistent Store Component. The Persistent Store Component provides persistent storage capabilities for these items. Like the Directory Component, the Persistent Store Component is also listening on an AMCC channel. The CT can locate the Persistent Storage Component by using the Directory Component to search for an attribute named “persistentStore” in a node named “System”.

3.0 System Models

3.1 Use Case Model

A non-participant is a user who has not logged into the system. A non-participant may create a new account as indicated by the RequestUsernameAndPassword use case. A user who already has an account may log in as described in the LogIntoSystem use case. After a successful login, a non-participant is promoted to a participant as illustrated in the BecomeParticpant use case. After log in, a user receives notifications that are expressed in the following use cases: NotifyAddOrDeleteFromProjects, NotifyActiveProjects, which have <<include>> relationships with the LogIntoSystem use case.

A user can create a project and become the chair of the project as specified in the CreateProject and BecomeChairOfCreatedProject use cases. Several privileged operations can only be performed by a chair and are described below: ActivateProject which begins a session, InactivateProject which ends a session, AddParticipant and DeleteParticipant which manage the members in a project, and DeleteProject which deletes a project.

When logged in, a user can join a session as indicated in the JoinSession use case. Current participants of the session are notified by the NofityParticipants use case. During a session a user may request to speak or to edit a document as illustrated in the RequestTurn and RequestEditControl use cases. The chair of the project may also prioritize himself/herself in the waiting queue by invoking the MoveToFrontOfQueue and GainDialogControl use cases. A turn or an edit control is released in the ReleaseTurn and ReleaseEditControl use cases. Most of the above dialogue/edit control operations involve modifying the waiting queues; hence, it is appropriate to use the <<include>> and <<extend>> relationships to link them with the UpdateDialogQueue and UpdateEditQueue use cases to generalize these similar operations.

Document manipulations are described by the following use cases: AddDocument, EditDocument, SaveDocument, InactivateDocument, and UpdateVersion.

A user leaves a session by invoking the LeaveSession use case. When a chair leaves a session, the project is inactivated as expressed in the InactivateProject use case. All participants are forced to leave as indicated by the <<include>> relationship with the ForceParticipantDeparture use case. The session dialogue is captured and saved in a transcript in the SaveTranscript use case. An <<extend>> relationship with the SaveDocument use case also exists to prompt the chair to save any modified documents. A user can log off the system as illustrated by the LogOffSystem use case.

Figure 1 Use Case Diagram

Use case name	RequestUsernameAndPassword
Initiating actor	Invoked by Non-Participant
Participating actor	None
Entry condition	1. The system has been started.
Flow of events	2. The “Register” button is clicked. 3. A request username/password form is displayed. 4. The appropriate fields in the form are filled and the “Submit” button is clicked. 5. If the form passes the form verification tests, a message is displayed indicating the request is successful. The system returns to the log in menu. 6. If the form fails the form verification tests, a message indicating the cause of the failure is displayed.
Exit condition	7. Either a new user account is created or the user is notified of an account creation error.
Special requirements	The username must be unique to those that already exist in the system.

Use case name	LogIntoSystem
Initiating actor	Invoked by Non-Participant
Participating actor	None
Entry condition	1. The system has been started.
Flow of events	2. The username and the password are entered, and the “Login” button is clicked. 3. If the authentication is successful, the main panel appears and the BecomeParticipant, NotifyAddOrDeleteFromProjects and NotifyActiveProjects use cases are invoked. 4. If the authentication is unsuccessful, a message indicating the cause of the login failure is displayed.
Exit condition	5. Either the user logs into the system, becomes a participant and receives the project notifications, or the user fails to log into the system and receives an error message.
Special requirements	None

Use case name	BecomeParticipant
Initiating actor	None
Participating actor	Non-Participant
Entry condition	1. The “Login” button has been clicked and the user has been authenticated.
Flow of events	2. The user becomes a participant of the system.
Exit condition	3. The user has been recognized as a participant of the system.
Special requirements	None

Use case name	NotifyAddOrDeleteFromProjects
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. The “Login” button has been clicked and the user has been authenticated.
Flow of events	2. A message listing the projects that the user has been added to or deleted from since he/she last logged off, is displayed.
Exit condition	3. The user has been notified of any recent project membership changes pertaining to him/her.
Special requirements	None

Use case name	NotifyActiveProjects
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. The “Login” button has been clicked and the user has been authenticated.
Flow of events	2. A message listing the currently active projects that the user belongs to is displayed.
Exit condition	3. The user has been notified of any participating projects that are currently active.
Special requirements	None

Use case name	CreateProject
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has logged into the system.
Flow of events	2. The “Create a New Project” button is clicked. 3. A prompt appears, the project name is entered and the “OK” button is clicked. 4. If the project name does not already exist in the system, the project is created and the BecomeChairOfCreatedProject is invoked. 5. If the project name already exists in the system, a message is displayed until a unique project name is entered.
Exit condition	6. A new project has been created and the creator has become the chair of the project.
Special requirements	The project name must be unique to those that already exist in the system.

Use case name	BecomeChairOfCreatedProject
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. A new project has been created.
Flow of events	2. The creator is assigned to be the chair of the new project.
Exit condition	3. The creator has become the chair of the new project.
Special requirements	None

Use case name	Add Document
Initiating actor	Invoked by Participant or Chair
Participating actor	Participant
Entry condition	1. The user has selected a project. 2. The “Add Document” button is pressed.
Flow of events	3. The name of the document is entered into the system. 4. The “OK” button is pressed.
Exit condition	5. A new document is added to the project without any errors.
Special requirements	None

Use case name	JoinSession
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has logged into the system and at least one project has been activated.
Flow of events	2. A session is selected from the active project list and the “Join Session” button is clicked. 3. A new panel appears and the NotifyParticipants use case is invoked.
Exit condition	4. The user has joined the selected session and everyone who is currently participating in the session has been notified.
Special requirements	None

Use case name	NotifyParticipants
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. A user has joined or left a session.
Flow of events	2. A message indicating who has joined or left the session is sent to every participant of the session.
Exit condition	3. Everyone who is currently participating in the session has been notified of who has just joined or left the session.
Special requirements	None

Use case name	RequestTurn
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has joined a session. 2. The user is not currently having a turn and is not in the request queue.
Flow of events	3. The “Request Turn” button is clicked. 4. If no one is currently holding a turn, the user is given a turn to speak. 5. Otherwise, the UpdateDialogQueue use case is invoked.
Exit condition	6. The user has either been given a turn or has been queued for a turn.
Special requirements	None

Use case name	UpdateDialogQueue
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. This use case extends the RequestTurn use case. It is initiated by the system when a user requests for a turn that is being held by another user, by the ReleaseTurn use case, or when a chair initiates the MoveToFrontOfQueue use case.
Flow of events	2. If it is initiated by a normal user request, the user is added to the end of the dialogue queue. 3. If it is initiated by the ReleaseTurn use case, the user in the front of the dialogue queue is removed. 4. If it is initiated by the MoveToFrontOfQueue use case, the chair is added to the front of the dialogue queue.
Exit condition	5. The dialogue queue has been updated according to the request.
Special requirements	None

Use case name	ReleaseTurn
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. This use case extends the LeaveSession use case. 2. The user has joined a session and is holding a turn.
Flow of events	3. The “Release Turn” button is clicked. 4. The user loses the privilege to speak. 5. The UpdateDialogQueue use case is invoked. 6. If exists, the user removed from the front of the dialogue queue is given a turn.
Exit condition	7. The user has released the turn. If the dialogue queue is not empty, the turn will be given to the first user in the queue.
Special requirements	None

Use case name	InputDialog
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has joined a session and is holding a turn.
Flow of events	2. The dialogue is entered and the “Send Message” button is clicked. 3. The dialogue is multicast to all participants in the session.
Exit condition	4. The dialogue has been sent to everyone participating in the session.
Special requirements	None

Use case name	RequestEditControl
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has joined a session. 2. The user does not currently have edit control and is not in the edit queue.
Flow of events	3. The “Request Edit Control” button is clicked. 4. If no one currently has edit control, the user is given control. 5. Otherwise, the UpdateEditQueue use case is invoked.
Exit condition	6. The user has either been given edit control or has been queued for control.
Special requirements	None

Use case name	UpdateEditQueue
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. This use case extends the RequestEditControl use case. It is initiated by the system when a user requests edit control that is being held by another user or by the ReleaseEditControl use case.
Flow of events	2. If it is initiated by a normal user request, the user is added to the end of the edit queue. 3. If it is initiated by the ReleaseEditControl use case, the user in the front of the edit queue is removed.
Exit condition	4. The edit queue has been updated according to the request.
Special requirements	None

Use case name	ReleaseEditControl
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. This use case extends the LeaveSession use case. 2. The user has joined a session and has edit control.
Flow of events	3. The “Release Edit Control” button is clicked. 4. The user loses the privilege to edit documents. 5. The UpdateEditQueue use case is invoked. 6. If exists, the user removed from the front of the edit queue is given edit control.
Exit condition	7. The user has released edit control. If the edit queue is not empty, edit control will be given to the first user in the queue.
Special requirements	None

Use case name	EditDocument
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has joined a session and has edit control.
Flow of events	2. A document is selected from the project document list and the “Edit Document” button is clicked. 3. If a modified active document already exists, the user is prompted to save it before it is made inactive. 4. The selected document is opened and activated; and some changes are performed. 5. The changes are reflected in every participant’s instance character-by-character.
Exit condition	6. The selected document has been opened and activated and any changes to it have been immediately reflected in every participant’s interface.
Special requirements	None

Use case name	SaveDocument
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. This use case extends the EditDocument use case. 2. The user has joined a session and has opened a document.
Flow of events	3. The “Save Document” button is clicked. 4. The active document is saved in persistent storage. 5. The UpdateVersion use case is invoked.
Exit condition	6. The active document has been saved in persistent storage and its version number has been incremented by one.
Special requirements	None

Use case name	UpdateVersion
Initiating actor	None
Participating actor	Chair or Participant
Entry condition	1. The user has requested to a document save.
Flow of events	2. The active document’s version number is incremented by one.
Exit condition	3. The active document‘s version number has been incremented by one.
Special requirements	None

Use case name	Inactivate Document
Initiating actor	Invoked by Participant or Chair
Participating actor	Participant
Entry condition	1. The user has selected a project. 2. The user is editing a document. 3. The “Inactivate Document” button has been pressed.
Flow of events	4. The “Save Document” use case is invoked if the document has been edited since the last save.
Exit condition	5. The document is inactivated without any errors.
Special requirements	The “Save Document” use case is an extension of the current use case. It is only invoked if the document has been updated since the last save.

Use case name	LeaveSession
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The user has joined a session.
Flow of events	2. The “Leave Session” button is clicked. 3. If the user is currently holding a turn, the ReleaseTurn use case is invoked. 4. If the user currently has edit control, the ReleaseEditControl use case is invoked. 5. If the user is the chair of the project, any active document is made inactive, and the InactivateProject use case is invoked. 6. The NotifyParticipants use case is invoked. 7. The session panel disappears and the main panel reappears.
Exit condition	8. The user has left the session and everyone who is currently participating in the session has been notified. Any discussion or edit controls that the user is holding are released. 9. If the user is the chair of the project, any active documents will be made inactive, the project will be made inactive, and all the participants will be forced to leave the session.
Special requirements	None

Use case name	LogOffSystem
Initiating actor	Invoked by Chair or Participant
Participating actor	None
Entry condition	1. The system has been started.
Flow of events	2. The “Log off” button is clicked. 3. The LeaveSession use case is invoked. 4. The user is logged off from the system.
Exit condition	5. The user has been logged off from the system and has left any active sessions that he/she may have been participating in.
Special requirements	None

Use case name	Activate Project
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. An Inactive Project has been selected. 3. The “Activate Project” button has been pressed.
Flow of events	4. The selected project is activated. 5. The “Notify Participants of Project” use case is invoked. 6. The “Capture Dialogs” use case is invoked.
Exit condition	7. The select project use case is activated without any errors.
Special requirements	None

Use case name	Move to Front of Queue
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. The user is in an active project. 3. A discussion has been engaged. 4. The “Request Turn” button has been pressed.
Flow of events	5. The user is placed in the front of the queue 6. The “Update Dialog Queue” has been invoked.
Exit condition	7. The “Update Dialog Queue” use case has been invoked and the dialogue queue has been updated without any errors.
Special requirements	None

Use case name	Inactivate Project
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. The user is in an active project. 3. The “Inactivate Project” button has been pressed.
Flow of events	4. The “Force Participant Departure” use case is invoked. 5. The “Save Transcript” use case is invoked. 6. The current project is inactivated.
Exit condition	7. The “Save Transcript” and “Force Participant Departure” use cases have returned without any errors.
Special requirements	If any document is not saved, a dialog is displayed, requesting that the user either save or not save. The “Save Document” use case is extended – it is invoked depending on the user’s choice (yes = invoke).

Use case name	Add Participants
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. The user is in an active project. 3. The “Add Participants” button has been pressed.
Flow of events	4. A list of participants who do not belong to the current project is displayed. 5. One or more participants have been selected. 6. The “Add” button has been pressed. 7. The selected participant(s) is added to the current project.
Exit condition	8. The select participant(s) has been added to the current project without any errors.
Special requirements	None

Use case name	Delete Participants
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. The user is in an active project. 3. The “Delete Participants” button has been pressed.
Flow of events	4. A list of participants who do not belong to the current project is displayed. 5. One or more participants have been selected. 6. The “Delete” button has been pressed. 7. A confirmation dialog is displayed. 8. The user answers “Yes” to the confirmation. 9. The selected participant(s) is removed from the project.
Exit condition	10. The select participant(s) has been removed from the current project without any errors.
Special requirements	None

Use case name	Delete Project
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of one or more projects. 2. The “Delete Project” button has been pressed.
Flow of events	3. A list of projects in which the user has “chair status” is displayed. 4. One or more projects have been selected. 5. The “Delete” button has been pressed. 6. The project is deleted from persistent storage.
Exit condition	7. The selected project(s) has been removed from without any errors.
Special requirements	None

Use case name	Gain Dialog Control
Initiating actor	Invoked by Chair
Participating actor	Chair
Entry condition	1. The user is the chair of the current project. 2. The user has been engaged in a discussion. 3. The “Gain Dialog Control” button has been pressed.
Flow of events	4. Control of the dialog is passed to the user. 5. The participant, who currently has control, is moved to the top of the queue.
Exit condition	6. The chair gains control of the dialog without any errors.
Special requirements	None

Use case name	Save Transcript
Initiating actor	None
Participating actor	Chair
Entry condition	1. The “Inactivate Project” use case initiates this use case.
Flow of events	2. The start time, end time, and the names of the documents edited during the session are captured and associated with the transcript. 3. The transcript is saved to disk.
Exit condition	4. The transcript is saved to disk without any errors.
Special requirements	None

Use case name	Force Participant Departure
Initiating actor	None
Participating actor	Chair, Participant
Entry condition	1. The “Inactivate Project” use case initiates this use case.
Flow of events	2. All participants engaged in this discussion are forced to leave the current session. 3. The user leaves the current session.
Exit condition	4. All participants have left the session without any errors.
Special requirements	None

Use case name	Notify Participants of Project
Initiating actor	None
Participating actor	Chair, Participant
Entry condition	1. The “Activate Project” use case initiates this use case.
Flow of events	2. All participants belonging to this project is notified.
Exit condition	3. All participants have been notified without any errors.
Special requirements	None

Use case name	Capture Dialogs
Initiating actor	None
Participating actor	Chair
Entry condition	1. The “Activate Project” use case initiates this use case.
Flow of events	2. The dialog (used later to compile the transcript) is captured and begins to listen to events that need to be recorded.
Exit condition	3. The dialog started without any errors.
Special requirements	None

Use case name	Get a List of Project Documents
Initiating actor	Invoked by Participant or Chair
Participating actor	Participant
Entry condition	1. The user has selected a project. 2. The “Show Documents” button is pressed.
Flow of events	3. A list of documents that belong to the selected project is displayed.
Exit condition	4. A list of documents that belong to the selected project is displayed without any errors.
Special requirements	None

Use case name	Get a List of Participated Projects
Initiating actor	Invoked by Participant or Chair
Participating actor	Participant
Entry condition	1. The user has selected a project. 2. The “Show Projects” button is pressed.
Flow of events	3. A list of projects that the user has membership to is displayed.
Exit condition	4. A list of projects that the user has membership to is displayed without any errors.
Special requirements	None

3.2 Object Model

The intent of this object model is to identify the entities, control, and interface objects of the collaborative tool according to the project description. The association and cardinality among the classes are also specified. Methods presented here are not exhaustive; they merely correspond to some operations proposed by the use cases. This preliminary class diagram will form the basis for a more detailed framework to be presented in the design document, to which design patterns will be applied.

Some general design issues have been taken into consideration to realize the associations between classes. For example, the user interface shall be de-coupled from the rest of the system to achieve better modularity. Also, entity classes should only contain the required attributes and access methods. Clients should not modify them directly but rather through their corresponding control objects.

3.2.1 Analysis Class Diagram

Figure 2 Class Diagram

3.2.2 Data Dictionary

Boundary/Interface Class: Non-Participant User Interface

Responsibility

Collaborators

Components

Operations

· Interface with non-participants

· Provide a login page for user to log in or to create an account

· Non-Participant Control

· Details not specified at requirements stage

· Create Account – create a new user account

· Login – identify a user by a username and password

Control Class: Chair Control

Responsibility

Collaborators

Components

Operations

· Access Participant DB by commands from Chair User Interface

· Provide superior/absolute control over a project

· Chair User Interface

· Project Control

· Participant DB

· Details not specified at requirements stage

· Add Participant – to add a participant to a project the chair created

· Delete Participant – to delete a participant from a project

· Get Participant – to get the list of names of the participants being added to the chair’s project

· Activate Project – to change a project’s state from inactive to active

· Inactivate Project – to change a project’s state from active to inactive

· Delete Project – to permanently close a project and clear all activities of that project

· Gain Dialogue Control – to take the control of the dialogue at any time

· Move To Front Of Queue – place the chair at the head of the queue at any time

Boundary/Interface Class: Participant User Interface

Responsibility

Collaborators

Components

Operations

· Interface with participant