Sdd 2

SoftwareArchitecture

Design Document

Collaborative Problem Solver

Revision : 3.0

Group ILilianne Tawil

Matthew ZwierEmily McIntyre

Michelle FreedmanWayne Johnson

October 30, 2003

Abstract

The SADD formally describes the architecture design for the proposed ProjectPlace. It setsout at a high level the modules, data structures, databases and interfaces that will be usedto implement the project. All essential requirements set out in the SRS are reflected in thearchitecture design. This serves as a basis for the Detailed Design, which describes the designof ProjectPlace in much greater detail.

1

Contents

1 Introduction 61.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Audience (Stakeholders) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.2 The Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.3 Team I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.4 440 Auditors/Reviewers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.5 Future Developers of the product . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.6 End-Users of ProjectPlace - Administrators and Supervisors . . . . . . . . . . 7

1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Product Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Definitions, acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Reference Documents 82.1 Internal Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Textbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 System Overview 93.1 Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Use Case Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.3 Class Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.4 Booch Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.5 Architecture Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.5.1 The Three-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Decomposition Description 124.1 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Module Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Client Applet Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.1.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.2 Server Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.2.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.3 Logger Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.3.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.4 Common Room Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.4.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2

4.2.5 Project Room Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.5.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.6 Plugin Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.6.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Concurrent Process Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.1 Client Process Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 Server Process Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.3 Client Talker Process Description . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Data Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.1 Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.2 Data Storage Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.3 User Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4.4 ProjUser Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.5 Project Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.6 Plugin Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.7 System Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.8 Log Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Dependency Description 295.1 Module Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Module: Client Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2 Module: Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.3 Module: Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.4 Module: Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.5 Module: Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.6 Module: Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Data Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.1 Client Applet - Common Room, Project Room, Module relationship . . . . . 325.2.2 Database - Common Room, Project Room, Module relationship . . . . . . . 32

6 Use Cases 336.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.1 Chat/Post Messages in Common Room . . . . . . . . . . . . . . . . . . . . . 346.2.2 Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.2.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.2.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.3 Accept/Reject Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.4 Assign Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.5 Change Colour Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.6 Enter/Continue Created Projects . . . . . . . . . . . . . . . . . . . . . . . . . 37


6.2.7 Supervisor Privileges - set Project Group size . . . . . . . . . . . . . . . . . . 38

3

6.2.8 Use ProjectPlace Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.9 Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.3.1 Add Decision Log Entry for Action . . . . . . . . . . . . . . . . . . . . . . . . 41


6.3.2 Chat/Post Messages in Project Room . . . . . . . . . . . . . . . . . . . . . . 426.3.3 Analyse Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3.4 Use Project Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3.4.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3.5 Exit Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4 Administrator Privileges - Administration Interface . . . . . . . . . . . . . . . . . . . 446.4.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.4.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Sequence Diagrams 467.1 Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.3 Common Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.4 Group Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.5 Enter Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.6 Project Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.7 Perform Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8 Interface Description 538.1 Module Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.1.1 Interaction 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.1.2 Interaction 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.3 Interaction 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.4 Interaction 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.5 Interaction 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.6 Interaction 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1.7 Interaction 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1.8 Interaction 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1.9 Interaction 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1.10 Interaction 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.2 Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.1 Administration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.2 Other Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 57

9 Glossary 58

4

List of Figures

