Download STUDENT CURRICULUM PLANNING SYSTEM

STUDENT CURRICULUM PLANNING SYSTEM
By:
KEVIN SUNG
A Report
Submitted in partial fulfillment of the requirements for the degree
Master in Software Engineering
Department of Computing & Information Sciences
Kansas State University
Manhattan, Kansas, 66506
USA
Fall 2004
Approved By:
Dr. Daniel Andresen
(Major Advisor)
Date: Dec 15th, 2004
Abstract
The student curriculum planning system (SCPS) is designed to help faculty and student
of the Computing and Information Science department to plan for student’s curriculum.
This system is built under the Microsoft .NET framework. It system has capabilities of
storing curriculum plans, sharing curriculum plans between student and their advisor,
generating new curriculum plan, and checking prerequisites of courses.
Table of Content
ABSTRACT ................................................................................................................................................... I
TABLE OF CONTENT ................................................................................................................................3
TABLE OF FIGURES ..................................................................................................................................9
LIST OF TABLES ...................................................................................................................................... 10
CHAPTER 1. VISION DOCUMENT........................................................................................................ 11
1.
INTRODUCTION ............................................................................................................................. 11
1.1.
2.
PROJECT OVERVIEW ................................................................................................................... 12
2.1.
2.2.
2.3.
3.
MOTIVATION ............................................................................................................................... 11
INTRODUCTION ........................................................................................................................... 12
GOAL .......................................................................................................................................... 13
PURPOSE ..................................................................................................................................... 13
REQUIREMENT SPECIFICATIONS ............................................................................................ 13
3.1.
3.2.
3.3.
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.6.
3.3.7.
3.3.8.
3.4.
3.5.
3.6.
3.7.
MAIN REQUIREMENTS................................................................................................................. 13
EXTERNAL INTERFACE REQUIREMENTS ...................................................................................... 14
CRITICAL USE CASES .................................................................................................................. 15
USE CASE 1: LOG-IN REQUIREMENT ........................................................................................... 15
USE CASE 2: ADD COURSE REQUIREMENT.................................................................................. 16
USE CASE 3: DROP COURSE REQUIREMENT ................................................................................ 17
USE CASE 4: GENERATE REPORT REQUIREMENT ........................................................................ 17
USE CASE 5: ADD COURSE REQUIREMENT.................................................................................. 17
USE CASE 6: DROP COURSE REQUIREMENT ................................................................................ 18
USE CASE 7: ADD USER REQUIREMENT ...................................................................................... 18
USE CASE 8: DROP USER REQUIREMENT .................................................................................... 19
PERFORMANCE REQUIREMENTS .................................................................................................. 19
ASSUMPTIONS ............................................................................................................................. 20
CONSTRAINTS ............................................................................................................................. 20
ENVIRONMENT ............................................................................................................................ 20
CHAPTER 2. PROJECT PLAN ................................................................................................................ 22
1.
TASK BREAKDOWN ...................................................................................................................... 22
1.1.
1.2.
1.3.
2.
COST ESTIMATE ............................................................................................................................ 24
2.1.
3.
INCEPTION PHASE ........................................................................................................................ 22
ELABORATION PHASE .................................................................................................................. 22
PRODUCTION PHASE .................................................................................................................... 23
COCOMO .................................................................................................................................. 24
ARCHITECTURE ELABORATION PLAN .................................................................................. 28
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
REVISION OF VISION DOCUMENT ................................................................................................. 28
REVISION OF PROJECT PLAN ........................................................................................................ 28
ARCHITECTURE DESIGN .............................................................................................................. 28
DEVELOPMENT OF PROTOTYPE.................................................................................................... 28
TEST PLAN .................................................................................................................................. 29
FORMAL TECHNICAL INSPECTIONS .............................................................................................. 29
FORMAL REQUIREMENT SPECIFICATIONS ................................................................................... 29
4.
IMPLEMENTATION PLAN ........................................................................................................... 29
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
WORK BREAKDOWN STRUCTURE ............................................................................................... 29
UPDATED DOCUMENTS ................................................................................................................ 32
USER’S MANUAL ......................................................................................................................... 32
COMPONENT DESIGN ................................................................................................................... 32
SOURCE CODE ............................................................................................................................. 33
ASSESSMENT EVALUATION ......................................................................................................... 33
PROJECT EVALUATION ................................................................................................................ 33
FORMAL TECHNICAL INSPECTION LETTERS ................................................................................. 33
CHAPTER 3. SOFTWARE QUALITY ASSURANCE PLAN ............................................................... 34
1.
PURPOSE ........................................................................................................................................... 34
2.
REFERENCES .................................................................................................................................. 34
3.
MANAGEMENT ............................................................................................................................... 34
3.1.
3.2.
3.3.
4.
ORGANIZATION ........................................................................................................................... 34
TASKS ......................................................................................................................................... 35
RESPONSIBILITIES ....................................................................................................................... 35
DOCUMENTATION......................................................................................................................... 36
4.1.
4.2.
4.3.
4.4.
4.5.
5.
SOFTWARE REQUIREMENT SPECIFICATION (SRS) ....................................................................... 36
SOFTWARE DESIGN DESCRIPTION (SDD) .................................................................................... 36
PROJECT PLAN ............................................................................................................................ 36
SOFTWARE TEST PLAN ................................................................................................................ 37
PROJECT EVALUATION ................................................................................................................ 37
STANDARDS, PRACTICES, CONVENTIONS, AND METRICS .............................................. 37
5.1.
5.2.
5.3.
DOCUMENTATION STANDARDS ................................................................................................... 37
CODING STANDARDS .................................................................................................................. 37
METRICS ..................................................................................................................................... 37
6.
REVIEWS AND AUDITS ................................................................................................................. 38
7.
TEST ................................................................................................................................................... 38
8.
PROBLEM REPORTING AND CORRECTIVE ACTION .......................................................... 38
9.
TOOLS, TECHNIQUES, AND METHODOLOGIES ................................................................... 38
10.
TRAINING .................................................................................................................................... 39
11.
DELIVERABLES ......................................................................................................................... 39
CHAPTER 4. ARCHITECTURE DESIGN .............................................................................................. 41
1.
INTRODUCTION ............................................................................................................................. 41
2.
CLASS DIAGRAM............................................................................................................................ 42
3.
SEQUENCE DIAGRAM .................................................................................................................. 45
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
LOG IN ........................................................................................................................................ 45
ADD COURSE --- USER ................................................................................................................ 46
DROP COURSE—USER ................................................................................................................ 48
LOAD PLAN---USER .................................................................................................................... 49
SAVE PLAN---USER ..................................................................................................................... 50
GENERATE REPORT---USER ........................................................................................................ 51
ADD COURSE---ADMINISTRATOR ............................................................................................... 52
DROP COURSE---ADMINISTRATOR .............................................................................................. 53
4.
STATE/ACTIVITY DIAGRAM ...................................................................................................... 54
CHAPTER 5. FORMAL REQUIREMENT SPECIFICATION ............................................................. 55
1.
PURPOSE ........................................................................................................................................... 55
2.
REFERENCES .................................................................................................................................. 55
3.
SPECIFICATIONS ........................................................................................................................... 55
3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
3.1.7.
3.1.8.
3.1.9.
3.1.10.
3.1.11.
3.1.12.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.2.7.
3.2.8.
3.2.9.
3.2.10.
3.2.11.
3.2.12.
3.2.13.
3.2.14.
3.2.15.
3.2.16.
3.2.17.
3.2.18.
3.2.19.
3.2.20.
3.3.
3.3.1.
CLASSES CLASSES....................................................................................................................... 55
SCPS .......................................................................................................................................... 55
PLANVIEW .................................................................................................................................. 56
COURSEVIEW .............................................................................................................................. 56
COURSEPLAN .............................................................................................................................. 56
ADMINVIEW ............................................................................................................................... 57
USER ........................................................................................................................................... 57
FACULTY..................................................................................................................................... 57
STUDENT ..................................................................................................................................... 58
ADMINISTRATOR ......................................................................................................................... 58
COURSE .................................................................................................................................. 58
TRANSCRIPT ........................................................................................................................... 59
TRANSCRIPTENTRY ................................................................................................................ 59
ASSOCIATION .............................................................................................................................. 60
TRANSCRIPTDB .......................................................................................................................... 60
TRANSCRIPTDATA ...................................................................................................................... 60
GRADE ........................................................................................................................................ 60
ADVISING .................................................................................................................................... 61
PLANDB ...................................................................................................................................... 61
COURSETAKEN ........................................................................................................................... 61
PLANOWNERSHIP ....................................................................................................................... 61
VIEWPLAN .................................................................................................................................. 62
VIEWCOURSE .............................................................................................................................. 62
MAINVIEW ............................................................................................................................. 62
ONEVIEW ............................................................................................................................... 63
FUTURECOURSE ..................................................................................................................... 63
UTILIZING .............................................................................................................................. 63
MODERATING ......................................................................................................................... 63
COURSEDB ............................................................................................................................. 64
DBADMIN............................................................................................................................... 64
VIEWDB ................................................................................................................................. 64
PREREQ .................................................................................................................................. 64
ADMINISTRATING ................................................................................................................... 65
COURSETRANSCIPT ................................................................................................................ 65
CONSTRAINTS ............................................................................................................................. 65
ONLY THE STUDENT, HIS OR HER ADVISOR, AND THE SYSTEM ADMINISTRATOR CAN ACCESS (THE
STUDENT’S) TRANSCRIPT. .......................................................................................................................... 65
3.3.2. THE STUDENT CANNOT HAVE MORE THAN ONE TRANSCRIPT. ...................................................... 66
3.3.3. A COURSE WHICH HAS A C OR ABOVE GRADE CAN BE PUT ON THE COURSE PLANNING CHART. ... 66
3.3.4. THE USER HAS A UNIQUE USER ID. ............................................................................................. 66
3.3.5. THERE ARE NO CIRCULAR PREREQUISITES. .................................................................................. 66
3.3.6. THE USER COULD ONLY SAVE A MAXIMUM OF THREE PLANS. ...................................................... 66
3.3.7. A COURSE AND A TRANSCRIPT ENTRY CANNOT BE ON THE PLAN AT THE SAME TIME IF THEY
REPRESENT THE SAME CLASS. .................................................................................................................... 66
3.3.8. NO DUPLICATE COURSE ON THE PLAN. ........................................................................................ 67
3.3.9. NO DUPLICATE TRANSCRIPTENTRY ON THE PLAN. ...................................................................... 67
3.3.10.
THERE SHOULD BE EITHER A PLANVIEW OR COURSEVIEW SHOWN TO THE USER. .................. 67
3.3.11.
FACULTY WHO HAS NO ADVISEES CANNOT ACCESS THE SYSTEM............................................ 67
3.3.12.
A TRANSCRIPT ENTRY MUST HAVE A UNIQUE TRANSCRIPT ID. ............................................... 67
3.3.13.
A TRANSCRIPT ENTRY MUST MATCH A COURSE IN THE COURSE DATABASE. ........................... 68
3.3.14.
ALL USERS AND ADMINISTRATORS SHOULD HAVE UNIQUE USER NAMES. ............................... 68
3.3.15.
EACH COURSE SHOULD HAVE AN UNIQUE REFERENCE NUMBER. ............................................ 68
3.4.
OPERATION ................................................................................................................................. 68
3.4.1. ADMINISTRATORS CAN ONLY ADD COURSES WHICH ARE NOT YET CONTAINED IN THE COURSE
DATABASE. ................................................................................................................................................ 68
3.4.2. ADMINISTRATORS CAN ONLY DELETE COURSES THAT ARE IN THE COURSE DATABASE. .............. 69
CHAPTER 6. TEST PLAN ........................................................................................................................ 70
TEST PLAN IDENTIFIER ........................................................................................................................ 70
1.
PURPOSE ........................................................................................................................................... 70
2.
TEST ITEMS ..................................................................................................................................... 70
3.
FEATURES TO BE TESTED .......................................................................................................... 70
4.
APPROACH ....................................................................................................................................... 71
4.1.
4.2.
4.3.
5.
ENVIRONMENTAL NEEDS. .......................................................................................................... 72
5.1.
5.2.
5.3.
6.
HARDWARE ................................................................................................................................. 72
SOFTWARE .................................................................................................................................. 72
OPERATING SYSTEM .................................................................................................................... 72
TEST CASES ..................................................................................................................................... 72
6.1.
6.1.1.
6.1.2.
6.1.3.
6.1.4.
6.1.5.
6.1.6.
6.1.7.
6.1.8.
6.2.
7.
UNIT TESTING ............................................................................................................................. 71
INTEGRATION TESTING ................................................................................................................ 71
SYSTEM TESTING ......................................................................................................................... 72
UNIT/INTEGRATION TESTING ....................................................................................................... 72
LOG INTO THE SCPS ................................................................................................................... 72
ADD COURSE TO COURSE PLAN ................................................................................................... 73
DROP COURSE FROM COURSE PLAN ............................................................................................. 74
GENERATE REPORT ..................................................................................................................... 74
SAVE COURSE PLAN .................................................................................................................... 75
LOAD COURSE PLAN .................................................................................................................... 75
ADD COURSE TO DATABASE ........................................................................................................ 76
DROP COURSE FROM DATABASE .................................................................................................. 76
SYSTEM TESTING ......................................................................................................................... 77
SCHEDULE ....................................................................................................................................... 77
CHAPTER 7. COMPONENT DESIGN .................................................................................................... 78
1.
INTRODUCTION ............................................................................................................................. 78
2.
CLASS DIAGRAM............................................................................................................................ 78
3.
CLASS DESCRIPTION .................................................................................................................... 79
3.1.
3.1.1.
3.1.2.
3.2.
3.2.1.
3.2.2.
3.3.
3.3.1.
3.3.2.
3.4.
SCPS CLASS ............................................................................................................................... 79
MEMBER ATTRIBUTES ................................................................................................................ 80
FUNCTIONS ................................................................................................................................. 81
PLANVIEW CLASS ....................................................................................................................... 82
MEMBER ATTRIBUTES ................................................................................................................ 82
FUNCTIONS ................................................................................................................................. 83
COURSEVIEW CLASS................................................................................................................... 85
MEMBER ATTRIBUTES ................................................................................................................ 85
FUNCTIONS ................................................................................................................................. 87
COURSEVIEWIS CLASS ............................................................................................................... 88
3.4.1.
3.4.2.
3.5.
3.5.1.
3.5.2.
3.6.
3.6.1.
3.6.2.
3.7.
3.7.1.
3.7.2.
3.8.
3.8.1.
3.8.2.
3.8.3.
3.9.
3.9.1.
3.9.2.
3.10.
3.10.1.
3.10.2.
3.11.
4.
SEQUENCE DIAGRAM ................................................................................................................ 100
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
5.
MEMBER ATTRIBUTES ................................................................................................................ 88
FUNCTIONS ................................................................................................................................. 90
CONTAINERVIEW CLASS ............................................................................................................. 91
MEMBER ATTRIBUTES ................................................................................................................ 91
FUNCTIONS ................................................................................................................................. 91
COURSECONTAINER CLASS ........................................................................................................ 92
MEMBER ATTRIBUTES ................................................................................................................ 92
FUNCTIONS ................................................................................................................................. 94
PRINTVIEW CLASS ...................................................................................................................... 94
MEMBER ATTRIBUTES ................................................................................................................ 95
FUNCTIONS ................................................................................................................................. 95
USER CLASS ................................................................................................................................ 95
CONSTRUCTORS .......................................................................................................................... 95
MEMBER ATTRIBUTES ................................................................................................................ 96
FUNCTIONS ................................................................................................................................. 96
FACULTY CLASS .......................................................................................................................... 96
CONSTRUCTORS .......................................................................................................................... 97
MEMBER ATTRIBUTES ................................................................................................................ 97
STUDENT CLASS .......................................................................................................................... 97
CONSTRUCTOR ....................................................................................................................... 98
MEMBER ATTRIBUTES ............................................................................................................ 98
OTHER CLASSES.......................................................................................................................... 98
LOG IN ...................................................................................................................................... 100
ADD COURSE---USER ................................................................................................................ 101
DROP COURSE—USER .............................................................................................................. 102
LOAD PLAN---USER .................................................................................................................. 103
SAVE PLAN---USER ................................................................................................................... 105
GENERATE REPORT---USER ...................................................................................................... 105
STATE/ACTIVITY DIAGRAM .................................................................................................... 106
CHAPTER 8. ASSESSMENT EVALUATION ...................................................................................... 107
1.
PURPOSE ......................................................................................................................................... 107
2.
TESTING RESULTS SUMMARY ................................................................................................ 107
3.
TEST RESULTS DETAIL .............................................................................................................. 107
3.1.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.3.
3.3.1.
3.3.2.
UNIT TESTING ........................................................................................................................... 107
INTEGRATION TESTING ............................................................................................................. 112
LOG INTO THE SCPS ................................................................................................................. 112
ADD COURSE TO COURSE PLAN ................................................................................................ 113
DROP COURSE FROM COURSE PLAN.......................................................................................... 113
GENERATE REPORT ................................................................................................................... 113
SAVE COURSE PLAN.................................................................................................................. 113
LOAD COURSE PLAN ................................................................................................................. 114
PERFORMANCE TESTING ........................................................................................................... 114
SUMMARY ................................................................................................................................. 116
SCALABILITY ............................................................................................................................ 117
CHAPTER 9. USER MANUAL ............................................................................................................... 118
1.
INTRODUCTION ........................................................................................................................... 118
2.
INSTALL SCPS ............................................................................................................................... 118
2.1.
2.2.
HARDWARE PREREQUISITE ....................................................................................................... 118
SOFTWARE PREREQUISITES ....................................................................................................... 118
2.3.
2.4.
3.
NETWORK PREREQUISITES ........................................................................................................ 119
SOFTWARE SETUP ..................................................................................................................... 119
CLIENT USAGE ............................................................................................................................. 120
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
LOG IN ...................................................................................................................................... 120
LOAD PLAN FOR FACULTY USER .............................................................................................. 121
LOAD PLAN---USER .................................................................................................................. 122
ADD COURSE --- USER .............................................................................................................. 123
DROP COURSE ........................................................................................................................... 124
SAVE PLAN ............................................................................................................................... 124
GENERATE REPORT---USER ...................................................................................................... 125
CHAPTER 10. PROJECT EVALUATION ............................................................................................ 126
1.
PURPOSE ......................................................................................................................................... 126
2.
USEFULNESS OF THE METHODOLOGIES USED ................................................................. 126
2.1.
2.2.
3.
UNIFIED MODELING LANGUAGE ............................................................................................... 126
OBJECT CONSTRAINT LANGUAGE ............................................................................................. 126
ACCURACY OF THE ESTIMATIONS ....................................................................................... 127
3.1.
3.2.
LINES OF CODE ......................................................................................................................... 127
TIME ESTIMATION ..................................................................................................................... 127
4.
LESSON LEARNED ....................................................................................................................... 130
5.
FUTURE WORK ............................................................................................................................. 131

