System and Software Architecture Description

System and Software Architecture Description (SSAD) Version 2.2

California Science Center Volunteer Tracking System

Team #3

Phongphan Danphitsanuphan Project Manager Charlie Lormanometee Project Coordinator / QA Deepak Pandey Software System Requirements Analyst Pongtip Aroonvatanaporn System Architect / Programmer Natachart Laoteppitak Software Architect / Programmer Ritesh Kothari Tester / Programmer Amit Shah IV & V Jerome Wan IV & V Jeremy Stoller Client Raul Pereyra User Vincent Tsan Maintainer

1 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2

Version History

Date Author Version Changes made Rationale

10/8/06 PA, NL 1.0 SSAD for LCO Draft Initial draft of SSAD

10/10/06 PA 1.1 Added Use-Case 2.3.1.30 Changes after inspection Added Use-Case 2.3.1.32 Added Use-Case 2.3.1.33 Added System Class UML Diagram In Use-Case 2.3.1.30, change from Automated Award Tracking to Automated Hour and Award Tracking 10/20/06 PA 2.0 Deleted Figure 2 System Class Diagram Changes made based on the suggestions Added Section 3.1.3 of the ARB. Added section 3.2 Section 3.1.3 provides the diagram for the deployment model. Added template for the rest of section 3 and 4 Section 3.2 provides the diagram for the information classes Added Use-case realization 10/23/06 PA 2.1 Changed System Administrator role from Changes made after inspection “User” to “Administrator” in section 2.1.6 Edited role of Volunteer Candidate Application Form in Section 2.2.1 Rename section 2.2.5 from Notification to Award Notification Clarified matching parameters in Section 2.2.10 Responsibility Edited UC-17: Scheduling is now only automatic matching, not automatic assignment Edited Purpose of UC-31, added that the award tracking will also send notifications to the volunteer coordinator. Edited the priority of the use-cases Edited the System Structure diagram – Volunteer, System Administrator, Supervisors, and Volunteer Candidate should be “*” not “1” and added errorDetection() as service 8/25/08 PA 2.2 Updated all diagrams. Refined the document for Instructional Changed section 3.1.2 to be Design ICM-Sw version Classes containing information class diagrams. Edited the Behavior section to break down the use-cases by capabilities.

2 System and Software Architecture Description (SSAD) Version 2.2

Table of Contents

Table of Tables

4 System and Software Architecture Description (SSAD) Version 2.2 Table of Figures

1.Introduction

1.1 Purpose of the SSAD The purpose of the SSAD document is to provide the analysis of the operational concept, design the architecture, and design the implementation of the California Science Center Volunteer Tracking System. It serves as a bridge linking between the inception and the construction phases by providing the in-depth architectural design and implementation of the proposed system. The initial draft of the SSAD document consists of the description of system analysis, behavior, and modes of operation of the Volunteer Tracking System. 1.2 Status of the SSAD The current version of the SSAD is at the Valuation phase. At this point, only the Technology-Independent Model is described because not all the COTS products and implementation technologies that will be used have been finalized as yet.

2.System Analysis

2.1 System Analysis Overview The primary purpose of the Volunteer Tracking System is to track the performance of volunteers working at the California Science Center. The Volunteer Tracking System keeps track of the number of hours each volunteer has completed and of communications and job requests between and among volunteers, supervisors, and the volunteer coordinator. The system generates reports and certificates based on the needs and preferences of the volunteer coordinator and the CSC’s managers. Notifications are sent to the volunteer coordinator once volunteers’ working hours meet certain levels required for special recognition. 2.1.1System Context Figure 1 shows the operational context of the CSC Volunteer Tracking System.

Figure 1: System Context Table 1: Actors Summary describes the actors and their corresponding responsibilities performed to the system. Table 1: Actors Summary

Actor Description Responsibilities

Volunteer Users that are working as  Clocks in at the beginning of work volunteers at the CSC. day and out at the end  Write comments to supervisors or volunteer coordinator via comment log.

Employee A member of the CSC  Submits job requests (supervisor) staff. He/she can request  Sends comments to volunteers and for volunteers to work to the volunteer coordinator via the under his/her supervision. comment log

7 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Actor Description Responsibilities

Volunteer The CSC staff member  Reviews volunteer applications Coordinator who is assigned to  Submits job requests coordinate the volunteer program. The Volunteer  Reviews, approves, and schedules Coordinator manages all job requests volunteer activities  Edits volunteers’ profiles and hours including job assignments, time tracking, report  Generates reports generations, etc.  Generate certificates of recognition to volunteers  Sends comments to volunteers and other employees via the comment log