1 The Top-level Architecture of ProjectPlace. . . . . . . . . . . . . . . . . . . . . . . . 112 The inputs and outputs of the system - both Client and Server side. . . . . . . . . . 123 The second-level design of ProjectPlace. . . . . . . . . . . . . . . . . . . . . . . . . . 144 Relationship Schema Diagram - Database Model . . . . . . . . . . . . . . . . . . . . 235 The collaboration diagram of the modules that are in the system. . . . . . . . . . . . 296 Use-case: Login to ProjectPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Use-case: Entry into Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Use-case: Chat/Post Messages in Common Room . . . . . . . . . . . . . . . . . . . 349 Use-case: Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3510 Use-case: Accept/Reject Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3611 Use-case: Assign Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3612 Use-case: Change Colour Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . 3713 Use-case: Enter/Continue Created Projects . . . . . . . . . . . . . . . . . . . . . . . 3714 Use-case: Supervisor Privileges - set Project Group size . . . . . . . . . . . . . . . . 3815 Use-case: Use ProjectPlace Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3816 Use-case: Logout of Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . 3917 Use-case: Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4018 Use-case: Add Decision Log Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4119 Use-case: Chat/Post Messages in Project Room . . . . . . . . . . . . . . . . . . . . 4220 Use-case: Analyse Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4321 Use-case: Use Project Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4322 Use-case: Exit the Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4423 Use-case: Use Case: Administrator Privileges . . . . . . . . . . . . . . . . . . . . . . 4424 Sequence Diagram: Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4625 Sequence Diagram: Client Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4726 Sequence Diagram: Common Room Chat . . . . . . . . . . . . . . . . . . . . . . . . 4827 Sequence Diagram: Group Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . 4928 Sequence Diagram: Enter Project Room . . . . . . . . . . . . . . . . . . . . . . . . 5029 Sequence Diagram: Project Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . 5130 Sequence Diagram: Perform Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 5231 The module interface diagram of the system . . . . . . . . . . . . . . . . . . . . . . 5332 Administration Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

List of Tables

1 User Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 ProjUser Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Project Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Plugin Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 System Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Log Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5

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 acomprehensive overview of the proposed system. It uses a number of architectural decompositionsto depict the di!erent aspects, corresponding with the requirements of the Client as portrayed inthe SRS. All requirements with be incorporated into this architectural design, depicting at a highlevel the appropriate modules, data structures, databases and interfaces. This document serves asa 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-mailMs Antonette Mendoza [email protected]

1.2.2 The Supervisor

Name E-mailMs Kathleen Keogh [email protected]

1.2.3 Team I

Team I will make use of this document in the design, implementation and testing phases of theproject.

Name E-mailMichelle Freedman [email protected] Johnson [email protected] McIntyre [email protected] Tawil [email protected] Matthew Zwier [email protected]

1.2.4 440 Auditors/Reviewers

440 Auditors/Reviewers will review and audit this document.Name E-mailAndrew Ayres [email protected] Sholl [email protected] Strunga [email protected] Tham [email protected] Tanto [email protected]

6

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 structureof 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 indeveloping ProjectPlace. Communicating at a purposefully high level, it will only form the basis forthe Software Detailed Design and implementation. However, the SADD itself will not be in su"cientdetail to implement the code. It will convey the overall system design of ProjectPlace, the userinterface 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 willbe 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 basedextensions, 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 ofMelbourne’s Department of Computer Science machines - machines with access to the web, JavaVirtual 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 ormore groups. This user will be there to monitor the groups’ progress and help with any issuesencountered while solving a project, or using ProjectPlace.

• Student - These are the users who will be collaboratively solving the problem posed by theAdministrator.

1.5 Existing System

There is no existing system that the client, or the Department of Computer Science and SoftwareEngineering, use for collaborative problem solving. The idea was constructed based on the currentneeds of the department.

7

2 Reference Documents

This section lists all of the textbooks, documents and manuals that assisted in the development ofthis 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 Std1471-2000.

2. Recommended Practice for Software Design Descriptions IEEE Std 1016-1998.

8

3 System Overview

ProjectPlace is a system designed to allow a class of students to interact and chat online in real-timeto work and solve a given problem. It is being written for the client Ms. Antonette Mendoza of theComputer 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 studentswork 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 designmethodology. The SRS also specifies the need for a highly modular approach to the software, asemphasised in the requirement of ’plug-in’ Project modules. The Booch method was chosen due toJava being the programming language and Java is used most e!ectively in an OO context. Referto 3.1.4 for details on the Booch Method.

ProjectPlace is a user oriented system, that requires a robust server in order to process multipleuser requests. This can be accommodated under an OO methodology, as the larger system can bebroken down into smaller, manageable pieces. With OO, the module structure and dependenciesof 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 forProjectPlace:

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 toolfor Team I, in formulating the architecture. Use cases were created as part of the SRS, and thesehave been extended upon in the SADD, to aid in modelling the actions of users. Refer to section6 to view the use cases.