TEST CODE..................................................................................................................................... 132

USE MODEL ................................................................................................................................... 135
APPENDIX B. FORMAL INSPECTION CHECKLIST ....................................................................... 143

CEM’S FORMAL INSPECTION CHECKLIST ......................................................................... 143
1.
PURPOSE ......................................................................................................................................... 143
2.
ITEMS TO BE INSPECTED.......................................................................................................... 143
3.
FORMAL TECHNICAL INSPECTORS ...................................................................................... 143
4.
FORMAL TECHNICAL INSPECTION CHECKLIST .............................................................. 143

GUILLEN’S FORMAL INSPECTION CHECKLIST ................................................................ 145
1.
PURPOSE ......................................................................................................................................... 145
2.
ITEMS TO BE INSPECTED.......................................................................................................... 145
3.
FORMAL TECHNICAL INSPECTORS ...................................................................................... 145
4.
FORMAL TECHNICAL INSPECTION CHECKLIST .............................................................. 145
APPENDIX C. FORMAL INSPECTION LETTER .............................................................................. 147

CEM’S FORMAL INSPECTION LETTER ................................................................................. 147

GUILLEN’S FORMAL INSPECTION LETTER ........................................................................ 147
Table of Figures
FIGURE 1. OVERVIEW OF SCPS ...................................................................................................................... 12
FIGURE 2. SCPS IN THREE-TIER ARCHITECTURE ............................................................................................ 14
FIGURE 3. CRITICAL USE CASES...................................................................................................................... 15
FIGURE 4. THE SCPS PROJECT GANTT CHART................................................................................................ 24
FIGURE 5. SCPS CLASS DIAGRAM .................................................................................................................. 42
FIGURE 6. USER LOG IN TO THE SYSTEM ......................................................................................................... 45
FIGURE 7. ADD A COURSE TO THE COURSE PLAN FOR THE USER ..................................................................... 46
FIGURE 8. USER DELETES A COURSE FROM THE COURSE PLAN ....................................................................... 48
FIGURE 9. USER LOADS AN EXISTING PLAN IN THE SYSTEM ............................................................................ 49
FIGURE 10. USER SAVES THE CURRENT PLAN ................................................................................................. 50
FIGURE 11. USER GENERATES A REPORT ........................................................................................................ 51
FIGURE 12. ADMINISTRATOR ADDS A NEW COURSE TO THE DATABASE .......................................................... 52
FIGURE 13. ADMINISTRATOR DROPS A COURSE FROM THE DATABASE ........................................................... 53
FIGURE 14. THE STATE DIAGRAM OF THE SCPS ............................................................................................. 54
FIGURE 15. SCPS CLASS DIAGRAM ................................................................................................................ 78
FIGURE 16. SCPS CLASS DIAGRAM ................................................................................................................ 79
FIGURE 17. PLANVIEW CLASS DIAGRAM ........................................................................................................ 82
FIGURE 18. COURSEVIEW CLASS DIAGRAM .................................................................................................... 85
FIGURE 19. COURSEVIEWIS CLASS DIAGRAM ................................................................................................ 88
FIGURE 20. CONTAINERVIEW CLASS DIAGRAM .............................................................................................. 91
FIGURE 21. COURSECONTAINER CLASS DIAGRAM .......................................................................................... 92
FIGURE 22. COURSECONTAINER CLASS DIAGRAM......................................................................................... 95
FIGURE 9. USER CLASS DIAGRAM .................................................................................................................. 95
FIGURE 24. FACULTY CLASS DIAGRAM ......................................................................................................... 97
FIGURE 25. FACULTY CLASS DIAGRAM ......................................................................................................... 97
FIGURE 26. USER LOG IN THE SYSTEM .......................................................................................................... 100
FIGURE 27. ADD COURSE TO THE COURSE PLAN FOR USER ........................................................................... 101
FIGURE 28. USER DELETES A COURSE FROM COURSE PLAN .......................................................................... 102
FIGURE 29. FACULTY USER LOADS AN EXISTING PLAN FROM THE SYSTEM ................................................... 103
FIGURE 30. STUDENT USER LOAD AN EXISTING PLAN FROM THE SYSTEM ..................................................... 104
FIGURE 31. USER SAVES THE CURRENT PLAN ............................................................................................... 105
FIGURE 32. USER GENERATES A REPORT ...................................................................................................... 105
FIGURE 33. THE STATE DIAGRAM OF THE SCPS ........................................................................................... 106
FIGURE 34. ONE-USER PERFORMANCE TEST RESULT .................................................................................... 115
FIGURE 35. TWO-USERS PERFORMANCE TEST RESULT .................................................................................. 115
FIGURE 36. THREE-USERS PERFORMANCE TEST RESULT ............................................................................... 115
FIGURE 37. FOUR-USERS PERFORMANCE TEST RESULT ................................................................................. 116
FIGURE 38. USER LOG IN THE SYSTEM .......................................................................................................... 120
FIGURE 39. FACULTY USER LOADS AN EXISTING PLAN FROM THE SYSTEM ................................................... 121
FIGURE 40. STUDENT USER LOADS AN EXISTING PLAN FROM THE SYSTEM ................................................... 122
FIGURE 41. COURSE PLAN INTERFACE .......................................................................................................... 123
FIGURE 42. ADD COURSE TO THE COURSE PLAN FOR USER ........................................................................... 124
FIGURE 43. USER GENERATES A REPORT ...................................................................................................... 125
FIGURE 44. PHASE I TASK BREAKDOWN DIAGRAM ....................................................................................... 129
FIGURE 45. PHASE II TASK BREAKDOWN DIAGRAM ...................................................................................... 129
FIGURE 46. PHASE III TASK BREAKDOWN DIAGRAM .................................................................................... 130
List of Tables
TABLE 1. THE PROJECT CHARACTERISTICS TABLE OF THE COCOMO MODEL................................................ 26
TABLE 2. THE WORK BREAKDOWN STRUCTURE TABLE .................................................................................. 29
TABLE 3. THE TEST CASE TABLE .................................................................................................................... 70
TABLE 4. THE TEST RESULT TABLE............................................................................................................... 107
TABLE 5. THE SCPS WEB FORM TEST RESULT TABLE .................................................................................. 107
TABLE 6. THE PLANVIEW WEB FORM TEST RESULT TABLE .......................................................................... 108
TABLE 7. THE COURSEVIEW WEB FORM TEST RESULT TABLE ..................................................................... 110
TABLE 8. THE COURSEVIEWIS WEB FORM TEST RESULT TABLE .................................................................. 110
TABLE 9. THE COURSECONTAINER CLASS TEST RESULT TABLE ................................................................... 111
TABLE 10. THE PERFORMANCE TEST RESULT TABLE .................................................................................... 116
TABLE 11. DURATION TABLE ....................................................................................................................... 128
TABLE 12. TASK BREAKDOWN TABLE .......................................................................................................... 128
Chapter 1. Vision Document
1.
Introduction
1.1.
Motivation
Kansas State University Computer and Information Science Department offers
two degree programs for its undergraduate students. Various specialization tracks
are tailored within each program to provide choices for students to better fit
themselves for industrial need. Constant growth of courses provided and changes
made to curriculums have created complexity for not only the students but also
their academic advisors to draft an optimal course plan for themselves or their
advisees. In order to ease strains on course planning, a better tool needs to be
developed.
Since its inception, the Internet has become an important tool to people for daily
communication. It has also provided an access point to an infinite knowledge
bank. Tools and software within the Web give ease for the decision-making
process. Microsoft Corp. has recently released a powerful tool, .NET Framework,
to enable Internet software developers to create extensive Web applications for
diverse purposes. Coordinated with the power of .NET Framework, the Internet
is a perfect environment for the new tool to be developed on.
The main motivation of this project is to create a Web application, Student
Curriculum Planning System (SCPS), to help students and faculty at the CIS
department with decision making for student course planning, and also to explore
the capabilities of .NET Framework.
2.
Project Overview
SQL Server
IIS Server
Clients
Figure 1. Overview of SCPS
2.1.
Introduction
SCPS provides an interactive user interface for planning a student’s curriculum. Its
target users are undergraduate students and their advisors in the CIS department.
SCPS will provide students with their transcript contents and a list of possible classes
that may be taken to satisfy their degree requirements. Students can then coordinate
their future academic planning with the information provided within the system. After
the plan is accomplished, it can be sent to the student’s advisor who will provide
feedback using the system.
Figure 1 shows a high-level lay out diagram of the SCPS system. The SCPS
system will interact as follows:
1. Client sends request and input as HTML form inputs over network.
2. Internet Information Server (IIS) receives HTML form inputs.
3. IIS Web server
a. Processes inputs.
b. If required, queries to the database and retrieves data.
4. IIS Web server sends back processed output over network as a Web page.
5. Client receives the output and renders as a Web page. If needed, caches the
SQL server response data performance.
2.2.
Goal
To provide an automated .NET Web application for a user to plan an optimal
curriculum plan over the Internet at any time.
2.3.
Purpose
To explore the capabilities of the Microsoft .NET Framework and provide a
convenient curriculum planning service to CIS undergraduate students and their
advisors.
3.
Requirement Specifications
3.1.
Main Requirements
1. Construct a system with three-tier architecture. Figure 2 shows the SCPS in
three-tier architecture.
2. Microsoft Visual Studio .NET Studio, ASP.NET, C # language, MSSQL, and
XML will be used to develop the system.
3. The final product will be run on the Internet Information Server (IIS).
4. Internet Explorer will be used as a main browser.
5. MSDE (Microsoft SQL Server 2000 Desktop Engine) will be used as a test
database to simulate the Microsoft SQL server.
6. SSL will be set up to ensure a secure communication channel is established.
7. System will be able to perform a course prerequisite check on every course
plan transaction made.
Clients
Client-tier
IIS Server
Application-server-tier
SQL Server
Data-server-tier
Figure 2. SCPS in three-tier Architecture
3.2.
External Interface Requirements
All user interfaces are ASP.NET-generated Web pages. In order to access the
system, the user will need to use a workstation with Internet accessibility and
equipped with Internet Explorer. Microsoft .NET Framework must be installed on
the machine A broadband connection is recommended to boost performance.
The user will have different views according to which step he or she is in. After
the server generates the main Web page to prompt the user for inputs, add or drop
course option buttons along with a list of courses available and taken, will be
shown on the Web page. Users can edit the course plan with the add/drop button
to produce a curriculum plan as they see fit. A report option will be provided at
the end to generate a report for the user to refer back to later on.
3.3.
Critical Use Cases
Generate Report
Login
Add Course
Administrator
Drop Course
User
Save Plan
Create Plan
Load Plan
Faculty
Student
Figure 3. Critical use cases
3.3.1.
Use Case 1: Log-in Requirement
Purpose: The purpose of this part of the application is to enable user
authentication.
Inputs: The user will enter two inputs, user name and password, through the
keyboard.
Processing: The system will then check the user name and password to see if they
are valid.
Outputs: If the user name or password is not valid, the system will prompt the
appropriate error message on the Web page to request the user re-enter his or her
user name and password. If the user inputs are valid, the course selection page
will be displayed. And if the user is a student, the student’s transcript entries will
be automatically input into the course plan according to the criteria they fit in. If
the administrator logs in, the system will show the administrator view, which
includes a list of the course data in the database.
3.3.2.
Use Case 2: Add Course Requirement
Purpose: The purpose of this part of the application is adding a course to the slot
in the curriculum plan from the course selection list.
Input: The customer will click the add button beside the Course Name in the
course selection list, then enter time of the course to be taken.
Processing: This system will validate the input based on whether the prerequisite
has been taken.
Output: If there is no error, the course will be added to the curriculum plan along
with the disable selection from the course selection list. Otherwise the system will
prompt an appropriate error message to the user to show which prerequisite the
user has not taken.
3.3.3.
Use Case 3: Drop Course Requirement
Purpose: The purpose of this part of the application is to drop a course from the
slot in the curriculum plan back to course selection list.
Input: The user will click the drop button beside the Course Name in the
curriculum plan.
Processing: The system will check the course dataset where the course to be
dropped is located on the course selection list
Output: The curriculum slot selected will be emptied out and the course will be
put back on the course selection list by enabling the adding course button.
3.3.4.
Use Case 4: Generate Report Requirement
Purpose: The purpose of this part of the application is to provide a final
curriculum report to the user.
Inputs: The user will hit the generate report button.
Processing: The system will render the final curriculum flowchart on a single
web page and feed it back to the user.
Output: A Web page containing the current course plan.
3.3.5.
Use Case 5: Add Course Requirement
Purpose: The purpose of this part of the application is to let the administrator add
a new course into the course database.
Inputs: The administrator will hit the add course button which will lead his or her
to an adding course form. The administrator will then enter the new course data
into the database.
Processing: The system will validate whether the new data is correct or it is not
already in the database.
Output: If the input is valid, the system will respond with a new data view with
the success message and the new course added in. Otherwise the system will
respond with the original data view with an input error message.
3.3.6.
Use Case 6: Drop Course Requirement
Purpose: The purpose of this part of the application is to let an administrator drop
a new course from the course database.
Inputs: The administrator will hit the drop course button which located in the
same row as the course to be dropped.
Processing: The system will validate whether the new data is correct or it is not
already in the database.
Output: If the input is valid, the system will respond with the new data view with
the success message and the course dropped from the data list. Otherwise the
system will respond with the original data view with an input error message.
3.3.7.
Use Case 7: Add User Requirement
Purpose: The purpose of this part of the application is to let an administrator add
a new user to the course database.
Inputs: The administrator will hit the add user button which will lead his or her to
an adding user form. The administrator will then enter the new user data into the
database.
Processing: The system will validate whether the data is correct or it is not
already in the database.
Output: If the input is valid, the system will respond with the new data view with
the success message and the new user added in. Otherwise the system will
response with the original data view with an input error message.
3.3.8.
Use Case 8: Drop User Requirement
Purpose: The purpose of this part of the application is to let an administrator drop
a user from the course database.
Inputs: The administrator will hit the drop user button which is located in the
same row of the user to be dropped.
Processing: The system will validate whether the data is correct or it is not
already in the database.
Output: If the input is valid, the system will respond with the new data view with
the success message and the user dropped from the data list. Otherwise the system
will respond with the original data view with an input error message.
3.4.
Performance Requirements
The application will be used for client side caching to reduce the load of the Web
server. Also, JavaScript will be used to implement the client-side input validation to
alleviate task load on the server side. The system load will mostly consist of querying
the data from the course database. The course data file should be about 4Mb in size.
Maximum response time and data transfer time between server and client will be
about two minutes with the typical 56kbps per transaction. The number of current
undergraduate student is about 100. Along with the faculty in the CIS department,
there will be approximately 130 total users. To allow maximum performance and
accommodate all user connections, the system will actually be built with the
Microsoft SQL server instead of the test server, MSDE, which only accepts 25 user
connections. Users are encouraged to access the system with a broadband connection.
3.5.
Assumptions

