1. Software
Architecture
Design Document
Collaborative Problem Solver
Revision : 3.0
Group I
Lilianne Tawil
Matthew Zwier
Emily McIntyre
Michelle Freedman
Wayne Johnson
October 30, 2003
Abstract
The SADD formally describes the architecture design for the proposed ProjectPlace. It sets
out at a high level the modules, data structures, databases and interfaces that will be used
to implement the project. All essential requirements set out in the SRS are reflected in the
architecture design. This serves as a basis for the Detailed Design, which describes the design
of ProjectPlace in much greater detail.
1
6. 1 Introduction
1.1 Purpose
Intending to capture and convey the architectural decisions that have been made in order to im-
plement ProjectPlace, the Software Architecture Design Document (SADD) formally provides a
comprehensive overview of the proposed system. It uses a number of architectural decompositions
to depict the different aspects, corresponding with the requirements of the Client as portrayed in
the SRS. All requirements with be incorporated into this architectural design, depicting at a high
level the appropriate modules, data structures, databases and interfaces. This document serves as
a basis for the detailed design, which will establish the design in increased detail.
1.2 Audience (Stakeholders)
The audience for this document include:
1.2.1 The Client
The client may wish to examine how the high level design meets the requirements.
Name E-mail
Ms Antonette Mendoza mendozaa@cs.mu.oz.au
1.2.2 The Supervisor
Name E-mail
Ms Kathleen Keogh kathleen@cs.mu.oz.au
1.2.3 Team I
Team I will make use of this document in the design, implementation and testing phases of the
project.
Name E-mail
Michelle Freedman freedman@students.cs.mu.oz.au
Wayne Johnson wkaj@students.cs.mu.oz.au
Emily McIntyre ekmcin@students.cs.mu.oz.au
Lilianne Tawil lilianne@students.cs.mu.oz.au
Yechiel Matthew Zwier yechiel@students.cs.mu.oz.au
1.2.4 440 Auditors/Reviewers
440 Auditors/Reviewers will review and audit this document.
Name E-mail
Andrew Ayres andrewsa@students.cs.mu.oz.au
Edward Sholl edwardas@students.cs.mu.oz.au
Rimantas Strunga rimantas@students.cs.mu.oz.au
Sean Tham jeeyt@students.cs.mu.oz.au
Ismasakti Tanto itanto@students.cs.mu.oz.au
6
7. 1.2.5 Future Developers of the product
This document is written such that any future developers employed for enhancements or modifica-
tions to the ProjectPlace code may use it to understand the existing system.
1.2.6 End-Users of ProjectPlace - Administrators and Supervisors
Administrators and Supervisors of ProjectPlace may use this design to understand the structure
of the system.
1.3 Scope
1.3.1 Document Scope
This document contains a thorough description of the high level architecture that will be used in
developing ProjectPlace. Communicating at a purposefully high level, it will only form the basis for
the Software Detailed Design and implementation. However, the SADD itself will not be in sufficient
detail to implement the code. It will convey the overall system design of ProjectPlace, the user
interface design and higher level module design (including data decomposition and dependencies).
Design details that will not be included in the SADD are:
1. Low level classes that will be used in the implementation. The full description of the imple-
mentation of each module is not needed, but the public modules that will be interfaced will
be described.
2. Exact detailed description of interactions within each module.
1.3.2 Product Scope
The product scope will be limited, in that while the framework will be designed for plug-in based
extensions, only a minesweeper plug-in will be implemented. This plug-in will illustrate the ca-
pabilities of ProjectPlace. ProjectPlace will be designed to function solely on The University of
Melbourne’s Department of Computer Science machines - machines with access to the web, Java
Virtual Machine installed and attached to the web browser.
1.4 Definitions, acronyms and abbreviations
The following are the ProjectPlace user definitions:
• Administrator - The Administrator will be in control of the configuration of ProjectPlace.
• Supervisor - The Supervisor will be assigned to oversee the collaborative work of one or
more groups. This user will be there to monitor the groups’ progress and help with any issues
encountered while solving a project, or using ProjectPlace.
• Student - These are the users who will be collaboratively solving the problem posed by the
Administrator.
1.5 Existing System
There is no existing system that the client, or the Department of Computer Science and Software
Engineering, use for collaborative problem solving. The idea was constructed based on the current
needs of the department.
7
8. 2 Reference Documents
This section lists all of the textbooks, documents and manuals that assisted in the development of
this document.
2.1 Internal Documents
1. SPMP: located in directory path/340/docs/SPMP
2. SRS: located in directory path/340/docs/SRS
2.2 Textbooks
1. Van Vliet, H. 2001, Software Engineering Principles and Practice, 2nd edn, John Wiley &
Sons Ltd, England.
2. Booch, Grady, 1994 Object-Oriented Analysis and Design with Applications 2nd edn, Ben-
jamin/Cummings, Redwood City, CA, USA. ISBN 0-8053-5340-2.
2.3 Manuals
1. Dart, P., et al. 2002, Software Engineering Project Manual, The University of Melbourne,
Australia.
2.4 Standards
1. Recommended Practice for Architectural Description of Software-Intensive Systems IEEE Std
1471-2000.
2. Recommended Practice for Software Design Descriptions IEEE Std 1016-1998.
8
9. 3 System Overview
ProjectPlace is a system designed to allow a class of students to interact and chat online in real-time
to work and solve a given problem. It is being written for the client Ms. Antonette Mendoza of the
Computer Science department, who is interested in analysing these interactions between students.
It is also important to the client that the system be modifiable to change the plugin that students
work on.
3.1 Design Process
As specified in the SRS, the Java programming language is to be used as the development lan-
guage for ProjectPlace. Using Java necessarily requires the adoption of an object-oriented design
methodology. The SRS also specifies the need for a highly modular approach to the software, as
emphasised in the requirement of ’plug-in’ Project modules. The Booch method was chosen due to
Java being the programming language and Java is used most effectively in an OO context. Refer
to 3.1.4 for details on the Booch Method.
ProjectPlace is a user oriented system, that requires a robust server in order to process multiple
user requests. This can be accommodated under an OO methodology, as the larger system can be
broken down into smaller, manageable pieces. With OO, the module structure and dependencies
of ProjectPlace can be shown in a clear and logical manner.
3.1.1 Considerations
The team had the following considerations in mind when deciding on the architectural design for
ProjectPlace:
1. The development language must be Java
2. Low coupled modules with high cohesion are a high priority
3. Usability of ProjectPlace
4. Maintainability and future development of ProjectPlace
5. ProjectPlace must be extendable to accept new Plug-ins.
6. ProjectPlace must be run through an Internet Web Browser.
7. ProjectPlace must be able to be run in real time.
3.1.2 Use Case Modelling
As ProjectPlace is largely user-driven software, use case modelling is an important analysis tool
for Team I, in formulating the architecture. Use cases were created as part of the SRS, and these
have been extended upon in the SADD, to aid in modelling the actions of users. Refer to section
6 to view the use cases.
9
10. 3.1.3 Class Modelling
After deciding to adopt an OO approach, class modelling was conducted to determine the classes
needed. Use cases were consulted to aid in deciding what behaviour should be implemented in which
classes. Many of the major classes are identified as a result of the adopted three-tier architecture,
which is explained in 3.1.5.1.
3.1.4 Booch Method
The Booch methodology in an OO context was decided upon primarily because one of the core
requirements of ProjectPlace is that it must be implemented in the Java Programming language.
Java code is designed most effectively in an object-oriented framework.
According to Booch, the design process can be divided into the following stages:
1. Establishing a core set of requirements - this is defined in the SRS.
2. Developing a model of the desired behaviour of ProjectPlace, with use case modelling, that
is used to create an architectural design that captures all functional requirements.
3. Creating a Software Architecture - this is described in this document.
4. Evolve the implementation - conducted in the detailed design and implementation phases.
3.1.4.1 Modules
Another stage, of the Booch design process is breaking the system into modules that exhibit low
coupling and high cohesion. This will facilitate the projects development, and will ensure a more
maintainable and robust design.
The Booch method for the architecture will be followed by:
1. Analysing the system as a whole and breaking it down into a specific architectural pattern.
2. Breaking the system down into manageable sized modules.
3. Describing the data structure of these modules.
4. Describing the interfaces of these modules.
5. Describing the interaction between modules.
The representation of the above steps will be aided by the use of UML - Class Diagrams, Sequence
Diagrams, Collaboration Diagrams.
For more information on the Booch methodology, refer to Object-Oriented Design and Principals
as listed in section 2.2.
3.1.5 Architecture Pattern
It is for the considerations in section 3.1.1 that a Client-Server three-tier architecture was chosen
for ProjectPlace.
A graphical representation of the system is shown in figure 1.
10
11. Figure 1: The Top-level Architecture of ProjectPlace.
3.1.5.1 The Three-Tier Architecture
The three tiers are as follows:
1. Presentation Layer (Client) - The Client of the system is responsible for outputting the
GUI to the user. It simply relays information passed to it by the Server and sends information
to the Server. This tier provides the functionality to generate HTML with Java applets.
2. Logic Layer (Server) - The server is the ’intelligent’ layer as it interacts with the pre-
sentation tier (Client) by being responsible for processing requests received by the client.
It does the relevant computation and sends information back to the necessary clients, and
manipulates data in the content layer, i.e. it updates the database.
3. Content Layer (Database) - The database is the content layer of the system as it is re-
sponsible for storing all data that needs to be saved within ProjectPlace. It saves information
that it receives from the server, and sends information requested back to the server.
This architectural design will ensure all clients have consistent information, as all of the information
is centralised through the server, which sends the current state of the system out to the clients. In
essence all that the clients have is the GUI. All of the work is done by the server and all of the
information is stored in the database.
In addition, keeping the interface separate from the processing ensures that if, at a later date,
the user interface needs to be changed this task will can be done independent of the underlying
architecture.
11
12. 4 Decomposition Description
In this section of the SADD, a top level description of ProjectPlace will be given, breaking it into
its module constituents and explaining their interaction. The modules in the system contain public
methods for input and output between them, run concurrent processes and use data that has been
modified during the system’s active life.
4.1 Inputs and Outputs
Shown in figure 2 is the structure of the working system with all its internal and external entities.
The diagram shows an initial interaction between the Web Server and the Clients Web Browser.
The Client initially contacts the Web Server and retrieve the Java Applet that makes up the client.
The Client then initialises a separate connection to the server on another port, connecting with
the servers ProjectPlace server. All interaction with the server is then done with the ProjectPlace
server. This diagram shows the inputs an outputs of the system as a whole, the inputs and outputs
of each module will be discussed in greater detail in section 4.2
Figure 2: The inputs and outputs of the system - both Client and Server side.
The inputs to the system are:
1. The Server Module receives input from the Client Applet in order to log in to the system.
See section 4.2.2.
2. The Client applet accepts inputs from a user through a web browser.
3. The Client applet accepts input from the CommonRoom and ProjectRoom modules, to up-
date the screen. See section 4.2.1.
4. The Database receives input from the Logger in order to add, modify or obtain information
from it.
5. The Logger receives input from the Server, ProjectRoom and CommonRoom modules to
obtain information from the database. See section 4.2.3.
6. The ProjectRoom and CommonRoom modules receive input from the client applet. See
sections 4.2.4 and 4.2.5.
12
13. The outputs of the system are:
1. The Server Module outputs a reference of the Common Room to the Client Applet.
2. The Client Applet outputs the interface and functionality of the system to the user.
3. The Client Applet outputs information it receives from the user to the Server, CommonRoom
and ProjectRoom Modules.
4. The Database outputs information to the logger.
5. The Logger outputs information from the database to the Server, CommonRoom and Pro-
jectRoom Modules.
6. The CommonRoom and ProjectRoom output chat messages to the Client Applet.
13
14. 4.2 Module Decomposition
Below is a description of the purpose, inputs and outputs of the modules depicted in figure 3.
Figure 3: The second-level design of ProjectPlace.
This is a description of the name, purpose or role, and function of each of the components in
the design.
4.2.1 Client Applet Module
4.2.1.1 Description
This module simply consists of all the GUI components and methods that will be used to interact
with the server. This module with be exported to the server, meaning that a reference to it will be
given to the server using RMI technologies so that the server can easily call methods on the Client
Applet. The Client Applet will only contain methods to update the Server of user interaction with
the Client Applet and methods that the Server can call on it to update the GUI.
4.2.1.2 Inputs and Outputs
Because it provides a remote reference to itself, the Client Applet will have methods in it that
the ProjectRoom and CommonRoom can call to give it input. Since it also has a reference to
the Project and Common Rooms, it can call methods on them passing information that the GUI
provides such as sending a chat message or inviting a group of people to complete a project. The
public methods of this module are:
14
15. 1. public void receive message(Message message)
This method is called by the Common Room or Project Room, when a message has been sent
to the chat window from another client. It takes as its argument a Message object and will
post the message to the client’s GUI chat window
2. public void receive invite(PPGroup projGrp)
This method is called by the Common Room when another user has requested a group for
this client to join.
3. public void add to projects list(PPGroup projGrp)
This method is called by the Common Room when a group request to complete a project has
been accepted by all users. It adds the project to the list of available projects.
4. public void update client list(Hashtable allClients)
This method is called by the Common Room to update the client with the list of users
currently logged in to ProjectPlace.
4.2.2 Server Module
4.2.2.1 Description
This module is the module on the Server side that acts as the initial contact with the Client. Since
this module is exported remotely using the RMI technologies (See Glossary), the Client receives a
reference to this module. The Server then handles all authentication procedures and initial setup
of the connection and then passes a reference of the CommonRoom to the client so that the client
can start interacting with the CommonRoom. It is also the first module that is created when
ProjectPlace is started, and subsequently instantiates the CommonRoom and Logger modules.
The server is essentially a doorman that greets the Clients.
4.2.2.2 Inputs and Outputs
The Server Module receives initial contact from the client applet, and outputs a reference of the
CommonRoom to the the client. The public methods of this module are:
1. public CommonRoom register()
The register method is the first access point to the server. It is called remotely from the
Client. It verifies a user login with the database and if successful, returns the CommonRoom
class to the client.
4.2.3 Logger Module
4.2.3.1 Description
The Logger module acts as a middle man between the ProjectRoom and CommonRoom modules
and the database. It is a Java class that is created by the server and passed to the CommonRoom
and then onto the ProjectRoom and provides an easy to use interface containing methods that are
called to query, add and delete data from the database.
15
16. 4.2.3.2 Inputs and Outputs
The Logger provides methods to add, remove and modify data in the database. A module can then
simply call methods on the Logger class which queries the database and returns the appropriate
values. The public methods of this module are:
1. public Object[][] DBget(String attribute, String table, String idAttribute, String
id)
The DBGet() method retrieves information from the database, and returns this information
to the calling class.
2. public Object[][] DBset(String table, String idAttribute, String id, String at-
tribute, String value)
The DBSet() method is used to add or modify something within the database.
3. public Object[][] DBdelete(String table, String idAttribute, String id)
The DBdelete() method is used to remove data from the database.
4.2.4 Common Room Module
4.2.4.1 Description
This module takes care of all the CommonRoom interaction. When the users first access Project-
Place, they are passed a reference to the CommonRoom. It provides methods that allow the user
to post messages to a global chat, and provides methods that allow Clients to form groups and
invite these groups to complete a project. It also provides methods that allow the Clients to log
out of ProjectPlace.
4.2.4.2 Inputs and Outputs
Its inputs are methods that the Client calls to post messages etc. Its outputs are method calls to
the Logger to set, delete and add data to the database, and method calls to the Client Applet to
update its GUI components. The public methods of this module are:
1. public void chatMessage(Message message)
The chatMessage method takes a chat message from a remote Client Applet and sends the
me it to all the other clients currently in the CommonRoom.
2. public String[] getPluginList()
The getPluginList() method is called by a remote Client Applet. It gets a list of available
plugins from the database and returns these to the Client Applet.
3. public String[] getSavedProjects()
The getSavedProjects() method is called by a remote Client Applet. It gets a list of saved
projects from the database and returns these to the Client Applet.
4. public void inviteClients(PPGroup group)
The inviteClients() method is called by a remote Client Applet. It takes as input a group
that has been generated by a single Client and sends invites out to the appropriate clients.
16
17. 5. public void acceptProjectInvite(String invitee, PPGroup group)
The acceptProjectInvite() method is called by a remote Client Applet. It is a method used
by the client to accept a project invitation.
6. public void enterProject(String userName, int projID)
The enterProject() method is called by a remote Client Applet. It is a method used by the
Client to enter a project.
4.2.5 Project Room Module
4.2.5.1 Description
This module is much the same as the CommonRoom module, but is specific to the group that is
solving a project. It contains a plugin that defines the problem they are to solve and provides the
generic functionality that the ProjectRoom is to provide. This is such things as a chat, just like
the CommonRoom and also provides a Decision log and a timer bar so the Clients can keep an eye
on their progress with respect to the time limit that is imposed by the Administrator.
4.2.5.2 Inputs and Outputs
The ProjectRoom is passed a reference to all the Client Applet’s that will be participating in the
project. A reference to it is also passed to all the Clients so that the client can call methods on the
ProjectRoom, and the ProjectRoom can call methods on the Client to update its GUI components.
It also provides methods that the plugin calls to add log information to the database. The public
methods of this module are”
1. public void chat message(Message message)
The chat message() is called remotely by a client Applet. It is used to send a chat message
to all clients in the project.
2. public void exit project(String userName)
The exit project method is called by a remote client Applet. It is used to tell the project
room that a user has logged out of the current project.
3. public void submit decision(String userName, String log)
This method is called by a remote client when they make an action and subsequently justify
this action in the decision log. This method stores logs this decision with the database.
4.2.6 Plugin Module
4.2.6.1 Description
The Plugin is the problem that will be solved by the Clients. It is a module that the Administrator
will create that will pose a problem to the clients that they must solve. The plugin interface will be
as lowly coupled with the Project Room module as possible so that the Administrator can create
more Plugins with ease.
17
18. 4.2.6.2 Inputs and Outputs
The inputs to this program are method calls from the Client to update some module of the plugin
and the outputs are method calls to the Clients to update Plugin part of their GUI interface. It
will also output log information to the ProjectRoom that will then be forwarded on to the Logger.
18
19. 4.3 Concurrent Process Decomposition
Following is a description of each module that acts ‘concurrently’ with other moduless in the system.
For each module there is a description of:
1. Identification
2. Type
3. Purpose or role
4. Function
5. Lifetime
6. Subordinates
The system can handle a multitude of Database accesses. Since there are concurrent processes
running in the server all of which require access to the database. In order to prevent critical section
problems with shared data, a single acces point has been created to the database through the
logger.
The processes can be split up as follows:
1. Client
Each Client is run on different machines and will hence have its process running separate
from the server. The client process calls methods on the server from time to time. See items
2 and 3 below on how this process interaction is handled.
2. Server
There is only one Server running on one computer in the system. The Server, comprising the
Server, CommonRoom, ProjectRoom, Logger and Plugin modules, run on one single process.
It receives calls from the Client, but because of issues with dropouts from clients, it cannot
call methods on the clients directly, else the whole ProjectPlace will hang while it tries to do a
simple method call on a remote computer. This is solved by the Client Talkers, described next.
3. Client Talkers
Each time a client connects to ProjectPlace, a client talker is created to handle method calls
on the client. All interaction between the server and the client is handled through these
talkers. Essentially the CommonRoom or ProjectRoom etc post messages to be sent to the
client with the Client Talkers. These messages are put into a queue, and are sent one by one
to the client.
4.3.1 Client Process Description
The Client Process can be broken up and described as follows:
1. Identification:
ProjectPlace Client
19
20. 2. Type:
Java Apple
3. Purpose:
Provide User interfaces and control from remote location via Internet.
Multiple instances are needed to accommodate multiple Users.
4. Function:
Displays system data and text messages through a graphical User interface.
Prepares and displays User requested command.
Obtain User requested data from ProjectPlace Server.
5. Lifetime:
As long as the Client has the ProjectPlace browser open.
6. Subordinates:
Web Browser.
HTML/Java Applet document (GUI).
Server operating system.
4.3.2 Server Process Description
The Server Process can be broken up and described as follows:
1. Identification:
ProjectPlace Server
2. Type:
Java Application
3. Purpose:
Spawn multiple instances of the Client Talkers to handle multiple requests.
Support the multiple Client instances.
Determine and set system state based on retrieved data and command.
4. Function:
Service Client requests.
Set system state based on retrieved data and command.
5. Lifetime:
The duration of the system’s life.
6. Subordinates:
Server operating system.
Web Server
Client communication process.
Server-Database interface.
20
21. 4.3.3 Client Talker Process Description
The Client Talker Process can be broken up and described as follows:
1. Identification:
ProjectPlace Client Talker
2. Type:
Java Thread
3. Purpose:
Provide a communication service, sending messages to the Client Applet to the appropriate
User’s computer.
4. Function:
Forwards messages to a User’s machine.
5. Lifetime:
As long as the Client is logged in.
6. Subordinates:
Server Operating System
21
22. 4.4 Data Decomposition
This section contains a description of each data element that is shared between components, its
persistence (or its lifetime), and its logical structure (but not its representation in a programming
language).
4.4.1 Data Sharing
Data is shared between modules to keep each section of the system well informed and up-to-date.
While the ProjectPlace Database, as described in the following sections, will be used as a point
of reference for the data-sharing, the system will use internal ’somewhat temporary’ variables to
pass information onto the relevant section. For example, the attributes of the plug-in can be
passed through variables, while the attributes when inactive can be stored in the database for later
reference.
4.4.2 Data Storage Overview
In order for the ProjectPlace system to function, it must have access to a database such as MySQL
which contains information about the System, Project (Problem with Users associated), as well as
Users. The Database is constructed using the relational model, which means that links can be made
between the various tables, and between attributes in those tables, allowing complex relationships
to be modelled.
The main principle of the relational model is to allow updates of tuples in the table without ad-
versely affecting other data. The relation must be structured in a way so that redundancy and
dependency are reduced as much as possible within the Database. This would include implementing
single point of contact for all attributes, with reference from other data tables when necessary.
22
23. Figure 4, below, shows the relationship between the different data entities and attributes in the
system’s Database. This diagram conveys equivalent information to the traditional E-R Diagram
(Entity-Relationship Diagram), though is visually more structured. Thus, it was decided that
further diagrams were not necessary. The Database Schema in more detail will be presented in the
following section.
Figure 4: Relationship Schema Diagram - Database Model
Data Decomposition BreakDown:
The data decomposition will be broken down using the following methodology:
Conceptual Design
→ Conceptual Schema (Entity-Relationship Model)
Logical Design
→ Logical Schema (Relational Model)
There are two steps taken to ensure the database design is robust.
Step 1: ER-to-Relational Mapping - product of this is shown in Figure 4.
Step 2: Normalisation: ”Improving” the design
23
24. 4.4.3 User Data Table
A User, in this data model, is someone who has registered (logged on one or more times) and whose
information is thus stored in the Database. This data table also includes associated statistics. This
data table (Database Schema) indicates the required attributes (non-NULL) with the use of an
asterisk (*).
Entry Type Example
*UserID String that contains the login name smithj
*UserPwd Encrypted field containing the password pwd123 (min 4 chars)
UserName String containing the User’s full name John Smith
UserDOB Date - Date of Birth 18/01/1982
UserEmail String containing an email address jsmith@students.com
UserPhone Integer containing a phone number 92053983
UserComment Short text for reference of administrator Watch him closely
*UserAStatus Character indicating Accessibility Status P
→ A = Accessible
→ S = Inaccessible, by Supervisor
→ P = Inaccessible, Password Failure
→ X = Inaccessible, Expired
A is the default - initial value
*UserSecLevel Two-digit integer for Security Level 00→ 32
*UserType Character indicating type (for expansion) N
→ N = Normal (Student)
→ S = Supervisor
→ A = Administrator
*UserCreated YYYYMMDDHHMMSS, time account created 20020301162452
*UserExpires YYYYMMDDHHMMSS, time account expires 20040101000000
00000000000000 = never
UserLoginID Last assigned SessionID (sent by Server) 4357
*UserCurrProjID Currently in this Project 0
0 = Common Room or not logged on
*UserVerbose Verbose mode on, Y=yes, N=no N
Statistics These entries are for statistical purposes
*UserLStatus Login Status, Y=Logged in, N=Logged out Y
UserLstLogTime YYYYMMDDHHMMSS, Last LoginTime 20030701131532
UserLstLogDura Integer (secs), On logout, Now-LstLogTime 3241
UserTotLogDura Integer (secs), Sum - Increases on logout 18291
Table 1: User Data Table
24
25. 4.4.4 ProjUser Data Table
This data model is the relational table between the Project and all its Users. A ProjUser is a
User that belongs to a Project. The following data table (Database Schema) indicates the required
attributes (non-NULL) with the use of an asterisk (*).
Entry Type Example
*ProjID ProjectID from Project table 3453
*UserID UserID from User table smithj
*puStatus Character indicating ProjectUser Status Y
→ Y = Accepted invitation
→ N = Finished or dropped out
Y is the default - initial value
*puLStatus Character indicating Room Login Status Y
→ Y = User is in room
→ N = User not in room
N is the default - initial value
*puControl Indicating if User is in control of room Y
→ Y = In control
→ N = Not in control
N is the default - initial value
Statistics These entries are for statistical purposes
puLstLogTime YYYYMMDDHHMMSS, Last LoginTime to room 20030701131532
puLstLogDura Integer (secs), Derived on logout of room 18291
puTotLogDura Integer (secs), Sum. Increases on room logout 42291
puLstCtlTime YYYYMMDDHHMMSS, Last Conrol Restart Time 20030701131532
puLstCtlDura Integer (secs), Derived on control loss 18291
puTotCtlDura Integer (secs), Sum. Increases on control loss 38291
Table 2: ProjUser Data Table
25
26. 4.4.5 Project Data Table
A project in this data model is a collection of attributes to completely describe a project. It contains
type, length and restrictions of a project and its Users. The project creator sets the majority of
attributes on project creation. Some fields have default values defined in the System table. This
data table also includes associated project statistics. The following data table (Database Schema)
indicates the required attributes (non-NULL) with the use of an asterisk (*).
Entry Type Example
*ProjID System-generated Project identification 3453
*ProjName String with User-defined module name John’s Maze
ProjPurpose Short text - User-defined project description A maze to solve.
*ProjType Character indicating Type N
→ N = Normal
*ProjCreated YYYYMMDDHHMMSS, time account created 20020301162452
ProjCUser Created By UserID smithj
*ProjAStatus Character indicating Accessibility Status N
→ I = Inactive, Accessible
→ A = Active, Accessible
→ N = Inaccessible, insufficient accepted participants
→ S = Inaccessible, by Supervisor
→ X = Inaccessible, Expired
→ V = Visitor Mode
I is the default - initial value
*ProjExpires YYYYMMDDHHMMSS, time account expires 20040101000000
00000000000000 = never
ProjManager Manager UserID, selected from ProjUser table smithj
ProjUserMin Min accepted participants for proj to be accessible 2
ProjUserMax Max ” 5
ProjSupervisor UserID supervisor list [smithj, jonesj]
Table 3: Project Data Table
26
27. 4.4.6 Plugin Data Table
This contains a list of all plug-in modules available to projects and some attributes. The atributes
may be modified by the plug-in author only when inserted into ProjectPlace. The following data
table (Database Schema) indicates the required attributes (non-NULL) with the use of an asterisk
(*).
Entry Type Example
*PlugID Plugin ID Maze101
*PlugName Descriptive name of module 5 person Maze
*PlugPath Path to object on server c:/here/module
PlugDesc Short text describing plugin functionality Maze allows 5 people
Table 4: Plugin Data Table
Note: there is also a ’hasPlugin’ table, which consists of ProjID and PlugID from the Project
and Plugin tables respectively. The sole purpose of the ’hasPlugin’ table is to link the two.
4.4.7 System Data Table
This data model holds a collection of attributes which make up the system preferences. Here, all
the variables and potential variables in ProjectPlace will be defined, even if there is currently no
option to change them. This improves single point of control implementation within the system.
Among other fields, it contains a list of projects that the system contains (linked to the Project data
table). The system initiator (the first person to start up ProjectPlace) could be given the option
to change the preferences on initialisation. Even if not implemented in our system, the option
remains to allow for extendability. This data table will also include associated system statistics
(if any where to be added in later). The following data table (Database Schema) indicates the
required attributes (non-NULL) with the use of an asterisk (*).
Entry Type Example
*SysID System record ID (always 1) 1
*SysProjUserMin Default minimum Users required for project 3
*SysProjUserMax Default maximum Users allowed for project 5
*SysStatus System Initialised. →Y = Yes, →N = No Y
*SysLogLevel Log depth mode on. 0=no audit 2
1=brief, 2=normal, 3=extended, 4=verbose
SysPortNumb Listening Port 8000
Table 5: System Data Table
27
28. 4.4.8 Log Data Table
This contains the system’s audit data. It may contain all client commands and system error
messages. The following data table (Database Schema) indicates the required attributes (non-
NULL) with the use of an asterisk (*).
Entry Type Example
*LogID Log ID 7679
*LogType Log record type: M=Message, A=Action, E=Error A
*LogTime YYYYMMDDHHMMSS, Log time 20030701131532
LogServerID This Server ID s3439
LogUserID Related UserID smithj
LogProjID Related ProjectID 3243
LogCommand Protocol command code received lgi
LogParameter Parameter along with command 345 smith
LogMessage Log message helloWorld
Table 6: Log Data Table
28
29. 5 Dependency Description
The following section will describe the relationship between each given module of the system with
the other modules of the system.
5.1 Module Dependencies
This section outlines the dependencies and interactions in the modules defined in Section 4.2. Figure
5 shows the collaboration diagram for the modules that are present in ProjectPlace.
Figure 5: The collaboration diagram of the modules that are in the system.
The dependencies and interactions between the modules are as follows:
5.1.1 Module: Client Applet
This modules dependencies are as follows:
1. User Input
The Client Applet receives input from the user. This input comes in the form of clicking on
a button in their browser or entering text into a text field (chat text).
29
30. 2. Server
The Client Applet then processes this information and calls methods on the Server to initialise
contact and pass a reference of itself to the Server.
3. CommonRoom
The Client Applet calls methods on the CommonRoom to send Chat Messages, Logout and
Create a Project Group, and is dependent on the CommonRoom for these tasks.
4. ProjectRoom
The Client Applet calls methods on the ProjectRoom to send Chat Messages, quit a project
or add a Decision Log entry when a decision has been made on a project.
5.1.2 Module: Server
The following are the Servers dependencies:
1. Client
The Server interacts with the client by receiving method calls from the client. It then returns
to the Client a reference to the CommonRoom and ProjectRoom. It does not call methods
on the client at all.
2. Logger
The Server gets and sets information in the database through the Logger, and also creates an
instance of it to pass to the CommonRoom.
3. Common Room
The Server simply calls a method on the CommonRoom that passes the Client Applet as a
reference.
5.1.3 Module: Logger
The Loggers dependencies are the following:
1. CommonRoom and ProjectRoom
The Logger has methods that the CommonRoom and ProjectRoom call to set, receive and
delete data elements from the database.
2. MySQL Database
The Logger passes information to the Database. It also queries the Database and retrieves
information stored in the Database.
5.1.4 Module: Common Room
1. ProjectRoom
The CommonRoom instantiates the ProjectRoom 5.1.5 and then passes a reference to all the
participants of the project to it, along with a reference to the Logger 5.1.3. After that the
CommonRoom has no interaction with the ProjectRoom.
30
31. 2. Server
See section 5.1.2.
3. Logger
See section 5.1.3
5.1.5 Module: Project Room
The following are the Project Rooms dependencies:
1. Client
The ProjectRoom receives chat messages from the Client Applets and sends these messages
to all other Clients. It also receives actions and decision log information from Clients.
2. Plugin
The ProjectRoom sends actions to the plugin and receives an updated visual state of the
plugin.
3. Logger
The ProjectRoom sends log information to be updated into the database.
5.1.6 Module: Plugin
1. ProjectRoom
See Section 5.1.5 for details.
31
32. 5.2 Data Dependencies
The data dependencies in the system can be broken into two relationships.
1. The relationship that the Client Applet and GUI has with the Common Room, Project Room
and Plug-In.
2. The relationship that the Common Room, Project Room and Plug-In have with the Database.
Essentially data flows from the GUI through the Client Applet and Project Room into the
database.
5.2.1 Client Applet - Common Room, Project Room, Module relationship
In this relationship, the modules Common Room, Project Room and Plug-In are all dependent
on the information that is entered in the Client GUI. Information such as chat text and Plug-In-
specific information is passed from the GUI to the various modules. For example, if the user is in
the Common Room, the information is sent to the Common Room module.
The reverse relationship is also true. Once the information is received by either the Common Room,
Project Room or Plug-In, the modules do some computing and this change needs to be reflected
on all of the Client GUI’s. Therefore the Client GUI is dependent on the data that is generated
from these modules. For instance, the Common Room may have received chat text from one of its
users, this text is then passed to all the other users in the Common Room updating their screen
with this new text.
5.2.2 Database - Common Room, Project Room, Module relationship
The Database is dependent on the information collected/set from the Common Room, Project
Room and Plug-In to give it the data for storage. Therefore the Database is dependent on infor-
mation that is generated in these modules and passed to it. An example could be the chat text
that is logged for the supervisor to check through when marking the project. This text needs to be
logged to the Database and therefore the Database is dependent on this data that is being passed
from the Project Room.
The Project Room, Common Room and Plug-In are also dependent on the information stored in
the Database. An example of this is the recalling of a saved project by the Common Room for a
user. When the user goes to reload an unfinished project, this information must be retrieved from
the Database, hence the Common Room is dependent on the data in the Database.
32
33. 6 Use Cases
This section contains use cases demonstrating the desired functionality of ProjectPlace. The use
cases were derived from the requirements for ProjectPlace, which can be found in the SRS. Use-case
scenarios will be used to illustrate any use cases that need further explanation.
NOTE: In the use case figures below, if the link between two use cases has not been specified as
”extends”, than it is ”includes”. This was not included in the figures, as they will become clustered.
6.1 Login
ProjectPlace shall allow users to login via the login window using their login and password. Users
may also change their password. Also, if the user has forgotten their password, it may be changed by
an Administrator. An error message will result if invalid details are entered. Refer to figure 6 below.
Figure 6: Use-case: Login to ProjectPlace
Refer to the SRS section 4.1 for requirements. Refer to section 7.2 for a sequence diagram depicting
the modules and interfaces and interactions associated with this use case.
6.1.1 A Valid Scenario
1. User in login window
2. User enters login and password
3. ProjectPlace authenticates User
4. User is logged into ProjectPlace
33
34. 6.1.2 A Invalid Scenario
1. User in login window
2. User enters login and password
3. ProjectPlace authentication of User failed; wrong password
4. ProjectPlace sends error message
6.2 Common Room
The user enters the common room once successful login into ProjectPlace has occurred.
Figure 7: Use-case: Entry into Common Room
Refer to the SRS section 7.1.2 for details of the common room.
Once in the common room, the user can perform the following actions:
6.2.1 Chat/Post Messages in Common Room
The user will have the ability to communicate with other users in the common room. Refer to
figure 8 for the actions that may be performed:
Figure 8: Use-case: Chat/Post Messages in Common Room
Refer to SRS section 4.3.2. Refer to section 7.3 for a sequence diagram depicting the modules and
interfaces, and interactions associated with this use case.
34
35. 6.2.2 Create Project
The user will have the ability to create a new project, by choosing a module and inviting other
users within the common room to join their group. The project will be created once the minimum
amount of users needed to form the specific project have accepted their invitation. Refer to figure
9 for the actions that may be performed:
Figure 9: Use-case: Create Project
Refer to the SRS section 4.2.2.1.
6.2.2.1 A Valid Scenario
1. User chooses a Module
2. User invites other Users by sending an invitation
3. Users waits for acceptance
4. More than minimum amount of Users needed to form the project accept
5. Project Created
6.2.2.2 A Invalid Scenario
1. User chooses a Module
2. User invites other Users by sending an invitation
3. Users waits for acceptance
4. Less than the minimum amount of Users needed to form the project accept
5. Project not created, its ”inactive”; therefore cannot enter project
35
36. 6.2.3 Accept/Reject Invitation
The user will have the ability to view all invitations to projects they have been assigned, and accept
or reject these. Refer to figure 10 for the actions that may be performed:
Figure 10: Use-case: Accept/Reject Invitation
Refer to the SRS sections 4.2.2.2 and 4.2.2.3.
6.2.4 Assign Groups
The Supervisor or Administrator are permitted to assign groups. In order to do this they will
choose a Module and allocate students to a group. Refer to figure 11 for the actions that may be
performed:
Figure 11: Use-case: Assign Groups
36
37. 6.2.5 Change Colour Preferences
The user will have the ability to change the colour of their chat font only within the common room.
Refer to figure 12 for the actions that may be performed:
Figure 12: Use-case: Change Colour Preferences
Refer to SRS section 4.2.5.
NOTE: View displayed current colour refers to the User being able see their current colour in
the common room.
6.2.6 Enter/Continue Created Projects
The user will have the ability to enter and continue any projects in their ”active” list. Refer to
figure 13 for the actions that may be performed:
Figure 13: Use-case: Enter/Continue Created Projects
Refer to SRS sections 4.2.2 and 4.2.2.4.
NOTE: A User is unable to enter the project of a group that they are not a member of, as
only the Users ”active” projects will appear in their active projects list. Users may only enter or
continue active projects. (refer to SRS section 4.2.2.5)
6.2.6.1 A Valid Scenario
1. User clicks on a project in their ”active projects” list
2. User clicks ”Enter”
3. User has entered the chosen project
37
38. 6.2.6.2 A Invalid Scenario
1. User clicks on a project in their ”inactive projects” list
2. User clicks ”Enter”
3. Error message results, no enter given into ’uncreated’ project
6.2.7 Supervisor Privileges - set Project Group size
The supervisor will have the ability to access a menu to set the minimum and maximum number
of people that can be in a Project group. Refer to figure 14 below:
Figure 14: Use-case: Supervisor Privileges - set Project Group size
Refer to SRS section 4.5.
6.2.8 Use ProjectPlace Help
The user will have the ability to use the ProjectPlace help option. Refer to figure 15 for the actions
that may be performed:
Figure 15: Use-case: Use ProjectPlace Help
Refer to SRS section 4.4.5. refer to section 7.4 for a sequence diagram depicting the modules and
interfaces, and interactions associated with this use case.
38
39. 6.2.9 Logout
The user is able to logout of ProjectPlace via the Common Room. Refer to the figure 16 below:
Figure 16: Use-case: Logout of Common Room
Refer to SRS section 4.2.4.
39
40. 6.3 Project Room
The user enters the Project Room once they choose to enter/continue an active project. Refer to
figure 17 for the actions that may be performed:
Figure 17: Use-case: Project Room
Refer to SRS sections 4.4.2, 4.4.2.2, 4.4.3.5, 4.4.4, 4.4.4.1 and 4.4.4.2.
User can also perform the following actions:
40
41. 6.3.1 Add Decision Log Entry for Action
The user will have the ability to add a decision log entry to justify any action they commit. Refer
to figure 18 for the actions that may be performed:
Figure 18: Use-case: Add Decision Log Entry
Refer to SRS section 4.4.3.2. Refer to section 7.7 for a sequence diagram depicting the modules,
interfaces, and interactions associated with this use case.
6.3.1.1 A Valid Scenario
1. User chooses action from ”standard” or ”user-defined” actions list
2. User writes justification for action committed
3. User submits decision
4. Action done
6.3.1.2 A Invalid Scenario
1. User chooses action from ”standard” or ”user-defined” actions list
2. User submits decision
3. Action not done; no decision justification given
41
42. 6.3.2 Chat/Post Messages in Project Room
The user will have the ability to communicate with other users in the Project Room. This will add
to the user’s contribution percentage, and also be appended to chat history. Refer to figure 19 for
the actions that may be performed:
Figure 19: Use-case: Chat/Post Messages in Project Room
Refer to SRS section 4.4.1.1. Refer to section 7.6 for a sequence diagram depicting the modules,
interfaces, and interactions associated with this use case.
42
43. 6.3.3 Analyse Statistics
The user will have the ability to view all statistics corresponding to the Project. Refer to figure 20
for the actions that may be performed:
Figure 20: Use-case: Analyse Statistics
Refer to SRS sections 4.4.2.1 and 4.4.2.2.
6.3.4 Use Project Help
The user will have the ability to use the project help option. Refer to figure 21 for the actions that
may be performed:
Figure 21: Use-case: Use Project Help
Refer to SRS sections 4.4.5 and 4.4.5.1. Refer to section 7.4 for a sequence diagram depicting the
modules and interfaces, and interactions associated with this use case.
6.3.4.1 A Valid Scenario
1. User chooses a help topic specific to the project
2. User views instructions on the chosen topic
43
44. 6.3.5 Exit Project Room
The user is able to exit the Project Room, to re-enter the Common Room. Refer to figure 22 below:
Figure 22: Use-case: Exit the Project Room
Refer to SRS section 4.4.7
6.4 Administrator Privileges - Administration Interface
The administrator has the ability to set the maximum number of users allowed to be in ProjectPlace,
view statistics, load and unload modules. Refer to figure 23 for the actions that may be performed:
Figure 23: Use-case: Use Case: Administrator Privileges
Refer to SRS sections ?? and ??.
6.4.1 A Valid Scenario
1. Administrator enters the maximum and minimum number of users that can be in one group
to complete a Project
2. Administrator sets the project time limit
3. Administrator browses for the full path of the file of the module that he/she wishes to load
into ProjectPlace
4. Administrator clicks on load module button
5. New module loaded into ProjectPlace
44
45. 6.4.2 A Invalid Scenario
1. Administrator sets the project time limit
2. Administrator browses for the full path of the file of the module that he/she wishes to load
into ProjectPlace
3. Administrator clicks on load module button
4. Error message results, as Administrator did not complete all fields to load a module
45
46. 7 Sequence Diagrams
The following section of the SADD displays sequence diagrams that depict the sequence of control
flow between modules of ProjectPlace when actions are performed by users as portrayed in the Use
Cases in section 6.
7.1 Server Startup
The sequence diagram illustrated in figure 24 below shows how the server loads at runtime.
Figure 24: Sequence Diagram: Server Startup
Figure 24 shows:
1. The Server Application first creates a new instance of the logger.
2. The Logger initiates the SQL database.
3. The Logger returns.
4. The Server Application Creates an instance of a Common Room, and sends a reference of the
logger to the Common room.
5. The Common Room Returns.
46
47. 7.2 Login
The sequence diagram illustrated in figure 25 below shows the sequence of events that occur when
a user logs into ProjectPlace and enters the common room.
Figure 25: Sequence Diagram: Client Login
Figure 25 shows:
1. The user enters his name and password through the Client Applet. The Client Applet sends
a reference of itself to the Server Application.
2. The Server Application verifys the username with the logger.
3. The Logger Validates the username with the database, and retrieves the user information.
4. The Database returns the information to the logger.
5. The Logger returns the information to the Server Application.
6. The Server Application creates a Client Interaction Thread to be associated with the client
7. The Client Interaction Thread returns control to the Server Application.
8. The Server Application sends a reference of the Client Interaction Thread to the Common
Room
9. The Common Room Returns.
10. The Server Returns a reference of the Common Room to the Client Applet.
47
48. 7.3 Common Room Chat
The sequence diagram illustrated in figure 26 below shows the sequence of events that occur when
a user sends a chat message in the common room.
Figure 26: Sequence Diagram: Common Room Chat
Figure 26 shows:
1. The user sending the message inputs the message to the Client Applet. The client applet
sends the message to the Common Room
2. The Common Room Sends the message to all client interaction threads for clients currently
in the Common Room. The Common Room returns to the Client Applet
3. Each Client Interaction thread sends the chat message to their associated client.
4. Each Client Interaction thread returns.
48
49. 7.4 Group Invitation
The sequence diagram illustrated in figure 27 below shows the sequence of events that occur when
a user invites other users to join a project.
Figure 27: Sequence Diagram: Group Invitation
Figure 27 shows:
1. The Inviter selects a user who he wants to invite to the group through the Client Applet.
The Client Applet sends the invitation to the Common Room
2. The common room sends a message to the Client Interaction thread of the invitee.
3. The Client Interaction thread of the invitee sends a message to the Client Applet of the invitee
informing it of the invitation.
4. The invitee either accepts or rejects the invitation through its client applet. The Client Applet
returns the acceptance or rejection to the Client Interaction thread.
5. The Client Interaction thread sends the result back to the Common Room.
6. The Common Room sends the result to the Client Interaction thread of the inviter.
7. The Client Interaction thread of the inviter informs the Client Applet of the result.
49
50. 7.5 Enter Project Room
The sequence diagram illustrated in figure 28 below shows the sequence of events that occur when
a user moves from the common room to the project room
Figure 28: Sequence Diagram: Enter Project Room
Figure 28 shows:
1. The User enters the Project Room through the Client Applet. The Client Applet sends a
request to the Common Room to enter the Project Room.
2. The Common Room requests a Project Room from the Server Application.
3. The Server Application creates a new Project Room, passing a reference of the Logger to it.
4. The Project Room creates a new instance of its associated Plugin.
5. The Plugin returns.
6. The Project returns its reference to the Server Application.
7. The Server Application Passes this reference to the Common Room.
8. The Common returns a reference to the Project Room to the Client Applet.
50
51. 7.6 Project Room Chat
The sequence diagram illustrated in figure 29 below shows the sequence of events that occur when
a user sends a message to chat in the Project Room.
Figure 29: Sequence Diagram: Project Room Chat
Figure 29 shows:
1. The User (Sender) sends the chat message through the Client Applet. The Client Applet
sends this message to the Project Room.
2. The Project Room sends the chat message to the logger to enter it into the database.
3. The Logger Returns
4. The Project Room sends the message to all Client Interaction threads currently in the Project
Room. The Project Room returns to the Client Applet of the sender.
5. The Client Interaction Threads send the chat message to their Client Applets.
6. The Client Applets return.
51
52. 7.7 Perform Action
The sequence diagram illustrated in figure 30 below shows the sequence of events that occur when
a user performs an action within a plugin and enters a decision log entry.
Figure 30: Sequence Diagram: Perform Action
Figure 30 shows:
1. The Project Room sends a message to the Client Applet, informing the client that it is its
turn to perform an action.
2. The Client Applet returns an action as well as a decision log entry.
3. The Project Room sends the Action to the Plugin.
4. The Plugin returns its current state, i.e. after the action was performed.
5. The Project Room sends the action and decision log entry to the Logger to update the
database.
6. The Logger returns.
7. The Project Room sends the current state of the plugin to all of the Client Interaction
Threads.
8. The Client Interaction Threads updates the state of all the Client Applets.
52
53. 8 Interface Description
8.1 Module Interfaces
The module interface diagram can be shown as follows:
Figure 31: The module interface diagram of the system
Arrows between modules in figure 31 indicate interactions between the two modules. An arrow
from one module to the other in the diagram indicates a method call from one module to the others.
Because of the teams choice to use the Java RMI technologies, all interaction between modules will
consist of method calls as RMI takes care of all the networking protocol.
As can be seen in the diagram, interactions between two specific modules are numbered. Below
is a description of each of these numbered interactions.
8.1.1 Interaction 1
1. Client Applet to Plugin - The Client Applet calls methods on the Plugin that update
changes in the Plugin area of the Clients screen. This update is specific to the plugin itself
and is defined by the Administrator that builds the plugin. For example, when a Client clicks
a button on the Plugin section of the ProjectRoom, the Administrator needs defined code
53
54. that calls a method in the Plugin module of the server updating it of the click. See the SDD
notes for a in-depth description of this interaction.
2. Plugin to Client Applet - The Plugin will call a method on the Client Applet instructing
it to update some parts of its on-screen Plugin section. This method is again defined by the
Administrator that builds the Plugin and a better description of this can be found in the
SDD notes.
8.1.2 Interaction 2
1. ProjectRoom to Plugin - The ProjectRoom initially creates the Plugin that the Clients
interact with. It then calls methods in the Plugin to tell which user is now in charge of making
decisions.
2. Plugin to ProjectRoom - The Plugin calls methods on the ProjectRoom to tell it to log
a certain piece of information, perhaps as part of the decision log. The Plugin also calls a
method on the ProjectRoom to indicate when a project is completed.
8.1.3 Interaction 3
1. ProjectRoom to Client Applet - The ProjectRoom calls a method on the Client Applet
to add a Chat Message to the on-screen display. It also calls a method to update who is
currently logged into this ProjectRoom.
2. Client Applet to ProjectRoom - The Client Applet calls methods on the ProjectRoom
to send Chat Messages to all the other participants in the project. It also calls methods to
add Decision Log entries to the Database, and to log out of the ProjectRoom.
8.1.4 Interaction 4
1. Server to Client Applet - When the Client initially contacts the Server, the Server calls a
method on the Client Applet that gives the client its unique ID number. The Client Applet
then uses this number in further interaction with the ProjectPlace Server.
2. Client Applet to Server - The Client Applet first calls a method on the Server to register
itself with the ProjectPlace server. The Server then passes a reference to the CommonRoom
to the Client Applet and the Client Applet has no further interaction with the Server.
8.1.5 Interaction 5
1. CommonRoom to Client Applet - The CommonRoom calls methods on the Client Applet
to update its client list, add a new chat message to the on-screen display and give notification
of group creation success or failure.
2. Client Applet to CommonRoom - The Client Applet calls methods on the CommonRoom
to send Chat Messages, logout of ProjectPlace and invite Clients to join a group to complete
a project. This request is then processed by the CommonRoom and sent to the appropriate
clients.
54
55. 8.1.6 Interaction 6
1. Server to Logger - The Server calls methods on the Logger to set and get database infor-
mation.
8.1.7 Interaction 7
1. CommonRoom to Logger - The CommonRoom calls methods on the Logger to set and
get database information.
8.1.8 Interaction 8
1. ProjectRoom to Logger - The ProjectRoom calls methods in the Logger to set and get
database information.
8.1.9 Interaction 9
1. ProjectRoom to CommonRoom - The ProjectRoom calls methods on the CommonRoom
to pass a Client back to the CommonRoom after completing a project. It also calls methods
on the CommonRoom to update it of clients connection status.
2. CommonRoom to ProjectRoom - Initially the CommonRoom creates the ProjectRoom
and passes a reference to the Client Applets of the Clients that are participating in the project.
After this interaction, the CommonRoom calls no methods on the ProjectRoom
8.1.10 Interaction 10
1. Server to CommonRoom - Initially the Server creates the CommonRoom and passes a
reference to the Logger to it. It then calls a method on the CommonRoom when it recieves
Client Applets to pass the Clients to the CommonRoom.
8.2 Graphical User Interfaces
This section describes the Administration User Interface, and lists the reference to all other Graph-
ical User Interfaces for ProjectPlace.
8.2.1 Administration Interface
This section describes the details of the Administration User Interface. This User Interface is a
stand-alone application, and must be run on the server.
The Administration Interface will consist of the following components, as illustrated in Figure 32
(above):
1. A ProjectPlace generic configuration box
2. Module specific configuration box
3. Help button
1. ProjectPlace generic configuration box
The ProjectPlace generic configuration box consists of:
55
56. Figure 32: Administration Interface.
(Note: Illustration is only a rough outline, final product may differ in appearance)
(a) ProjectPlace Maximum Users field - specifies the maximum number of users that
can be logged into ProjectPlace.
(b) ComboBox - list of all the Projects.
(c) Statistics button - Brings up the statistics window for the Project chosen in the
”ComboBox”. (refer to the SRS section 7.1.7 for details of the statistics window)
2. Module specific configuration box
The Module specific configuration box consists of:
(a) Module Maximum Users field - Specifies the maximum number of users that can be
on one group to complete a Project.
(b) Module Minimum Users field - Specifies the minimum number of users that can
form a Project group.
(c) Project Time limit field - sets the time allocated to complete a Project.
(d) Text field - Have the full path of the file of the module that will be loaded.
(e) Browse button - Brings up a file selector window.
(f) Load Module button - Loads the file in the ”text field” into ProjectPlace.
(g) Unload Module button - Unloads the file in the ”text field” from ProjectPlace.
56
57. 3. Help button - Brings up a help window.
8.2.2 Other Graphical User Interfaces
For all other Graphical User Interfaces, refer to the SRS section 7.1.
57
58. 9 Glossary
Action An operation performed by the User that will change the Plug-In
Apache web server
Back-End The database, and the rooms that hold information for the currently active rooms
Basic Users students
Client A User of ProjectPlace.
Client Applet The module a Client receives.
CM Client machine
Concurrently Describes when two or more processes or actions are running in concurrence, or at
the same time
CSSE Department of Computer Science and Software Engineering at the University of Melbourne
Database An organised body of information that is stored on a disk, that can be modified or read
from.
Dialog pop-up window
Group A collection of students, together whom will work on a problem.
GUI Graphical User Interface
HTML Hyper-Text Mark-up Language
Java Object oriented programming language
Java Applet A small program that is not intended to be run on its own, but rather to be embedded
inside another application.
Module Consists of the collaborative Problem, ”project”, to be worked on
MySQL A software package for creating SQL databases.
Persistence Refers to when
Plug-In A Specific model designed for ProjectPlace, ie: minesweeper
Port An entrance to or exit from a data network
Problem The task or problem. In the case of this project, the problem is in the form of a plug-in
that the Administrator has set for the Students to solve collaboratively.
Project A task or problem to be solved by the students
ProjectPlace The system formerly known as ’Collaborative Problem Solver’ will be renamed to
’ProjectPlace’ from this point on. This name will appear on the product interface and any
future documentation.
58
59. Project settings numbers of users per project
Room It is a place where a user communicates with other users given access to the same room,
by broadcasting messages. Throughout the SRS, a room is either a ”common” or a ”project”
room (refer to sections ?? and ?? of the GUI)
Relational Model The model representing the relationships between data entities.
RMI Remote Method Invocation: a java library for object communication and method calls across
a network.
SADD Software Architectural Design Document
Server The machine acting as a central point for collaborative communication. It runs the server-
side application.
SPMP Software Project Management Plan document
SPOC Single Point of Reference
SRS Software Requirements Specification document
System Settings amount of users allowed onto the whole system, ProjectPlace.
TP Test Plan document
Tuples Groups of two
User The party interacting with the Client Machine
Walk-through A thorough demonstration or explanation that details each step of the process.
UD User Documentation document ie:ProjectPlace manual
University The University of Melbourne
59
