Html prototype similar to section 5 in attached file.
Design Document Group #4 Arpit Rai(
[email protected]) Jedidiah John Nagarajan(
[email protected]) Sunitha Giridipudi(
[email protected]) Wenbo Wang(
[email protected]) Wismy Seide(
[email protected]) Tej Ranu(
[email protected]) Gavin Persaud(
[email protected]) Revision History Date Version Description Author Nov 26, 2020 1.0 Added Introduction Tej Ranu Nov 26, 2020 2.0 System design and overview Wismy and Gavin Nov 27, 2020 3.0 System class Wismy and Gavin Nov 27, 2020 3.0 Defining all the interfaces Wismy and Gavin Nov 27, 2020 4.0 Class descriptions Sunitha and Jedidiah Nov 28, 2020 4.0 Class descriptions Sunitha and Jedidiah Nov 28, 2020 5.0 User interface design Wenbo and Arpit Nov 29, 2020 5.1 Documenting user interface Wenbo and Arpit Nov 29, 2020 6.0 Reformatted the document Tej Ranu Table of Contents Revision History Table of Contents 1. Introduction 2. System design and overview 3. System class 4. Class descriptions 5. User interface design Design Document 1. Introduction The purpose of the design document is to provide diagnosis and tracking of PATH. Path will be presented both as a web interface and a mobile application. The web interface can be implemented in the portal/pipeline and will have the majority of features and controls. Our plan is to suggest different interfaces to all the different stakeholders. This system will purely work on a set of existing records consisting of a student’s academic history/performance, interests and academic skills, and also the faculty’s way of teaching, practical depth of the course. 1.1.Purpose The design document provides an overview of PATH and the user interface looks like. It presents a number of different user views to depict the different aspects of the system. 1.2.Scope The scope of this design document is to explain the user view of PATH. Different views on how the user accesses the software are explained. 1.3.Overview In order to fully document all the aspects of the document, the design Document contains the following subsections : 2.0 System design overview 3.0 System class 4.0 Class descriptions 2. System Design Overview High level overview · Student component This is one of the key components of the PATH System. This is where the student subject selection option is implemented. This also includes the result preview, semester preview and profile functions. · Authentication and user management component This is the major sub system that is responsible for the security of the PATH system. It authenticate users and also handles the user management activities such as creating new user ac-counts, removing accounts from the system etc. Furthermore this component Implements the “control access privilege matrix”. · Subject component This is the key component that implements the functions related to the subject operations of admin-istrator such as adding a new subject, editing credits of an existing subject and removing subjects etc. Subject component is also responsible for displaying the available subject list for every semester. · Publish component Publish component is the component responsible for publishing notices created by the administrator and also the time tables. This component has the ability to publish multiple notices and time tables at the same time. · Public component This is a relatively small subsystem compared to the other components of the PATH System. This is the component which is responsible for the guest viewer (public) to view student re-sults. 3. System class 4. Class Descriptions Class descriptions describe the class attributes which are also called as state of the object, how they interact with each other in other words behaviour of the object. It also defines the relationship with other classes. 4.1. Student Class 4.1.1 Attributes: studentID, firstName, middleInitial, surName, email, major, userName, password, address, phoneNumber and cellPhone 4.1.2 Description: Student class is used to define the student object attributes and operations that are required for every admitted student in the institution. 4.1.3 Operations: Student class allows the below operations that can be called by other classes. 4.1.2.1 getStudentInfo - can search users and can return student details for Advisor, Login class to verify user authentication. 4.1.2.2 enterStudentInfo - Admission class can use this method to add student information of the admitted students. 4.1.2.3 updateStudentInfo - Admissions and Registration classes can call this function to update students details. 4.2. Professor Class 4.2.1 Attributes: professorID, firstName, middleInitial, surName, email, phoneNumber, department, rating, yearsOfExperience, username, password. 4.2.2 Description: Professor class defines attributes for professor and operations required to call for different classes like Advisors, Registration and Academics classes. 4.2.3 Operations: 4.2.3.1 getProfessorInfo to get the professor details based on professorId, department, userName or firstName or lastName. 4.2.3.2 addProfessor is called by Academics class when a new professor is joined the institution 4.2.3.3 getProfessorRating to get the rating of the professor by Advisor class and Academics class 4.3. Advisor Class 4.3.1 Attributes: advistorID, firstName, middleInitial, surName, email, phoneNumber, department, rating, yearsOfExperience, username, password. 4.3.2 Description: Advisor class is used to create advisors and manage operations used by students and professors and academic departments classes. 4.3.3 Operations: 4.3.3.1 getAdvisorInfo to get the advisor details based on advisorId, department, userName or firstName or lastName. 4.3.3.2 addAdvisor is called by Academics class when a new Advisor is joined the institution 4.4. Department Class 4.4.1 Attributes: departmentId, departmentName and departmentHead 4.4.2 Description: Department class is used to define departments managed by the institution. 4.4.3 Operations: 4.4.3.1 getDepartment: to get department details, this operation can be accessed by professor, advisor, student and academics classes. 4.4.3.2 setDepartment: this is called by academics class whenever a new department is added to the institution. 4.4.3.3 removeDepartment: this is called by academics class when the institution no longer requires or if any department is merged to become a new department. 4.5. Course Class 4.5.1 Attributes: courseCode, courseTitle, departmentId and courseUnit 4.5.2 Description: Course class defines properties and functions required to manage courses by academic department class. 4.5.3 Operations: 4.5.3.1 addCourse is called by Academics class whenever a new course has been added in a department. 4.5.3.2 getCourseDetails is called by professor, advisor and department classes to get course details 4.5.3.3 removeCourse is called by Academics when a course is no longer continued. 4.6. CourseRegistration Class 4.6.1 Description: The students have the liberty to choose their course which will reference through the available course listed by the academic advisor and professor. CourseRegistration class defines attributes for registration and operations required to call for different classes like course listing, courseinfo and registering courses 4.6.2 Attributes: courseCode, courseTitle, courseUnit, semesterTerm, semesterYear, dateRegStart 4.6.3 Operations: 4.6.3.1 GetCourseList: To get the list of available courses for the current semester. 4.6.3.2 EnterCourseinfo: We can enter the information of the course as the syllabus is often updated each semester. 4.6.3.3 RegCourse: The courseRegistration class holds courseCode, CourseTitle, course_desc, instructid, instruct_desc, pre_req, course_catalog and approx_fee Course Suggestions Primary Secondary Description The primary element is the courseid, instructid, pre_req and course_catalog The secondary elements show the preferred data inside the portal.Such as subjectid, course_desc, instruct_desc and approx_fee The students have the liberty to choose their courseid which will reference through the available course listed by the academic advisor. This also provides the relation to the instructor preferred from instructid. As the list of courses was chosen it will trigger the pre_req data table with reference to the major they opted in high school. The course_catalog contains the details listed under the courseid as it acts as the foreign key. The instructor description is triggered from the main class instructid as it contains the details about the professor. As everything is listed and courses are selected the total fee with respect to the university per credit fee structure will be generated which allows students to identify how much they were each course cost as a group and individual. 4.7 ApprovedRegisteredCourses Class 4.7.1 Attributes: courseCode, courseTitle, studentName, program 4.7.2 Description: ApprovedRegisteredCourse class defines the students approved courses for registration. 4.7.3 Operations: 4.7.3.1 getCourseList: This operation is called by professor and advisor class to verify the students requested courses for approval. 4.7.3.2 seekApproval: this function is called by a student or an advisor to ask approval from a professor. 4.7.3.3 approveCourseRequest: this operation is called by a professor to approve a request that came from a student or advisor. 4.7.3.4 disaproveCourseRequest: this operation is called from a professor's class to disapprove a request that came for approval. 4.8 ProfessorsUtility Class 4.8.1 Description: ProfessorsUtility class defines attributes for adding and removing students, It is also used in assessing the student performance via getting datas from an add grade table. 4.8.2 Attributes: students, totalStudents, courseDetails 4.8.3 Operations: 4.8.3.1 removeStudent: With this function instructor can remove the additional students or the student who does not have the minimum requirements who has the prerequisite to be completed. 4.8.3.1 addStudent: With this function the instructor has the ability to add the students to the course. 4.8.3.2 addGrades: This is a foreign key which acts as a mirror of the grades class where the student grade will be populated and the performance will be analysed by the instructor. 4.9 Grades 4.9.1 Description: The grades class has the ability to add or get the grades which are personalised by the instructor. 4.9.2 Attributes: studentName, courseCode, grade, professor, semester 4.9.3 Operations: 4.9.3.1 getGrades: The getGrades function stimulates the grades that are provided by the instructor and automatically populates the data in it. 4.9.3.2 addGrades: The addGrade function helps to add the grades manually in the portal by the instructor. 4.10 ImportantDates 4.10.1 Attributes: eventType, startDate and endDate 4.10.2 Description: ImportantDates class is used to maintain