System and Software Architecture Description

System and Software Architecture Description (SSAD) Version 2.2System and Software Architecture DescriptionCalifornia Science Center Volunteer Tracking SystemTeam #3Phongphan 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 Maintainer1 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2Version HistoryDate Author Version Changes made Rationale10/8/06 PA, NL 1.0 SSAD for LCO Draft Initial draft of SSAD10/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.2Table of Contents3 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2Table of Tables4 System and Software Architecture Description (SSAD) Version 2.2 Table of Figures5 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.21.Introduction1.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 Analysis2.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. 6 System and Software Architecture Description (SSAD) Version 2.2Figure 1: System Context Table 1: Actors Summary describes the actors and their corresponding responsibilities performed to the system. Table 1: Actors SummaryActor Description ResponsibilitiesVolunteer 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 ResponsibilitiesVolunteer 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 logManager 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 time8 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 SummaryArtifact PurposeATF-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 arbitrarilyATF-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 ApplicationSubmit Application Table 3: Process Description - Submit ApplicationIdentifier UC- 1 Submit Application11 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 applicationDevelopment None RisksPre-conditions System database is properly initialized Volunteer Candidate has loaded application pagePost-conditions The Volunteer Candidate’s status was noted as “pending”. The application was posted in system databaseTable 4: Typical Course of Action - Submit ApplicationSeq# Actor Actions System Response1 Fill in appropriate fields2 Click submit the form3 Check the completeness & uniqueness of the form4 Save the application in the system database5 Display a message: “the application received” Table 5: Alternate Course of Action - Submit Application: IncompleteSeq# Actor Actions System Response1 Fill in some or no fields2 Click submit the form3 Check the completeness & uniqueness of the form4 [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 Application1 Fill in appropriate fields2 Click submit the form3 Check the completeness & uniqueness of the form4 [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 ApplicationIdentifier UC- 2 View Volunteer ApplicationPurpose Once the applications are submitted, the volunteer coordinator can view them through the system.Requirements CR-1 Online applicationDevelopment None RisksPre-conditions System database is properly initialized Volunteer Coordinator has loaded view application page Post-conditions Volunteer Candidate application is displayed on the screenTable 8: Typical Course of Action – View Volunteer ApplicationSeq# Actor Actions System Response1 Click on volunteer’s name [hyperlink]2 Retrieve the volunteer candidate’s application from the database3 Display the applicationApprove Volunteer Application Table 9: Process Description – Approve Volunteer ApplicationIdentifier 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.Requirements CR-1 Online applicationDevelopment None RisksPre-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 ApplicationSeq# Actor Actions System Response1 Click on “Approve” button2 Display message: “Approved”Alternate course of action not applicable Exceptional course of action not applicableDeny Volunteer Application Table 11: Process Description – Deny Volunteer ApplicationIdentifier UC- 4 Deny Volunteer ApplicationPurpose Once the applications are submitted, the volunteer coordinator can deny them through the system.Requirements CR-1 Online applicationDevelopment None RisksPre-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 ApplicationSeq# Actor Actions System Response1 Click on “Deny” button14 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 AuthenticationLogin Table 13: Process Description - LoginIdentifier UC- 5: LoginPurpose 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 systemRequirements CR-2 Authorization and AuthenticationDevelopment None RisksPre-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 Response1 [user] Enters a user name and password2 [user] Clicks Login button3 Sends username and password to the authentication module of the EventRSVP system4 [EventRSVP System] Sends authentication verification and user session data5 [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 appropriateTable 15: Alternate Course of Action – Login: FailureSeq# Actor Action System Response1 - 4 Refer to typical course of action5 Displays An error message: “username or password is wrong” in a dialog box6 Clicks OK button7 Redirects the user to the login pageNote: 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 – LogoutIdentifier UC- 6: LogoutPurpose To log out of the systemRequirements CR-2 Authorization and AuthenticationRisks N/APre-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 – LogoutSeq# Actor Actions System Response1 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 data16 System and Software Architecture Description (SSAD) Version 2.2 2 Display a message: “you have logged out of the system” in a dialog box3 Click OK button4 Redirect the actor to CSC main pageAlternate Course of Action for Volunteer Logout is not applicable Table 18: Exception Course of Action - LogoutSeq# Actor Actions System Response1 CSC User tries to directly load logout page2 [invalid] An error message: “you have not logged in yet”.Time TrackingClock in Table 19: Process Description - Clock InIdentifier UC- 7 Clock InPurpose To track volunteers’ working hoursRequirements CR-3 Track volunteer hours and performanceDevelopment None RisksPre-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 InSeq# Actor Actions System Response1 Click the “Clock in” button2 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 applicableClock out Table 21: Process Description - Clock OutIdentifier UC- 8 Clock OutPurpose To track volunteers’ working hoursRequirements CR-3 Track volunteer hours and performanceDevelopment None RisksPre-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 OutSeq# Actor Actions System Response1 Click the “Clock out” button2 Signal Clock to get time3 Return current system time4 Record time to database5 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 applicableRecord Awards Table 23: Process Description - Record AwardsIdentifier UC- 9 Record AwardsPurpose 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 performanceDevelopment None RisksPre-conditions System database is properly initializedPost-conditions Names of volunteers that meets the requirements is recorded to the system database. Table 24: Typical Course of Action - Record AwardsSeq# Actor Actions System Response1 Volunteer clocks out1 System identifies volunteers that meet award requirements2 Update award notification3 Update volunteer award historyAlternate course of action not applicable Exceptional Course of Action not applicableSpecify Award Criteria Table 25: Process Description - Specify Award CriteriaIdentifier UC- 10 Specify Award CriteriaPurpose Specifies the specific criteria for volunteer rewards such as the number of hours.Requirements CR-5: Award TrackingDevelopment None RisksPre-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 updatedTable 26: Typical Course of Action - Specify Award Criteria19 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response1 Click on “Award Criteria” link2 Display the Award Criteria page3 Fill in the award criteria in the appropriate fields4 Click Submit5 Save new award criteria in the system databaseAlternate course of action not applicable Exceptional Course of Action not applicable Comment LogSubmit Comment Table 27: Process Description - Submit CommentIdentifier UC- 11 Submit CommentPurpose Tracking communication between (a) volunteers and supervisors, and (b) volunteers and volunteer coordinator. Requirements CR-4 Communication TrackingDevelopment None RisksPre-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 windowTable 28: Typical Course of Action - Submit CommentSeq# Actor Actions System Response1 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 pageAlternate 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 Response1 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” pageTable 30: Exceptional Course of Action - Submit Comment: Empty1 Send an empty message2 An error message: “the message is empty” with a link to redirect the actor back to “write a comment log” pageScheduling ToolSchedule Jobs Table 31: Process Description - Schedule JobsIdentifier UC- 12 Schedule jobsPurpose Schedule volunteers with job requests based on criteria and skillsRequirements CR-9: Volunteer schedulingDevelopment 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 initializedPost-conditions Volunteers with matching criteria and skills are assigned to jobs and recorded into the databaseTable 32: Typical Course of Action - Schedule Jobs: AutomaticSeq# Actor Actions System Response1 Click on “Schedule jobs” button2 Match volunteers with jobs based on criteria and skills, and displays them on the screen21 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 3 Click on “Approve” button4 Record results to the database5 Display the Job Requests pageTable 33: Alternate Course of Action – Schedule Jobs: ManualSeq# Actor Actions System Response1 Click on “Manually Schedule jobs” button2 List all job requests and all available volunteers3 Assign volunteers’ names to jobs4 Click “Approve”5 Record results to the database6 Display the Job Requests pageExceptional Course of Action not applicable Job Requests SubmissionView Job Request Table 34: Process Description - View Job RequestIdentifier UC- 13 View Job RequestPurpose Users have the ability to view his/her tasks that have been requestedRequirements CR-8: Job requestsDevelopment None RisksPre-conditions User is logged into the system.Post-conditions Current tasks is displayed on user’s screenTable 35: Typical Course of Action - View Job RequestSeq# Actor Actions System Response1 Click on “View Current Tasks” link22 System and Software Architecture Description (SSAD) Version 2.2 2 Display current tasks page3 Click on the task link4 Display task profile, list of volunteers assigned, and status of taskAlternate course of action not applicable Exceptional Course of Action not applicableSubmit Job Request Table 36: Process Description - Submit Job RequestIdentifier UC- 14 Submit Job RequestPurpose Providing the online ability for users to request volunteers to work for themRequirements CR-8 Job RequestsDevelopment None RisksPre-conditions User must be an employeePost-conditions The request is recorded to the databaseTable 37: Typical Course of Action - Submit Job RequestSeq# Actor Actions System Response1 Click on “Job Requests” link2 Display the Job Requests page3 Fill in the appropriate fields4 Click submit5 Validate required information6 [valid] Save job request entry in the database7 Display a message: “the request has been sent” with a link to supervisor home pageTable 38: Alternate Course of Action - Submit Job Request23 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response1 Click on “Job Requests” link2 Directs to the Job Request page3 Fill some or no fields4 Click submit5 Validate required information6 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 RequestsIdentifier UC- 15 View All Job RequestsPurpose Shows all job requests submitted by the supervisors including old and new requestsRequirements CR-8: Job requestsDevelopment 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 coordinatorPost-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 RequestsSeq# Actor Actions System Response1 Click on “View All Requests” link2 Displays all job requests in list view on user’s screenAlternate Course of Action for View all job requests is not applicable Exceptional Course of Action not applicableDelete Job Request 24 System and Software Architecture Description (SSAD) Version 2.2 Table 41: Process Description - Delete Job RequestIdentifier UC- 16 Volunteer Coordinator deletes job requestPurpose Allows the user to delete job requests that have been previously requested by supervisors and the volunteer coordinatorRequirements CR-8: Job requestsDevelopment Database reference may cause problems RisksPre-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 RequestSeq# Actor Actions System Response1 Click on “View All Requests” link2 Display View All Job Request page with all jobs in database3 Click on task link4 Click Delete5 Prompt for confirmation1. 2. Click 6 OK7 Deletes the task from the databaseAlternate course of action not applicable Exceptional Course of Action not applicable Performance AnalysisGenerate Report Table 43: Process Description - Generate ReportIdentifier UC- 17 Generate ReportPurpose 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 ReportsDevelopment None RisksPre-conditions  User is volunteer coordinator or manager  Database is properly initialized Post-conditions Report is displayedTable 44: Typical Course of Action - Generate ReportSeq# Actor Actions System Response1 Click on “Generate Reports” link2 Display Report Generator page3 Select which information to be generated4 Click “Submit”5 Display report on user’s screen Alternate course of action not applicable Exceptional Course of Action not applicableGenerate Certificate Table 45: Process Description - Generate CertificateIdentifier UC- 18 Generates CertificatePurpose The user has the ability to generate certificatesRequirements CR-7: Generate CertificatesDevelopment None RisksPre-conditions User is volunteer coordinator or manager Certificates template exists on the databasePost-conditions Certificate is generatedTable 46: Typical Course of Action - Generate CertificateSeq# Actor Actions System Response26 System and Software Architecture Description (SSAD) Version 2.2 1 Click on “Generate Certificates” link2 Display certificates generator page3 Select which type of certificate to be generated4 Click “Submit”5 Display Certificate on user’s screen Alternate course of action not applicable Exceptional Course of Action not applicable Error DetectionDetect Clock Out Error Table 47: Process Description – Detect Clock Out ErrorIdentifier UC- 19 Detect Clock Out ErrorPurpose Signals the system that a user is still logged in at 11 PMRequirementsDevelopment None RisksPre-conditionsPost-conditions If any volunteer is clocked in at 11 PM then, volunteer coordinator is notified.Table 48: Typical Course of Action – Detect Clock Out ErrorSeq# Actor Actions System Response1 Clock signals that it is 11 PMCheck 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 ManagementView Volunteer Profile Table 49: Process Description - View Volunteer ProfileIdentifier UC- 20 View Volunteer ProfilePurpose View information, profiles, history, and skills of volunteers that have been assigned to the job requests. RequirementsDevelopment None RisksPre-conditions User is an employeePost-conditions Displaying the profile of each volunteer on screen.Table 50: Typical Course of Action – View Volunteer ProfileSeq# Actor Actions System Response1 Click on the name of each volunteer (the name is a link)2 Display profile of the specific volunteerAlternate course of action not applicable Exceptional course of action not applicableView Volunteer list Table 51: Process Description – View Volunteer ListIdentifier UC- 21 View Volunteer ListPurpose Allows the volunteer coordinator to view the list of volunteers based on different searching and sorting algorithmsRequirementsDevelopment Retrieving large list of volunteers from the database may put Risks stress on the network system as well as slowing down performance significantly.Pre-conditions User is volunteer coordinatorPost-conditions List of volunteers is displayed on the user’s screenTable 52: Typical Course of Action – View Volunteer List28 System and Software Architecture Description (SSAD) Version 2.2 Seq# Actor Actions System Response1 Click on “View Volunteers” link2 Display volunteer listing page3 Choose searching and sorting preferences4 Click “Submit”5 Display list of volunteers on user’s screenAlternate course of action not applicable Exceptional course of action not applicableEdit Volunteer Hours Table 53: Process Description – Edit Volunteer HourIdentifier UC- 22 Edit Volunteer HoursPurpose 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 performanceDevelopment None RisksPre-conditions User is volunteer coordinatorPost-conditions New volunteer hour is recorded to the databaseTable 54: Typical Course of Action – Edit Volunteer HourSeq Actor System Response # Actions1 Click on “Edit volunteer’s hours” link2 Display list of volunteers that have problems on their accounts (e.g. missing clock in/out entry)3 Click on volunteer’s name4 Display the hours record of the 29 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 volunteer3 Edit volunteer’s hours4 Click “Submit”5 Save changes to Volunteer’s hours in the database6 Display the hours record of the volunteerAlternate 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 time30 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 Design5.1 Design Overview 5.1.1System StructureFigure 4: Hardware Component Class Diagram31 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2Figure 5: Software Component Class DiagramFigure 6: Deployment Diagram32 System and Software Architecture Description (SSAD) Version 2.2Figure 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 DescriptionHardware Component DescriptionNon-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 DescriptionSoftware Component DescriptionUser 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 DescriptionWeb Component DescriptionBrowser 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 ClassesFigure 8: Interface Class Diagram Table 58 contains the description for each design class described for the set of interface classes. Table 58: Interface Class DescriptionClass Type DescriptionVolunteerApplicationPage 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 ClassesFigure 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 DescriptionClass Type DescriptionVolunteerApplicationController 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 ClassesFigure 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 DescriptionClass Type DescriptionTimeAwardController 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 ClassesFigure 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 DescriptionClass Type DescriptionJobController 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 ClassesFigure 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 DescriptionClass Type DescriptionReportCertificateController 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 ClassesFigure 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 DescriptionClass Type DescriptionCommentLogController 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 ClassesFigure 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 DescriptionClass Type DescriptionPersonManagementController 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 component42 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<To be done in Foundations phase>43 0a3ac602cf9616e5050c5232fba171e6.doc 8/25/06 System and Software Architecture Description (SSAD) Version 2.2 7.Architecture Styles, Patterns, and FrameworksTable 65 shows the architecture styles, patterns and frameworks used in this design. Table 65: Architectural Styles, Patterns, & FrameworkName Description Benefits, Costs, and Limitations3-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. 44

System and Software Architecture Description

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support