The user will have Internet connection whenever he or she is using the SCPS.

The user will use Internet Explorer whenever he or she is using the SCPS.

The course database will be implemented using the Microsoft SQL server.

The user has an account within the CIS system.
3.6.

Constraints
The Web application is developed under the .NET Framework; hence, the system
can only be deployed on the IIS server.

MSDE, which can only accept 25 user connections, will be replaced by the SQL
server, which will allow the maximum user connection.

If unable to access the actual course database within the college system, the test
data is hand entered and simulated by developer.
3.7.
Environment

C# will be selected as the developing language.

Microsoft Visual Studio .NET will be selected as the development environment.

The SCPS will be tested on the Windows XP platform.

The MSDE will be used as the test database.

The final version of the SCPS will be using the SQL Server as the database.
Chapter 2. Project Plan
1.
Task Breakdown
1.1.
Inception phase
The goal of the inception phase is to layout the project requirements. Major
activities involved are developing documentations for use of the committee
approving the general direction of project. The documentations that will be
presented in this phase are: the vision document, software quality assurance plan,
and project plan. The vision document contains the core requirements and goals
of the system, while the software quality assurance plan consists of defining the
activities and measures that will be taken for quality assurance purposes. At the
end, an initial project plan will be drawn to schedule tasks, responsibilities, and
deliverables of each phase. Cost estimation will be also added in the project plan
to provide a detailed look of the project.
Along with the document presentation, a working prototype will be presented to
the committee to show all requirements of this phase are complete.
The inception phase concluded once the committee members approved all
required documentation and the working prototype after the first presentation.
1.2.
Elaboration phase
The goal of the elaboration phase is to achieve a sound architecture design of the
system. This phase calls for formal requirement specifications to be developed to
verify soundness of the system. The architecture design of the system, which will
be presented Unified Model Language (UML), will be developed in this phase. A
test plan will outline the testing criteria, testing methods, and evaluation methods
that will be undertaken by the developer. Two technical inspectors will inspect the
architecture design with the formal checklist prepared by the developer. The
vision document and project plan will be updated per requests from committee
members at the end of the inception phase.
Along with the document presentation, an executable architecture prototype will
be demonstrated to the committee to show all requirements of this phase are
satisfied.
The elaboration phase will be completed once committee members approve all
required documentation and the executable architecture prototype after the second
presentation.
1.3.
Production phase
The goal of the production phase is to complete the implementation and testing of
the system. The architecture design artifacts, which complete the last phase, will
be expanded to detail component designs and documents. Final implementation of
the system will be finished in this phase. The committee-approved testing plan
will be executed and results will be documented in the assessment evaluation
artifacts. A complete user’s manual will be written to describe proper usage of the
final product.
The production phase will be completed once committee members approve all
required documentation and the final version of the software product after the
third and the last presentation.
The grant chart below shows a schedule for finishing the tasks in each phase.
Figure 4. The SCPS project Gantt chart
2.
Cost Estimate
2.1.
COCOMO
The constructive cost model (COCOMO), which was developed by Barry
Boehm, has been selected as the cost-estimate model. The model estimates cost
using one of three different development modes: organic, semidetached, and
embedded. The organic mode is used to estimate the small, least complex, and
highly flexible project. The embedded mode is used on the project under tight
constraints. The product must operate within (is embedded in) a strongly coupled
complex of hardware, software, regulations, and operational procedures. Lastly,
the semidetached mode is used to represent the project that has intermediate
complexity and constraints between organic and embedded mode projects.
The Student Curriculum Planning System (SCPS) is a small-scale, non-essential
Web application with high flexibility. It can be classified as an organic mode
project in the COCOMO model. The following formula is used in the COCOMO
model for a cost estimate on an organic mode project:
Effort = 3.2*EAF*(Size) ^1.05
Time = 2.5*(Effort) ^0.38
Where:
Effort = number of staff-months (PM)
EAF = Effort Adjustment Factor
Size = number of lines of code for completed product. It is measured in
KLOC (thousands of lines of code).
Time = total number of months
The Effort Adjustment Factor is the product of the 15 adjustment parameters.
Each adjustment parameter is categorized as very low, low, nominal, high, or
very high. Table 1 below shows all adjustment factors and their ranges.
Table 1. The project characteristics table of the COCOMO model
Adjustment factors are as follows:

Required reliability as nominal and a value of 1.00.

Database size as high and a value of 1.08.

Product complexity as low and a value of 0.85

Execution time constraint as nominal and a value of 1.00

Main storage constraint as nominal and a value of 1.00.

Virtual machine volatility as nominal and a value of 1.15.

Computer turnaround time as low and a value of 0.87.

Analyst capability as high and a value of 0.8.

Applications experience as nominal and a value of 1.00.

Programmer capability as nominal and a value of 1.00.

Virtual machine experience as nominal and a value of 1.00.

Language experience as nominal and a value of 1.00.

Use of modern practices as high and a value of 0.91.

Use of software tools as high and a value of 0.91

Required development schedule as nominal and a value of 1.00.
The EAF value is calculated to 0.61. Looking at similar Web application examples and
based on the SCPS prototype, the size is estimated to be 3000 LOC.
Effort = 3.2*0.61*(3) ^1.05 = 6.18 staff months
Time = 2.5*(6.18) ^0.38 = 4.99 months (the development time)
Since the project only involved one staff member and is relatively small scale, projected
time of completion will be about three months.
3.
Architecture Elaboration Plan
The second phase tasks are outlined as follows:
3.1.
Revision of vision document
Based on feedback provided by committee members during this phase of the
project, the vision document will be updated. The revised vision document will
subject to the major professor’s approval prior to submitting to committee
members for a second presentation.
3.2.
Revision of project plan
Based on feedback provided by committee members during this phase of the
project, the project plan will be updated. The revised vision document will be
subject to the major professor’s approval prior to submitting to committee
members for a second presentation.
3.3.
Architecture design
The architecture of the product will be documented using Unified Model
Language standards and diagrams.
3.4.
Development of prototype
The architecture executable prototype will be built to demonstrate achievement of
the satisfaction of the critical requirements list in the vision document.
3.5.
Test plan
A test plan will be developed to outline all test activities, results evaluation, and
documentation needs for product testing.
3.6.
Formal technical inspections
The architecture design will be inspected by two MSE students, Esteban Guillen
and Cem Oguzhan.
3.7.
Formal Requirement Specifications
Formal specification of the product will be verified using the OCL.
4.
Implementation Plan
4.1.
Work Breakdown Structure
Table 2. The work breakdown structure table
Deliverables
Task
Completion
Time
Cost
07/09/04
1day
07/09/04
1
Criteria
Revise formal
1. Update formal
Obtain
requirement
requirement
committee
specification
specification
members’
approval
Revise test plan
1. Update test plan
Obtain
committee
members’
approval
day
Component
design
1. Complete class
Document all
diagram
07/10/04
component
1
day
internal design
Complete sequence diagram
Document
all 07/10/04
component
1
day
activities
Complete component diagram
Document
all 07/11/04
component
1
day
dependency
Source code
1. Outline classes with
class diagram
Implement
all
All source code
07/12/04
implemented
database
1
day
07/12/04
interface
1
day
Implement all user functions
07/13/04
5
day
Implement all administrator
07/13/04
functions
3
day
Implement all user interface
07/18/04
5
day
Unit testing
1. Produce unit testing
modules
Perform test
All unit tests
07/19/04
completed
1
day
07/19/04
1
day
Integration
testing

1. Produce integration
All integration
testing module
tests completed
07/20/04
day
07/20/04
Perform test
1
1
day
User’s manual
1. Write user manual
Obtain
07/21/04
committee
3
day
members’
approval
Assessment
evaluation
1. Document all testing
All testing
processes and results
07/22/04
process and
1
day
results are
documented
Project
evaluation
1. Evaluate usefulness of
methodologies used
Evaluate
accuracy
Obtain
07/23/04
committee
of members’
estimations
day
07/23/04
approval
Evaluate usefulness of reviews
1
1
day
07/24/04
1
day
Evaluate whether it achieved
07/24/04
all critical requirement listed in
1
day
the vision document
Final document
1. Final compilation of all
documents
All documents
and references
07/25/04
1
day
 All references gathered
gathered and
07/25/04
compiled
Formal technical
inspection letters
1. Collect formal
technical inspection
All inspection
letters collected
1
day
07/26/04
1
day
letters
Total Cost
35
day
4.2.
Updated documents
After a second presentation, all documents that are produced during the second
phase, the architecture phase, will be updated according to supervisory committee
options and suggestions.
4.3.
User’s manual
The user’s manual of SCPS will be produced. An overview and explanation of
common usage, user commands, error messages, and data formats will be
included.
4.4.
Component design
All component internal designs will be documented by the class diagram.
Component activity details will be documented by the sequence diagram.
Component diagrams will capture the dependencies between various parts of the
system.
4.5.
Source code
Implementation of all source code should follow the architecture and component
design of the SCPS. C# Coding convention will be used to document the source
code.
4.6.
Assessment evaluation
Detailed descriptions of all tests performed and their results will be recorded in
this document.
4.7.
Project evaluation
The process will be reviewed, including usefulness of the methodologies used,
accuracy of the estimations, and usefulness of the reviews. Satisfaction of the
critical requirements listed in the vision document of the final product will be also
evaluated and documented.
4.8.
Formal technical inspection letters
The technical inspectors, Cem Cogzhan and Esteban Guillen, will present letters
ensuring the projects have successfully passed the technical requirements.
Chapter 3. Software Quality Assurance Plan
1.
Purpose
The purpose of this document is to define the software quality assurance plan for the
Student Curriculum Planning System which will be used throughout the project life
cycle.
2.
3.
References

IEEE Guide for Software Quality Assurance Planning Std 730.1-1995

IEEE Standard for Software Quality Assurance Planning Std 730-1998
Management
3.1.
Organization
Supervisory Committee:
Dr. Daniel Andresen
Dr. Rodney R. Howell
Dr. Mitchell L. Neilsen
Major Professor:
Dr. Daniel Andresen
Developer:
Kevin Sung
Formal Technical Inspectors:
Esteban Guillen
Cem Oguzhan
3.2. Tasks
All tasks that will be performed are documented in the project plan. The project
plan includes a Gantt chart, which provides a schedule for each task.
3.3.
Responsibilities
Supervisory Committee:
The committee will be responsible for attending the presentations and reviews at
the end of each phase. Additionally, committee members will provide feedback
and suggestions about the project to the developer. The major professor will be
also responsible for supervising and evaluating work and progress done by the
developer throughout project.
Developer:
The developer will be responsible for the design, documentation, and software
implementation of the project. The developer will meet with the supervisory
committee and major professor regularly throughout the project life cycle for
reviewing. Moreover, the developer will be responsible to perform tasks
according to feedback from the supervisory committee.
Formal Technical Inspectors:
The formal technical inspectors will be responsible for inspection of the
architecture design artifacts using the annotated checklist provided by the
developer.
4.
Documentation
The MSE portfolio handbook for MSE students outlines an official documentation
requirement for MSE projects at http://www.cis.ksu.edu/~sdeloach/mse/portfolio.htm.
The following list contains the minimum documentation requirement for the MSE
project.
4.1.
Software Requirement Specification (SRS)
The SRS will document essential functionalities of the software and external
interfaces.
Modifications of the SRS can be made in the elaboration phase to ensure that all
critical requirements are included.
4.2.
Software Design Description (SDD)
SDD depicts how the software will be structured to satisfy requirements in the
SRS. It describes components and subcomponent of software design. Object
diagram, class diagram, and sequence diagram will be created using Rational
Rose.
4.3.
Project Plan
The project plan will outline the time period, job, and milestones. Adjustments
can be made as needed as the project progresses.
4.4.
Software Test Plan
The software test plan will define the tests required and show that the product has
met the evaluation criteria.
4.5.
Project Evaluation
The project will be reviewed and evaluated based on whether the final project
functionalities have met the critical requirements.
All documentation will be drafted by the developer and evaluated by the supervisory
committee.
The documentation can be obtained by going to the Web site at
http://www.cis.ksu.edu/~sung/MSE/index.htm.
5.
Standards, Practices, Conventions, and Metrics
5.1.
Documentation Standards
IEEE standards will be used for all documentation of the project. Adjustments can be
made as necessary.
5.2.
Coding Standards
Source code and comments will follow the guidelines in the C# coding standards and
style guide.
5.3.
Metrics
The COCOMO model will be used to predict project effort.
6.
Reviews and Audits
Review meetings will be scheduled regularly between the major professor and
developer to provide constant feedback as the project progresses. The supervisory
committee will review all designs, documentation, and implementation during
presentation at the end of each phase. Committee members will provide feedback on
the documents and the prototype demonstration. Two technical inspectors will inspect
the architecture design artifacts and submit a formal report.
7.
Test
Tests will be performed according to the test plan drawn up by the developer. This
will include the test activities, evaluation criteria, and functional testing. All tests
must meet the evaluation criteria. The test report will record all test activities
performed and test results.
8.
Problem Reporting and Corrective Action
All problems and corrective actions taken will be reported directly to the major
professor as the project progress. The developer will also report to the supervisory
committee if necessary.
9.
Tools, Techniques, and Methodologies
The following tools will be used for the SCPS project.

Microsoft Visual Studio .NET IDE – for coding

C# – for coding

IIS – for Web server

ASP.NET – for Web forms
10.

MS SQL – for database server

MS Visio – for documentation

USE 2.0.1 – for formal specification and verification
Training
The developer will be responsible for self-training on the technology used for the
system development. All research required will be conducted by the developer also.
11.
Deliverables
The deliverable submissions required at the end of each phase are listed as follows:
Phase I:

Vision Document

Project Plan

Demonstration

Software Quality Assurance Plan
Phase II:

Action Items

Vision Document

Project Plan

Formal Requirements Specification

Architecture Design

Test Plan

Formal Technical Inspection

Executable Architecture Prototype
Phase III:

Action Items

User Manual

Component Design

Source Code

Assessment Evaluation

Project Evaluation

References