Manager A member of the  Reviews performance of volunteers executive/managerial staff  Generates reports as needed. of the CSC. (Managers do not interact directly with volunteers.)

Volunteer Candidate A person applying to the  Fills in a volunteer application form CSC for a volunteer online position.  Submits the application to be reviewed by the Volunteer Coordinator.

Newsletter System A separate CSC system,  Provides the CSC Volunteer being built by another Tracking System with an interface CSCI577 team, with which for sending emails. the CSC Volunteer Tracking System must interact.

EventRSVP System A separate CSC system,  Provides the CSC Volunteer being built by another Tracking System with an interface CSCI577 team, with which for authenticating users upon log in the CSC Volunteer and log out. Tracking System must interact.

Clock A system clock  Provides the system time

8 System and Software Architecture Description (SSAD) Version 2.2 2.1.2Artifacts & Information This section of the document describes the artifacts and information created by the system. These artifacts can either be used by the end user or reused by the system to produce further artifacts. The artifacts and relationships between/among them are described below.

Figure 2: Artifacts and Information Model Table 2 contains a description of each artifact shown above. Table 2: Artifacts and Information Summary

Artifact Purpose

ATF-1: Application Form Contains all information about a Volunteer Candidate that the Volunteer Coordinator needs for the volunteer approval process, including contact information.

ATF-2: Volunteer Profile Contains all information included on the Application Form that a Volunteer submitted when s/he was a Volunteer Candidate, plus all information about the Volunteer’s work, as a volunteer, for the CSC that is required for the system and other users to properly interact with the Volunteer. (See Section 2.1.3.1)

ATF-3: Job Request Form Contains the information required to assign a job to a Volunteer and to schedule the job. This includes a description of the job, the responsible CSC staff member(s), the number of Volunteers required, the preferred Volunteer skills, etc.

9 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 ATF-4: Time Sheet Contains a recording of the time at which a Volunteer clocks ins to the system at the start of each of his/her volunteer job sessions and the time at which s/he clocks out at the end of the session. This time tracking data is used for report generation, award conferral, etc.

ATF-5: Time The actual time provided by the system clock.

ATF-6: Award Notification This artifact is automatically generated by the system, and sent to the Volunteer Coordinator when a Volunteer’s total number of working hour meets the criteria for conferring a reward to a Volunteer. The award notification includes the name of the Volunteer, the type of award, and the date on which the award was conferred.

ATF-7: Report The volunteer coordinator as well as manager can generate this report for any purposes such as monthly volunteer department report, report for executive meeting or simply for quick review. Contains customized information that the user needs for his/her report. (The user can tailor his/her reports arbitrary, see UC- 22 for more details)

ATF-8: Certificate This artifact will be generated according to CSC certificate format. An example of this artifact is community service certification letter. Contains information derived from the system (for example, in community service certification letter case, the information is the name of the volunteer, the amount of hours s/he works etc.) which is filled within CSC certificate template format. Note that the volunteer coordinator can modify the template arbitrarily

ATF-9: Job Schedule The artifact is the output resulting from the Job Scheduling process. It contains the matching between job criteria and volunteer profile.

ATF-10: Comment Log A log of the comment messages. The comment log is used as a mean of communication between volunteers, supervisors and volunteer coordinator.

ATF-11: Comment Contains comment messages, the sender name, the optional receiver name and the optional flag telling whether the sender want to expose this comment to the public or not.

ATF-12: User Error Log The automatically generated log. The system generates this log when it detects that some volunteers forgot to clock out from their working time..

10 System and Software Architecture Description (SSAD) Version 2.2 ATF-13: Job Profile Contains adequate information for the job scheduling process including name, description, schedule, responsible staff, amount of volunteers needed, preferred volunteer’s skill etc. The information in Job Request Form will be transferred to this artifact, so the job scheduling can use this artifact for matching between job and volunteer.

ATF-14: Employee Profile Contains the information of the employee. This includes name, department, and job title.

2.1.3Behavior The following Use-Case Diagram shows the 21 processes that were identified when analyzed the capabilities described in the OCD were analyzed.

Figure 3: Process Diagram Online Application

Submit Application Table 3: Process Description - Submit Application

Identifier UC- 1 Submit Application

11 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Purpose Recruiting new volunteers via web application. Therefore, volunteer candidates do not need to apply the application in person anymore.

Requirements CR-1 Online application

Development None Risks

Pre-conditions System database is properly initialized Volunteer Candidate has loaded application page

Post-conditions The Volunteer Candidate’s status was noted as “pending”. The application was posted in system database

Table 4: Typical Course of Action - Submit Application

Seq# Actor Actions System Response

1 Fill in appropriate fields

2 Click submit the form