9

3.1.3 Class Modelling

After deciding to adopt an OO approach, class modelling was conducted to determine the classesneeded. Use cases were consulted to aid in deciding what behaviour should be implemented in whichclasses. 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 corerequirements of ProjectPlace is that it must be implemented in the Java Programming language.Java code is designed most e!ectively 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, thatis 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 lowcoupling and high cohesion. This will facilitate the projects development, and will ensure a moremaintainable 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, SequenceDiagrams, Collaboration Diagrams.For more information on the Booch methodology, refer to Object-Oriented Design and Principalsas 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 chosenfor ProjectPlace.A graphical representation of the system is shown in figure 1.

10

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 theGUI to the user. It simply relays information passed to it by the Server and sends informationto 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, andmanipulates 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 informationthat 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 informationis centralised through the server, which sends the current state of the system out to the clients. Inessence all that the clients have is the GUI. All of the work is done by the server and all of theinformation 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 underlyingarchitecture.

11

4 Decomposition Description

In this section of the SADD, a top level description of ProjectPlace will be given, breaking it intoits module constituents and explaining their interaction. The modules in the system contain publicmethods for input and output between them, run concurrent processes and use data that has beenmodified 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 withthe servers ProjectPlace server. All interaction with the server is then done with the ProjectPlaceserver. This diagram shows the inputs an outputs of the system as a whole, the inputs and outputsof 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 informationfrom it.

5. The Logger receives input from the Server, ProjectRoom and CommonRoom modules toobtain information from the database. See section 4.2.3.

6. The ProjectRoom and CommonRoom modules receive input from the client applet. Seesections 4.2.4 and 4.2.5.

12

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, CommonRoomand 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

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 inthe 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 interactwith the server. This module with be exported to the server, meaning that a reference to it will begiven to the server using RMI technologies so that the server can easily call methods on the ClientApplet. The Client Applet will only contain methods to update the Server of user interaction withthe 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 thatthe ProjectRoom and CommonRoom can call to give it input. Since it also has a reference tothe Project and Common Rooms, it can call methods on them passing information that the GUIprovides such as sending a chat message or inviting a group of people to complete a project. Thepublic methods of this module are:

14

1. public void receive message(Message message)

This method is called by the Common Room or Project Room, when a message has been sentto the chat window from another client. It takes as its argument a Message object and willpost 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 forthis 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 hasbeen 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 userscurrently 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. Sincethis module is exported remotely using the RMI technologies (See Glossary), the Client receives areference to this module. The Server then handles all authentication procedures and initial setupof the connection and then passes a reference of the CommonRoom to the client so that the clientcan start interacting with the CommonRoom. It is also the first module that is created whenProjectPlace is started, and subsequently instantiates the CommonRoom and Logger modules.The server is essentially a doorman that greets the Clients.


The Server Module receives initial contact from the client applet, and outputs a reference of theCommonRoom 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 theClient. It verifies a user login with the database and if successful, returns the CommonRoomclass 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 modulesand the database. It is a Java class that is created by the server and passed to the CommonRoomand then onto the ProjectRoom and provides an easy to use interface containing methods that arecalled to query, add and delete data from the database.

15


The Logger provides methods to add, remove and modify data in the database. A module can thensimply call methods on the Logger class which queries the database and returns the appropriatevalues. The public methods of this module are:

1. public Object[][] DBget(String attribute, String table, String idAttribute, Stringid)

The DBGet() method retrieves information from the database, and returns this informationto 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 userto post messages to a global chat, and provides methods that allow Clients to form groups andinvite these groups to complete a project. It also provides methods that allow the Clients to logout of ProjectPlace.


Its inputs are methods that the Client calls to post messages etc. Its outputs are method calls tothe Logger to set, delete and add data to the database, and method calls to the Client Applet toupdate 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 theme 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 availableplugins 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 savedprojects 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 groupthat has been generated by a single Client and sends invites out to the appropriate clients.