Formal Technical Inspection Letters
Chapter 4. Architecture Design
1. Introduction
The purpose of this document is to explain using Unified Modeling Language (UML)
to lay out the architecture design of the Student Curriculum Planning System. The
design is shown in three diagrams: class diagram, sequence diagram, and state
diagram.
2. Class Diagram
Figure 5. SCPS class diagram
The Student Curriculum Planning System (SCPS) is composed of 12 classes: SCPS,
CoursePlan,
Course,
User,
Transcript,
Administrator,
Faculty,
Student,
TranscriptEntry, PlanView, CourseView, and AdminView classes. The front end of
this application, which is the user interface of this program, contains the SCPS,
PlanView, CourseView, and AdminView classes. These classes also house the main
functions of the system, which directly manipulate the data in the database.
The SCPS class is the main interface for the system. The SCPS has only the log-in
method embedded to allow users and administrators to login in to the system.
Implementation of the functionality for creating, loading, and deleting user
curriculum plans will be embedded in the PlanView class, while the detail functions
that will be handling the manipulation of the plan contents will be housed in the
CourseView class. Finally, AdminView class will provide the administrative interface
of the course database with all the functionality made available to the administrator.
The Course class represents a course entry with its information in the database. The
basic information about a particular course offered by the university is captured by
individual variables in the class. The CoursePlan class represents either a new
curriculum plan created by the user or a previous stored curriculum plan in the
system. Two pieces of critical information are used to identify the individual plan.
First, a unique course plan name, which is captured by the variable “planName” in the
class.
Lastly, the student ID of the author, which is stored as the variable of
“authoreId” Furthermore, the entry of the plan will be referenced from either the
course database or the student’s transcript. The transcript is a datatable which will be
created in real time as a container for all student transcript entries. The transcript will
be named with the student Id. The TranscriptEntry class is an individual entry for a
student.
User is a super class for the Student and Faculty class. All methods users will need to
access and manipulate the course plan will be provided through this class. This class
will contain the user log-in information, which is the user ID (in userId) and the
Password (in password). The Faculty and Student classes are used to contain the user
information from the system. Moreover, any further expansion functionality that is
user-specific can be embedded in these classes to achieve better security. The
Administrator class contains the log-in information and functionality for the
administrators. With this implementation, the system will be better protected by not
exposing the administrative function to outsiders.
3. Sequence Diagram
3.1.
Log In
: SCPS
: User
login(username, password)
verify
[ifVerify]Success
: PlanView
[NotVerified] NotSuccess
Figure 6. User log in to the system
The user will log in to the system by entering his or her user ID and password.
The system will validate the user’s identity. If the user ID and password are
correct, the system will redirect the user to the PlanView page. Otherwise, the
system will prompt the user to check the ID and password entered and reenter
with the correct information.
3.2.
Add Course --- User
: User
: CourseView
: CoursePlan
: Transcript
:
TranscriptEntry
: Course
AddCourse(courseType,courseId)
AddCourse(courseType,courseId)
FindCourse(courseId, courseType)
[courseId!=NULL]FindCourse(courseId, courseType)
*[courseId:=this.courseId]courseId,courseName,timeTaken
[courseNotFound]FindCourse(courseId, courseType)
*checkPrerequisites(courseId)
[courseType:=this.courseType||courseId:=this.courseId]courseId, courseName,timeAvailable
courses
courseId, timeToTake
updatePlan
success
Figure 7. Add a course to the course plan for the user
The user will enter the course ID and course type (require, technical elective, etc.)
that he or she wishes to add to the CourseView class, which will contain the
loaded course plan. The message will be passed to the Transcript class to attempt
to check whether this course has been completed or not. And if this course is
completed and the grade obtained is a C or above, the system will automatically
insert this course to the course plan with the grade and course information.
Otherwise the system will retrieve the course information from the course
database and then insert it to the course plan. The system will also perform the
prerequisite checking during this process. After the insert process is complete, the
system will provide a drop-down list that has the time available for user to take
the course. The user will enter the time when he or she wishes to take the course
to complete the process.
3.3.
Drop Course—User
: CourseView
: User
DropCourse(courseId)
: CoursePlan
DropCourse(courseId)
*DropCourse(courseId)
*checkPrerequistes(courseId)
[courseDrop]success
[courseNotDrop]Failure
Figure 8. User deletes a course from the course plan
The user will engage this activity by entering the course ID that needs to be
dropped to the Course View class. The system will then check to see whether
other courses will be affected by this action, due to the course dropped being a
prerequisite. At the end, all courses that will be affected will be dropped from the
course plan.
3.4.
Load Plan---User
: User
: CoursePlan
: PlanView
LoadPlan(planName)
LoadPlan(planName)
Data
: CourseView
View
Figure 9. User loads an existing plan in the system
The user will load an existing plan in the system by first entering the plan name to
the PlanView class. The system will then retrieve the plan and load it into the
CourseView class for the user. If the plan has no entry in the course plan
database, the system will generate a new plan for the user.
3.5.
Save Plan---User
: User
: CourseView
: CoursePlan
SavePlan(planName)
[PlanNum=<3]SavePlan(planName)
success
Figure 10. User saves the current plan
The user will save the loaded plan in the system if the number of the existing plan
isn’t over three.
3.6.
Generate Report---User
: User
: CourseView
: CoursePlan
GenerateReport()
GenerateReport()
Report
Figure 11. User generates a report
The user can generate a report from a loaded plan by pressing the generate button,
which will invoke the generate function. The system will respond with a report
view of the current plan.
3.7.
Add Course---Administrator
: Administrator
: AdminView
AddCourse(courseId, courseName, timeAvailable, prerequisites)
[NoCourse]AddCourse(courseId, courseName, timeAvailable, prerequisites)
: Course
success
Figure 12. Administrator adds a new course to the database
The administrator can add a new course to the database by invoking the Add
Course method by pressing the “Add Course” button on the data administration
Web form. The system will prompt the user to enter course information as course
ID, course name, time available, and prerequisites. After all information is
entered, the system will add the course into the database and generate a unique
reference number.
3.8.
Drop Course---Administrator
: Administrator
: AdminView
DropCourse(referenceNum)
[referenceNum:=this.referenceNumber]DropCourse(referenceNum)
: Course
success
Figure 13. Administrator drops a course from the database
The administrator can delete an existing course from the database by invoking the
Drop Course method by pressing the “Drop Course” button beside each course
data entry on the data administration Web form. Besides the deleting selected
course, the system will promptly update all courses that have this course as a
prerequisite by deleting this course from their prerequisite entry.
4. State/Activity Diagram
SCPS()
Initialization
Saving
Plan
Creating
New Plan
Generating
Report
Dropping
Course
Login
GenerateReportDropCourse( courseId )
event enterIndentity( name, password )/
SavePlan( planName )
AddCourse( courseId )
CreatePlan( planName )
[ Administrator ]
User Wait (CourseView)
event
event
event
event
event
[ User ]
AddCourse(courseId,timeTaken)/
SavePlan(planName)/
DropCourse( courseId )/
GenerateReport/
Finish/
Adding
Course
Finish
Admin Wait
User Wait (MainView)
event AddCourse( courseName, courseId, timeAvailable,courseInfo )/
event DeleteCourse( courseId )/
event Logout/
event
event
event
event
LoadPlan( planName )/
DeletePlan( planName )/
Logout/
CreatePlan( planName )/
LoadPlan(planName)
DeletePlan( planName )
DeleteCourse( courseId )
AddCourse( courseName, courseId, timeAvailable,courseInfo )
Adding Course
to Database
Logout
Logout
Deleting
Plan
Deleting Course to
Database
Figure 14. The state diagram of the SCPS
Loading
Plan
Chapter 5. Formal Requirement Specification
1.
Purpose
The purpose of this document is to identify formal requirement specifications of the
Student Curriculum Planning System. Specification will be defined with the
UML/OCL language. Critical requirements in the Vision Document and Class
Diagram in Architecture Design are use to derive the specifications. Furthermore, we
use the UML-based Specification Environment (USE) tool to do the type and syntax
check to ensure correctness of the specifications.
2.
3.
References

Vision Document Version 1.1

Architecture Design Version 1.0
Specifications
3.1.
Classes Classes
3.1.1.
SCPS
This is the main interface of the system which mostly contains front end of
the system.
class SCPS
operations
Login(userId:String,password:String):Boolean
end
3.1.2.
PlanView
This will be the Web form provided for the user to select whether to load,
delete, or create a course plan.
class PlanView
attributes
operations
CreatePlan(planName:String):Boolean
DeletePlan(planName:String):Boolean
LoadPlan(planName:String):Boolean
end
3.1.3.
CourseView
This will be the front end (Web form) for the loaded course plan.
class CourseView
attributes
operations
AddCourse(courseId:String, timeAvailable:String):Boolean
DropCourse(courseId:String):Boolean
GenerateReport():Boolean
SavePlan():Boolean
end
3.1.4.
CoursePlan
This is the class course plan which the user has currently created or stored.
class CoursePlan
attributes
planName:String
authorId:String
operations
FindCourse(courseId:String) : Course
CheckPrerequiste(courseId:String) : Boolean
end
3.1.5.
AdminView
This will be the front end (Web form) for administrator to add or delete
course in the courses database.
class AdminView
attributes
operations
AddCourse(courseName : String, courseId : String, timeAvailable : String) :
Boolean
DropCourse(courseId : String) : Boolean
end
3.1.6.
User
This class represents the user of the system and is embedded with the main
user functions and log-in data.
class User
attributes
userId:String
password:String
operations
end
3.1.7.
Faculty
This class represents the faculty user of the system and is has embedded with
faculty user functions and faculty data.
class Faculty < User
attributes
facultyName:String
facultyId:String
end
Student
3.1.8.
This class represents the student user of the system. It has embedded the
student user functions and student data.
class Student < User
attributes
studentName:String
studentId:String
major:String
track:String
end
Administrator
3.1.9.
This class represents the administrator of the system and is embedded with
administrator functions and log-in data.
class Administrator
attributes
userName:String
password:String
operations
end
3.1.10.
Course
This class represents a course entry in the SCPS database. All data in the
entry is categorized by the variables in this class.
class Course
attributes
referenceNumber:String
courseId:String
courseName:String
timeAvailable:String
isRequire:Boolean
csRequire:Boolean
techElective:Boolean
humanElective:Boolean
dbMgmtTrack:Boolean
isAnalystTrack:Boolean
misTrack:Boolean
appProgTrack:Boolean
commAnalystTrack:Boolean
operations
closure(s:Set(Course)):Set(Course)=
if s->includesAll(s.thePrereq->asSet) then s
else closure(s->union(s.thePrereq->asSet))
endif
reachableFromSelf():Set(Course)=closure(Set{self})
end
3.1.11.
Transcript
This class represents a user’s entire transcript entry collection for in the
SCPS database. This student id is used to identify the transcript ownership.
class Transcript
attributes
studentId:String
end
3.1.12.
TranscriptEntry
This class represents a transcript entry for a user. All data for a particular
transcript is captured here.
class TranscriptEntry
attributes
transcriptId:String
referenceNumber:String
grade:String
timeTaken:String
end
3.2.
Association
3.2.1.
TranscriptDB
This association illustrates the SCPS saving an individual user transcript into
its database.
association TranscriptDB between
SCPS[1] role transcriptDb
Transcript[*] role transcriptSaved
end
3.2.2.
TranscriptData
This association illustrates a transcript for an individual user as a collection
of the transcript entry, which holds the grade information for a particular
course that has been taken in the past.
association TranscriptData between
Transcript[1] role theTranscript
TranscriptEntry[*] role theTranscriptEntry
end
3.2.3.
Grade
This association establishes the ownership between a student and his or her
transcript.
association Grade between
Transcript[1] role hasTranscript
Student[1] role transcriptOwner
end
3.2.4.
Advising
This association defines the relationship between the faculty advisor and his
or her advisees.
association Advising between
Student[*] role advisee
Faculty[1] role advisor
end
3.2.5.
PlanDb
This association describes how the system stores individual user’s course
plans in the system.
association PlanDb between
SCPS[1] role planDb
CoursePlan[*] role planSaved
end
3.2.6.
CourseTaken
This association provides a link for a course plan to add a transcript entry to
itself through transcript collection.
association CourseTaken between
CoursePlan[*] role referneceIn
Transcript[1] role contains
end
3.2.7.
PlanOwnerShip
This association establishes ownership between the student and his or her
course plans.
association PlanOwnership between
CoursePlan[0..3] role hasPlan
User[1] role planOwner
end
ViewPlan
3.2.8.
The association represents the interaction between the user and the main
plan selection Web form.
association ViewPlan between
User[0..1] role theUser
PlanView[0..1] role thePlanView
end
ViewCourse
3.2.9.
This association represents the interaction between the user and the course
planning Web form.
association ViewCourse between
User[0..1] role theUser
CourseView[0..1] role theCourseView
end
3.2.10.
MainView
This association represents the link established between the course plan
selection view and the actual course plan.
association MainView between
PlanView[*] role thePlanView
CoursePlan[*] role theCoursePlan
end
3.2.11.
OneView
This association represents the link established between the course planning
Web form and the actual course plan.
association OneView between
CourseView[0..1] role theCourseView
CoursePlan[0..1] role theCoursePlan
end
3.2.12.
FutureCourse
This association provides a link for a course plan to add a course to itself.
association FutureCourse between
CoursePlan[*] role containIn
Course[*] role hasReference
end
3.2.13.
Utilizing
This association defines the user’s ability to access the system.
association Utilizing between
User[0..*] role theUser
SCPS[1] role theSCPS
end
3.2.14.
Moderating
This association depicts the ability of the administrator to control the user
activity.
association Moderating between
Administrator[1..*] role theAdministrator
User[*] role theUser
end
3.2.15.
CourseDb
This association shows how the system stores individual course information
to its database.
association CourseDb between
SCPS[1] role courseDb
Course[*] role courseSaved
end
3.2.16.
DbAdmin
This association represents the interaction between the main database
administration view and the adminiatrator.
association DbAdmin between
AdminView[1] role theAdminView
Administrator[1] role theAdministrator
end
3.2.17.
ViewDb
This associaton is the link between the course in the database and the
administration interface.
association ViewDb between
AdminView[0..*] role theAdminView
Course[0..*] role theCourse
end
3.2.18.
Prereq
This association establishes the prerequisite relationship between the
courses.
association Prereq between
Course[0..1] role theCourse
Course[0..1] role thePrereq
end
3.2.19.
Administrating
This association represents the administrating power of the administrators
over the entire system.
association Administrating between
Administrator[1..*] role theAdministrator
SCPS[1] role theSCPS
End
3.2.20.
CourseTranscipt
This association describes how the transcript can reference back to a course
in the database.
association CourseTranscript between
Course[1] role theCourse
TranscriptEntry[0..*] role theTranscriptEntry
end
3.3.
Constraints
3.3.1.
Only the student, his or her advisor, and the system administrator can
access (the student’s) transcript.
context t:Transcript
inv Privacy:
Student.allInstances->forAll(s|t.transcriptOwner->includes(s) implies
t.studentId=s.studentId and t.transcriptOwner->size =1
and s.advisor=t.transcriptOwner.advisor and
Administrator.allInstances=t.transcriptDb.theAdministrator)
3.3.2.
The student cannot have more than one transcript.
Captured by the Grade association.
3.3.3.
A course which has a C or above grade can be put on the course
planning chart.
context te:TranscriptEntry
inv CAbove:
CoursePlan.allInstances>forAll(cp|(te.theTranscript.transcriptOwner=cp.planOwner
and cp.contains.theTranscriptEntry->includes(te)) implies (te.grade='A'
or te.grade='B' or te.grade= 'C'))
3.3.4.
The user has a unique User ID.
context User
inv uniqueId:
User.allInstances->forAll(u1,u2|u1<>u2
u1.userId<>u2.userId)
3.3.5.
implies
There are no circular prerequisites.
context Course
inv noCircularPrereq:
Course.allInstances->forAll(c|c.reachableFromSelf()>excludes(self))
3.3.6.
The user could only save a maximum of three plans.
Capture by the PlanOwnerShip association.
3.3.7.
A course and a transcript entry cannot be on the plan at the same time if
they represent the same class.
context te:TranscriptEntry
inv noSameCourseInOnePlan:
CoursePlan.allInstances->
forAll(cp|te.theTranscript.transcriptOwner=cp.planOwner
and Set{te}=cp.contains.theTranscriptEntry
and Course.allInstances->forAll(c|cp.hasReference->includes(c)
implies c.referenceNumber<>te.referenceNumber))
No duplicate course on the plan.
3.3.8.
context cp:CoursePlan
inv uniqueCourseOnPlan:
Course.allInstances->forAll(c|cp.hasReference->includes(c)
implies cp.hasReference->intersection(Set{c})->size=1)
No duplicate TranscriptEntry on the plan.
3.3.9.
context cp:CoursePlan
inv uniqueTEOnPlan:
TranscriptEntry.allInstances->forAll
(te|te.theTranscript.transcriptOwner=cp.planOwner
and cp.contains.theTranscriptEntry->includes(te)
implies cp.contains.theTranscriptEntry->intersection(Set{te})>size=1)
3.3.10.
There should be either a PlanView or CourseView shown to the user.
context User
inv onlyOneView:
User.allInstances->forAll(u|(u.thePlanView->size>0
implies u.theCourseView->size=0)and (u.theCourseView>size>0 implies u.thePlanView->size=0) and
(u.theCourseView->size<2 and u.thePlanView->size<2))
3.3.11.
Faculty who has no advisees cannot access the system.
context f:Faculty
inv facultyAccess:
f.advisee->size=0 implies (f.thePlanView->size=0 and
f.theCourseView->size=0)
3.3.12.
A transcript entry must have a unique transcript ID.
context te1:TranscriptEntry
inv uniqueTranscriptId:
TranscriptEntry.allInstances->forAll(te2|te1<>te2 implies
te1.transcriptId<>te2.transcriptId)
3.3.13.
A transcript entry must match a course in the course database.
context te:TranscriptEntry
inv TranscriptInCourse:
Course.allInstances>exists(c|c.referenceNumber=te.referenceNumber)
3.3.14.
All users and administrators should have unique user names.
context u:User
inv uniqueUserAdminUserId:
Administrator.allInstances->forAll(a|a.userId<>u.userId)
context u1:User
inv uniqueUserUserId:
User.allInstances->forAll(u2|((u1<>u2) implies
(u1.userId<>u2.userId)))
context a1:Administrator
inv uniqueAdminUserId:
Administrator.allInstances->forAll(a2|((a1<>a2) implies
(a1.userId<>a2.userId)))
3.3.15.
Each course should have an unique reference number.
context c1:Course
inv uniqueReferenceNum:
Course.allInstances->forAll(c2|((c1<>c2) implies
(c1.referenceNumber<>c2.referenceNumber)))
3.4.
Operation
3.4.1.
Administrators can only add courses which are not yet contained in the
course database.
context AdminView::AddCourse(courseName : String, courseId : String,
timeAvailable : String) : Boolean
pre Current: theCourse->forAll(c1,c2|c1<>c2 and
c1.referenceNumber<>c2.referenceNumber)
post Added: theCourse->forAll(c1,c2|c1<>c2 and
c1.referenceNumber<>c2.referenceNumber)
3.4.2.
Administrators can only delete courses that are in the course database.
context AdminView::DropCourse(referenceNum : Integer) : Boolean
pre Current: theCourse->exists(c|c.referenceNumber=referenceNum)
post Deleted: theCourse->forAll(c|c.referenceNumber<>referenceNum)
Chapter 6. Test Plan
Test Plan Identifier
TestPlan-SCPS-001
1. Purpose
This document will entail the testing which will be performed on the SCPS. Test
items and features will be addressed and will also include features from the vision
document.
2. Test Items