3 Check the completeness & uniqueness of the form

4 Save the application in the system database

5 Display a message: “the application received”

Table 5: Alternate Course of Action - Submit Application: Incomplete

1 Fill in some or no fields

4 [missing information] Reload the application page containing the filled information with the error message: “the application was not complete”

12 System and Software Architecture Description (SSAD) Version 2.2 Table 6: Alternate Course of Action - Submit Application: Duplicate Application

1 Fill in appropriate fields

4 [duplicate application] Reload the application page containing the filled information with an error message: “the application was sent before”

View Volunteer Application Table 7: Process Description – View Volunteer Application

Identifier UC- 2 View Volunteer Application

Purpose Once the applications are submitted, the volunteer coordinator can view them through the system.

Pre-conditions System database is properly initialized Volunteer Coordinator has loaded view application page Post-conditions Volunteer Candidate application is displayed on the screen

Table 8: Typical Course of Action – View Volunteer Application

1 Click on volunteer’s name [hyperlink]

2 Retrieve the volunteer candidate’s application from the database

3 Display the application

Approve Volunteer Application Table 9: Process Description – Approve Volunteer Application

Identifier UC- 3 Approve Volunteer Application 13 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Purpose Once the applications are submitted, the volunteer coordinator can approve them through the system.

Pre-conditions System database is properly initialized Volunteer Coordinator has loaded the view application page Volunteer Coordinator has clicked on a volunteer candidate’s name to view the application Post-conditions The Volunteer Candidate’s status was noted as “approved”. The personal information is saved to the database as a volunteer. Table 10: Typical Course of Action – Approve Volunteer Application

1 Click on “Approve” button

2 Display message: “Approved”

Alternate course of action not applicable Exceptional course of action not applicable

Deny Volunteer Application Table 11: Process Description – Deny Volunteer Application

Identifier UC- 4 Deny Volunteer Application

Purpose Once the applications are submitted, the volunteer coordinator can deny them through the system.

Pre-conditions System database is properly initialized Volunteer Coordinator has loaded the view application page Volunteer Coordinator has clicked on a volunteer candidate’s name to view the application Post-conditions The Volunteer Candidate’s status was noted as “denied”.

Table 12: Typical Course of Action – Deny Volunteer Application

1 Click on “Deny” button

14 System and Software Architecture Description (SSAD) Version 2.2 2 Display message: “Denied”

Alternate course of action not applicable Exceptional course of action not applicable Authentication

Login Table 13: Process Description - Login

Identifier UC- 5: Login

Purpose Determine if a person logging in to the system can be authenticated, and, if so, what the person’s privileges are as a user of the system, i.e., what the person is authorized to do when using the system

Requirements CR-2 Authorization and Authentication

Pre-conditions System database is properly initialized. User is on a computer locally connected to the CSC network. (Logging in from remote computers is not allowed.) Post-conditions If user is authorized s/he is given access to system operations appropriate to his/her role; otherwise, s/he is denied access to the system.

Table 14: Typical Course of Action – Login: Successful

Seq# Actor Action System Response

1 [user] Enters a user name and password

2 [user] Clicks Login button

3 Sends username and password to the authentication module of the EventRSVP system

4 [EventRSVP System] Sends authentication verification and user session data

5 [valid] Redirects the actor to Volunteer home page, CSC employee home page, 15 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 CSC Manager home page, or System Administrator home page, as appropriate

Table 15: Alternate Course of Action – Login: Failure

Seq# Actor Action System Response

1 - 4 Refer to typical course of action

5 Displays An error message: “username or password is wrong” in a dialog box

6 Clicks OK button

7 Redirects the user to the login page

Note: Entering only a username, a password, or blanks will be treated the same as entering an invalid username and password.

Logout Table 16: Process Description – Logout

Identifier UC- 6: Logout

Purpose To log out of the system

Requirements CR-2 Authorization and Authentication

Risks N/A

Pre-conditions The user is a CSC User The user’s login session still exists Post-conditions The user login session is terminated. The user is detached from the system Table 17: Typical Course of Action – Logout

1 CSC User clicks the “log out” hypertext

2 Signal the authentication module of the EventRSVP system with the user session data.

3 EventRSVP System returns logout verification and data

16 System and Software Architecture Description (SSAD) Version 2.2 2 Display a message: “you have logged out of the system” in a dialog box

3 Click OK button

4 Redirect the actor to CSC main page

Alternate Course of Action for Volunteer Logout is not applicable Table 18: Exception Course of Action - Logout

1 CSC User tries to directly load logout page

2 [invalid] An error message: “you have not logged in yet”.

Time Tracking

Clock in Table 19: Process Description - Clock In

Identifier UC- 7 Clock In