16

5. public void acceptProjectInvite(String invitee, PPGroup group)

The acceptProjectInvite() method is called by a remote Client Applet. It is a method usedby 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 theClient 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 issolving a project. It contains a plugin that defines the problem they are to solve and provides thegeneric functionality that the ProjectRoom is to provide. This is such things as a chat, just likethe CommonRoom and also provides a Decision log and a timer bar so the Clients can keep an eyeon their progress with respect to the time limit that is imposed by the Administrator.


The ProjectRoom is passed a reference to all the Client Applet’s that will be participating in theproject. A reference to it is also passed to all the Clients so that the client can call methods on theProjectRoom, 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 publicmethods 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 messageto 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 projectroom 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 justifythis 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 Administratorwill create that will pose a problem to the clients that they must solve. The plugin interface will beas lowly coupled with the Project Room module as possible so that the Administrator can createmore Plugins with ease.

17


The inputs to this program are method calls from the Client to update some module of the pluginand the outputs are method calls to the Clients to update Plugin part of their GUI interface. Itwill also output log information to the ProjectRoom that will then be forwarded on to the Logger.

18

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 processesrunning in the server all of which require access to the database. In order to prevent critical sectionproblems with shared data, a single acces point has been created to the database through thelogger.The processes can be split up as follows:

1. ClientEach Client is run on di!erent machines and will hence have its process running separatefrom the server. The client process calls methods on the server from time to time. See items2 and 3 below on how this process interaction is handled.

2. ServerThere is only one Server running on one computer in the system. The Server, comprising theServer, 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 cannotcall methods on the clients directly, else the whole ProjectPlace will hang while it tries to do asimple method call on a remote computer. This is solved by the Client Talkers, described next.

3. Client TalkersEach time a client connects to ProjectPlace, a client talker is created to handle method callson the client. All interaction between the server and the client is handled through thesetalkers. Essentially the CommonRoom or ProjectRoom etc post messages to be sent to theclient with the Client Talkers. These messages are put into a queue, and are sent one by oneto the client.

4.3.1 Client Process Description

The Client Process can be broken up and described as follows:

1. Identification:ProjectPlace Client

19

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 ServerClient communication process.Server-Database interface.

20

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 appropriateUser’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

4.4 Data Decomposition

This section contains a description of each data element that is shared between components, itspersistence (or its lifetime), and its logical structure (but not its representation in a programminglanguage).

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 pointof reference for the data-sharing, the system will use internal ’somewhat temporary’ variables topass information onto the relevant section. For example, the attributes of the plug-in can bepassed through variables, while the attributes when inactive can be stored in the database for laterreference.

4.4.2 Data Storage Overview

In order for the ProjectPlace system to function, it must have access to a database such as MySQLwhich contains information about the System, Project (Problem with Users associated), as well asUsers. The Database is constructed using the relational model, which means that links can be madebetween the various tables, and between attributes in those tables, allowing complex relationshipsto be modelled.

The main principle of the relational model is to allow updates of tuples in the table without ad-versely a!ecting other data. The relation must be structured in a way so that redundancy anddependency are reduced as much as possible within the Database. This would include implementingsingle point of contact for all attributes, with reference from other data tables when necessary.

22

Figure 4, below, shows the relationship between the di!erent data entities and attributes in thesystem’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 thatfurther diagrams were not necessary. The Database Schema in more detail will be presented in thefollowing 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

4.4.3 User Data Table

A User, in this data model, is someone who has registered (logged on one or more times) and whoseinformation is thus stored in the Database. This data table also includes associated statistics. Thisdata table (Database Schema) indicates the required attributes (non-NULL) with the use of anasterisk (*).

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 SmithUserDOB Date - Date of Birth 18/01/1982UserEmail String containing an email address [email protected] Integer containing a phone number 92053983UserComment 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, ExpiredA 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 = neverUserLoginID 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 NStatistics These entries are for statistical purposes*UserLStatus Login Status, Y=Logged in, N=Logged out YUserLstLogTime YYYYMMDDHHMMSS, Last LoginTime 20030701131532UserLstLogDura Integer (secs), On logout, Now-LstLogTime 3241UserTotLogDura Integer (secs), Sum - Increases on logout 18291