SCPS class

CoursePlan class

Course class

User class

Transcript class

Administrator class

Faculty class

Student class

TranscriptEntry class
3. Features to Be Tested
This section outlines all features that will be tested from the vision document.
Table 3. The test case table
Feature Identifier
Description
Requirement Number
T-001
Log in system
3.2.1
T-002
Add course to course plan
3.2.2
T-003
Drop course from course 3.2.3
plan
T-004
Generate report
3.2.4
T-005
Save course plan
3.2.5
T-006
Load course plan
3.2.6
T-007
Add course to database
3.2.7
T-008
Drop
course
from 3.2.8
database
4. Approach
4.1. Unit testing
All executable source code will be subject to the test. Tests will consist of class and
Web form as the base unit. The “NUnit”, a testing tool for C#, will used as the
testing tool of choice.
4.2. Integration testing
After unit testing, the integration testing will consist of testing the several modules
together to see whether the main requirements of system are achieved.
4.3. System testing
Finally, system testing will be performed to test the entire system to see whether all
driving requirements are satisfied.
5. Environmental Needs.
5.1. Hardware
All tests will be conducted on an Intel-based machine.
5.2. Software
Microsoft Visual Studio .Net 2003 and NUnit testing software will be used as the
test environment.
5.3. Operating system
Windows XP Professional
6. Test Cases
6.1. Unit/integration testing
The SCPS is highly involved with the database. With most of the operation
involving manipulating the data within the database, most test cases will at least
test two modules of the system (database and the actual code or class). Therefore,
the integration testing can be done while conducting the individual unit testing.
6.1.1. Log into the SCPS
Test Item: SCPS class
Input: Username and Password
Pass Criteria:

User Input is validated

User Identity is validated.

According to the user identity a faculty, student, or administrator
class is generated with the user information stored.

If the identity is validated, user or administrator should be direct to
the appropriate Web page.

All invalid inputs are blocked and prompted to re-log in again.
Fail Criteria:

A new faculty, student, or administrator class is not created after
identity is validated.

System failed to redirect to the correct Web page after validation.

Identity is falsely validated.
6.1.2. Add course to course plan
Test Item: Student and Faculty class
Input: Course Type and Course ID
Pass Criteria:

User inputs are validated.

The course is added to the course plan—this Web form is updated
correctly.

All prerequisites integrity is check and hold.
Fail Criteria:

The Web form is not updated correctly.

The prerequisites integrity is not preserved

Course plan not updated.

The input is invalid.
6.1.3. Drop course from course plan
Test Item: Student and Faculty class
Input: Course ID
Pass Criteria:

User inputs are validated.

The course is added to the course plan—this Web form is updated
correctly.

All prerequisites integrity is check and hold.
Fail Criteria:

The Web form is not updated correctly.

The prerequisites integrity is not preserved

Course plan not updated.

The input is invalid.
6.1.4. Generate report
Test Item: Student and Faculty class
Input: Hitting the “Generate Report” button on the web form.
Pass Criteria:

The correct Web form with the printable course plan is generated.
Fail Criteria:

The Web form is not generated correctly.
6.1.5. Save course plan
Test Item: Student and Faculty class
Input: Hitting the “Save Plan” button on the web form.
Pass Criteria:

Course plan is saved.

The number of user-saved course plans doesn’t exceed three.
Fail Criteria:

Course plan is not saved.

The number of user-saved plans exceeded three.
6.1.6. Load course plan
Test Item: Student and Faculty class
Input: Course plan name
Pass Criteria:

The correct course plan is loaded.

The Web form is correctly generated.

The number of user-saved course plans doesn’t change.

User owns the load-course plan.

Course plan content doesn’t change.
Fail Criteria:

Course plan content changed.

User can load a plan which he/she doesn’t own.

The Web form generates incorrectly.

The number of user-saved plans changed.
6.1.7. Add course to database
Test Item: Administrator class
Input: Course ID, Course Name, Time Offer, Course types
Pass Criteria:

User inputs are validated.

No course has the same name and ID.

All prerequisites integrity is check and hold.

Web form and database are correctly updated.
Fail Criteria:

Duplicate courses are added in the database.

The prerequisites integrity is violated.

Web form and database are not correctly updated.

User entered invalid data and the new course is still updated into the
web form and database.
6.1.8. Drop course from database
Test Item: Administrator class
Input: Course ID
Pass Criteria:

User inputs are validated.

All prerequisites integrity is check and hold.

Web form and database are correctly updated.
Fail Criteria:

The prerequisites integrity is violated.

Web form and database are not correctly updated.