Purpose To track volunteers’ working hours

Requirements CR-3 Track volunteer hours and performance

Pre-conditions System Database is properly initialized User is a Volunteer. Post-conditions The volunteer’s beginning time of work was recorded to his/her profile.

Table 20: Typical Course of Action - Clock In

1 Click the “Clock in” button

2 Record clock time in user’s profile

17 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 3 Display a message: “your work’s beginning time was recorded.

Alternate Course of Action for Clock in is not applicable Exceptional Course of Action for Clock in is not applicable

Clock out Table 21: Process Description - Clock Out

Identifier UC- 8 Clock Out

Purpose To track volunteers’ working hours

Requirements CR-3 Track volunteer hours and performance

Pre-conditions System database is properly initialized Volunteer has already clocked in.

Post-conditions The volunteer’s finishing time of work was recorded to his/her profile.

Table 22: Typical Course of Action - Clock Out

1 Click the “Clock out” button

2 Signal Clock to get time

3 Return current system time

4 Record time to database

5 A message: “you have clocked out and the finishing time has been recorded in the system database”

Alternate Course of Action for Clock out is not applicable Exceptional Course of Action for Clock out is not applicable

Record Awards Table 23: Process Description - Record Awards

Identifier UC- 9 Record Awards

Purpose Automatically track volunteers’ hours as well as determine which

18 System and Software Architecture Description (SSAD) Version 2.2 volunteer meet the award criteria and sends award notifications to the volunteer coordinator as appropriate.

Requirements CR-5: Award Tracking, CR-3: Track volunteer hours and performance

Pre-conditions System database is properly initialized

Post-conditions Names of volunteers that meets the requirements is recorded to the system database.

Table 24: Typical Course of Action - Record Awards

1 Volunteer clocks out

1 System identifies volunteers that meet award requirements

2 Update award notification

3 Update volunteer award history

Alternate course of action not applicable Exceptional Course of Action not applicable

Specify Award Criteria Table 25: Process Description - Specify Award Criteria

Identifier UC- 10 Specify Award Criteria

Purpose Specifies the specific criteria for volunteer rewards such as the number of hours.

Requirements CR-5: Award Tracking

Pre-conditions System database is properly initialized User is volunteer coordinator Data table for award criteria exists in the database Post-conditions Award criteria in the system database is updated

Table 26: Typical Course of Action - Specify Award Criteria

19 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response

1 Click on “Award Criteria” link

2 Display the Award Criteria page

3 Fill in the award criteria in the appropriate fields

4 Click Submit

5 Save new award criteria in the system database

Alternate course of action not applicable Exceptional Course of Action not applicable Comment Log

Submit Comment Table 27: Process Description - Submit Comment

Identifier UC- 11 Submit Comment

Purpose Tracking communication between (a) volunteers and supervisors, and (b) volunteers and volunteer coordinator.

Requirements CR-4 Communication Tracking

Pre-conditions System database is properly initialized User is logged into the system. Post-conditions The written comment log was record to the system database and will show up at the receiver’s comment logs window

Table 28: Typical Course of Action - Submit Comment

1 Send a comment message from the user’s main page.

2 A message: “the message has already been sent” with a link to redirect the actor back to volunteer home page

Alternate Course of Action for Clock out is not applicable Table 29: Exceptional Course of Action - Submit Comment: Long 20 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response

1 Send a long comment message

2 [message is too long]An error message: “ the message size exceeded the limited length” and a link to redirect the actor back to “write a comment log” page

Table 30: Exceptional Course of Action - Submit Comment: Empty

1 Send an empty message

2 An error message: “the message is empty” with a link to redirect the actor back to “write a comment log” page

Scheduling Tool

Schedule Jobs Table 31: Process Description - Schedule Jobs

Identifier UC- 12 Schedule jobs

Purpose Schedule volunteers with job requests based on criteria and skills

Requirements CR-9: Volunteer scheduling

Development Evaluating volunteer’s qualification and matching them with job Risks criteria will require complex algorithm.

Pre-conditions  User is volunteer coordinator  User is at the volunteer coordinator GUI page.  Database is properly initialized

Post-conditions Volunteers with matching criteria and skills are assigned to jobs and recorded into the database

Table 32: Typical Course of Action - Schedule Jobs: Automatic

1 Click on “Schedule jobs” button

2 Match volunteers with jobs based on criteria and skills, and displays them on the screen

21 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 3 Click on “Approve” button

4 Record results to the database

5 Display the Job Requests page

Table 33: Alternate Course of Action – Schedule Jobs: Manual

1 Click on “Manually Schedule jobs” button

2 List all job requests and all available volunteers

