System and Software Architecture Description (SSAD) Version 2.2
System and Software Architecture Description (SSAD)
Student Scheduling System
Team #06
Douglass Kinnes: Project Manager, Quality Focal Point, Implementation Team member
Alexey Tregubov: System Architect, UML Modeler, Implementation Team member
Mihir Daptardar: Operational Concept Engineer, Quality Focal Point, Implementation Team member
Ihsan Tolga: Life Cycle Planner, Feasibility Analyst, Implementation Team member
Simone Lojeck: IV&V, Shaper, Quality Focal Point
2/24/2013
vi
SSAD_RDCP_S13b_T06_V2.2.doc Version Date: 2/24/2013
System and Software Architecture Description (SSAD) Version 2.2
Version History
Date / Author / Version / Changes made / Rationale /2/24/2013 / Alexey Tregubov / 1.0 / · Document created.
· Filled in sections 1, 2.1.1 – 2.1.4 / · Created initial version of the document.
10/21/2012 / Alexey Tregubov / 1.1 / · Fixed defects 7258, 7261, 7262
· Added section 2.2 / · defects are fixed
· new section for draft FCP added.
10/27/2012 / Alexey Tregubov / 1.2 / · Fixed defect 7263.
· Updated artifact diagram in section 2.1.2 / · defects are fixed
· added new information on the diagram.
10/30/2012 / Alexey Tregubov / 1.3 / · Fixed defects that were pointed out by TA. / · Fixed defects that were pointed out by TA.
11/14/12 / Alexey Tregubov / 1.4 / · Fixed defects 7602
· Fixed table formatting / · Updated status of the document.
11/26/12 / Alexey Tregubov / 1.5 / · Fixed defects: 7754-7759, 7743, 7744, 7747, 7749, 7750, 7752
· Sections 3, 4, and 5 were added. / · Fixed defects that were pointed out by TA after grading FCP.
· Updates for DC package.
12/10/12 / Alexey Tregubov / 1.6 / · Updated design class diagrams
· Updated deployment diagram (browser versions included) / · ARB recommendations are included.
02/11/13 / Alexey Tregubov / 2.0 / · Updated design class diagrams (typos fixed)
· Algorithm design added. / · ARB recommendations are included.
02/20/13 / Alexey Tregubov / 2.1 / · Pseudo code added
· Pseudo code description added / · Client’s request resolved.
· Pseudo code description answers client’s questions.
02/24/13 / Alexey Tregubov / 2.2 / · All the hand-written formulas retyped.
· Added description for each formula for each constraint.
· Pseudo code description shaped. / · Client’s request resolved.
Table of Contents
System and Software Architecture Description (SSAD) i
Version History ii
Table of Contents iii
Table of Tables iv
Table of Figures vi
1. Introduction 1
1.1 Purpose of the SSAD 1
1.2 Status of the SSAD 1
2. System Analysis 2
2.1 System Analysis Overview 2
2.2 System Analysis Rationale 18
3. Technology-Independent Model 19
3.1 Algorithm design 19
4. Technology-Specific System Design 28
4.1 Design Overview 28
4.2 Design Rationale 47
5. Architectural Styles, Patterns and Frameworks 48
vi
SSAD_RDCP_S13b_T06_V2.2.doc Version Date: 2/24/2013
System and Software Architecture Description (SSAD) Version no 2.2
Table of Tables
Figure 1: System Context DiagramTable 1: Actors Summary 2
Table 2: Artifacts and Information Summary 5
Table 3: Process Description 6
Table 4: Typical Course of Action 7
Table 5: Exceptional Course of Action 7
Table 6: Process Description 8
Table 7: Typical Course of Action 8
Table 8: Process Description 8
Table 9: Typical Course of Action 9
Table 10: Exceptional Course of Action 9
Table 11: Process Description 9
Table 12: Typical Course of Action 10
Table 13: Exceptional Course of Action 10
Table 14: Process Description 10
Table 15: Typical Course of Action 11
Table 16: Exceptional Course of Action 11
Table 17: Process Description 12
Table 18: Typical Course of Action 12
Table 19: Alternate Course of Action 13
Table 20: Process Description 13
Table 21: Typical Course of Action 14
Table 22: Exceptional Course of Action 14
Table 23: Process Description 15
Table 24: Typical Course of Action 15
Table 25: Exceptional Course of Action 15
Table 26: Process Description 16
Table 27: Typical Course of Action 16
Table 28: Exceptional Course of Action 16
Table 29: Process Description 17
Table 30: Typical Course of Action 17
Table 31: Exceptional Course of Action 17
Table 32: Hardware Component Description 31
Table 33: Software Component Description 31
Table 34: Supporting Software Component Description 31
Table 35: Interface Classes Description 33
Table 36: Design Class Description 36
Table 37: Design Class Description 37
Table 38: Design Class Description 39
Table 39: Design Class Description 40
Table 40: Design Class Description 41
Table 41: Architectural Styles, Patterns, and Frameworks 48
Table of Figures
Figure 1: System Context DiagramTable 1: Actors Summary 2
Figure 2: Artifacts and Information Diagram 4
Figure 3: Process Diagram 6
Figure 4: Example of Study plan (matrix S) 19
Figure 5: Reordering of the decision variables (gray cells). 27
Figure 6: Hardware Component Class Diagram 28
Figure 7: Software Component Class Diagram 29
Figure 8: Deployment Diagram 30
Figure 11: Supporting Software Component Class Diagram 30
Figure 10: Interface Class Diagram 32
Figure 11: Study plan construction Class Diagram` 35
Figure 12: Course management Class Diagram 37
Figure 13: Course group management Class Diagram 38
Figure 14: Requirements management Class Diagram 39
Figure 15: Degree management Class Diagram 40
Figure 16: Request Study Plan Sequence Diagram 42
Figure 17: Add New Degree Sequence Diagram 43
Figure 18: Interface between presentation and control levels 44
Figure 19: Data base design diagram 46
vi
SSAD_RDCP_S13b_T06_V2.2.doc Version Date: 2/24/2013
System and Software Architecture Description (SSAD) Version 2.2
1. Introduction
1.1 Purpose of the SSAD
The purpose of the SSAD is to document the results of the object-oriented analysis and design (OOA&D) of the Student Scheduling System. The SSAD is used by the builder (programmer/developer) as reference to the system architecture. The Student Scheduling System should be faithful to the architecture specified in this document. Furthermore, the SSAD is used by the maintainer and clients to help understand the structure of the system once the proposed system is delivered.
1.2 Status of the SSAD
This is SSAD – version 2.1 for RDC package. All sections are completed.
2. System Analysis
2.1 System Analysis Overview
The purpose of the Student Scheduling System is to so save students’ and advisers’ time spent on constructing study plan at Stevens University of Technology. The system is intended to achieve goal though automation of study plan construction. Course directors enter information in the system about the courses and degree requirements for each of three degrees (CS, SyS, IS) offered at Stevens department of Computer Science. After that students are able to enter their requirements for the study plan in the system such as desired year of graduation, preferred elective courses, and transfer credits; the system makes attempt to construct study plan satisfying these requirements. If it is not possible to find schedule satisfying the requirements the system suggests the student to relax constrains for the study plan and repeat attempt to construct the study plan.
2.1.1 System Context
Figure 1: System Context Diagram
Table 1: Actors Summary
User / Any user of the system / · Log in / log out
Student / Stevens’ students that use the system to construct study plan. / · Enter constraints for the study plan (year of graduation, electives, and so on) and request the system to construct the study plan.
Course director / Stevens’ faculty staff who is responsible for adding and updating available courses and degree requirements. / · Add and/or update available courses and degree requirements.
System administrator / Stevens’ staff who is responsible for adding, deleting, and updating user profile (accounts). / · Add, delete, and update user profile.
2.1.2 Artifacts & Information
Figure 2: Artifacts and Information Diagram
In the Figure 2 the following data types were used:
· Integer – integer number
· Date – date
· Varchar – string
For this diagram default Visual Paradigm data types were used (there were no string, only varchar was available). Only Professional Edition of VP allows changing default data types.
Table 2: Artifacts and Information Summary
Study plan / Contains schedule of courses that satisfies student’s constraints. That is a final artifact which student wants to get.
Study plan constraint / Constraints study plan construction which allow student to specify his/her desires such as preferred electives, year of graduation, etc.
Course profile / Contains description of the course and its attributes such as number of credits, level, type (CS, HUM, …). These course profiles are used to specify Study plan constraints (such as preferred electives) and Degree requirements.
Degree requirement / Represents a constraint for the study plan satisfying the requirements of a particular degree. All the Degree requirements for a particular degree comprise a set of all possible study plans solutions. Student adds his/her constrains to this set.
Degree profile / Contains general information about the degree (such as name). Student has to choose degree (one of the three CS, SyS, IS) and then specify his/her constraints for study plan.
2.1.3 Behavior
Figure 3: Process Diagram
2.1.3.1 Authentication
2.1.3.1.1 Log in
Table 3: Process Description
Identifier / UC-1: Log inPurpose / Authorize the user to log in the system and assign the user associated system role.
Requirements / WC_1533:
System must provide user privileges according his/her role (student/administrator).
Development Risks / None
Pre-conditions / Log in page is opened.
Post-conditions / Authorized users get access to the system, and initial page will be shown. Unauthorized users will be denied.
Table 4: Typical Course of Action
Seq# / Actor’s Action / System’s Response1 / Enters a username and password on the login page.
2 / Clicks the “Sign in” button.
3 / System retrieves information associated with given username (role, password hash) form DB and checks password (password hash). System ensures that credentials are correct (they are correct), and then it shows initial page according to the user’s role.
Table 5: Exceptional Course of Action
Seq# / Actor’s Action / System’s Response1 / Enters a username and password on the login page.
2 / Clicks the “Sign in” button.
3 / System retrieves information associated with given username (role, password hash) form DB and checks password (password hash).System ensures that credentials are not correct.
Then system shows message: “Username or password is wrong. Please try again.”
4 / System shows log in page again.
There is no Alternate Courses of Action. Blank fields are treated as wrong username or password.
2.1.3.1.2 Log out
Table 6: Process Description
Purpose / Authorize the user to log in the system and assign the user associated system role.
Requirements / WC_1533:
System must provide user privileges according his/her role (student/course director/system administrator).
Development Risks / None.
Pre-conditions / User logged in the system. User can be on any page (except login page, because user is already in the system); “Log out” link is available on every page.
Post-conditions / User’s session is closed, and log in page will be shown.
Table 7: Typical Course of Action
Seq# / Actor’s Action / System’s Response1 / Clicks the “Sign out” button.
2 / System shows message that session was successfully closed, and then it shows log in page again.
There is no Exceptional or Alternate Courses of Action. Blank fields are treated as wrong username or password.
2.1.3.2 User management
2.1.3.2.1 Add user
Table 8: Process Description
Identifier / UC-3: Adding new user.Purpose / Give the administrator ability to add new user in the system.
Requirements / WC_1533:
System must provide user privileges according his/her role (student/course director/system administrator). User is on the initial page.
Development Risks / None.
Pre-conditions / User successfully entered the system as a system administrator. User is on initial page.
Post-conditions / One user profile is added to the system.
Table 9: Typical Course of Action
Seq# / Actor’s Action / System’s Response1 / Clicks the button “Add new user”
2 / System shows empty user profile.
3 / Enters user’s name, login, role, and password.
4 / Clicks the button “Add”
5 / System checks correctness of the data. Data is correct. System adds new user and confirmation that user was added successfully.
Table 10: Exceptional Course of Action
Seq# / Actor’s Action / System’s Response1-4 / Actions and responses are the same as in typical scenario.
5 / System checks correctness of the data. Data is incorrect (for example, username already exists). System shows appropriate message. System shows the same page.
There is no Alternate Course of Action.
2.1.3.2.2 Delete user
Table 11: Process Description
Identifier / UC-4: Deleting user.Purpose / Give the administrator ability to delete existing user from the system.
Requirements / WC_1533:
System must provide user privileges according his/her role (student/course director/system administrator). User is on the initial page.
Development Risks / None.
Pre-conditions / User successfully entered the system as a system administrator.
System contains user for deletion. Edit user profile page is opened.
Post-conditions / One user profile is deleted from the system.
Table 12: Typical Course of Action
Seq# / Actor’s Action / System’s Response1 / Presses the button “Delete user”
2 / System requests confirmation for deletion the user.
3 / Confirms deletion
4 / System deletes the user and shows confirmation that user was deleted successfully.
System redirects user to the initial page.
Table 13: Exceptional Course of Action
Seq# / Actor’s Action / System’s Response1-3 / Actions and responses are the same as in typical scenario.
4 / The user cannot be deleted (DB is not accessible or user was not found). System shows appropriate message (ex. “DB is accessible” or “User was not found. Probably it was already deleted”)
There is no Alternate Courses of Action that have special processing.
2.1.3.2.3 Update user profile
Table 14: Process Description
Identifier / UC-5: Updating user profile.Purpose / Give the administrator ability to update existing user from the system (reset password, change name, and so on).
Requirements / WC_1533:
System must provide user privileges according his/her role (student/course director/system administrator). User is on the initial page.
Development Risks / None.
Pre-conditions / User successfully entered the system as a system administrator.
System contains user for updating. . Edit user profile page is opened.
Post-conditions / One user profile is updated.
Table 15: Typical Course of Action