User entered invalid data and the new course is still updated into the
Web form and database.
6.2. System testing
The system testing will be done by letting multiple users log into the system and
perform the operation at the same time. The test case will be the combination of
the test cases from the integration and unit-testing sections. The most critical test
will be preservation of the data integrity.
7. Schedule
All activities will be conducted between July 19 and July 20.
Chapter 7. Component Design
1. Introduction
The purpose of this document is to use UML to layout the component design of the
Student Curriculum Planning System (SCPS). The design is show in three diagrams:
the class diagram, the sequence diagram, and the state diagram.
2. Class Diagram
Figure 15. SCPS class diagram
The Student Curriculum Planning System (SCPS) is composed of 12 classes: SCPS,
CoursePlan,
Course,
CourseView,
User,
Transcript,
Faculty,
Student,
TranscriptEntry, PlanView, CourseView (or CourseViewIS), PrintView, and
CourseContainer classes. The front-end of this application, which is the user interface
of this program, contains the SCPS, PlanView, CourseView (or CourseViewIS),
CourseContainer, ContainerView and PrintView classes. These classes also house the
main functions of the system, which will directly manipulate the data in the database.
3. Class Description
This section denotes the design of the SCPS project class design. Descriptions of critical
member attributes and functions are also provided through the source code
documentation.
3.1.
SCPS Class
SCPS
#txtUserId : TextBox
#lblUserId : Label
#lblPassword : Label
#lblTitle : Label
#btnSubmit : Button
#sqlSelectCommand1 : SqlCommand
#sqlInsertCommand1 : SqlCommand
#sqlUpdateCommand1 : SqlCommand
#sqlDeleteCommand1 : SqlCommand
#sqlConnection1 : SqlConnection
#sqlDataAdapter1 : SqlDataAdapter
#sqlSelectCommand2 : SqlCommand
#sqlInsertCommand2 : SqlCommand
#sqlUpdateCommand2 : SqlCommand
#sqlDeleteCommand2 : SqlCommand
#sqlDataAdapter2 : SqlDataAdapter
#lblErrorMsg : Label
#Image1 : Image
#Image2 : Image
#sqlSelectCommand3 : SqlCommand
#sqlInsertCommand3 : SqlCommand
#sqlUpdateCommand3 : SqlCommand
#sqlDeleteCommand3 : SqlCommand
#sqlDataAdapter3 : SqlDataAdapter
#txtPassword : TextBox
-Page_Load(in sender : object, in e : EventArgs)
#OnInit(in e : EventArgs)
-InitializeComponent()
-btnSubmit_Click(in sender : object, in e : EventArgs)
Figure 16. SCPS class diagram
The SCPS class is the main interface for the system. The SCPS has embedded the
login method to provide users and administrators a way to log in to the system.
3.1.1.
Member Attributes
System.Web.UI.WebControls.Button btnSubmit
Button initiates the system to verify the user log-in information.
System.Web.UI.WebControls.Image Image1
Image shows the CIS department title.
System.Web.UI.WebControls.Image Image2
Image shows a horizontal divider on the page.
System.Web.UI.WebControls.Label lblErrorMsg
Label displays an error message when a log-in error occurs.
System.Web.UI.WebControls.Label lblPassword
Label gives an indication to users where to enter their user password.
System.Web.UI.WebControls.Label lblTitle
Label shows the title of the log-in section.
System.Web.UI.WebControls.Label lblUserId
Label gives an indication to users where to enter their user ID
System.Data.SqlClient.SqlConnection sqlConnection1
Connection to the course database
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter2
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter3
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlCommand sqlDeleteCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlDeleteCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlDeleteCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlInsertCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlInsertCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlInsertCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlSelectCommand1
Auto-Generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlSelectCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlSelectCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlUpdateCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlUpdateCommand2
SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlUpdateCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Web.UI.WebControls.TextBox txtPassword
Textbox for user to enter the user password
System.Web.UI.WebControls.TextBox txtUserId
Textbox for user to enter the user ID
3.1.2.
Functions
void btnSubmit_Click (object sender, System.EventArgs e)
System.Web.UI.WebControls.Button click event handler. This is used to verify
the user identity.
void Page_Load (object sender, System.EventArgs e)
Page-loading routine for developer initialization code. Implementation of the Page
Load routine.
3.2.
PlanView Class
PlanView
#sqlConnection1 : SqlConnection
#sqlDataAdapter1 : SqlDataAdapter
#sqlSelectCommand1 : SqlCommand
#panMain : Panel
#Search : Button
#grdSelectStudent : DataGrid
#All : Button
#txtFirstName : TextBox
#txtLastName : TextBox
#lblPlan : Label
#ddlPlan : DropDownList
#btnLoadPlan : Button
#btnLogout : Button
#txtStudentID : TextBox
#panFaculty : Panel
-Page_Load(in sender : object, in e : EventArgs)
-ddlPlan_SelectedIndexChanged(in sender : object, in e : EventArgs)
-btnLoadPlan_Click(in sender : object, in e : EventArgs)
-LoadFaculty()
-Search_Click(in sender : object, in e : EventArgs)
-grdSelectStudent_SelectedIndexChanged(in sender : object, in e : EventArgs)
-LoadStudent()
#OnInit(in e : EventArgs)
-InitializeComponent()
-btnLogout_Click(in sender : object, in e : EventArgs)
Figure 17. PlanView class diagram
Implementation of the functionality for creating and loading user curriculum plans
will be embedded in the PlanView class.
3.2.1.
Member Attributes
System.Web.UI.WebControls.Button All
Button that will show all advisee selections on grdSelectStudent when
clecked.
System.Web.UI.WebControls.Button btnLoadPlan
Button that will initiate loading of the selected course plan when clicked.
System.Web.UI.WebControls.Button btnLogout
Button that will logout the user from the system when clicked
System.Web.UI.WebControls.DropDownList ddlPlan
DropDownList that provides course plan selections to user
System.Web.UI.WebControls.DataGrid grdSelectStudent
DataGrid that displays selection of advisees
System.Web.UI.WebControls.Label lblPlan
Label that indicates to the user where to make course plan selection
System.Web.UI.WebControls.Panel panFaculty
Panel that encloses faculty-use only Web controls
System.Web.UI.WebControls.Panel panMain
Main panel that contains all Web controls for this class
System.Web.UI.WebControls.Button Search
Button that initiates execution of the queries that faculty users enter for
searching for their advisees
System.Data.SqlClient.SqlConnection sqlConnection1
Connection to the course database
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlCommand sqlSelectCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Web.UI.WebControls.TextBox txtFirstName
Textbox for user to enter query for advisee’s first name
System.Web.UI.WebControls.TextBox txtLastName
Textbox for user to enter query for advisee’s last name
System.Web.UI.WebControls.TextBox txtStudentID
Textbox for user to enter query for advisee student ID
3.2.2.
Functions
void btnLoadPlan_Click (object sender, System.EventArgs e)
btnLoadPlan Button click event handler. Load the user or advisee course plan.
void btnLogout_Click (object sender, System.EventArgs e)
btnLogout button click event handler. Clear all session information and return
user to log-in screen.
void ddlPlan_SelectedIndexChanged (object sender, System.EventArgs e)
ddlPlan DropDownList SelectedIndexChanged event handler
void grdSelectStudent_SelectedIndexChanged (object sender, System.EventArgs e)
grdSelectStudent button SelectedIndexChanges event handler. Recording user
selection of advisee
void LoadFaculty ()
Load the faculty user info after a faculty user log in.
void LoadStudent ()
Setting user interface for student user
void Page_Load (object sender, System.EventArgs e)
Page loading routine for developer initialization code. Implementation of the
Page. Load routine.
void Search_Click (object sender, System.EventArgs e)
Search button click event handler. Searches the user's advisee(s) information and
posts it back.
3.3.
CourseView Class
CourseView
#myCSCourseTable : Table
#lblUserIdtag : Label
#lblUserId : Label
#lblNametag : Label
#lblName : Label
#lblMajortag : Label
#lblMajor : Label
#Save : Button
#sqlConnection1 : SqlConnection
#sqlDataAdapter1 : SqlDataAdapter
#sqlDataAdapter2 : SqlDataAdapter
#sqlDataAdapter3 : SqlDataAdapter
#sqlSelectCommand2 : SqlCommand
#sqlInsertCommand2 : SqlCommand
#Clear : Button
#sqlSelectCommand1 : SqlCommand
#sqlInsertCommand1 : SqlCommand
#sqlDeleteCommand2 : SqlCommand
#sqlSelectCommand3 : SqlCommand
#sqlInsertCommand3 : SqlCommand
#sqlUpdateCommand1 : SqlCommand
#sqlDeleteCommand1 : SqlCommand
#Back : Button
#Print : Button
-Page_Load(in sender : object, in e : EventArgs)
-Load_Course(in dt : DataTable, in ID : string, in i : int, in coursePlan1 : DataTable)
#OnInit(in e : EventArgs)
-InitializeComponent()
-Back_Click(in sender : object, in e : EventArgs)
-Save_Click(in sender : object, in e : EventArgs)
-Clear_Click(in sender : object, in e : EventArgs)
-Print_Click(in sender : object, in e : EventArgs)
Figure 18. CourseView class diagram
Detail functions that will be handling manipulation of the plan contents will be
housed in the CourseView class according to the student’s user or advisee’s
major.
3.3.1.
Member Attributes
System.Web.UI.WebControls.Button Back
Button for going back to main menu, which is the PlanView
System.Web.UI.WebControls.Button Clear
Button for clearing current plan
System.Web.UI.WebControls.Label lblMajor
Major of the student or advisee
System.Web.UI.WebControls.Label lblMajortag
Label indicates to user location of the student or advisee major label
System.Web.UI.WebControls.Label lblName
Student name of the student or advisee
System.Web.UI.WebControls.Label lblNametag
Label indicates to user location of the student or advisee name label
System.Web.UI.WebControls.Label lblUserId
Student ID of the student or the advisee
System.Web.UI.WebControls.Label lblUserIdtag
Label indicates to user location of the student or advisee ID label
System.Web.UI.WebControls.Table myCSCourseTable
Container table for each CourseContainer control
System.Web.UI.WebControls.Button Print
Button for printing current plan, which will be shown in PrintView
System.Web.UI.WebControls.Button Save
Button for saving current plan
System.Data.SqlClient.SqlConnection sqlConnection1
Connection to the course database
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter2
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter3
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlCommand sqlDeleteCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlDeleteCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlInsertCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlInsertCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlInsertCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlSelectCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlSelectCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlSelectCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlUpdateCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
3.3.2.
Functions
void Back_Click(object sender, System.EventArgs e)
“Back” button click event handler. The active course plan will be clear and the
user will be redirected to the main plan selection view.
void Clear_Click(object sender, System.EventArgs e)
“Clear” button click event handler. The active course plan will be clear.
void Load_Course(System.Data.DataTable dt, string ID, int i, System.Data.DataTable
coursePlan1)
This method will load the course into the course plan.
void Page_Load(object sender, System.EventArgs e)
Page loading routine for developer initialization code. Implementation of the
Page. Load routine.
void Print_Click(object sender, System.EventArgs e)
“Print” button click event handler. Uses JavaScript to open a new window to
enable user to print the active course plan
void Save_Click(object sender, System.EventArgs e)
“Save” button click event handler. The system will delete all existing course plan
records that have the same plan number as the current active one. Then, the active
course plan will be inserted in the database.
3.4.
CourseViewIS Class
CourseViewIS
#lblUserIdtag : Label
#lblUserId : Label
#lblNametag : Label
#lblName : Label
#lblMajortag : Label
#lblMajor : Label
#Save : Button
#myISCourseTable : Table
#sqlConnection1 : SqlConnection
#sqlDataAdapter1 : SqlDataAdapter
#sqlDataAdapter2 : SqlDataAdapter
#sqlDataAdapter3 : SqlDataAdapter
#sqlSelectCommand2 : SqlCommand
#sqlInsertCommand2 : SqlCommand
#Clear : Button
#sqlSelectCommand1 : SqlCommand
#sqlInsertCommand1 : SqlCommand
#sqlDeleteCommand2 : SqlCommand
#sqlSelectCommand3 : SqlCommand
#sqlInsertCommand3 : SqlCommand
#sqlUpdateCommand1 : SqlCommand
#sqlDeleteCommand1 : SqlCommand
#Back : Button
#Print : Button
-Page_Load(in sender : object, in e : EventArgs)
-Load_Course(in dt : DataTable, in ID : string, in i : int, in coursePlan1 : DataTable)
#OnInit(in e : EventArgs)
-InitializeComponent()
-Back_Click(in sender : object, in e : EventArgs)
-Save_Click(in sender : object, in e : EventArgs)
-Clear_Click(in sender : object, in e : EventArgs)
-Print_Click(in sender : object, in e : EventArgs)
Figure 19. CourseViewIS class diagram
The detail functions that will be handling the manipulation of the plan contents
will be housed in the CourseViewIS class according to the student’s user or
advisee’s major.
3.4.1.
Member Attributes
System.Web.UI.WebControls.Button Back
Button for going back to main menu, which is the PlanView
System.Web.UI.WebControls.Button Clear
Button for clearing current plan
System.Web.UI.WebControls.Label lblMajor
Major of the student or advisee
System.Web.UI.WebControls.Label lblMajortag
Label indicates to user location of the student or advisee major label.
System.Web.UI.WebControls.Label lblName
Student name of the student or the advisee
System.Web.UI.WebControls.Label lblNametag
Label indicates to user location of the student or advisee name label.
System.Web.UI.WebControls.Label lblUserId
Student ID of the student or the advisee.
System.Web.UI.WebControls.Label lblUserIdtag
Label indicates to user location of the student or advisee ID label.
System.Web.UI.WebControls.Table myCSCourseTable
Container table for each CourseContainer control
System.Web.UI.WebControls.Button Print
Button for printing current plan, which will be shown in PrintView
System.Web.UI.WebControls.Button Save
Button for saving current plan
System.Data.SqlClient.SqlConnection sqlConnection1
Connection to the course database
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter2
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter3
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlCommand sqlDeleteCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlDeleteCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlInsertCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlInsertCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlInsertCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlSelectCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlSelectCommand2
Auto-generated SQL command by Visual Studio for sqlDataAdapter2
System.Data.SqlClient.SqlCommand sqlSelectCommand3
Auto-generated SQL command by Visual Studio for sqlDataAdapter3
System.Data.SqlClient.SqlCommand sqlUpdateCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
3.4.2.
Functions
void Back_Click(object sender, System.EventArgs e)
“Back” button click event handler. The active course plan will be clear and the
user will be redirected to the main plan selection view.
void Clear_Click(object sender, System.EventArgs e)
“Clear” button click event handler. The active course plan will be clear.
void Load_Course(System.Data.DataTable dt, string ID, int i, System.Data.DataTable
coursePlan1)
This method will load the course into the course plan.
void Page_Load(object sender, System.EventArgs e)
Page-loading routine for developer initialization code. Implementation of the
Page. Load routine.
void Print_Click(object sender, System.EventArgs e)
“Print” button click event handler. Using JavaScript to open a new window to
enable user to print the active course plan.
void Save_Click(object sender, System.EventArgs e)
“Save” button click event handler. The system will delete all existing course plan
records that have the same plan number as the current active one. Then, the active
course plan will be inserted in the database
3.5.
ContainerView Class
ContainerView
#Panel1 : Panel
-Page_Load(in sender : object, in e : EventArgs)
#OnInit(in e : EventArgs)
-InitializeComponent()
Figure 20. ContainerView class diagram
The detail functions that will be handling the manipulation of the plan contents will be
housed in the CourseViewIS class according to the student’s user or advisee’s major.
3.5.1.
Member Attributes
protected System.Web.UI.WebControls.Panel Panel1
Panel that contains the CourseContainer
3.5.2.
Functions
void Page_Load(object sender, System.EventArgs e)
Page-loading routine for developer initialization code. Implementation of the
Page. Load routine.
3.6.
CourseContainer Class
CourseContainer
#lblCourseID : Label
#lblCourseName : Label
#lblTimeTaken : Label
#btnDropCourse : Button
#btnAddCourse : Button
#lblType : Label
#panCoursePanel : Panel
#listTime : DropDownList
#btnSubmit : Button
#listCourse : DropDownList
#lblGradeTag : Label
#sqlSelectCommand1 : SqlCommand
#sqlInsertCommand1 : SqlCommand
#sqlConnection1 : SqlConnection
#sqlDataAdapter1 : SqlDataAdapter
#lblGrade : Label
-Page_Load(in sender : object, in e : EventArgs)
-checkPrereq(in courseTable : DataTable) : DataTable
-Eval(in data : string) : string
#OnInit(in e : EventArgs)
-InitializeComponent()
-btnDropCourse_Click(in sender : object, in e : EventArgs)
-checkPrereq1(in data : string, in deleteSelection : int) : bool
-btnAddCourse_Click(in sender : object, in e : EventArgs)
-listCourse_SelectedIndexChanged(in sender : object, in e : EventArgs)
-listTime_SelectedIndexChanged(in sender : object, in e : EventArgs)
-btnSubmit_Click(in sender : object, in e : EventArgs)
-PopUp(in prereq : string)
Figure 21. CourseContainer class diagram
The CourseContainer class is used to displayed course information which the user
or advisee needs to take. A type of course is assigned to it. This class is embedded
with all the functionalities to enable the user to change the course that will fit this
CourseContainer type.
3.6.1.
Member Attributes
System.Web.UI.WebControls.Button btnAddCourse
Button initiates the action of add course to start when clicked
System.Web.UI.WebControls.Button btnDropCourse
Button initiates the action of drop course to start when clicked
System.Web.UI.WebControls.Button btnSubmit
Button commits the course and time selected to the database when clicked
System.Web.UI.WebControls.Label lblCourseID
Label that displays the course ID
System.Web.UI.WebControls.Label lblCourseName
Label that displays the course name
System.Web.UI.WebControls.Label lblGrade
Label that displays the grade of the course selected if available
System.Web.UI.WebControls.Label lblGradeTag
Label indicates to user location of the student or advisee grade label.
System.Web.UI.WebControls.Label lblTimeTaken
Label that displays when the course should be taken
System.Web.UI.WebControls.Label lblType
Label that displays the type of the course
System.Web.UI.WebControls.DropDownList listCourse
DropDownList that provides course options for user to select which course
will be taken
System.Web.UI.WebControls.DropDownList listTime
DropDownList that provides time options for user to select when course
should be taken
System.Web.UI.WebControls.Panel panCoursePanel
Panel that contains all web controls for this class
System.Data.SqlClient.SqlConnection sqlConnection1
Connection to the course database
System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1
DataAdapter connected to the course database through sqlConnection1
System.Data.SqlClient.SqlCommand sqlInsertCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
System.Data.SqlClient.SqlCommand sqlSelectCommand1
Auto-generated SQL command by Visual Studio for sqlDataAdapter1
3.6.2.
Functions
void btnAddCourse_Click(object sender, System.EventArgs e)
“btnAddCourse” button click event handler. The selected course will be added to
the active course plan.
void btnDropCourse_Click(object sender, System.EventArgs e)
“btnDropCourse" button click event handler. The selected course will be dropped
from the active course plan
void btnSubmit_Click(object sender, System.EventArgs e)
btnSubmit button click event handler.
System.Data.DataTable checkPrereq(System.Data.DataTable courseTable)
Checking the courses in the courseTable whether their prerequisites are satisfied
with current active course plan
bool checkPrereq1(string data, int deleteSelection)
Pre-checking on integrity of prerequisite conditions of the courses in the active
course plan after the selected course is dropped.
string Eval(string data)
Parser that performs logical evaluation on the boolean string "data"
void listCourse_SelectedIndexChanged(object sender, System.EventArgs e)
listCourse DropDownList SelectedIndexChanged handler. It is synchronized the
listTime DropDownList when every course selection is made
void listTime_SelectedIndexChanged(object sender, System.EventArgs e)
listTime DropDownList SelectIndexChanged event handler.
void Page_Load(object sender, System.EventArgs e)
Page-loading routine for developer initialization code. Implementation of the
Page. Load routine.
void PopUp(string prereq)
Showing a JavaScript popup box to inform user about errors
3.7.
PrintView Class
PrintView
#dgdTable : DataGrid
-Page_Load(in sender : object, in e : EventArgs)
#OnInit(in e : EventArgs)
-InitializeComponent()
Figure 22. CourseContainer Class Diagram
The PrintView class will provide the printable format of the active course plan to
the user.
3.7.1.
Member Attributes
System.Web.UI.WebControls.DataGrid dgdTable
DataGrid table that shows the course plan information
3.7.2.
Functions
void Page_Load(object sender, System.EventArgs e)
Page-loading routine for developer initialization code. Implementation of the
Page. Load routine.
3.8.
User class
User
+userId : string
+password : string
+User()
+User(in theUserId : string, in thePassword : string, in theFacultyId : string, in theFacultyName : string)
+User(in theUserId : string, in thePassword : string, in theStudentId : string, in theStudentName : string, in theMajor : string, in theTrack : string)
+User(in theUserId : string, in thePassword : string)
+SetInfo(in theUserId : string, in thePassword : string)
Figure 23. User Class Diagram
User is a super class for the Student and Faculty class. It contains the user log in
information which is the user ID (in userId) and the Password (in password).
3.8.1.
Constructors
User()
Default constructor
User(string theUserId, string thePassword, string theFacultyId, string theFacultyName)
Constructor for the faculty user
Parameters:
theUserId - The faculty user ID
thePassword - The faculty user password
theFacultyId - The faculty ID
theFacultyName - The faculty's name
User(string theUserId, string thePassword, string theStudentId, string theStudentName,
string theMajor, string theTrack)
Constructor for the student user
Parameters:
theUserId - The faculty user ID
thePassword - The faculty user password
theFacultyId - The faculty ID
theFacultyName - The faculty's name
User(string theUserId, string thePassword)
Constructor for administrating user
Parameters:
theUserId - The administrator user ID
thePassword - The administrator password
3.8.2.
Member Attributes
string password
Password of the user
string userId
User ID of the user
3.8.3.
Functions
void SetInfo(string theUserId, string thePassword)
Setting user information
3.9.
Faculty class
Faculty
+facultyId : string
+facultyName : string
+advisee : DataTable
+Faculty(in theUserId : string, in thePassword : string, in theFacultyId : string, in theFacultyName : string, in theAdvisee : DataTable)
Figure 24. Faculty Class Diagram
The Faculty class contains faculty user information from the system. Moreover,
any further expansion functionality that is faculty user-specific can be embedded
in these classes to achieve better security.
3.9.1.
Constructors
Faculty(string theUserId, string thePassword, string theFacultyId, string theFacultyName,
System.Data.DataTable theAdvisee)
Constructor for the faculty user
Parameters:
theUserId - The faculty user ID
thePassword - The faculty user password
theFacultyId - The faculty ID
theFacultyName - The faculty's name
theAdvisee - The data table that contains the faculty advisees
3.9.2.
Member Attributes
System.Data.DataTable advisee
Data table contains advisees of the faculty user
string facultyId
Faculty ID of the faculty user
string facultyName
Name of the faculty user
3.10.
Student class
Student
+studentId : string
+studentName : string
+major : string
+track : string
+Student(in theUserId : string, in thePassword : string, in theStudentId : string, in theStudentName : string, in theMajor : string, in theTrack : string)
Figure 25. Faculty Class Diagram
The Student class contains the student user information from the system.
Moreover, any further expansion functionality that is student user-specific can be
embedded in these classes to achieve better security.
3.10.1.
Constructor
Student(string theUserId, string thePassword, string theStudentId, string
theStudentName, string theMajor, string theTrack)
The constructor for the student user
Parameters:
theUserId - The student user ID
thePassword - The student user password
theStudentId - The Student ID
theStudentName - The student's name
theMajor - The student's major
theTrack - The student's specialization track
3.10.2.
Member Attributes
string major
Major of the student user
string studentId
Student ID of the student user
string studentName
Name of the student name
string track
Specialization track of the student user
3.11.
Other Classes
The Course class represents a course entry with it course information in the course
database. The basic information about a particular course offered by the university is
captured by individual variables in the class. The CoursePlan class represents either a
new curriculum plan created by the user or a previous stored curriculum plan in the
system. Two pieces of critical information are used to identify the individual plan.
First, a unique course plan name, which is captured by the variable “planName” in the
class. Lastly, the student ID of the author, which is stored as the variable of the
“authorId”. Furthermore, the entry of the plan will be referenced from either the
entry’s course database or the student’s transcript. The transcript is a datatable which
will be created in real time as a container for all student transcript entries. The
transcript will be named with the student ID. The TranscriptEntry class is an
individual entry for a student.
4. Sequence Diagram
4.1.
Log In
: SCPS
: User
btnSubmit_Click(object sender, System.EventArgs e)
verify
[ifVerify]Success
: PlanView
[NotVerified] NotSuccess
Figure 26. User log in the system
User will log into the system by entering his or her user ID and password. The
system will validate the user identity. If the user ID and password are correct, the
system will redirect user to the PlanView page. Otherwise, the system will prompt
user to check the ID and password entered and reenter with the correct
information.
4.2.
Add Course---User
Figure 27. Add course to the course plan for user
The user clicks on the btnAdd button which will invoke the btnAddCourse_Click
to start the process. SCPS will then check all courses in the database which
satisfied course requirements of the CourseContainer selected. If not, a popup box
will appear to warn user about the prerequisite violation and the process will be
aborted. All qualified courses will be sent to the listCourse DropDownList for the
user to select which course him or her want to add. After the course is chosen, the
user will enter the time when the course should be taken through the listTime
DropDownList. When the user has entered all option, he or she will promptly
click on the btnSubmit to finish the process.
4.3.
Drop Course—User
:
CourseContainer
btnDropCourse_Click(object sender, System.EventArgs e)
: User
checkPrereq1(string data, int deleteSelection)
Updated Course Plan
The popup box will be
shown when the a
prerequisite violation
occurs.
Figure 28. User deletes a course from course plan
The user will engage this activity by clicking on the btnDropButton to select the
course that needs to be dropped. The system will then check whether other
courses that will be affected by this action due to the course dropped being a
prerequisite. At the end, all courses that will be affected will be dropped from the
course plan. If there is a prerequisite violation, a JavaScript popup box will appear
to warn the user and abort the dropping action.
4.4.
Load Plan---User
: PlanView
: User
Search_Click(object sender, System.EventArgs e)
Advisee Information
grdSelectStudent_SelectedIndexChanged(object sender, System.EventArgs e)
Course Plan Informtion
ddlPlan_SelectedIndexChanged(object sender, System.EventArgs e)
btnLoadPlan_Click(object sender, System.EventArgs e)
: CourseView
Figure 29. Faculty user loads an existing plan from the system
: PlanView
: User
ddlPlan_SelectedIndexChanged(object sender, System.EventArgs e)
btnLoadPlan_Click( )
: CourseView
Figure 30. Student user load an existing plan from the system
The user will load an existing plan in the system by first entering the plan name
through the ddlPlan DropDownList on the PlanView. The system will then
retrieve the plan and load it into the CourseView or CourseViewIS (decide by
advisee or student user major) to the user. If the plan has no entry in the course
plan database, the system will generate a new plan for user.
4.5.
Save Plan---User
: CourseView
: User
Save_Click(object sender, System.EventArgs e)
success
Figure 31. User saves the current plan
The user will save the loaded plan in the system by clicking the Save button.
4.6.
Generate Report---User
: User
: CourseView
Print_Click(object sender, System.EventArgs e)
: PrintView
Figure 32. User generates a report
The user can generate a report from a loaded plan by pressing the Print button
which will invoke the generate function. The system will respond with a report
view of the current plan.
5. State/Activity Diagram
SCPS()
Initialization
Login
event enterIndentity( name, password )/
[ User ]
Creating
New Plan
Dropping
Course
Adding
Course
AddCourse( courseId )
CreatePlan( planName )
Saving
Plan
DropCourse( courseId )
SavePlan( planName )
User Wait (CourseView)
User Wait (PlanView)
Finish
event LoadPlan( planName )/
event Logout/
event Search Advisee(Query String)/
event
event
event
event
event
AddCourse(courseId,timeTaken)/
SavePlan(planName)/
DropCourse( courseId )/
GenerateReport/
Finish/
LoadPlan(planName)
GenerateReport
Search Advisee(Query String)
Logout
Find
Advisee
Loading
Plan
Figure 33. The state diagram of the SCPS
Generating
Report
Chapter 8. Assessment Evaluation
1. Purpose
This document will entail the testing which will be performed on the SCPS. Test
items and features will be addressed and will also include features from the vision
document.
2. Testing Results Summary
Table 4. The test result table
Feature Identifier
Description
Result
T-001
Log-in system
Passed
T-002
Add course to course plan
Passed
T-003
Drop course from course Passed
plan
T-004
Generate report
Passed
T-005
Save course plan
Passed
T-006
Load course plan
Passed
3. Test Results Detail
3.1. Unit Testing
Table 5. The SCPS Web form test result table
Test Unit
Test Case
Result
btnSubmit
Invalid user ID
Prompts the user to enter valid user ID
Message: Log in failure, please check your
user ID or password
Invalid password
Prompts the user to enter valid password
Message: Log in Failure, please check your
Valid user ID and
password
user ID or password
User will be led to the PlanView.aspx for the
next step of planning
Table 6. The PlanView Web form test result table
Test Unit
Test Case
Result
Page_Load
Student
System executes the LoadStudent() routine.
The ddlPlan DropDownList is enabled for
the user to select plan.
Faculty
System executes the LoadFaculty() routine.
The grdSelectStudent datagrid will provide
options for faculty user to select advisees.
grdSelectStudent Faculty
The ddlPlan DropDownList is enabled for
user to select plan once faculty makes
selection by clicking “Select” button.
Search
Faculty
System will execute a query for faculty
user’s advisees, which is composed by ID,
last name, and first name provided by user
from the text box txtStudentID,
txtLastName, and FirstName. The query
result will be promptly shown the
grdSelectStudent.
All
Faculty
System executes the LoadFaculty() routine.
The grdSelectStudent datagrid will provide
options for faculty user to select advisees.
btnLogout
All user
All Session variables are cleared. System
will logout the user. User will be prompted
to SCPS.aspx, the log-in webform.
ddlPlan
No planed selected
The button, btnLoadPlan, is disabled to
prevent user from to making the wrong
A plan selected
selection.
The button, btnLoadPlan, is enabled for user
to click to load the plan.
btnLoadPlan
IS student
When clicked, the system will promptly lead
user to the CourseViewIS.aspx webform.
CS student
When clicked, the system will promptly lead
user to the CourseView.aspx webform.
IS advisee selected
When clicked, the system will promptly l
ead user to the CourseViewIS.aspx
CS advisee selected
webform.
When clicked, the system will promptly lead
user to the CourseView.aspx webform.
Table 7. The CourseView Web form test result table
Test Unit
Test Case
Result
Save
CS student and CS
The course plan will be saved back to the
advisee
database.
CS student and CS
User will be led back to the PlanView.aspx.
Back
advisee
Clear
CS student and CS
The new course plan will be loaded.
advisee
Print
CS student and CS
A table view of the course plan will be
advisee
shown by opening a new window of the
PrintView.aspx webform.
Table 8. The CourseViewIS Web form test result table
Test Unit
Test Case
Result
Save
IS student and IS
The course plan will be saved back to the
advisee
database.
IS student and IS
User will be led back to the PlanView.aspx.
Back
advisee
Clear
IS student and IS
The new course plan will be loaded.
advisee
Print
IS student and IS
A table view of the course plan will be
advisee
shown by opening a new window of the
PrintView.aspx webform.
Table 9. The CourseContainer class test result table
Test Unit
Test Case
Result
btnAddCourse
All user
When clicked, a list of the courses that
satisfy this course container type will be
generated into the listCourse drop-down list.
User then will be led to ContainerView.aspx.
listCourse
None selected
The listTime drop list contents are cleared
and the btnSubmit button is disabled.
A course is selected
System will generate a list of times available
for this course and input them into the
listTime drop down list.
listTime
btnSubmit
None selected
The btnSubmit button is disabled.
A course is selected
The btnSubmit button is enabled.
IS student
The course selected will be loaded in the user
session course plan. User will be led back to
the CourseViewIS.aspx webform.
CS student
The course selected will be loaded in the user
session course plan. User will be led back to
IS advisee
the CourseView.aspx webform.
The course selected will be loaded in the user
session course plan. User will be led back to
CS advisee
the CourseViewIS.aspx webform.
The course selected will be loaded in the user
session course plan. User will be led back to
the CourseView.aspx webform.
btnDropCourse All user
When clicked, the course selected will be
dropped from the course plan.
3.2. Integration Testing
3.2.1. Log into the SCPS
This test was passed based on the following evidences:

The user inputs and identity were validated.

The user class was generated correctly according to the user identity.

The user is redirected to the correct Web page after validation
processes.

The incorrect and invalid inputs were blocked of access to the
system.
3.2.2. Add Course to Course Plan
This test was passed based on the following evidences:

User inputs are validated.

The course is added to the course plan—this Web form is updated
correctly.

All prerequisites integrity is check and hold.
3.2.3. Drop Course from Course Plan
This test was passed based on the following evidences:

User inputs are validated.

The course is added to the course plan—this Web form is updated
correctly.

All prerequisites integrity is check and hold.
3.2.4. Generate Report
This test was passed based on the following evidences:

The correct Web form with the printable course plan is generated.
3.2.5. Save Course Plan
This test was passed based on the following evidences:

Course plan is saved.

The number of user-saved course plans doesn’t exceed three.
3.2.6. Load Course Plan
This test was passed based on the following evidences:

The correct course plan is loaded.

The Web form is correctly generated.

The number of user-saved course plans doesn’t change.

User owns the Load Course plan.

Course plan content doesn’t change.

Web form and database are correctly updated.
3.3. Performance Testing
This section of testing is done on a test server which has the Microsoft Internet
Information Services 5.0 (provided by the operation system Windows XP)
installed. Due limitations of Internet Information Services, only 10 active
connections can be made available at once. The test can be performed on up to
four users with the constraint of drop rate<5%. The OpenSTA testing software
package is also used to simulate the virtual users (clients) needed for testing.
Figure 34. One-user performance test result
Figure 35. Two-users performance test result
Figure 36. Three-users performance test result
Figure 37. Four-users performance test result
3.3.1. Summary
Table 10. The performance test result table
Deviation
Throughput
Average
One User
Two Users
Three Users
Four Users
--
18.23
14.83
13.93
82.05
83.00
81.94
82.00
--
69.21
64.82
61.38
The throughput is network traffic and overall load id depended on the server. It
may help the throughput of the application if the database server is completely
dedicated to the application. The deviation characterized the behavior of the
network and the system performance. User will experience higher variation of
speed and quality of service as the deviation increases. The average value
indicates a typical time period for a user to load a particular page
Although the statistics indicate a better performance on the deviation and average
time, the drop rates have increased due the limited connections available. The
database server (MSDE) has been installed on the same server, which may have
also decreased the performance of the server. A better performance can be
achieved by providing dedicated database and web servers. Also, using
commercial-grade server software (such as the Windows Server 2003 and the
SQL Server 2000) will dramatically improve the resources (such as active
connections available) and performance.
3.3.2. Scalability
The current server setup will accept up to 10 active connections. A better
scalability can be achieved by upgrading the server software. Commercial-grade
software such as the Windows Server 2003 (supports up to one million concurrent
network connections) will boost the system performance considerably. Along
with the upgrade of the database server, for example to SQL Server 2000, will
also drastically improve the data processing ability.
Chapter 9. User Manual
1. Introduction
This section of the documentation will explain how to set up the SCPS and usage of the
system.
2. Install SCPS
2.1.
Hardware Prerequisite

A Microsoft SQL database server
o Servers should equip with a processor clock speed over 1.5GHz and
memory over 512mb.

IIS Web server
o Servers should equip with a processor clock speed over 1.5GHz and
memory over 512mb.
2.2.
Software Prerequisites

The client should use Internet Explorer 6.0 and above with Microsoft
.NET Framework installed in order to ensure the quality of service.

Microsoft SQL server 2000 and above are required for the database server.

Microsoft IIS 6.0 and above are also required for the Web server.

Microsoft Visual Studio .Net 2003 professional and above are needed to
configure the sqlConnection between the IIS server and SQL Database
server.
2.3.
Network Prerequisites
A broadband connection is needed for the client to provide fast linkage to the
server. A 10Mbp connection and above are recommend for the server to provide
quality service to user.
2.4.
Software Setup
First, unpack software to the World Wide Web root of the IIS server, usually
“C:\Inetpub\wwwroot”.
Second, import the dataFile.xls with the Import and Export Data Wizard from the
SQL server software to create the database needed for the SCPS.
Third, use the Visual Studio .Net to open the project file, “SCPS.csproj”. The file
should be located in the “SCPS” directory in the World Wide Web root of the IIS
server.
Fourth, locate the SCPS database on your SQL server with the Server Explorer of
the Visual Studio .NET.
Fifth, configure all sqlConnection1 objects with the Visual Studio .Net in the
CourseView.aspx,
CourseViewIS.aspx,
PlanView.aspx,
SCPS.aspx,
AdminView.aspx, and CourseContainer.aspx to connect to the SCPS database on
your SQL Server.
At last, build the project and start using the system!!!
3. Client Usage
3.1.
Log In
Figure 38. User log in the system
The user will log in to the system by entering his or her ID and password. The
system will validate the user identity. If the user ID and password are correct, the
system will redirect the user to the PlanView page. Otherwise, the system will
prompt the user to check the ID and password entered and reenter with the correct
information.
3.2.
Load Plan for Faculty User
Figure 39. Faculty user loads an existing plan from the system
The user can first conduct an advisee search, which can be conducted through the
query textbox supplied above. Clicking on the “Search” button will commence the
search action and results will be posted on the data grid below. The “Show All”
button enables the user to view all advisees she or he might have. The user then
selects the advisee to work on by hitting the “Select” button in front of the student
name. When the advisee is selected, the plan selection will be made available in
the drop-down list below. After a plan selection is made, system will then retrieve
the plan and load it into the CourseView to the user. If the plan has no entry in the
course plan database, the system will generate a new plan for the user.
3.3.
Load Plan---User
Figure 40. Student user loads an existing plan from the system
The plan selection will be made available in the drop-down list below. After a
plan selection is made, system will then retrieve the plan and load it into the
CourseView to the user. If the plan has no entry in the course plan database, the
system will generate a new plan for the user.
3.4.
Add Course --- User
Figure 41. Course plan interface
Figure 42. Add course to the course plan for user
The user clicks on the “Add Course” button to start the process. The SCPS will
provide all qualified course names in the drop-down list. After the course is
chosen, the time when the course should be taken can be entered through the
drop-down list below the course name drop-down list. After all options are
entered, the course will be added by clicking the “Submit” button.
3.5.
Drop Course
A drop course can be performed by clicking on the “Drop Course” button on the
course to be dropped. If other courses that will be affected by this action due to
the course dropped bring a prerequisite, a popup box with a warning message will
be shown and the action will be aborted.
3.6.
Save Plan
A course plan can be saved by hitting the “Save Plan” button.
3.7.
Generate Report---User
Figure 43. User generates a report
A printable report can be generated from a loaded plan by pressing the “Printable
Plan” button.
Chapter 10. Project Evaluation
1. Purpose
The purpose of this document is to review the usefulness of the methodologies used, the
accuracy of the estimations, and the usefulness of the reviews of this project. The final
product will be evaluated on the basis of whether the initial requirements or ideas
presented in the initial overview have accomplished and the quality of the product.
2. Usefulness of the Methodologies Used
2.1.
Unified Modeling Language
The Unified Modeling Language is standard for software-specification modeling.
It models not only application structure, behavior, and architecture, but also
business processes and data structure.
UML conveys designs and ideas in the
initial stage through many diagrams such as class, sequence and state etc. This
technique establishes a simple and clear standard for communication between
developers. It also ensures the quality of the product during the inception of the
project. Translation from designs to code can be done effortlessly.
2.2.
Object Constraint Language
Object Constraint Language (OCL) is a tool to develop a formal specification at
the initial inception stage of the project. It is used to formally verify the design.
This modeling technique also checks requirements of each component prior to the
actual coding. It is quite useful for the developer to have an in-depth look at the
design without doing much of the coding.
3. Accuracy of the Estimations
3.1.
Lines of Code
At the end of the first phase of development, the estimated number line of code
was 3000. The actual line of code is 4977. Reasons that cause the drastic
difference between the estimation and actual number are inexperience of the
developer, unfamiliarity with the programming language and database used, and
the auto-generated code by the IDE used.
Following are the final lines of code statistics:
Lines of Code =4468
HTML Web Form=509
Total= 4977
3.2.
Time Estimation
Estimated time from the COCOMO model analysis of the project is 6.18 staff
months and 4.99 months at the end of second phase. Actual time is about 10
months. Much time devoted toward research and learning was not recorded since
the developer was as novice user of the software and tools employed toward
development of this product. The complex business logic behind the student
curriculum selection process has increased the time spent. Inexperience of the
developer has also contributed to the over-optimistic time estimation.
The following tables will provide a more detailed look at the distribution of time
spent.
Table 11. Duration table
Start Time
Finish Time
Phase I
2/2/2004
5/17/2004
Phase II
5/17/2004
7/9/2004
Phase III
7/9/2004
12/7/2004
Table 12. Task breakdown table
Phase I minutes Phase II minutes Phase III minutes
Research
410
100
430
Design
20
630
0
Coding
2360
760
1745
Testing
0
0
1800
520
875
970
Documentation
Phase I minutes
Research, 410,
12%
Design, 20, 1%
Documentation,
520, 16%
Testing, 0, 0%
Coding, 2360, 71%
Figure 44. Phase I task breakdown diagram
Phase II minutes
Research, 100,
4%
Documentation
, 875, 37%
Testing, 0, 0%
Design, 630,
27%
Coding, 760,
32%
Figure 45. Phase II task breakdown diagram
Phase III m inutes
Documentation,
970, 20%
Research, 430,
9% Design, 0, 0%
Coding, 1745,
35%
Testing, 1800,
36%
Figure 46. Phase III task breakdown diagram
4. Lesson Learned
Problems encountered during the process of developing the SCPS are due to the
inexperience of the developer. Intensive and extensive research was required to overcome
the steep learning curve of the software deployed. Lack of knowledge of the system
components employed caused design changes at the later stages of development. Prior to
the design, the developer should have learned all about tools being used to better
understand the interaction between the components, hence, to prevent the major late
design change.
Underestimations of the complexity of the business logic have also hindered the effort of
development on this project. Certain complexity issues, for example requirements
checking, were overlooked during the design. Delays caused by these issues have thrown
the project off schedule. Costs incurred were very high since the project was finished four
month behind schedule.
Overall, an understanding of the tools used and a good design are critical to the success
of the project. Lack of quality designs and experienced developers will prolong the
development process when unforeseen issues arise.
5. Future Work

Upgrading Software Used During Deployment
The project was developed under several testing engines and software. A series of
the enterprise-grade software can be used to improve the performance and
resources available for the system. Currently, Microsoft Corporation has
developed powerful enterprise servers such as the SQL server 2000 to support
business needs. Incorporating better servers and software component will
considerably increase the efficiency and performance of the system

Import Data from a Better Data Source
The data administration interface was not implemented since a new and secure
data source from the Kansas State University administration system was
discovered during project development. This data source has been constantly
updated and has contained all data records needed for this project. Due to the
security issue, there was no access to this database. Only a test database was
developed for this project. A new data adapter should be developed to import the
data for the new source.
Appendix A. USE Test Script