3 Assign volunteers’ names to jobs

4 Click “Approve”

5 Record results to the database

Exceptional Course of Action not applicable Job Requests Submission

View Job Request Table 34: Process Description - View Job Request

Identifier UC- 13 View Job Request

Purpose Users have the ability to view his/her tasks that have been requested

Requirements CR-8: Job requests

Pre-conditions User is logged into the system.

Post-conditions Current tasks is displayed on user’s screen

Table 35: Typical Course of Action - View Job Request

1 Click on “View Current Tasks” link

22 System and Software Architecture Description (SSAD) Version 2.2 2 Display current tasks page

3 Click on the task link

4 Display task profile, list of volunteers assigned, and status of task

Submit Job Request Table 36: Process Description - Submit Job Request

Identifier UC- 14 Submit Job Request

Purpose Providing the online ability for users to request volunteers to work for them

Requirements CR-8 Job Requests

Pre-conditions User must be an employee

Post-conditions The request is recorded to the database

Table 37: Typical Course of Action - Submit Job Request

1 Click on “Job Requests” link

3 Fill in the appropriate fields

4 Click submit

5 Validate required information

6 [valid] Save job request entry in the database

7 Display a message: “the request has been sent” with a link to supervisor home page

Table 38: Alternate Course of Action - Submit Job Request

23 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response

1 Click on “Job Requests” link

2 Directs to the Job Request page

3 Fill some or no fields

4 Click submit

5 Validate required information

6 Reload the page with the filled information and display an error message: “The job request is incomplete”

View All Job Requests Table 39: Process Description - View All Job Requests

Identifier UC- 15 View All Job Requests

Purpose Shows all job requests submitted by the supervisors including old and new requests

Development A fast algorithm will need to be used to retrieve and display the Risks list of all job requests as the list may be large.

Pre-conditions User is volunteer coordinator

Post-conditions All job requests are retrieved from the database and displayed on the user’s screen.

Table 40: Typical Course of Action - View All Job Requests

1 Click on “View All Requests” link

2 Displays all job requests in list view on user’s screen

Alternate Course of Action for View all job requests is not applicable Exceptional Course of Action not applicable

Delete Job Request 24 System and Software Architecture Description (SSAD) Version 2.2 Table 41: Process Description - Delete Job Request

Identifier UC- 16 Volunteer Coordinator deletes job request

Purpose Allows the user to delete job requests that have been previously requested by supervisors and the volunteer coordinator

Development Database reference may cause problems Risks

Pre-conditions User is volunteer coordinator Database is properly initialized Post-conditions Job request is deleted from the database.

Table 42: Typical Course of Action - Delete Job Request

1 Click on “View All Requests” link

2 Display View All Job Request page with all jobs in database

3 Click on task link

4 Click Delete

5 Prompt for confirmation

1. 2. Click 6 OK

7 Deletes the task from the database

Alternate course of action not applicable Exceptional Course of Action not applicable Performance Analysis

Generate Report Table 43: Process Description - Generate Report

Identifier UC- 17 Generate Report

Purpose The user has the ability to generate reports that include 25 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 information specified by him/her.

Requirements CR-6: Generate Reports

Pre-conditions  User is volunteer coordinator or manager  Database is properly initialized

Post-conditions Report is displayed

Table 44: Typical Course of Action - Generate Report

1 Click on “Generate Reports” link

2 Display Report Generator page

3 Select which information to be generated

4 Click “Submit”

5 Display report on user’s screen

Generate Certificate Table 45: Process Description - Generate Certificate

Identifier UC- 18 Generates Certificate

Purpose The user has the ability to generate certificates

Requirements CR-7: Generate Certificates

Pre-conditions User is volunteer coordinator or manager Certificates template exists on the database

Post-conditions Certificate is generated

Table 46: Typical Course of Action - Generate Certificate

26 System and Software Architecture Description (SSAD) Version 2.2 1 Click on “Generate Certificates” link

2 Display certificates generator page

3 Select which type of certificate to be generated

5 Display Certificate on user’s screen

Alternate course of action not applicable Exceptional Course of Action not applicable Error Detection

Detect Clock Out Error Table 47: Process Description – Detect Clock Out Error

Identifier UC- 19 Detect Clock Out Error

Purpose Signals the system that a user is still logged in at 11 PM

Requirements

Pre-conditions

Post-conditions If any volunteer is clocked in at 11 PM then, volunteer coordinator is notified.

Table 48: Typical Course of Action – Detect Clock Out Error

1 Clock signals that it is 11 PM

Check to see if any user is still logged in.

2 Signal the system to send notification the Newsletter System to send email to volunteer coordinator and record the error.

27 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Person Management

