Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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