Test code
The following code will create the scenario where all invariant are violated to provide
a test to the formal specifications of the SCPS model.
!create scps:SCPS
!create coursePlan1:CoursePlan
!create coursePlan2:CoursePlan
!create faculty1:Faculty
!create faculty2:Faculty
!create student1:Student
!create student2:Student
!create admin1:Administrator
!create admin2:Administrator
!create course1:Course
!create course2:Course
!create transcript1:Transcript
!create transcript2:Transcript
!create transcriptEntry11:TranscriptEntry
!create transcriptEntry21:TranscriptEntry
!create courseView1: CourseView
!create courseView2: CourseView
!create planView1: PlanView
!create planView2: PlanView
!create planView3: PlanView
!create planView4: PlanView
!create adminView1: AdminView
!set coursePlan1.planName:='ABC'
!set coursePlan1.authorId:='384930403'
!set faculty1.facultyName:='John Doe'
!set faculty1.facultyId:='431431444'
!set faculty2.facultyName:='John Doe. Jr'
!set faculty2.facultyId:='431431441'
!set student1.studentName:='Jane Doe'
!set student1.studentId:='843941345'
!set student1.major:='CS'
!set student1.userId:='hotshot'
!set student1.password:='isfun'
!set student2.studentName:='Stephanie Lee'
!set student2.studentId:='847674445'
!set student2.major:='IS'
!set student2.track:='Application'
!set student2.userId:='hotshot'
!set student2.password:='Iloveflying'
!set admin1.userId:='hotshot'
!set admin1.password:='nooneknow'
!set admin2.userId:='hotshot'
!set admin2.password:='Iknow'
!set course1.courseId:='CIS300'
!set course1.courseName:='Programming'
!set course1.timeAvailable:='Fall'
!set course1.isRequire:=true
!set course1.csRequire:=true
!set course1.techElective:=false
!set course1.humanElective:=false
!set course1.dbMgmtTrack:=false
!set course1.isAnalystTrack:=false
!set course1.misTrack:=false
!set course1.commAnalystTrack:=false
!set course1.referenceNumber:='00003'
!set course2.courseId:='CIS200'
!set course2.courseName:='Fundamental'
!set course2.timeAvailable:='Fall'
!set course2.isRequire:=true
!set course2.csRequire:=true
!set course2.techElective:=false
!set course2.humanElective:=false
!set course2.dbMgmtTrack:=false
!set course2.isAnalystTrack:=false
!set course2.misTrack:=false
!set course2.commAnalystTrack:=false
!set course2.referenceNumber:='00003'
!set transcript1.studentId:='847674445'
!set transcript2.studentId:='843941345'
!set transcriptEntry11.transcriptId:='00001'
!set transcriptEntry11.referenceNumber:='00001'
!set transcriptEntry11.grade:='D'
!set transcriptEntry11.timeTaken:='Fall'
!set transcriptEntry21.transcriptId:='00001'
!set transcriptEntry21.referenceNumber:='00001'
!set transcriptEntry21.grade:='F'
!set transcriptEntry21.timeTaken:='Fall'
!insert (scps,transcript1) into TranscriptDB
!insert (scps,transcript2) into TranscriptDB
!insert (course1,course2) into Prereq
!insert (transcript1,transcriptEntry11) into TranscriptData
!insert (transcript1,transcriptEntry21) into TranscriptData
!insert (transcript1,student1) into Grade
!insert (transcript2,student2) into Grade
!insert (student1,faculty1) into Advising
!insert (student2,faculty1) into Advising
!insert (scps,coursePlan1) into PlanDb
!insert (scps,coursePlan2) into PlanDb
!insert (coursePlan1, transcript1) into CourseTaken
!insert (coursePlan2, transcript2) into CourseTaken
!insert (coursePlan1, student1) into PlanOwnership
!insert (coursePlan2, student2) into PlanOwnership
!insert (coursePlan1,course2) into FutureCourse
!insert (coursePlan2,course2) into FutureCourse
!insert (student1,scps) into Utilizing
!insert (student2,scps) into Utilizing
!insert (faculty1,scps) into Utilizing
!insert (faculty2,scps) into Utilizing
!insert (admin1,student1) into Moderating
!insert (admin1,student2) into Moderating
!insert (admin1,faculty1) into Moderating
!insert (admin1,faculty2) into Moderating
!insert (admin2,student1) into Moderating
!insert (admin2,student2) into Moderating
!insert (admin2,faculty1) into Moderating
!insert (admin2,faculty2) into Moderating
!insert (scps,course1) into CourseDb
!insert (scps,course2) into CourseDb
!insert (adminView1,course1) into ViewDb
!insert (adminView1,course2) into ViewDb
!insert (admin1,scps) into Administrating
!insert (admin2,scps) into Administrating
!insert (adminView1,admin1) into DbAdmin
!insert (student1, planView1) into ViewPlan
!insert (student2, planView2) into ViewPlan
!insert (faculty1, planView3) into ViewPlan
!insert (faculty2, planView4) into ViewPlan
!insert (planView1,coursePlan1) into MainView
!insert (planView2,coursePlan2) into MainView
!insert (planView3,coursePlan1) into MainView
!insert (planView3,coursePlan2) into MainView
!insert (student1, courseView1) into ViewCourse
!insert (student2, courseView2) into ViewCourse
!insert (courseView1,coursePlan1) into OneView
!insert (courseView2,coursePlan2) into OneView
!insert(course2, transcriptEntry11) into CourseTranscript
!insert(course2, transcriptEntry21) into CourseTranscript

USE Model
model SCPS
--- CLASSES
-class SCPS
operations
Login(userId:String,password:String):Boolean
end
class CourseView
attributes
operations
AddCourse(courseId:String, timeAvailable:String):Boolean
DropCourse(courseId:String):Boolean
GenerateReport():Boolean
SavePlan():Boolean
end
class PlanView
attributes
operations
CreatePlan(planName:String):Boolean
DeletePlan(planName:String):Boolean
LoadPlan(planName:String):Boolean
end
class CoursePlan
attributes
planName:String
authorId:String
operations
FindCourse(courseId:String) : Course
CheckPrerequiste(courseId:String) : Boolean
end
class User
attributes
userId:String
password:String
operations
end
class Faculty < User
attributes
facultyName:String
facultyId:String
end
class Student < User
attributes
studentName:String
studentId:String
major:String
track:String
end
class AdminView
attributes
operations
AddCourse(courseName : String, courseId : String, timeAvailable : String) : Boolean
DropCourse(referenceNum:Integer) : Boolean
end
class Administrator
attributes
userId:String
password:String
operations
end
class Course
attributes
referenceNumber:String
courseId:String
courseName:String
timeAvailable:String
isRequire:Boolean
csRequire:Boolean
techElective:Boolean
humanElective:Boolean
dbMgmtTrack:Boolean
isAnalystTrack:Boolean
misTrack:Boolean
appProgTrack:Boolean
commAnalystTrack:Boolean
operations
closure(s:Set(Course)):Set(Course)=
if s->includesAll(s.thePrereq->asSet) then s
else closure(s->union(s.thePrereq->asSet))
endif
reachableFromSelf():Set(Course)=closure(Set{self})
end
class Transcript
attributes
studentId:String
end
class TranscriptEntry
attributes
transcriptId:String
referenceNumber:String
grade:String
timeTaken:String
end
--- ASSOCIATIONS
-association TranscriptDB between
SCPS[1] role transcriptDb
Transcript[*] role transcriptSaved
end
association TranscriptData between
Transcript[1] role theTranscript
TranscriptEntry[*] role theTranscriptEntry
end
association Grade between
Transcript[1] role hasTranscript
Student[1] role transcriptOwner
end
association Advising between
Student[*] role advisee
Faculty[1] role advisor
end
association PlanDb between
SCPS[1] role planDb
CoursePlan[*] role planSaved
end
association CourseTaken between
CoursePlan[*] role referneceIn
Transcript[1] role contains
end
association PlanOwnership between
CoursePlan[0..3] role hasPlan
User[1] role planOwner
end
association ViewPlan between
User[0..1] role theUser
PlanView[0..1] role thePlanView
end
association ViewCourse between
User[0..1] role theUser
CourseView[0..1] role theCourseView
end
association MainView between
PlanView[*] role thePlanView
CoursePlan[*] role theCoursePlan
end
association OneView between
CourseView[0..1] role theCourseView
CoursePlan[0..1] role theCoursePlan
end
association FutureCourse between
CoursePlan[*] role containIn
Course[*] role hasReference
end
association Utilizing between
User[0..*] role theUser
SCPS[1] role theSCPS
end
association Moderating between
Administrator[1..*] role theAdministrator
User[*] role theUser
end
association CourseDb between
SCPS[1] role courseDb
Course[*] role courseSaved
end
association DbAdmin between
AdminView[0..1] role theAdminView
Administrator[1] role theAdministrator
end
association ViewDb between
AdminView[0..*] role theAdminView
Course[0..*] role theCourse
end
association Prereq between
Course[0..1] role theCourse
Course[0..*] role thePrereq
end
association Administrating between
Administrator[1..*] role theAdministrator
SCPS[1] role theSCPS
end
association CourseTranscript between
Course[1] role theCourse
TranscriptEntry[0..*] role theTranscriptEntry
end
--- CONSTRAINTS
-constraints
-- Privacy
-- Only the student, his or her advisor, and the system administrator can access his or
her (the student) --- transcript.
context t:Transcript
inv Privacy:
Student.allInstances->forAll(s|t.transcriptOwner->includes(s) implies
t.studentId=s.studentId and t.transcriptOwner->size =1 and
s.advisor=t.transcriptOwner.advisor and
Administrator.allInstances=t.transcriptDb.theAdministrator)
-- Students cannot have more than one transcript.
-- Capture by the multiplicity.
-- A course which has a C or above grade can be put on the course planning chart.
context te:TranscriptEntry
inv CAbove:
CoursePlan.allInstances>forAll(cp|(te.theTranscript.transcriptOwner=cp.planOwner
and cp.contains.theTranscriptEntry->includes(te)) implies (te.grade='A' or
te.grade='B' or te.grade= 'C'))
-- A user has a unique user ID.
context User
inv uniqueId:
User.allInstances->forAll(u1,u2|u1<>u2 implies u1.userId<>u2.userId)
-- There are no circular prerequisites.
context Course
inv noCircularPrereq:
Course.allInstances->forAll(c|c.reachableFromSelf()->excludes(self))
-- A user can only has a maximum of three plans.
-- Capture by the multiplicity.
--A course and a transcript entry cannot be on the plan at the same time if they
represent the same class.
context te:TranscriptEntry
inv noSameCourseInOnePlan:
CoursePlan.allInstances>forAll(cp|te.theTranscript.transcriptOwner=cp.planOwner
and Set{te}=cp.contains.theTranscriptEntry
and Course.allInstances->forAll(c|cp.hasReference->includes(c) implies
c.referenceNumber<>te.referenceNumber))
--No duplicate courses on the plan.
context cp:CoursePlan
inv uniqueCourseOnPlan:
Course.allInstances->forAll(c|cp.hasReference->includes(c) implies
cp.hasReference-> intersection(Set{c})->size=1)
--No duplicate TranscriptEntry on the plan.
context cp:CoursePlan
inv uniqueTEOnPlan:
TranscriptEntry.allInstances>forAll(te|te.theTranscript.transcriptOwner=cp.planOwner
and cp.contains.theTranscriptEntry->includes(te)
implies cp.contains.theTranscriptEntry->intersection(Set{te})->size=1)
--All students should have a faculty advisor.
--enforce by the multiplicity.
--There should be either a PlanView or CourseView to show the user
context User
inv onlyOneView:
User.allInstances->forAll(u|(u.thePlanView->size>0 implies
u.theCourseView-> size=0)and (u.theCourseView->size>0 implies
u.thePlanView->size=0) and (u.theCourseView->size<2 and
u.thePlanView->size<2))
--Faculty who have no advisees cannot access the system.
context f:Faculty
inv facultyAccess:
f.advisee->size=0 implies (f.thePlanView->size=0 and f.theCourseView>size=0)
--A transcript entry must have a unique transcript ID.
context te1:TranscriptEntry
inv uniqueTranscriptId:
TranscriptEntry.allInstances->forAll(te2|te1<>te2 implies
te1.transcriptId<>te2.transcriptId)
--A transcript entry must match a course in the course database.
context te:TranscriptEntry
inv TranscriptInCourse:
Course.allInstances->exists(c|c.referenceNumber=te.referenceNumber)
--All users and administrators should have unique user names.
context u:User
inv uniqueUserAdminUserId:
Administrator.allInstances->forAll(a|a.userId<>u.userId)
context u1:User
inv uniqueUserUserId:
User.allInstances->forAll(u2|((u1<>u2) implies (u1.userId<>u2.userId)))
context a1:Administrator
inv uniqueAdminUserId:
Administrator.allInstances->forAll(a2|((a1<>a2) implies
(a1.userId<>a2.userId)))
--All courses should have unique reference numbers.
context c1:Course
inv uniqueReferenceNum:
Course.allInstances->forAll(c2|((c1<>c2) implies
(c1.referenceNumber<>c2.referenceNumber)))
--- Operations
---Administrators can only add a course which is not yet contained in the course
database.
context AdminView::AddCourse(courseName : String, courseId : String,
timeAvailable : String) : Boolean
pre Current: theCourse->forAll(c1,c2|c1<>c2 implies
c1.referenceNumber<>c2.referenceNumber)
post Added: theCourse->forAll(c1,c2|c1<>c2 implies
c1.referenceNumber<>c2.referenceNumber)
--Administrators can only delete a course that is in the course database.
context AdminView::DropCourse(referenceNum : String) : Boolean
pre Current: theCourse->exists(c|c.referenceNumber=referenceNum)
post Deleted: theCourse->forAll(c|c.referenceNumber<>referenceNum)
Appendix B. Formal Inspection Checklist

Cem’s formal inspection checklist
1. Purpose
The purpose of this document is to provide a checklist for the technical inspectors of the SCPS. The
goal of the technical inspection is to aid the developer in checking for correctness and consistency with
the architectural design.
2. Items to be Inspected


UML Diagrams
o Class diagrams
o Sequence diagrams
o State/Activity Diagram
Formal Specification
3. Formal Technical Inspectors


Cem Oguzhan
Esteban Guillen
4. Formal Technical Inspection Checklist
Inspection Item
Pass/Fail/Partial
1. The symbols used in the class diagrams conform to
the UML standards
Pass
2. The symbols used in the sequence diagrams
conform to the UML standards
Pass
3. The class diagrams have a corresponding
description provide in the architectural design
document
Pass
4. The descriptions of all class diagrams are clear and
makes sense
Pass
5. The message that is include in the sequence
diagram are named with actual public methods of the
appropriate classes
Pass
6. All classes of the SCPS are found in the USE model
Pass
7. The role names and multiplicities in the USE model
match correctly to UML diagrams for the SCPS
Pass
8. The attributes and operation in the USE model
Pass
Comments
match correctly to UML diagrams for the SCPS
9. The actions/activities are all defined as methods
(public/private) of the current class, or the class to
whom the event is being sent in the State Diagram
Pass

Guillen’s formal inspection checklist
1. Purpose
The purpose of this document is to provide a checklist for the technical inspectors of the SCPS. The
goal of the technical inspection is to aid the developer in checking for correctness and consistency with
the architectural design.
2. Items to be Inspected


UML Diagrams
o Class diagrams
o Sequence diagrams
o State/Activity Diagram
Formal Specification
3. Formal Technical Inspectors


Cem Oguzhan
Esteban Guillen
4. Formal Technical Inspection Checklist
Inspection Item
Pass/Fail/Partial
1. The symbols used in the class diagrams conform to
the UML standards
Pass
2. The symbols used in the sequence diagrams
conform to the UML standards
Pass
3. The class diagrams have a corresponding
description provide in the architectural design
document
Pass
4. The descriptions of all class diagrams are clear and
makes sense
Pass
5. The message that is include in the sequence
diagram are named with actual public methods of the
appropriate classes
Pass
6. All classes of the SCPS are found in the USE model
Pass
7. The role names and multiplicities in the USE model
match correctly to UML diagrams for the SCPS
Pass
8. The attributes and operation in the USE model
match correctly to UML diagrams for the SCPS
Pass
9. The actions/activities are all defined as methods
Pass
Comments
(public/private) of the current class, or the class to
whom the event is being sent in the State Diagram
Appendix C. Formal Inspection Letter

Cem’s formal inspection letter
Dr.Andresen,
I have completed the Formal Technical Inspection for Kevin Sung's MSE project. I found
everything satisfactory. All of the items in the checklist passed.
Regards,
Cem Oguzhan

Guillen’s formal inspection letter
Formal Technical Inspection
For Student Curriculum Planning System
Completed for Dr. Andresen and Kevin Sung
Inspected by Esteban Guillen, Software Engineer Sandia National Laboratories
I have completed the Formal Technical Inspection for Kevin Sung’s MSE project. I found no obvious
errors in the documentation provided to me by Kevin. All of the items in the attached checklist passed. In
addition I found Kevin’s documentation to be thorough and complete.
Esteban Guillen