View Volunteer Profile Table 49: Process Description - View Volunteer Profile

Identifier UC- 20 View Volunteer Profile

Purpose View information, profiles, history, and skills of volunteers that have been assigned to the job requests.

Requirements

Pre-conditions User is an employee

Post-conditions Displaying the profile of each volunteer on screen.

Table 50: Typical Course of Action – View Volunteer Profile

1 Click on the name of each volunteer (the name is a link)

2 Display profile of the specific volunteer

View Volunteer list Table 51: Process Description – View Volunteer List

Identifier UC- 21 View Volunteer List

Purpose Allows the volunteer coordinator to view the list of volunteers based on different searching and sorting algorithms

Requirements

Development Retrieving large list of volunteers from the database may put Risks stress on the network system as well as slowing down performance significantly.

Post-conditions List of volunteers is displayed on the user’s screen

Table 52: Typical Course of Action – View Volunteer List

28 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response

1 Click on “View Volunteers” link

2 Display volunteer listing page

3 Choose searching and sorting preferences

5 Display list of volunteers on user’s screen

Edit Volunteer Hours Table 53: Process Description – Edit Volunteer Hour

Identifier UC- 22 Edit Volunteer Hours

Purpose Allows the volunteer coordinator to edit the volunteer’s hours and clock in/out entries if they happen to forget.

Requirements CR-3: Track volunteer hours and performance

Post-conditions New volunteer hour is recorded to the database

Table 54: Typical Course of Action – Edit Volunteer Hour

Seq Actor System Response # Actions

1 Click on “Edit volunteer’s hours” link

2 Display list of volunteers that have problems on their accounts (e.g. missing clock in/out entry)

3 Click on volunteer’s name

4 Display the hours record of the

29 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 volunteer

3 Edit volunteer’s hours

5 Save changes to Volunteer’s hours in the database

6 Display the hours record of the volunteer

Alternate course of action not applicable Exceptional Course of Action not applicable 2.1.4Modes of Operation The CSC Volunteer Tracking System, as we envision implementing it, will operate in only one mode, so nothing further need be said of modes of operation. 2.2 System Analysis Rationale Based on our analysis of how the users interact with the system, as shown in the Behavior subsection (see BehaviorError: Reference source not found) of System Behavior Analysis, we have identified 2 classes of operational stakeholders. 3. California Science Center Users – these users include volunteers, supervisors, volunteer coordinators, and managers. These users require authentication in order to access the system with various permissions and functionalities based on the type of user. This part of the system can be accessed only through workstations connected to the CSC network.

4. Volunteer Candidates – these are users who are interested in becoming, or are in the process of applying to become, Volunteers at the California Science Center. Such users connect to the application form webpage over the Internet, with no authentication or authorization being required.

There are 3 external system actors that interface with the CSC Volunteer Tracking System. They are:

1. Newsletter System – provides email service to the CSC Volunteer Tracking System. 2. EventRSVP System – provides authentication services for to the CSC Volunteer Tracking System. 3. Clock – provides system time

30 System and Software Architecture Description (SSAD) Version 2.2 The Newsletter and EventRSVP systems are being built by two other CSCI577 teams. The clients have requested that the projects be integrated and that relevant modules be shared. The CSC Volunteer Tracking System is, therefore, being designed to use the relevant modules provided by these two other systems. Furthermore, the Clock actor serves as the system time provider for the system. This time is used when volunteers clock in and out.

5.Technology-Independent System Design

5.1 Design Overview 5.1.1System Structure

Figure 4: Hardware Component Class Diagram

Figure 5: Software Component Class Diagram

Figure 6: Deployment Diagram

Figure 7: Web Framework Component Classes Table 55 and Table 56 contain the descriptions of the hardware and software components that make up the CSC Volunteer Tracking System. Table 55: Hardware Component Description

Hardware Component Description

Non-CSC Workstation A workstation that connects to the CSC Volunteer Tracking System over the Internet, i.e., from outside of the California Science Center.

CSC Workstation A workstation located at the California Science Center and connected to the CSC Volunteer Tracking System through the Local Area Network.

Web Server A Web Server that accepts connections from Non-CSC Workstations. Such connections are forwarded to the Application Server through the Local Area Network.

Application Server The Application Server is the server on which the majority of the Volunteer Tracking System components reside. The server communicates with the Web Server through the Local Area Network and provides both database access as well as the business logic.

Table 56: Software Component Description

Software Component Description

User Interface This component contains Volunteer Tracking System web pages Component for use by all Volunteer Tracking System users who are not currently CSC staff members or Volunteers. Its primary component is the Volunteer application form used by Volunteer Candidates to apply for Volunteer status.