Table 1: User Data Table

24

4.4.4 ProjUser Data Table

This data model is the relational table between the Project and all its Users. A ProjUser is aUser that belongs to a Project. The following data table (Database Schema) indicates the requiredattributes (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 outY is the default - initial value

*puLStatus Character indicating Room Login Status Y! Y = User is in room! N = User not in roomN is the default - initial value

*puControl Indicating if User is in control of room Y! Y = In control! N = Not in controlN is the default - initial value

Statistics These entries are for statistical purposespuLstLogTime YYYYMMDDHHMMSS, Last LoginTime to room 20030701131532puLstLogDura Integer (secs), Derived on logout of room 18291puTotLogDura Integer (secs), Sum. Increases on room logout 42291puLstCtlTime YYYYMMDDHHMMSS, Last Conrol Restart Time 20030701131532puLstCtlDura Integer (secs), Derived on control loss 18291puTotCtlDura Integer (secs), Sum. Increases on control loss 38291

Table 2: ProjUser Data Table

25

4.4.5 Project Data Table

A project in this data model is a collection of attributes to completely describe a project. It containstype, length and restrictions of a project and its Users. The project creator sets the majority ofattributes on project creation. Some fields have default values defined in the System table. Thisdata 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 MazeProjPurpose Short text - User-defined project description A maze to solve.*ProjType Character indicating Type N

! N = Normal*ProjCreated YYYYMMDDHHMMSS, time account created 20020301162452ProjCUser Created By UserID smithj*ProjAStatus Character indicating Accessibility Status N

! I = Inactive, Accessible! A = Active, Accessible! N = Inaccessible, insu"cient accepted participants! S = Inaccessible, by Supervisor! X = Inaccessible, Expired! V = Visitor ModeI is the default - initial value

*ProjExpires YYYYMMDDHHMMSS, time account expires 2004010100000000000000000000 = never

ProjManager Manager UserID, selected from ProjUser table smithjProjUserMin Min accepted participants for proj to be accessible 2ProjUserMax Max ” 5ProjSupervisor UserID supervisor list [smithj, jonesj]

Table 3: Project Data Table

26

4.4.6 Plugin Data Table

This contains a list of all plug-in modules available to projects and some attributes. The atributesmay be modified by the plug-in author only when inserted into ProjectPlace. The following datatable (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/modulePlugDesc 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 Projectand 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, allthe variables and potential variables in ProjectPlace will be defined, even if there is currently nooption 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 datatable). The system initiator (the first person to start up ProjectPlace) could be given the optionto change the preferences on initialisation. Even if not implemented in our system, the optionremains 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 therequired 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=verboseSysPortNumb Listening Port 8000

Table 5: System Data Table

27

4.4.8 Log Data Table

This contains the system’s audit data. It may contain all client commands and system errormessages. 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 20030701131532LogServerID This Server ID s3439LogUserID Related UserID smithjLogProjID Related ProjectID 3243LogCommand Protocol command code received lgiLogParameter Parameter along with command 345 smithLogMessage Log message helloWorld

Table 6: Log Data Table

28

5 Dependency Description

The following section will describe the relationship between each given module of the system withthe other modules of the system.

5.1 Module Dependencies

This section outlines the dependencies and interactions in the modules defined in Section 4.2. Figure5 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 ona button in their browser or entering text into a text field (chat text).

29

2. Server

The Client Applet then processes this information and calls methods on the Server to initialisecontact and pass a reference of itself to the Server.

3. CommonRoom

The Client Applet calls methods on the CommonRoom to send Chat Messages, Logout andCreate 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 projector 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 returnsto the Client a reference to the CommonRoom and ProjectRoom. It does not call methodson the client at all.

2. Logger

The Server gets and sets information in the database through the Logger, and also creates aninstance 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 areference.

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 anddelete data elements from the database.

2. MySQL Database

The Logger passes information to the Database. It also queries the Database and retrievesinformation 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 theparticipants of the project to it, along with a reference to the Logger 5.1.3. After that theCommonRoom has no interaction with the ProjectRoom.

30

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 messagesto 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 theplugin.

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

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 Roomand 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 thedatabase.

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 dependenton 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 inthe 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 reflectedon all of the Client GUI’s. Therefore the Client GUI is dependent on the data that is generatedfrom these modules. For instance, the Common Room may have received chat text from one of itsusers, this text is then passed to all the other users in the Common Room updating their screenwith 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, ProjectRoom 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 textthat is logged for the supervisor to check through when marking the project. This text needs to belogged to the Database and therefore the Database is dependent on this data that is being passedfrom the Project Room.

The Project Room, Common Room and Plug-In are also dependent on the information stored inthe Database. An example of this is the recalling of a saved project by the Common Room for auser. When the user goes to reload an unfinished project, this information must be retrieved fromthe Database, hence the Common Room is dependent on the data in the Database.

32

6 Use Cases

This section contains use cases demonstrating the desired functionality of ProjectPlace. The usecases were derived from the requirements for ProjectPlace, which can be found in the SRS. Use-casescenarios 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. Usersmay also change their password. Also, if the user has forgotten their password, it may be changed byan 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 depictingthe 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

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 tofigure 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 andinterfaces, and interactions associated with this use case.

34

6.2.2 Create Project

The user will have the ability to create a new project, by choosing a module and inviting otherusers within the common room to join their group. The project will be created once the minimumamount of users needed to form the specific project have accepted their invitation. Refer to figure9 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

6.2.3 Accept/Reject Invitation

The user will have the ability to view all invitations to projects they have been assigned, and acceptor 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 willchoose a Module and allocate students to a group. Refer to figure 11 for the actions that may beperformed:

Figure 11: Use-case: Assign Groups

36

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 inthe 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 tofigure 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, asonly the Users ”active” projects will appear in their active projects list. Users may only enter orcontinue active projects. (refer to SRS section 4.2.2.5)


1. User clicks on a project in their ”active projects” list

2. User clicks ”Enter”

3. User has entered the chosen project

37


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 numberof 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 actionsthat 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 andinterfaces, and interactions associated with this use case.

38

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

6.3 Project Room

The user enters the Project Room once they choose to enter/continue an active project. Refer tofigure 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

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. Referto 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.


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


1. User chooses action from ”standard” or ”user-defined” actions list

2. User submits decision

3. Action not done; no decision justification given

41

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 addto the user’s contribution percentage, and also be appended to chat history. Refer to figure 19 forthe 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

6.3.3 Analyse Statistics

The user will have the ability to view all statistics corresponding to the Project. Refer to figure 20for 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 thatmay 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 themodules and interfaces, and interactions associated with this use case.


1. User chooses a help topic specific to the project

2. User views instructions on the chosen topic

43

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 groupto 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 loadinto ProjectPlace

4. Administrator clicks on load module button

5. New module loaded into ProjectPlace

44

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 loadinto ProjectPlace

3. Administrator clicks on load module button

4. Error message results, as Administrator did not complete all fields to load a module

45

7 Sequence Diagrams

The following section of the SADD displays sequence diagrams that depict the sequence of controlflow between modules of ProjectPlace when actions are performed by users as portrayed in the UseCases 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 thelogger to the Common room.

5. The Common Room Returns.

46

7.2 Login

The sequence diagram illustrated in figure 25 below shows the sequence of events that occur whena 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 sendsa 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 CommonRoom

9. The Common Room Returns.

10. The Server Returns a reference of the Common Room to the Client Applet.

47

7.3 Common Room Chat

The sequence diagram illustrated in figure 26 below shows the sequence of events that occur whena 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 appletsends the message to the Common Room

2. The Common Room Sends the message to all client interaction threads for clients currentlyin 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

7.4 Group Invitation

The sequence diagram illustrated in figure 27 below shows the sequence of events that occur whena 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 inviteeinforming it of the invitation.

4. The invitee either accepts or rejects the invitation through its client applet. The Client Appletreturns 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

7.5 Enter Project Room

The sequence diagram illustrated in figure 28 below shows the sequence of events that occur whena 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 arequest 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

7.6 Project Room Chat

The sequence diagram illustrated in figure 29 below shows the sequence of events that occur whena 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 Appletsends 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 ProjectRoom. 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

7.7 Perform Action

The sequence diagram illustrated in figure 30 below shows the sequence of events that occur whena 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 itsturn 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 thedatabase.

6. The Logger returns.

7. The Project Room sends the current state of the plugin to all of the Client InteractionThreads.

8. The Client Interaction Threads updates the state of all the Client Applets.

52

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 arrowfrom 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 willconsist 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. Belowis 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 updatechanges in the Plugin area of the Clients screen. This update is specific to the plugin itselfand is defined by the Administrator that builds the plugin. For example, when a Client clicksa button on the Plugin section of the ProjectRoom, the Administrator needs defined code

53

that calls a method in the Plugin module of the server updating it of the click. See the SDDnotes for a in-depth description of this interaction.

2. Plugin to Client Applet - The Plugin will call a method on the Client Applet instructingit to update some parts of its on-screen Plugin section. This method is again defined by theAdministrator that builds the Plugin and a better description of this can be found in theSDD notes.

8.1.2 Interaction 2

1. ProjectRoom to Plugin - The ProjectRoom initially creates the Plugin that the Clientsinteract with. It then calls methods in the Plugin to tell which user is now in charge of makingdecisions.

2. Plugin to ProjectRoom - The Plugin calls methods on the ProjectRoom to tell it to loga certain piece of information, perhaps as part of the decision log. The Plugin also calls amethod 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 Appletto add a Chat Message to the on-screen display. It also calls a method to update who iscurrently logged into this ProjectRoom.

2. Client Applet to ProjectRoom - The Client Applet calls methods on the ProjectRoomto send Chat Messages to all the other participants in the project. It also calls methods toadd 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 amethod on the Client Applet that gives the client its unique ID number. The Client Appletthen 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 registeritself with the ProjectPlace server. The Server then passes a reference to the CommonRoomto 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 Appletto update its client list, add a new chat message to the on-screen display and give notificationof group creation success or failure.

2. Client Applet to CommonRoom - The Client Applet calls methods on the CommonRoomto send Chat Messages, logout of ProjectPlace and invite Clients to join a group to completea project. This request is then processed by the CommonRoom and sent to the appropriateclients.

54

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 andget database information.

8.1.8 Interaction 8

1. ProjectRoom to Logger - The ProjectRoom calls methods in the Logger to set and getdatabase information.

8.1.9 Interaction 9

1. ProjectRoom to CommonRoom - The ProjectRoom calls methods on the CommonRoomto pass a Client back to the CommonRoom after completing a project. It also calls methodson the CommonRoom to update it of clients connection status.

2. CommonRoom to ProjectRoom - Initially the CommonRoom creates the ProjectRoomand 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 areference to the Logger to it. It then calls a method on the CommonRoom when it recievesClient 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 astand-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 boxThe ProjectPlace generic configuration box consists of:

55

Figure 32: Administration Interface.(Note: Illustration is only a rough outline, final product may di!er in appearance)

(a) ProjectPlace Maximum Users field - specifies the maximum number of users thatcan 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 boxThe Module specific configuration box consists of:

(a) Module Maximum Users field - Specifies the maximum number of users that can beon one group to complete a Project.

(b) Module Minimum Users field - Specifies the minimum number of users that canform 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

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

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 atthe 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 readfrom.

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 embeddedinside 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-inthat 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 anyfuture documentation.

58

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 acrossa 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