Uploaded on

FOR TEST

FOR TEST

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,288
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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