33 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Person Management This component performs functions involved in managing Component information relating to authenticated users of the Volunteer Tracking System.

Comment Log This component manages comments sent between CSC Volunteer Component Tracking System users, comments which, taken together, constitute the CSC Volunteer Tracking System’s Comment Log.

Volunteer Application This component contains the application form and the component Component to display and manage the forms.

Volunteer Management This component performs all the main functionalities of the Component volunteer management process. These functionalities include:  Automated time tracking  Job scheduling  Job request  Report Generation  Certificate Generation DBMS This is the Database Management System (DBMS) that stores all data used by the CSC Volunteer Tracking System.

Table 57 contains the descriptions of the web framework components used in the Volunteer Tracking System. These framework components are the supporting structure of the system, but are not implemented by the developers. Table 57: Web Framework Component Description

Web Component Description

Browser An Internet browser that connects to the Volunteer Tracking System web application and is responsible for displaying Volunteer Tracking System web pages.

Web Server Component The server component that routes all network traffic and requests between external systems and the application server.

Application Server The server component where the Volunteer Tracking System Component resides on. All the logical computations are done on this component.

Web Pages The actual web pages created by the Volunteer Tracking System.

5.1.2Design Classes The Design Class Diagrams shown below describe the relationships among the boundary, entity, and the control classes for the Volunteer Tracking System.

34 System and Software Architecture Description (SSAD) Version 2.2 Interface Classes

Figure 8: Interface Class Diagram Table 58 contains the description for each design class described for the set of interface classes. Table 58: Interface Class Description

Class Type Description

VolunteerApplicationPage Boundary The page to display the volunteer application form.

VolunteerPage Boundary The main Volunteer page.

EmployeePage Boundary The main Employee page.

ViewJobRequestPage Boundary Displays the list of job requests that the user has requested.

JobRequestPage Boundary Displays the form to submit job requests.

VolunteerCoordinatorPage Boundary The main Volunteer Coordinator page.

ViewVolunteerListPage Boundary Displays the list of volunteers.

ViewVolunteerProfilePage Boundary Displays the profile of individual volunteers.

ViewAllJobRequestsPage Boundary Displays the list of all the job requests submitted by all employees.

ScheduleJobPage Boundary Displays the list of job requests matching with the volunteer criteria. The Volunteer 35 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Coordinator can then assign volunteers to each job.

ReportGenerationPage Boundary Displays the criteria to generate the report and the actual report itself.

CertificateGenerationPage Boundary Displays the criteria to generate the certificate and the certificate itself.

ApplicationApprovalPage Boundary Displays the list of volunteer applications and allows the Volunteer Coordinator to approve or deny them.

AwardsPage Boundary Displays the list of awards available and ability to add more awards.

CommentLogPage Boundary Displays the log of comments between users and place to enter new comments.

Volunteer Application Management Classes

Figure 9: Volunteer Application Management Class Diagram Table 59 contains the description for each design class described in the Volunteer Application Management classes. Table 59: Volunteer Application Management Class Description

VolunteerApplicationController Componen Contains all the logical computations for t managing volunteer application related functions.

VolunteerApplicationForm Entity Contains the information submitted by a Volunteer Candidate. This information

36 System and Software Architecture Description (SSAD) Version 2.2 includes personal information as well as CSC-related information, e.g., the Volunteer Candidate’s CSC-related skills.

Time Management Classes

Figure 10: Time Management Class Diagram Table 60 contains the description for each design class described in the Time Management classes. Table 60: Time Management Class Description

TimeAwardController Componen Contains all the logical computations for t managing time and award related functions.

TimeSheetLog Entity The log or list of time sheets.

TimeSheet Entity Contains time stamps of a Volunteer’s clocks (in/out).

Time Entity The system time.

AwardSet Entity The set of awards given to volunteers. Contains the mapping between volunteers and awards.

Award Entity Contains the information of a particular award.

37 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Job Management Classes

Figure 11: Job Management Class Diagram Table 61 contains the description for each design class described in the Job Management classes. Table 61: Job Management Class Description

JobController Componen Contains all the logical computations for t managing job related functions.

Job Entity Contains a description of a job requested by a member of the CSC staff as well as information required to assign the job to a Volunteer, e.g., skills required to perform the job.

