Professional Documents
Culture Documents
Architecture
Design Document
Collaborative Problem Solver
Revision : 3.0
Group I
Lilianne Tawil
Matthew Zwier
Emily McIntyre
Michelle Freedman
Wayne Johnson
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
Contents
1 Introduction 6
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Audience (Stakeholders) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 The Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Team I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 440 Auditors/Reviewers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.5 Future Developers of the product . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.6 End-Users of ProjectPlace - Administrators and Supervisors . . . . . . . . . . 7
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Product Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Definitions, acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Reference Documents 8
2.1 Internal Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Textbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 System Overview 9
3.1 Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Use Case Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 Class Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Booch Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Architecture Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5.1 The Three-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Decomposition Description 12
4.1 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Module Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 Client Applet Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2 Server Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3 Logger Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Common Room Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2
4.2.5 Project Room Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6 Plugin Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6.2 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Concurrent Process Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 Client Process Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 Server Process Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Client Talker Process Description . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Data Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.1 Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.2 Data Storage Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.3 User Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.4 ProjUser Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.5 Project Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.6 Plugin Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.7 System Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.8 Log Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Dependency Description 29
5.1 Module Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Module: Client Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2 Module: Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Module: Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.4 Module: Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.5 Module: Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.6 Module: Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Data Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Client Applet - Common Room, Project Room, Module relationship . . . . . 32
5.2.2 Database - Common Room, Project Room, Module relationship . . . . . . . 32
6 Use Cases 33
6.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1 Chat/Post Messages in Common Room . . . . . . . . . . . . . . . . . . . . . 34
6.2.2 Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.2.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.2.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.3 Accept/Reject Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.4 Assign Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.5 Change Colour Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.6 Enter/Continue Created Projects . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.6.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.6.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.7 Supervisor Privileges - set Project Group size . . . . . . . . . . . . . . . . . . 38
3
6.2.8 Use ProjectPlace Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.9 Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3 Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.1 Add Decision Log Entry for Action . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.1.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.1.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.2 Chat/Post Messages in Project Room . . . . . . . . . . . . . . . . . . . . . . 42
6.3.3 Analyse Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.4 Use Project Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.4.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.5 Exit Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Administrator Privileges - Administration Interface . . . . . . . . . . . . . . . . . . . 44
6.4.1 A Valid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4.2 A Invalid Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7 Sequence Diagrams 46
7.1 Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3 Common Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.4 Group Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.5 Enter Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.6 Project Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.7 Perform Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8 Interface Description 53
8.1 Module Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1.1 Interaction 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1.2 Interaction 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.3 Interaction 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.4 Interaction 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.5 Interaction 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.6 Interaction 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.7 Interaction 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.8 Interaction 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.9 Interaction 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.10 Interaction 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2.1 Administration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2.2 Other Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 57
9 Glossary 58
4
List of Figures
1 The Top-level Architecture of ProjectPlace. . . . . . . . . . . . . . . . . . . . . . . . 11
2 The inputs and outputs of the system - both Client and Server side. . . . . . . . . . 12
3 The second-level design of ProjectPlace. . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Relationship Schema Diagram - Database Model . . . . . . . . . . . . . . . . . . . . 23
5 The collaboration diagram of the modules that are in the system. . . . . . . . . . . . 29
6 Use-case: Login to ProjectPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Use-case: Entry into Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 Use-case: Chat/Post Messages in Common Room . . . . . . . . . . . . . . . . . . . 34
9 Use-case: Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10 Use-case: Accept/Reject Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11 Use-case: Assign Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12 Use-case: Change Colour Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13 Use-case: Enter/Continue Created Projects . . . . . . . . . . . . . . . . . . . . . . . 37
14 Use-case: Supervisor Privileges - set Project Group size . . . . . . . . . . . . . . . . 38
15 Use-case: Use ProjectPlace Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
16 Use-case: Logout of Common Room . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
17 Use-case: Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
18 Use-case: Add Decision Log Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
19 Use-case: Chat/Post Messages in Project Room . . . . . . . . . . . . . . . . . . . . 42
20 Use-case: Analyse Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
21 Use-case: Use Project Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
22 Use-case: Exit the Project Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
23 Use-case: Use Case: Administrator Privileges . . . . . . . . . . . . . . . . . . . . . . 44
24 Sequence Diagram: Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
25 Sequence Diagram: Client Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
26 Sequence Diagram: Common Room Chat . . . . . . . . . . . . . . . . . . . . . . . . 48
27 Sequence Diagram: Group Invitation . . . . . . . . . . . . . . . . . . . . . . . . . . 49
28 Sequence Diagram: Enter Project Room . . . . . . . . . . . . . . . . . . . . . . . . 50
29 Sequence Diagram: Project Room Chat . . . . . . . . . . . . . . . . . . . . . . . . . 51
30 Sequence Diagram: Perform Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
31 The module interface diagram of the system . . . . . . . . . . . . . . . . . . . . . . 53
32 Administration Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
List of Tables
1 User Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 ProjUser Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Project Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Plugin Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 System Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6 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 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.
Name E-mail
Ms Antonette Mendoza mendozaa@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
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.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.
7
2 Reference Documents
This section lists all of the textbooks, documents and manuals that assisted in the development of
this document.
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.
8
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.
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:
3. Usability of ProjectPlace
9
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.
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.
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.
1. Analysing the system as a whole and breaking it down into a specific architectural pattern.
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.
10
Figure 1: The Top-level Architecture of ProjectPlace.
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
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.
Figure 2: The inputs and outputs of the system - both Client and Server side.
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, CommonRoom
and ProjectRoom Modules.
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.
This is a description of the name, purpose or role, and function of each of the components in
the design.
14
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
15
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:
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.
16
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.
17
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
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.
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.
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
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
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).
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
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.
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 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 (*).
24
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 (*).
25
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 (*).
26
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
(*).
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.
27
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 (*).
28
5 Dependency Description
The following section will describe the relationship between each given module of the system with
the other modules of the system.
Figure 5: The collaboration diagram of the modules that are in the system.
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
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.
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.
2. MySQL Database
The Logger passes information to the Database. It also queries the Database and retrieves
information stored in the Database.
30
2. Server
See section 5.1.2.
3. Logger
See section 5.1.3
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.
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 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.
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.
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
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.
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.
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
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:
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
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:
4. More than minimum amount of Users needed to form the project accept
5. Project Created
4. Less than the minimum amount of Users needed to form the project accept
35
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:
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:
NOTE: View displayed current colour refers to the User being able see their current colour in
the common room.
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)
37
6.2.6.2 A Invalid Scenario
1. User clicks on a project in their ”inactive projects” list
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
6.2.9 Logout
The user is able to logout of ProjectPlace via the Common Room. Refer to the figure 16 below:
39
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:
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.
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. Refer
to figure 18 for the actions that may be performed:
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.
4. Action done
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 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:
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 20
for the actions that may be performed:
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.
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:
3. Administrator browses for the full path of the file of the module that he/she wishes to load
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 load
into ProjectPlace
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 control
flow between modules of ProjectPlace when actions are performed by users as portrayed in the Use
Cases in section 6.
Figure 24 shows:
4. The Server Application Creates an instance of a Common Room, and sends a reference of the
logger to the Common room.
46
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 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.
3. The Logger Validates the username with the database, and retrieves the user information.
6. The Server Application creates a Client Interaction Thread to be associated with the client
8. The Server Application sends a reference of the Client Interaction Thread to the Common
Room
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 when
a user sends a chat message in the common room.
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.
48
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 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
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 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.
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 when
a user sends a message to chat in the Project Room.
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.
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.
51
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 shows:
1. The Project Room sends a message to the Client Applet, informing the client that it is its
turn to perform an action.
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.
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
8 Interface Description
8.1 Module Interfaces
The module interface diagram can be shown as follows:
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
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
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.
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.
3. Help button
55
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)
(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
3. Help button - Brings up a help window.
57
9 Glossary
Action An operation performed by the User that will change the Plug-In
Back-End The database, and the rooms that hold information for the currently active rooms
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.
Java Applet A small program that is not intended to be run on its own, but rather to be embedded
inside another application.
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.
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
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.
Server The machine acting as a central point for collaborative communication. It runs the server-
side application.
System Settings amount of users allowed onto the whole system, ProjectPlace.
Walk-through A thorough demonstration or explanation that details each step of the process.
59