JobSchedule Entity Contains a schedule of all jobs together with the volunteer(s) assigned to each. (Job scheduling is done by matching the criteria required for a job with the profile of the volunteers.

38 System and Software Architecture Description (SSAD) Version 2.2 Report Management Classes

Figure 12: Report Management Class Diagram Table 62 contains the description for each design class described in the Report Management classes. Table 62: Report Management Class Description

ReportCertificateController Componen Contains all the logical computations for t managing report and certificate generation related functions.

Certificate Entity The textual certificate generated.

Report Entity The textual report generated.

39 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Comment Log Classes

Figure 13: Comment Log Class Diagram Table 63 contains the description for each design class described in the Comment Log classes. Table 63: Comment Log Class Description

CommentLogController Componen Contains all the logical computations for t managing the comment log funcationality.

CommentLog Entity The collection of comments.

Comment Entity Contains a comment that one user sends to another user. A Comment includes identifications of the sender and recipient as well as the message.

40 System and Software Architecture Description (SSAD) Version 2.2 Person Management Classes

Figure 14: Person Management Class Diagram Table 64 contains the description for each design class described in the Person Management classes. Table 64: Person Management Class Description

PersonManagementController Componen Contains all the logical computations for t managing person and profiles related functions.

Person Entity Contains the information about a person who is an authenticated user of the CSC Volunteer Tracking System. This information includes the person’s name, his/her contact information, his/her login information, etc.

VolunteerProfile Entity Contains additional information about a Volunteer that is not contained in the Person class. These information include the the Volunteer’s skills, abilities, interests, etc.

41 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 AuthenticationController Componen The component interfaces with the t authentication service provided by the EventRSVP system.

5.1.3Process Realization This section describes how each process identified in System Analysis (see Behavior) is realized by the designed architecture (see System Structure) and instances of the information classes (see Design Classes). For this design, each process has one realization. We used the same name for the process realization as the process to facilitate tracing. The Use-Case Realization Diagrams can be found in the RSM design model. This remainder of this section shows the Sequence Diagrams for the high-risk processes. Each diagram shows that how the process can be implemented using our architecture and instances of the information classes. The following diagram is the sequence diagram for the Clock-In process (see Clock in).

Figure 15: Clock In Process Sequence Diagram 5.2 Design Rationale We adopted a 3-tiered architecture because our customer, who is highly technical, wanted a very flexible design. Specifically, the customer required (a) a clear separation between the user interface and the logic; and (b) a clear separation of the logic from the data storage and management. In addition, as described below, we have chosen to use an off-the-shelf DBMS, which does not does not provide custom logic. The following list shows the 3-tiers (commonly called “layers”) of the architecture and the specific components in each tier.  User Interface Layer o User Interface component

42 System and Software Architecture Description (SSAD) Version 2.2  Business Logic Layer o Person Management component o Comment Log component o Volunteer Management component o Volunteer Application component  Database Management Layer o DBMS The three-tiered architecture clearly shows the separation between user interface and business logic and between business logic and data storage. The Business Logic layer components are broken down in such way that each component performs specific functions that do not overlap with the functions assigned to any other component. For example, the Comment Log component does not perform any functions that deal with jobs since those belong to the Job component. Although the Person Management and Authentication components may appear to be highly coupled, they serve different purposes and their separation allows for better integration with the other systems. As the customer required that the Volunteer Tracking System have a modular design and that it be able to integrate with the EventRSVP and Newsletter systems, the Person Management will provided services to manage user’s personal information to other systems requesting them. In return, the EventRSVP and the Newsletter systems will provide the authentication and emailing services respectively. Although the authentication service is provided by the EventRSVP system, it does not provide the front-end of the login and logout functionality. This means that the users will appear to login and logout through the Volunteer Tracking system. However, the logic behind the login and logout functionalities such as creating and terminating user sessions and verifying usernames and passwords will be done through the service provided by the EventRSVP. We decided to use a COTS DBMS because it would be too time consuming to implement the data storage component through the hardware platform’s file system. We chose to show the sequence diagram for the Clock-in process in the previous section because it is a complex process that involves communication among components in all 3 layers, i.e. once the clock-in button is clicked in the User Interface component, the time is recorded to the database and then displayed to the user.

6.Technology–Specific System Design

43 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 7.Architecture Styles, Patterns, and Frameworks

Table 65 shows the architecture styles, patterns and frameworks used in this design. Table 65: Architectural Styles, Patterns, & Framework

Name Description Benefits, Costs, and Limitations

3-Tier The 3-tier architecture separates the The use of this architecture allows for Architecture application into 3 different layers: increased abstraction between the layers user interface, logic, and domain and of components. This allows for the user data access. This means that the interface and logic to be independent of model disassociates the data each other satisfying the client’s controller and access from the user requirement. The 3-tier architecture also interface. The communication allows for single model to have multiple between the visual and data views meaning that the control and the components are done via the logic, or UI mechanisms are flexible and adaptive the controllers. for future changes. However, adopting this architecture may increase complexity as well as the size of the application due to the separation of data, process, visualization, and display components.