Project Atlantis: Functional Design Document

Table Of Contents

• Executive Summary
• Introduction
• Management Plan
  1. Revisions and Additions
  2. Features of the System
  3. Classes of Functions
  4. Component Interaction
  5. Evaluation of Conceptual Design Comments
  6. Project Atlantis Implementation Timeline
  7. Division of Work in the Development Team
• Context Diagrams

  Legend

  1. Features of the System
  2. Classes of Functions
• Entity Relationship Diagrams

  Legend

  1. Overview
  2. Administrator
  3. Student
  4. Course
  5. Class Section
• Data Dictionary
  1. Entity: Student
  2. Entity: Course History
  3. Entity: Administrator
  4. Entity: Course
  5. Entity: Course Section
• Data Flow Diagrams

  Legend

  1. User

     1.0.0 User Login

  2. Student

     2.1.0 Student System

     2.2.0 Change Password

     2.2.1 View Timetable

     2.2.2 Course Registration

     2.2.3 View Courses Taken

     2.2.4 View Course Information

     2.3.0 Add Course

     2.3.1 Drop Course

     2.3.2 Change Course Registration

  3. Administrator

     3.1.0 Administrator System

     3.2.0 Assigning Grades

     3.2.1 Overload a Course

     3.2.2 Modify a Course

     3.2.3 Add a new Course

     3.2.4 Remove a Course

     3.2.5 Add a new Administrator

     3.2.6 Modifying an Administrator

     3.2.7 Overriding Co/Pre-Requisites

     3.2.8 Modifying a Student

     3.2.9 Add a new Student

     3.2.10 Change Password

     3.2.11 Set Trimester Deadlines

• User Interfaces
  1. General Interfaces

     1.1 Login

     1.2 Logout

  2. Student Interfaces

  2.1 Start up Screen and Main Menu

  2.2 View Timetable

  2.3 Register in Course

  2.4 Course Information

  2.5 View Courses Taken

  2.6 Change Password

  3. Administrator Interfaces

     3.1 Main Menu

     3.2 Assign Grades

     3.3 Overload Course

     3.4.1 Add Course / Section

     3.4.2 Add Pre-Requisites

     3.5.1 Modify Course / Section

     3.5.2 Remove Section

     3.5.3 Remove Pre-Requisite

     3.6 Remove Course

     3.7 Set Trimester Deadlines

     3.8 Add Student

     3.9 Modify Student

     3.10 Override Co/Pre-Requisites

     3.11 Add Administrator

     3.12 Modify Administrator

     3.13 Change Password

• Pseudocode
  1. Login
  2. Change Password
  3. Student Main Menu
  4. View Timetable
  5. Course Registration
  6. Display Course Information
  7. View Previously Completed Courses
  8. Administrator Main Menu
  9. Assign Grades
  10. Overload a Student in a Course
  11. Add Course
  12. Add Lecture Section to a Course
  13. Remove Lecture Section from a Course
  14. Add Prerequisites to a Course
  15. Remove Course
  16. Set Trimester Deadlines
  17. Add a Student to the System
  18. Add an Administrator to the System
  19. Select Student From List
  20. Select Administrator From List
  21. Select Course From List
  22. Select Course Section From List
• Testing
• Summary
• Glossary

Introduction

next previous top

Our main goal for this document is to provide a technical picture of the specification of the Project Atlantis Registration System. Based on our existing design document we implemented GUIs, descriptions, pseudocode outlines as well as an extensive test plan and schedule, which are helpful to clarify the overall structure of the Project Atlantis Registration System. The document consists of a number of sections, which individually, break this complex project down into subsections for ease of understandability and implementation purposes.

The GUI descriptions provide detailed information about all the graphical user interfaces within the Project Atlantis Registration System. The straightforward and logical textual descriptions accompanied with pictures illustrate what the interface accomplishes, and how tasks are accomplished.

Following this is a section containing the data structures and pseudocode upon which all WinterSoft staff members will base their implementations of their assigned modules.

The final section contains our test plan and walkthroughs, which must be read and understood by all staff members. Our testing schedule will be based on this, and every procedure discussed should be implemented.

This document is designed to simplify the implementation and testing process. Feel free to discuss any misunderstandings, ambiguities, or clarifications that you require in order to better implement the Project Atlantis Registration System.

Management Plan

next previous top

The Management Plan outlines the basic features of Project Atlantis. Discussion of the different types of users and how they interact with the system provides an overview of Project Atlantis. It also provides Wintersoft with the opportunity to discuss component interaction and the features offered by the system. This section also provides a timeline by which the University of Atlantis can measure our progress. Finally, the division of work is provided so that specific teams may be contacted if there are any concerns with a particular aspect of the system.

1. Revisions and Additions

next previous top

This document contains parts of the Conceptual Design Document as well as some new material. This section acts as an overview of the major revisions and additions.

• The management plan now includes a response to the UofA's Conceptual Design Document Comments
• The division of work for the development team has been updated.
• All of the Entity Relationship Diagrams have been revised.
• The Data Dictionary has been revised.
• Section 2.2.2 of the Data Flow Diagrams has been revised, and section 2.3.2 has been added.
• Pseudocode has been added to this document, to act as a high-level prototype for our actual code later on.
• The Graphical User Interfaces have been updated.
• A Test Plan has been created, included here as a separate document.

2. Features of the System

next previous top

• All users will be required to login to the system using their unique assigned ID number.
• The system will consist of a timetable scheduling system for students, professors and administrators.
• The system will allow students to enroll, drop and change registration in classes. To be able to do this conveniently, the students must be able to display the courses that are being offered and the information associated with a particular course. The system will allow the student to be placed on a waiting list in the event that a class is full.
• The system will also allow the student to access grades from previous courses that they have completed.
• The students will be able to view their schedules at all times while logged on the system.
• Students will also be able to add themselves to a waiting list if they are unable to enroll in a course.
• Professors and administrators will be able to add and delete course from the course database as well as edit courses and their personal information. They will be able to enter course descriptions and set the time and place at which the courses will be held.
• Administrator-level users will also be able to overload a course.
• For security purposes, all users are required to logout when they are finished using the system. The system will automatically log them out if there is a period of six minutes or more of inactivity.

3. Classes of Functions

next previous top

The system will be comprised of the following components: users and courses. All functionality of the system will involve the interaction of these two components.

The user component consists of instructors/administrators and students. Each of the two user groups will have different capabilities according to their access level.

The student level of access allows the user to construct and modify their course timetable, view grades from courses already taken and change their password.

The main functionality of an administrator is to access student information and to add users to the system. As well, administrators are able to manage the course database.

The course component contains all information relative to a course, which consists of:

• Name and Number
• Lecture, lab and tutorial sections
• Location (room, building)
• Length of each section
• Instructor
• Description
• Pre-requisite(s) and Co-requisite(s), if applicable
• Class list
• Maximum class size
• Waiting list

To create a new course, its name and number is required. For each course name, the course number, lecture number, lab number, tutorial number, description and waiting list must be unique. Since classes often become full, waiting lists will be used.

4. Component Interaction

next previous top

Users and Courses

The two types of users interact with the course component differently. Student users add courses to their timetables and can view course attributes. They may also modify their course information after adding one or more courses to their schedules.

The administrators will interact with the student and course information but will have little interaction with the scheduler. Administrators have the ability to add students and courses to the system as well as access and edit student and course information.

5. Evaluation of the Conceptual Design Document Comments

next previous top

After studying the University of Atlantis Evaluation of Conceptual Design Document WinterSoft would like to make some important clarifications.

• 2. Features of the System
  This list of features was meant to cover only the key aspects of the University of Atlantis system. Some capabilities may have been left out of this list as they were not considered "key", such as the course overloading capability, and there was more detail on these functions elsewhere in the document. This functionality has been added to the list of features in this document. If the University of Atlantis feels that this feature or any other isn't being given the appropriate priority, please feel free to contact us!
• 3. Component Interaction
  Naturally students should be able to make changes to their courses after adding them, this was an oversight in the component interaction part of the management plan.
• 4. Implementation Timeline
  The University of Atlantis felt that the timeline in our last document was imposing deadlines on them, which was not the intention. Any "deadlines" implicating the University of Atlantis were simply meant as suggested dates for the University to offer feedback for our work, in order to keep the project "on track". Our apologies for this miscommunication.
  Furthermore, there was a slight mistake in the timeline: February 18th was listed as the date for acceptance tests to be "conducted", when our actual intention was that we should have the acceptance tests the University of Atlantis wants us to run by that date. This request has since been satisfied by the University of Atlantis' Acceptance Test Document, and the timeline has been revised.
• 5. Context Diagrams: General Concerns
  We agree that a legend would be useful, and one has been added to the previous document, as well as this document.
• 6. ERDs: Overview
  The Entity Relationship Diagrams specify that a student can register for anywhere from one course to "M" courses. Because of the University of Atlantis' structure, the un-specified number "M" is actually ten, Wintersoft was generalizing by using the variable "M" rather than "10".
• 7. Data Dictionary: Administrator
  The active and inactive statuses refer to whether or not an administrator is currently working at the University of Atlantis. Current employees are marked active, and former ones are marked inactive. See the glossary for additional details.
• 9. DFDs: User Login
  We will be giving specific details such as the range of Student and Administrator IDs in this document. As specified by the University of Atlantis, those ranges are 00000000-001000000 for administrators and 00100001-999999999 for students. See the Data Dictionary for more details.
• 10. DFDs: The Student System
  A Data Flow Diagram which allows students to change course information without dropping the course has been added to this document.
• 11. DFDs: Add A New Administrator
  As specified by the University of Atlantis, the system should automatically assign ID numbers to new administrators.
• 12. DFDs: General Concerns
  With respect to security concerns, DFDs are meant to cover the system at a high level. We discussed the Login function, which is one of our main security features. We felt that other security features were beyond the scope of the conceptual design document.
  Errors were left out of the actual DFDs in order to make the diagrams more readable. In most cases, errors are caused by an unusuccessful search of a database.
• 13. General Interfaces
  This is a very unfortunate error, and it has been rectified.
• 14. View Timetable
  As determined in our meeting with the University of Atlantis' customer representatives in January, the timetable will never be more than "one click away". This means that it will not be available simultaneously while a student is making changes to his or her courses, so this comment does not apply to our system. It is true of course, that if a student makes changes to his or her schedule, and then clicks the view timetable button, the timetable will reflect those changes.
• 15. Register in a Course
  It is important for the system to be able to check on whether or not a student has the pre or co-requisites for a course, and this should have been considered a potential "error" in the course registration GUIs.
• 16. Drop Course
  This was an oversight. Students dropping courses will automatically be taken to a screen where they will be asked to confirm that they would like to drop the course specified, rather than being taken to the "Add/Change Courses" screen. The only exception will be if that student is attempting to drop a course that is a co-requisite, in which case they will receive an "error" message.
• 17. Access Calendar Information
  The early GUIs in our Conceptual Design Document did not demonstrate it, but it will be possible to look up class information in the calendar without entering the entire course name and number.
• 18. View Course Availability
  The figure specified was actually figure 7.8. The error has been fixed.
• 19. Assign Grades
  While the system cannot be programmed to ensure that an administrator does not accidentally give a student a valid grade which is not correct for that particular student, Wintersoft agrees that the system should deal with input that is obviously incorrect (i.e. a non-percentile grade) or input which is out of the acceptable range (e.g. 110%).
• 20. Add Course
  The system will handle location conflicts (i.e. the scheduling of one room for two classes at the same time) by automatically assigning rooms for administrators.
• 21. Add New Student
  As per our correspondence with Kris Read on February 20th, 2001, we will attempt to include student names in the system, if it does not interfere with higher priorities.
• 22. Add Administrator
  The "windows" presented in the conceptual design document are still very preliminary, and it is likely that this field will be implemented as a "check box", or something similar.
• 23. Modify Administrator
  The textual description should have read "does not" rather than "does". This mistake has been fixed.

WinterSoft is happy that The University of Atlantis is taking such an active interest in this project, as it will help to ensure the overall success of the Project Atlantis registration system.

6. Project Atlantis Implementation Timeline:

next previous top

The following is an estimated timeline for the development process of the Project Atlantis Registration System.

• February 11th, 2001 - The Conceptual design document is completed and submitted.
• February 18th, 2001 - Evaluation of Conceptual design document. Customer acceptance tests should be submitted to Wintersoft.
• February 27th, 2001 - The System design presentation is conducted.
• March 4th, 2001 - The Technical design document is completed.
• March 7th, 2001 - Coding phase begins
• March 25th, 2001 - The User manual is submitted to our customer.
• April 1st, 2001 - Customer should begin Evaluation of User manual and Change Request document.
• April 5th, 2001 - The Test report record is completed.
• April 6th, 2001 - Demonstration of the final product. Delivery of Project Atlantis.

7. Division of Work Among the Development Team:

next previous top

The purpose of this Management Plan was to outline the fundamental sections of the system. It provides a list of components and their interaction, giving a general idea of how the system will function. As well, it gives a general overview of sections that will be discussed in greater detail, later on in this document.

Context Diagrams

next previous top

Context diagrams give a brief view of the two different types of users and the functionality that they can perform in the system. They provide a very general view without specifying the technical details of how the tasks are performed.

Legend

next previous top

	The blue rectangles with rounded edges represent users who control the system.
	The yellow rectangles represents a the system, which responds to the requests of users.
	Arrows show requests and responses passing back and forth between the user and the system.

1. Student User Diagram

next previous top

The following diagram represents the relationship between a student user and the Project Atlantis Registration System. Interaction between the two entities is evident as the user sends requests for either data display or record manipulation and the system responds appropriately. For example, if a student wishes to delete a course, the system confirms the choice and deletes the desired course from the student's timetable.

fig.3.1 Student User Context Diagram

2. Administrator User Diagram

next previous top

The following diagram represents the relationship between an administrator user and the Project Atlantis Registration System. The user requests a service and the system responds appropriately. For example, if an administrator wishes to overload a course, they add the student to the course and the system responds by updating the class list and the student's timetable.

fig.3.2 Administrator User Context Diagram

The above diagrams give a nice overview of the Project Atlantis system. This general view of the functions each user can perform is useful in outlining aspects of the system that will be discussed in more detail later on in this document.

Entity Relationship Diagrams

next previous top

Entity Relationship Diagrams (ERDs) are designed to show the relationship between different types of users and courses, as well as their attributes. These users are referred to as entities and the interaction between them is called a relationship. Our ERDs have been revised under the advisement of our co-ordinator consultant. The new design should result in greater cohesiveness within each entity, and reduce coupling between the entities, resulting in a more modular design.

Legend

next previous top

	This represents a relationship between entities.
	An entity is a real world object such as a person, place, or thing. An entity can be a student, an administrator or a course.
	An entity's attribute - what it "has".
M	One student can register in up to M courses
N	Any number up to infinity
1	A single entity
1...X	A range of entities from one to X, where X is M or N

1. Overview

next previous top

This diagram illustrates the overall relationships that exist between administrators, students, courses, and class sections. Each entity has its own attributes, which are described in separate diagrams. The relationships described in this diagram are as follows:

An administrator can manage any number of administrators, students and courses. In addition, each administrator can teach from zero to ten class sections.
A student manages their own timetable, and can register in one to ten courses. A student can register in up to ten courses and can be waiting to register in up to ten courses. There is a limit on the number of students that can register in each class section.
A course consists of any number of class sections and can have any number of courses as pre-requisites or co-requisites. As well, a course may be a pre-requisite or co-requisite for any number of other courses.

fig.4.1 An Overview of Relationships between major Entities (click for a larger image.)

2. Administrator

next previous top

fig.4.2 Administrator Diagram

In addition to the relationships an administrator entity has with students, courses and class sections, an administrator has an ID number, a password, a name and a status as attributes.

3. Student

next previous top

In addition to the relationships a student entity has with courses and class lists, a student has an ID number, a password and a status as attributes. fig.4.3 Student Diagram A student has also taken a certain number of courses in past semesters, as illustrated by the course history entity. A single course history has as attributes a course name and number, a grade and the trimester the course was completed.

4. Course

next previous top

fig.4.4 Course Diagram A course has as attributes a name and calendar description.

5. Class Section

next previous top

A class section refers to a course lecture, lab or tutorial section. fig.4.5 Class Section Diagram It has as attributes a lecture, lab or tutorial number, a location, a maximum class size, the ID number of the instructor teaching the section, as well as the time and days the section is offered.

Without going into too much detail, this section used ERDs to provide a quick and easy way to see how entities are related. This section was designed to provide a better understanding of how one entity interacts with another and to display the attributes that make each entity distinct.

Data Dictionary

next previous top

As illustrated in the last section, entities are composed of attributes. This section expands the ERDs by providing a detailed description of each attribute. These descriptions are provided to give a better understanding of their purpose in the Project Atlantis Registration System.

1. Entity: Student

next previous top

Name: ID number
Description: The unique identifier for each person in the system.
Restrictions: Must be an 8-digit integer with a value > 00100000.

Name: Password
Description: The sequence of characters that a user must provide to gain access to the registration system.
Restrictions: Must be between 5 and 15 characters long.

Name: Status
Description: The standing of a student will be either full-time, part-time or inactive.
Restrictions: May only be one of either full-time, part-time or inactive.

2. Entity: Course History

next previous top

Name: Course Name
Description: The name of the course, which the student has taken.
Restrictions: Must be 7 characters: 4 capital letters followed by 3 digits; need not specify a currently active course.

Name: Trimester Taken
Description: The trimester and year in which this course was taken.
Restrictions: Must be 6 characters: 1, 2 or 3 specifying the trimester in which the course was taken, ‘T’, and the 4-digit year in which the course was taken.

Name: Grade
Description: The percentage grade the student received in the course.
Restrictions: Must be an integer in the range 0..100.

3. Entity: Administrator

next previous top

Name: Name
Description: An administrator's full name.
Restrictions: None.

Name: ID number
Description: A unique identifier for each person in the system.
Restrictions: Must be an 8-digit integer <= 00100000.

Name: Password
Description: The sequence of characters that a user must provide to gain access to the registration system.
Restrictions: Must be between 5 and 15 characters in length.

Name: Status
Description: The standing of the administrator can be either active or inactive.
Restrictions: May only hold one of the values [active, inactive].

4. Entity: Course

next previous top

Name: Name
Description: The name of the department that offers the specified course, and the specific course number.
Restrictions: Must be 7 characters: 4 capital letters followed by 3 digits.

Name: Description
Description: Textual information pertaining to the course as found in the University of Atlantis calendar.
Restrictions: None.

5. Entity: Course Section

next previous top

Name: Section Number
Description: The section type identifier and the numerical identifier for the section.
Restrictions: Must be 3 characters: ‘L’ (lecture section), ‘B’ (lab section) or ‘T’ (tutorial section); followed by 2 digits.

Name: Instructor ID
Description: The instructor who is scheduled to teach a course.
Restrictions: Must be a valid administrator ID number.

Name: Location
Description: The building name and room number, where a lecture, lab or tutorial section is scheduled to occur.
Restrictions: Must be 6 characters: 3 capital letters followed by 3 digits.

Name: Max Class Size
Description: The maximum number of students allowed to register in a course.
Restrictions: Must be an integer >= 1.

Name: Time
Description: The time of day when this section will take place.
Restrictions: Must be a valid time between 08:00-19:00, on the hour.

Name: Days
Description: The days of the week on which this section will take place.
Restrictions: Must be an ordered subset of “UMTWRFS”, with no duplicate characters.

The attributes are provided to outline the specific qualities associated with each entity. The data dictionary is designed to give a clearer understanding of these attributes. In the above section, we have described all the attributes for the five entities that compose the Project Atlantis Registration System, as well as the restrictions placed on them by the system.

Data Flow Diagrams

next previous top

This section deals with the flow of information through the system and its processes. This flow of information is best displayed with the use of data flow diagrams (DFDs). As illustrated below, the flow of data starts with the users of the system. These users can be either students or administrators. There are four levels of DFDs, level zero through level three. Level zero deals with the initial login onto the system. It is here that the system will decide if the user is a student or an administrator. Level one separates the different functionality of the student and administrator. The diagrams showing levels two and three deal with the specific tasks for each type of user.

Legend

next previous top

	Entity: An entity supplies data to the system and/or receives data from it. In this system, entities are users, which can be administrators or students.
	Process: A process performs operations on data. In this system, entities carry out tasks through processes.
	Database: A collection of data arranged for ease and speed of search and retrieval. In this system we have three databases, one for administrators, students and courses.
	Data Flow: Represents the flow of data.

1. User

0.0 User Login

next previous top

The user logs into the system by providing an ID number and a password. Depending on the range of the number, the system will access either the student database or the administrator database. The password is then checked by the login process, which will decide if the user has the proper access. If the ID number is in the student range, and their password is correct, they will be given access to the student system. If the ID number is in the administrator range, and the password is correct, the user will be given access to the administrator system. An error will occur if the ID is not found in either the student or the administrator database, or if the password is not valid for the given ID number.

fig.6.1 Login Flow

2. Student

1.0 The Student System

next previous top

Once the student has been granted access to the system, they will be able to choose from the list of student processes. For a student to view their timetable, the system requires their student ID number and will return their timetable information. Course Registration requires a student's ID number to access the current list of courses and the courses taken for that student. To view course information, the course name and number provide the student with the course details. To change passwords, the student's ID number is needed to provide access to the student database information.

fig.6.2 Student Capabilities (click for a larger image)

2.0 Change Password

next previous top

If a student would like to change their password, they must provide the system with their old password, as well as a new password that must be entered twice. The old password is retrieved from the student database with the use of the student's ID number. If the old password matches the one in the student database, and the two new passwords match, the new password will be updated in the database.

fig.6.3 Change Password

An error will arise if the user's two new passwords do not match or if the old password does not match the one retrieved from the database.

2.1 View Timetable

next previous top

fig.6.4 View Timetable

When a student would like to display their current timetable, the system will access the student database with their ID number. The timetable, detailing the student's current list of courses, will be accessed from the database and displayed to the student.

2.2 Course Registration

next previous top

To add, change or drop a course from their schedule, a student must provide the system with basic course information.

fig.6.5 Course Registration

This information includes the class name and number, as well as the lecture, lab and tutorial section numbers. After this, the user has the choice to add or drop the course, or change their lecture, lab or tutorial section.

2.3 View Courses Taken

next previous top

When a student would like to view the list of courses that they have already taken, along with the grades they received in those courses, they perform this action.

fig.6.6 View Finished Courses

The student's ID number is used to access the student database, from which the list of previously taken courses and grades are returned. This information is then displayed to the user.

2.4 View Course Information

next previous top

To access the information for a particular course, the system will take the supplied course name and number to retrieve the course attributes from the course database.

fig.6.7 View Course Information

These attributes include the course description, the instructors and availability of each lecture, lab and tutorial section of the course.

3.0 Add Course

next previous top

Once a student decides to add a course to their schedule, the system will add this course to the student's information. It will also add the student to the class list, through the course database. If the add is unsuccessful, an error will occur. A message will be generated if the course was full, the student is already registered in this course or if the student does not have the required pre/co-requisites.

fig.6.8 Add a Course

If the course is full, the student will have the option of being added to the waiting list.

3.1 Drop Course

next previous top

The dropping of a course is handled in a similar way to the add function. The student tells the system which course they would like removed from their schedule and then that course is removed from the student's information.

fig.6.9 Drop Course

The class list, in the course database, is updated to reflect this change. There will be a confirmation message when dropping. An error will occur if the course is a co-requisite of another course.

3.2 Change Course Registration

next previous top

If a student who is already registered in a course wishes to change the lecture, lab or tutorial section without dropping the course, they must provide the system with the course name and number. fig.6.10 Change a Course This is used to provide the course information from the student’s timetable in the student database. The student changes the sections and the information is used to update the student’s timetable, as well as the class lists for the course in the course database. An error message will be generated if the new lecture, lab, or tutorial sections conflict with the student’s timetable, or if any of the sections are full, as in 3.0 Add Course.

3. Administrator

1.0 Administrator System

next previous top

Once an administrator has been granted access to the system, they will be able to choose from the list of administrator processes. There are four types of tasks an administrator can perform, those pertaining to students, courses, administrators and general tasks.

Student tasks include adding a new student, modifying a student's information and overriding pre/co-requisites. Each of these tasks requires different information: Adding a student requires all the student's information including the student's ID number, status and password. Modifying a student's information requires the student's ID number, and to override course pre/co-requisites requires the student's ID number and the pertinent information for the course the student is registering in.

Course-related tasks include assigning grades, adding a course to the system, modifying a course's information, removing a course, and overloading a course. Each of these tasks requires information particular to the specific task: assigning grades requires the course name, number, and lecture section and the grades to assign to each student registered in the course. To add a course to the system, the information required is the course name, number, number of lectures, labs and tutorials, the maximum number of students, the instructor teaching it, and the day(s), time(s) and location(s) of the lecture(s), lab and tutorial sections.

Tasks related to the administrator include adding a new administrator, which requires the new administrator's ID number, name and status; and modifying an administrator's information, which requires the administrator's ID number.

General tasks include changing the current user's password, which requires the user's old password and new passwords; and setting trimester deadlines, which requires the start and end dates for the trimester.

fig.6.10 Administrator Capabilities (click for a larger picture)

2.0 Assigning Grades

next previous top

Once a trimester has finished, an administrator will enter the grades for the students. The assignment of grades is accessed via the class list in each lecture section. The course name, number and lecture sections are needed so the class list can be returned from the database.

fig.6.11 Assigning Grades

For each student ID number in the course list, the administrator will assign a grade. The student ID number is used to access the student database where the grade for the course specified will be updated in the student's list of courses taken.

2.1 Overload Course

next previous top

If an administrator wishes to overload a course without expanding the maximum class size, the administrator enter the student's ID number and the course name, number, lecture, lab and tutorial sections. The course information is used to access the class list in the course database and add the student to it.

fig.6.12 Overload Course

As well, the student's ID number is needed to add the course to the student's timetable in the student database. An error will occur if the student is already registered in this course.

2.2 Modify a Course

next previous top

To modify course information an administrator is required to provide the system with the course name, number, and lecture section. Information that can be edited includes: instructor, location, course description, maximum class size, and number of lecture/lab/tutorial sections.

fig.6.13 Modify Course

This information is used to access the course in the course database. Once the information has been modified it will be updated in the course database. An error will occur if there are still students in the class list of a section to be removed.

2.3 Add a New Course

next previous top

To add a new course, an administrator enters the course information, including description, name, number, lecture, lab and tutorial sections, pre- and co-requisites, the instructor teaching each lecture, the size of each lecture, and the rooms for each section.

fig.6.14 Add a new Course

The new course is then added to the course database. An error will occur if the course name and number already exist in this database.

2.4 Remove a Course

next previous top

If a course is to be removed from the system, the course name and number must be specified.

fig.6.15 Remove a Course

This information will be used to remove the course and all of its lecture, lab, and tutorial sections from the course database. An error will occur if there are still lecture sections with class lists that are not empty.

2.5 Add a New Administrator

next previous top

To add a new administrator to the system, the administrator's name and ID number are required. The new administrator is then added to the administrator database.

fig.6.16 Adding a New Administrator

An error will occur if a staff member with the same ID number already exists in the database.

2.6 Modifying an Administrator

next previous top

To modify an administrator's information, the administrator's ID number is used to retrieve their information from the administrator database.

fig.6.17 Modifying an Administrator

The administrator's name, password and status can be modified, and the changes will be updated in the administrator database.

2.7 Overriding Co/Pre-Requisites

next previous top

A student may get special permission to take courses without having taken its pre-requisite(s) or meeting the co-requisite requirements. An administrator needs to enter the student's ID number and the details for the course they wish to register in: the course name, number, and lecture, lab and tutorial sections. The student is then added to the class list for the course in the course database and the course is added to the student's timetable in the student database.

fig.6.18 Overriding Co/Pre-Requisites

2.8 Modifying a Student

next previous top

fig.6.19 Modifying a Student

If a student forgets their password, or their record becomes inactive, their information can be accessed from the student database through their student ID number. The updated password or status is provided and the student's information is updated in the student database.

2.9 Adding a new Student

next previous top

fig.6.20 Adding a Student

When a new student is added to the system, their ID number, status, and password are entered. The new student is then added to the student database. An error will occur if there already exists a student in the database with the same ID number.

2.10 Change Password

next previous top

If an administrator would like to change their password, they must provide the system with their old password, as well as a new password that must be entered twice. The old password is retrieved from the administrator database with the use of the ID number. If the old password matches the one in the administrator database, and the two new passwords match, the password will be updated. An error will arise if the user's two new passwords do not match or if the old password does not match the one retrieved from the database.

fig.6.21 Changing a Password

2.11 Set Trimester Deadlines

next previous top

When setting the trimester deadlines, the administrator provides the system with the dates, which are stored in the course database. All courses will follow the same deadlines.

fig.6.22 Adding a Student

The flow of data is important because it shows the explicit exchange of information between users, databases and the system. It provides a nice overview of how the each process will be carried out and handled by the system. These can be viewed as the next level in the system description because it provides more specific implementation ideas, although it is generally simple enough for non-technical people to follow.

User Interfaces

next previous top

In our ever-evolving GUI design process, we at Wintersoft strive to create user interfaces that provide our customers with full functionality as well as being user friendly. In this section we display the latest version of the GUIs for Project Atlantis. Included with each GUI will be a detailed description of User flow.

1. General Interfaces

1.1 Login

next previous top

To log onto the Project Atlantis Registration System, a student or administrator must enter a valid login ID number and password and click "OK". If the user is a student, he will be brought to the main student menu (figure 7.2.1). If the user is an administrator, they will be brought to the main administrator menu (figure). If the login ID is invalid, or password is incorrect for the login ID, an error message will be displayed.

fig.7.1.1 Login Screen

1.2 Logout

next previous top

When a student or administrator clicks the "Logout" button from the Main Menu, they will be prompted for confirmation and logged out of the system.

fig.7.1.2 Logout Screen If a student has not been active for 6 minutes, she will be logged out of the system and an appropriate message will be displayed.

2. Student Interfaces

2.1 Start Up Screen and Main Menu

next previous top

When a student successfully logs into Project Atlantis, the student startup screen will be displayed. All tasks a student can perform are displayed to the left, on the Main Menu, and are visible throughout the student’s session. The task windows will be displayed in the right part of the screen. Information displayed on the screen includes the student’s ID number and the current date.

Clicking on "View Timetable" will provide the student with the View Timetable window, allowing the student to view their current timetable. Clicking on "Course Registration" will provide the student with the Course Registration window to add, drop and change courses. Clicking on "Course Information" will provide the Course Information window, which allows the student to browse calendar information by course. Clicking "View Courses Taken" displays the View Courses Taken window with a list of courses the student has completed, and the grades they received. Clicking on "Change Password" provides the student with the Change Password window, allowing the student to change their current password. The user may log out from the system by clicking on the "Logout" button.

fig.7.2.1 Student's Main Screen (click for a larger picture)

2.2 View Timetable

next previous top

This GUI allows a student to view their current timetable, and can be accessed from the Main Menu by clicking on "View Timetable".
The student’s ID number, the current date, the current trimester, and a table showing the student’s current timetable is displayed.

fig.7.2.2 View Student Timetable

2.3 Register in a Course

next previous top

This GUI is used by a student to register for a course and is accessed from the Main Menu by clicking "Course Registration". In Step 1, the student selects a course from the drop down menu and clicks "Ok". This will display step 2, which contains the course description, lecture, lab, and tutorial sections, and any pre- or co-requisites for the course entered in Step 1.

To register for a course, the student must select a lecture, lab and tutorial section by clicking on the appropriate radio buttons. Clicking "Add" will add the course sections to the student’s timetable. An error message will be displayed if the student did not correctly chose the lecture, lab or tutorial section, or if any section conflicts with the student’s current timetable. If the student tries to register in more than 10 courses, there will also be an error message produced. If the selected lecture section is full, a confirmation message for adding the student to the waiting list will be displayed.

If the student is already registered in the course they have selected, the lecture, lab, and tutorial sections they are currently registered in will be already be selected in Step 2. To change their registration in a course, a student must select different lecture, lab or tutorial sections and click the "Change" button. If the student is not already registered in the course, clicking the "Change" button will produce an error message.

To drop a course, a student clicks the "Drop" button.

After a successful "Add", "Change", or "Drop", a system message will be displayed. Clicking "Cancel" will return the student to the main menu without registering a student or modifying their registration.

fig.7.2.3 Course Registration (click for a larger image)

2.4 Course Information

next previous top

This GUI allows a student to view the calendar information of all courses in the University of Atlantis calendar. When a student clicks "Course information" in the Main Menu, Step 1 will be displayed. By selecting a course from the drop-down menu and clicking "Ok", Step 2 will be displayed, along with the course name and number, the calendar description and any pre- and co-requisites this course may have. Step 1 may be repeated any number of times.

fig.7.2.4 Course Information

2.5 View Courses Taken

next previous top

This GUI is accessed from the Main Menu by clicking "View Courses Taken". It allows a student to view a list of the courses they have completed and the grades they received.

fig.7.2.5 Course Information Request

2.6 Change Password

next previous top

This GUI allows a student to change their password. It is accessed from the Main Menu by clicking "Change Password". The user enters their current (or old) password and then their new password twice. A message confirming that the password was updated is displayed when the user clicks "Ok". There will be an error message if the current password is not correct, or if the new passwords do not match, or if the new password is not 5 to 15 characters long. Clicking "Cancel" will return the student to the Main Menu without making any changes.

fig.7.2.6 Change Student Password

3. Administrator Interfaces

3.1 Start up Screen and Main Menu

next previous top

This GUI is the initial screen an administrator will see when they log into the Project Atlantis Registration System. From the left part of the screen, which is visible throughout the administrator’s session, the administrator may choose to perform a variety of tasks. The task windows will be displayed in the right part of the screen.

Clicking on "Assign Grades" will load the Assign Grades window, which allows the administrator to assign grades to all students registered in a particular course. Clicking on "Overload Course" will take the administrator to the Overload Course window, which allows the administrator to overload a student in a course when the course is full or the student wishes to register in more than 10 courses. Clicking "Add course" will take the administrator to the Add Course window, which allows the administrator to add a course to the system. Clicking on "Modify Course" will allow the administrator to modify an existing course’s information through the Modify Course window. Clicking on "Remove Course” will display the Remove Course window, which allows the user to remove a course from the system. Clicking on "Set Trimester Deadlines" will allow the administrator to set the initial and final course registration dates through the Set Trimester Deadlines window.

Clicking on "Add New Student" will allow the administrator to add a new student to the system in the Add New Student window. Clicking on "Modify Student" will allow the administrator to modify an existing student’s information in the Modify Student window. Clicking on "Override Pre/Co-Requisites" button will allow the administrator to override a student’s pre- or co-requisites in the Override Pre/Co-Requisites window. Clicking on "Add Administrator" allows the existing administrator to add a new administrator to the system in the Add Administrator window. Clicking on "Modify Administrator" allows an administrator to change his own or another administrator’s data in the Modify Administrator window.

Clicking on "Change Password" button will allow the administrator to change her current password in the Change Password window. The "Logout" button will terminate the administrator’s session.

fig.7.3.1 Administrator Main Menu (click for a larger image)

3.2 Assign Grades

next previous top

This GUI is accessed from the administrator's main menu by clicking on "Assign Grades". In Step 1, the administrator selects a course from the drop-down menu and clicks "Ok", which displays the course name and number chosen in Step 2. Here the administrator selects a lecture section from the drop-down menu and clicks "Ok", which loads Step 3, where the administrator enters the grades for corresponding student ID numbers. Clicking "Ok" in step 3 will display a confirmation message and update the changes in the student’s course history, as well as in the course list. If any grades are not in the range from 0 to 100 an error message will be displayed. Clicking "Cancel" at any step will return the administrator to the Main Menu without making any changes.

fig.7.3.2 Assign Grades (click for a larger image)

3.3 Overload Course

next previous top

This GUI allows an administrator to overload a student in a course that is full, or to allow a student to register in more than 10 courses. Step 1 is displayed when an administrator clicks "Overload Course" from the Main Menu. The administrator enters the student’s ID number and chooses a course from the drop down menu and clicks "Ok", which loads Step 2. In Step 2, the student ID number and course name entered in step one are displayed. The administrator selects a lecture, lab and tutorial section from the drop down menus and clicks "Ok". A message will be displayed to inform the user that the course has been overloaded for the student. In the steps of the above, if any field is left blank or the student ID is invalid, an error message will be displayed. Clicking "Cancel" at either step will return the administrator to the Main Menu without making any changes.

fig.7.3.3 Overload Course

3.4.1 Add Course

next previous top

This GUI allows an administrator to add new a course to the course database. When an administrator clicks “Add Course” in the administrator main menu, Step 1 will be displayed. The administrator selects a course from the drop down menu and clicks "Ok". This loads Step 2, where the administrator can add, modify and remove lecture, lab, and tutorial sections, enter the calendar description for the course, and add and remove pre- and co-requisites.

Clicking "Ok" in Step 2 will add the course and its lecture, lab and tutorial sections. Clicking any "Add", "Modify" or "Remove" buttons will load the appropriate Step 3.

Clicking "Add" for Lecture, Lab or Tutorial section in Step 2 will load the Step 3 shown in the figure below. Here the administrator selects the section number for the Lecture, Lab or Tutorial section. The "Add Section" is shown here. To select the days of the week that the section is offered, the administrator clicks on the appropriate radio buttons. A time for the section is selected from the drop-down menu. The administrator enters the maximum number of students and selects the instructor from the drop down menu. The room is automatically assigned. Clicking "Ok" will add the section to the course and return the administrator to Step 2. Clicking "Cancel" will return the administrator to Step 2 without adding the section. An error will be displayed if that section already exists, there are no days selected, or the maximum number of students is invalid.

Clicking "Add" for Pre-requisite loads 3.4.2 Add Course with Add Pre-requisite in Step 3. "Modify" and "Remove" are discussed in Modify Course.

To finish adding a course, the administrator clicks "Ok" in Step 2. A message confirming the addition will be displayed. An error message is displayed if there are no lecture sections or a description entered for the course.

fig.7.3.4.1 Add Course With Add Section (click for a larger image)

3.4.2 Add Course (Add Pre-Requisite)

next previous top

fig.7.3.4.2 Add Pre-Requisite (see Add Course for more detail) Clicking "Add" for Pre-requisite loads "Add Pre-requisite" in Step 3 of the Add Course window. An administrator selects a course from the drop-down menu and clicks "Ok". An error message will be generated if the course is already a pre-requisite or a co-requisite. Clicking "Cancel" will return the administrator to Step 2 without adding the pre-requisite. Adding a co-requisite has the same procedure as adding a pre-requisite.

3.5.1 Modify Course

next previous top

This GUI allows an administrator to modify an existing course from the course database, and is accessed by clicking "Modify Course" in the Main Menu. In Step 1, the administrator selects a course from the drop-down menu and clicks "Ok". This will load Step 2, where the administrator can add, modify or remove lecture, lab and tutorial sections, add or remove pre- and co-requisites or modify the course’s calendar description.

Clicking “Add” for a lecture, lab or tutorial section will load Step 3 with 2.4 Add Course with Add Section. Clicking "Add" for a pre- or co-requisite will load Step 3 with 2.4.1 Add Course with Add Pre-requisite.

Clicking "Modify" for a lecture, lab or tutorial section will load Step 3 with Modify Section, as illustrated. The section information is loaded and can be modified here, as in Add Section. Clicking "Ok" will display a message confirming the change and the administrator is returned to Step 2. Clicking "Cancel" will return the administrator to Step 2 without modifying the section.

Clicking "Remove" for a lecture, lab or tutorial section will load Step 3 with Remove Section, as shown in 3.5.2 Remove Section. Clicking "Remove" for a pre-requisite will load Step 3 with 3.5.3 Remove Pre-requisite. Removing a co-requisite has the same procedure as removing a pre-requisite.

fig.7.3.5.1 Modify Course With Modify Section (click for a larger image)

3.5.2 Modify Course (Remove Section)

next previous top

fig.7.3.5.2 Remove Course Section (see Modify Course for more detail) Clicking “Remove” for a lecture, lab or tutorial section while in the Modify Course window will load Step 3 with Remove Section, as illustrated. The administrator selects a section from the drop-down menu and clicks "Ok". A confirmation message will be displayed and the lecture, lab or tutorial section is removed from the course. Clicking “Cancel” will return the administrator to Step 2 without removing the section.

3.5.3 Modify Course (Remove Pre-Requisite)

next previous top

fig.7.3.5.3 Remove Pre-Requisite (see Modify Course for more detail) Clicking "Remove" for a pre-requisite will load Step 3 of the Modify Course window with Remove Pre-requisite. The administrator selects the course they wish to remove from the drop down menu and clicks "Ok". A message confirming the removal of the pre-requisite will be displayed and the course will be removed from the pre-requisites. Clicking "Cancel" will return the administrator to Step 2 without removing the pre-requisite.

3.6 Remove Course

next previous top

This GUI allows an administrator to remove a course from the system, and is accessed by clicking "Remove Course" from the Main Menu. The administrator selects the course from the drop down menu and clicks "Ok". A message confirming the removal of the course will be displayed and the course will be removed from the system. Clicking "Cancel" will return the administrator to the Main Menu without removing the course.

fig.7.3.6 Remove Course

3.7 Set Trimester Deadlines

next previous top

This GUI allows an administrator to set the start and end dates for registration in a trimester and is accessed from the Main Menu by clicking "Set Trimester Deadlines".

The administrator enters the start date and end date and clicks "Ok". A confirmation message will be displayed if this action was successful. An error message will be displayed if the start or end dates were invalid. Clicking "Cancel" will return the administrator to the Main Menu without setting the deadlines.

fig.7.3.7 Set Trimester Deadline

3.8 Add New Student

next previous top

This GUI allows an administrator to add a new student to the system and is accessed from the Main Menu by clicking "Add New Student".

The system will automatically generate an 8-digit student ID number and set the student's status to part-time. The administrator enters a password for the student and clicks "Ok". A message confirming the addition of the student will be displayed and the student will be added to the system. An error message will be displayed if the password is not between 5 and 15 characters long. Clicking "Cancel" will return the administrator to the Main Menu without adding the student.

fig.7.3.8 Add New Student

3.9 Modify Student

next previous top

This GUI allows an administrator to modify an existing student's information and is accessed by clicking "Modify Student" from the Main Menu.

In Step 1, the administrator enters the ID number of the student and clicks "Ok". Step 2 is loaded with the student's information. The administrator can modify the student's password and status, and can view the student's timetable or courses taken. The timetable and the list of courses taken are displayed below Step 2 as illustrated above. Clicking "Ok" causes a confirmation message to be displayed and the student's information is updated. An error message will be displayed in Step 1 if the student ID number is not valid, and in Step 2 if the password is not between 5 and 15 characters long. Clicking "Ok" will return the administrator to the main menu without modifying the student's information.

fig.7.3.9 Modify Student (click for a larger image)

3.10 Override Pre/Co-Requisites

next previous top

This GUI allows an administrator to override a pre- or co-requisite for a course that a student has been given permission to register in, and is accessed from the Main Menu by clicking "Override pre/Co-requisites".

In Step 1, the administrator enters the student’s ID number and clicks "Ok". In Step 2, the administrator selects a course from the drop-down menu and clicks "Ok". In Step 3, the administrator clicks "Override Pre-requisites" and/or "Override Co-requisites" and clicks "Ok". A message confirming this task will be displayed and the student will be allowed to register in the course. An error will occur in Step 1 if the student ID number is invalid. Clicking "Cancel" at any step will return the administrator to the Main Menu without making any changes.

fig.7.3.10 Override Pre/Co-Requisites

3.11 Add Administrator

next previous top

This GUI allows an administrator to add a new administrator to the system and is accessed from the Main Menu by clicking "Add Administrator".

The system will automatically generate an 8-digit administrator ID number and set their status to active. The administrator enters the administrator's name and a password and clicks "Ok". A message confirming the addition of the administrator will be displayed and the new administrator will be added to the system. An error message will be displayed if the password is not between 5 and 15 characters long or if the name is not filled in. Clicking "Cancel" will return the administrator to the Main Menu without adding the administrator.

fig.7.3.11 Add Administrator

3.12 Modify Administrator

next previous top

This GUI allows an administrator to modify an existing administrator's information and is accessed by clicking "Modify Administrator" from the Main Menu.

In Step 1, the administrator enters the ID number of the administrator and clicks "Ok". Step 2 is loaded with the administrator's information. The administrator can modify the name, password and status. Clicking "Ok" causes a confirmation message to be displayed and the administrator's information is updated. An error message will be displayed in Step 1 if the administrator's ID number is not valid, and in Step 2 if the password is not between 5 and 15 characters long, or if the name is left blank. Clicking "Ok" will return the administrator to the main menu without modifying the administrator's information.

fig.7.3.12 Modify Administrator

3.13 Change Password

next previous top

This GUI allows an administrator to change her password. It is accessed from the Main Menu by clicking "Change Password". The user enters her current (or old) password and then her new password twice. A message confirming that the password was updated is displayed when the user clicks "Ok". There will be an error message if the current password is not correct, or if the new passwords do not match, or if the new password is not 5 to 15 characters long. Clicking "Cancel" will return the administrator to the Main Menu without making any changes.

fig.7.3.13 Change Administrator Password

The Project Atlantis Registration System serves the needs of both the students and administrators of the University of Atlantis in a simple and easy-to-use manner.

The student may view and change their current trimester timetable, may view all of the courses taken in previous trimesters, along with the grades received, and they may also look up information on any course in the calendar.

Administrators have the ability to introduce and maintain all types of information supported by Project Atlantis. Some of the options available to aid them include adding, modifying and removing courses, including calendar information; set initial and final course registration dates; add new students into the system and maintain the student’s information; add and maintain the information of other administrators, as well as maintaining their own information; allow students to take courses which are full, or for which they do not have the pre- and co-requisites. The administrator may also enter student grades on a per-course and per-lecture section basis.

Pseudocode

next previous top

This section deals with the processes and functions that make up the University of Atlantis Registration System. For each major process and function there is a short description that contains the following:

Inputs - The input(s) from the user, which are required for a procedure or function.
Outputs - The output(s) from a function or procedure that are based on the input(s).
Security Level - Points out who has the access to perform the function or process.
Description - A brief overview of the function or process.
Errors - Expected errors that the system will notice and the conditions that will cause these errors to arise.
Pseudocode - An outline of how the process and function will be implemented.

The purpose of this section is to display how the system will be set to react when various actions are executed with various types of inputs. It is designed to provide a deeper look into the Registration System.

1. Login

next previous top

Figure:

fig. 7.1.1

Inputs:

ID number (integer)

password (string)

Outputs:

None.

Security Level:

All.

Description:

This process is used to determine valid users and provides them with access to the Registration System. The range of the ID number will determine which database to check, either student or administrator.

Errors:

Invalid login error will arise if the user enters an invalid ID number or, if the ID number is correct, the password does not match.

Pseudocode:

procedure login
     display ( Login form )
     accept input ( ID number, password from user via form )
     if ( user pressed OK ) then
          if ( ID number does not exist or if password is not correct ) then
              error ( "Invalid login" )
          else
               close the form
               if ( ID number <= 00100000 ) then
                   call ( adminMain procedure )
               else
                   call ( studentMain procedure )
               endif
           endif
     endif
endproc

2. Change Password

next previous top

Figures:

fig. 7.2.6 and fig. 7.3.13

Inputs:

old password (string)

new password (string)

Outputs:

None.

Security Level:

All.

Description:

This window will be used for the user to change their password. It requires their old password and the new password entered twice.

Errors:

An error will be generated if the old password is not correct or if the new password, which was entered twice, does not match.

Pseudocode:

procedure changePassword
     show ( Change Password form)
     accept input ( old password, new password, confirmation from user via form )
     if ( user presses OK and no errors occurred, or were corrected ) then
          if ( length of password is less than  5 or greater than 15 ) then
               error ( "Password must be at least 5 characters or at most 15 characters" )
         elseif ( old password from form doesn’t match user's current password ) then
               error ( "Invalid password" )
         elseif ( new password is not the same as confirmation ) then
               error ( "Password does not match confirmation" )
         else
               update the database and close the form
         endif
     elseif ( user presses Cancel button ) then
         close the form
     endif
endproc

3. Student Main Menu

next previous top

Figure:

fig. 7.2.1

Inputs:

None.

Outputs:

None.

Security Level:

Student.

Description:

This is the main menu for student functionality. Once a student is successfully logged in, they will be presented with this menu. From this menu they are able to access additional menus.

Errors:

None.

Pseudocode:

procedure studentMain
	show ( Student Startup form )
	display ( student ID number, current date )
	if ( user pressed View Timetable ) then
		call ( viewTimetable procedure )
	elseif ( user pressed Course Registration ) then
		call ( courseRegistration procedure ) 
	elseif ( user pressed Course Information ) then
		call ( courseInformation procedure )
	elseif ( user pressed View Courses Taken ) then
		call ( viewCoursesTaken procedure )
	elseif ( user pressed Change Password ) then
		call ( changePassword procedure )
	elseif ( user pressed Logout ) then
		close the form and terminate the session
	endif
endproc

4. View Timetable

next previous top

Figure:

fig. 7.2.2

Inputs:

None.

Outputs:

None.

Security Level:

Student.

Description:

This window will display the information for a student's timetable. It will display the seven days of a week and the hours from 08:00 to 19:00. The courses that a student is registered in, along with course information, will be displayed here.

Errors:

None.

Pseudocode:

procedure viewTimetable
     display ( table row and column headers { 08:00-19:00 x UMTWRFS } )
     foreach ( class section the student is registered in )
          foreach ( day the section is scheduled for )
               display ( name of the course associated with the section,
                    and the section number in the table position indicated by {day, section time} )
          endfor
     endfor
endproc

5. Course Registration

next previous top

Figure:

fig. 7.2.3

Inputs:

lecture (boolean)

lab (boolean)

tutorial (boolean)

Outputs:

None.

Security Level:

Student.

Description:

When a student wishes to register in a course they check the appropriate lecture, lab and tutorial sections they would like to register in. Once they click the add button the sections will be added or an error will be generated. As well, a student can drop a course from this menu.

Errors:

When adding or changing sections of a course, errors will be generated under the following conditions if a student:

1. Is already registered in the course.
2. Does not meet the pre-requisite requirements.
3. Does not meet the co-requisite requirements.
4. Fails to select a lecture.
5. Selected more then one lecture.
6. Fails to enter a lab section.
7. Selected more then one lab.
8. Fails to enter a tutorial section.
9. Selected more then one tutorial.

When a student drops a course, errors can be generated if:

1. The student is not entered in the course.
2. The course is a co-requisite of another.

Pseudocode:

procedure courseRegistration
     show ( Course Registration form )
     call ( selectCourse procedure to retrieve course )
     display ( course name )
     display ( course description )
     foreach ( pre-requisite course ) do
          display ( pre-requisite name )
     endfor
     foreach ( co-requisite course ) do
          display ( co-requisite name )
     endfor
     display ( table header )
     foreach ( class section in the course {lecture, lab, tutorial} ) do
          display ( a checkbox if the section does not conflict with student’s current schedule )
          display ( section number, time, "1h", section days, location and instructor name )
     endfor
     accept input ( desired lecture, lab, and tutorial sections via checkboxes placed in section list )
     if ( user pressed Add ) then
          if ( student is already registered in this course ) then
               error ( "You are already registered in this course" )
          elseif ( student does not have all necessary pre-requisites ) then
               error ( "You require one (or more) pre-requisite(s) before taking this course.
                    Please consult the course information")
          elseif ( student does not have all necessary co-requisites ) then
               error ( "You require one (or more) co-requisite(s) before taking this course.
                    Please consult the course information")
          elseif ( no lecture section checkbox is checked ) then
               error ( "You must select a lecture section" )
          elseif ( more than one lecture section checkbox is checked ) then
               error ( "You may only select one lecture section" )
          elseif ( course has at least one lab section and no lab section checkbox is checked ) then
               error ( "You must select a lab section" )
          elseif ( more than one lab section checkbox is checked ) then
               error ( "You may only select one lab section" )
          elseif ( course has at least one tutorial section and no tutorial section checkbox is checked ) then
               error ( "You must select a tutorial section" )
          elseif ( more than one tutorial section checkbox is checked ) then
               error ( "You may only select one tutorial section" )
          elseif ( course is full) then
               query if student wants to be placed on waiting list
               if ( yes ) then
                    add to waiting list
               endif
          else
               update database and close the form
          endif
     elseif ( user pressed Change )
          if ( student is not already registered in this course ) then
               error ( "You are not registered in this course"d )
          elseif ( no lecture section checkbox is checked ) then
               error ( "You must select a lecture section" )
          elseif ( more than one lecture section checkbox is checked ) then
               error ( "You may only select one lecture section" )
          elseif ( course has at least one lab section and no lab section checkbox is checked ) then
               error ( "You must select a lab section" )
          elseif ( more than one lab section checkbox is checked ) then
               error ( "You may only select one lab section" )
          elseif ( course has at least one tutorial section and no tutorial section checkbox is checked ) then
               error ( "You must select a tutorial section" )
          elseif ( more than one tutorial section checkbox is checked ) then
               error ( "You may only select one tutorial section" )
          else
               update database and close the form
          endif
     elseif ( user pressed Drop )
          if ( student is not already registered in this course ) 
               error ( "You are not registered in this course" )
          elseif ( this course is a co-requisite of any other course the student is registered in)
               error ( "This course is a co-requisite for " + other course name(s) 
                    + "Please drop it(them) first." )
          else
               if ( another student is on the waiting list)
                    add other student to course
               endif
               update database and close the form
          endif
     endif
endproc

6. Display Course Information

next previous top

Figure:

fig. 7.2.4

Inputs:

None.

Outputs:

None.

Security Level:

Student.

Description:

This window will display the course information. This consists of displaying the course name, course description, pre-requisites and co-requisites.

Errors:

None.

Pseudocode:

procedure displayCourseInfo
     call ( selectCourse procedure to retrieve course )
     display ( course name )
     display ( course description )
     foreach ( pre-requisite course ) do
          display ( pre-requisite name )
     endfor
     foreach ( co-requisite course ) do
          display ( co-requisite name )
     endfor
     if ( user pressed OK )
          close the form
     endif
endproc

7. View Previously Completed Courses and Grades

next previous top

Figure:

fig. 7.2.5

Inputs:

None.

Outputs:

None.

Security Level:

Student.

Description:

This window will display the student's list of previously taken courses, the trimester the courses were taken, and the grades received.

Errors:

None.

Pseudocode:

procedure viewCoursesTaken
     display ( table header )
     foreach ( entry in student’s course history )
          display ( course name, trimester, grade received )
     endfor
endproc

8. Administrator Main Menu

next previous top

Figure:

fig. 7.3.1

Inputs:

None.

Outputs:

None.

Security Level:

Administrator.

Description:

This is the main window that an administrator is presented with after they have successfully logged into the system.

Errors:

None.

Pseudocode:

procedure adminMain
     show ( Admin Startup form )
     if ( user pressed Assign Grades ) then
          call ( assignGrades procedure )
     elseif ( user pressed Overload Course ) then
          call ( overloadCourse procedure )
     elseif ( user pressed Add Course ) then
          call ( addCourse procedure )
     elseif ( user pressed Modify Course ) then
          call ( modifyCourse procedure )
     elseif ( user pressed Remove Course ) then
          call ( removeCourse procedure )
     elseif ( user pressed Set Trimester Deadlines ) then
          call ( setDeadlines procedure )
     elseif ( user pressed Add New Student ) then
          call ( addStudent procedure )
     elseif ( user pressed Modify Student ) then
          call ( modifyStudent procedure )
     elseif ( user pressed Override Pre/Co-Requisites ) then
          call ( overloadCourse procedure )
     elseif ( user pressed Add Administrator ) then
          call ( addAdmin procedure )
     elseif ( user pressed Modify Administrator ) then
          call ( modifyAdmin procedure )
     elseif ( user pressed Change Password ) then
          call ( changePassword procedure )
     elseif ( user pressed Logout ) then
          close the form and terminate the session
     endif
endproc

9. Assign Grades

next previous top

Figure:

fig. 7.3.2

Inputs:

grade(s) (integer)

Outputs:

None.

Security Level:

Administrator.

Description:

An administrator uses this window to enter student grades for a particular lecture. They select the course number, lecture number and student and then select the appropriate grade.

Errors:

If the grade entered is not between the range of 0 and 100 then an error will be produced.

Pseudocode:

procedure assignGrades
     call ( selectCourse function to retrieve course )
     if ( returned value is null {cancelled} )
          close the form and exit procedure
     endif
     call ( selectSection function to retrieve section )
     if ( returned value is null {cancelled} )
          close the form and exit procedure
     endif
     display ( table header )
     foreach (student registered in the section )
          display ( student ID and an edit box for the grade )
          accept input ( grade from user via edit box )
     endfor
     if ( user pressed OK ) then
          if ( any grade is not an integer from 0..100 )
               error ( "Invalid grade" )
               position cursor in invalid field
          else
               update database and close the form
          endif
     elseif ( user pressed Cancel ) then
          close the form
     endif
endproc

10. Overload a Student in a Course

next previous top

Figure:

fig. 7.3.3

Inputs:

None.

Outputs:

None.

Security Level:

Administrator.

Description:

When a class is full, an administrator can overload it. In this window, the administrator selects the course number, lecture number, tutorial number and student ID number. Once confirmed, the student will be added to the course.

Errors:

An error is generated if the student to be overloaded is already registered in the course.

Pseudocode:

procedure overloadCourse
     show ( Overload Course form )
     call ( selectStudent function to retrieve student )
     if ( returned value is null {cancelled} ) then
          close the form and exit procedure
     endif
     call ( selectCourse function to retrieve course )
     if ( returned value is null {cancelled} ) then
          close the form and exit procedure
     endif
     loop
          call ( selectSection function to retrieve lecture section from course )
          if ( returned value is null {cancelled} ) then
               close the form and exit procedure
          endif
     until ( selected section is a lecture section )
     if ( course has at least one lab section ) then
          loop
               call ( selectSection function to retrieve lab section from course )
               if ( returned value is null {cancelled} ) then
                    close the form and exit procedure
               endif
          until ( selected section is a lab section )
     endif
     if ( course has at least one lab section ) then
          loop
               call ( selectSection function to retrieve tutorial section from course )
               if ( returned value is null {cancelled} ) then
                    close the form and exit procedure
               endif
          until ( selected section is a lab section )
     endif
     if ( user pressed OK ) then
          if ( student already registered in course ) then
               error ( "Student already registered in course" )
          elseif ( selected lecture section conflicts with the student’s current schedule )
               error ( "The selected lecture section conflicts with the student’s current timetable" )
          elseif ( a lab section was required and the selected lab section
               conflicts with the student’s current schedule )
               error ( "The selected lab section conflicts with the student’s current timetable" )
          elseif ( a tutorial section was required and the selected tutorial section
               conflicts with the student’s current schedule )
               error ( "The selected tutorial section conflicts with the student’s current timetable" )
          else
               update database and close the form
          endif
          elseif ( user pressed Cancel )
              close the form
     endif
endproc

11. Add Course

next previous top

Figure:

fig. 7.3.4.1

Inputs:

course name (string).

Outputs:

None.

Security Level:

Administrator.

Description:

To add a new course to the system, the administrator would perform this action from this menu. The administrator must enter a course name, course description, lecture, lab, tutorial sections and pre- and co-requisites, if applicable.

Errors:

Errors will be generated when the course name is not valid or the entered course name is the same as an existing course.

Pseudocode:

procedure addCourse
     show ( Add Course form )
     loop
          accept input ( course name from user via form )
          if ( course name is not valid ) then
               error ( "That is not a valid course name" )
          elseif ( a course with that name already exists in database ) then
               error ( "A course already exists with that name" )
          endif
     until ( no error occurs or user pressed Cancel )
     accept input ( course description from user via form )
     if ( user pressed add lecture section button ) then
          call ( addLectureSection procedure )
     elseif ( user pressed modify lecture section button ) then
          call ( modifyLectureSection procedure )
     elseif ( user pressed delete lecture section button ) then
          call ( deleteLectureSection procedure )
     elseif ( user presses add lab section button ) then
          call ( addLabSection procedure )
     elseif ( user pressed modify lab section button ) then
          call ( modifyLabSection procedure )
     elseif ( user pressed delete lab section button ) then
          call ( deleteLabSection procedure )
     elseif ( user presses add tutorial section button ) then
          call ( addTutorialSection procedure ) 
     elseif ( user pressed modify tutorial section button ) then
          call ( modifyTutorialSection procedure )
     elseif ( user pressed delete tutorial section button ) then
          call ( deleteTutorialSection procedure )
     elseif ( user pressed add pre-requisite button ) then
          call ( addPreReq procedure )
     elseif ( user pressed delete pre-requisite button ) then
          call ( deletePreReq procedure )
     elseif ( user pressed add co-requisite button ) then
          call ( addCoReq procedure )
     elseif ( user pressed add co-requisite button ) then
          call ( deleteCoReq procedure )
     elseif ( user pressed OK button ) then
          update database and close the form
     elseif ( user pressed Cancel button ) then
          close the form
     endif
endproc

12. Add Lecture Section to a Course

next previous top

Figure:

fig. 7.3.4.1

Inputs:

section number (string).

Outputs:

None.

Security Level:

Administrator.

Description:

This is used to add sections to a course. The administrator enters a section in the form of 'Lxx' where xx are integers. The days the course is offered must also be entered, along with time, location and the maximum class size.

Errors:

If the section does not start with 'L' then it is not a valid lecture section so an error will be produced. An error will also be generated when the entered section already exists, the room number is invalid, or the days of the week are entered incorrectly.

Pseudocode:

procedure addLectureSection ( course )
     show ( Add Section form )
     display ( course name )
     loop
          accept input ( section number from user via form )
          if ( section number is not valid or does not start with ‘L’ {lecture} ) then
               error ( "That is not a valid lecture section number" )
          elseif ( a section with that number already exists for the course ) then
               error ( "A section already exists with that number" )
          endif
     until ( no error occurs )
     accept input ( section days, time, location and maximum class size from user via form)
     accept input ( instructor ID from user via selectAdmin function )
     if ( user pressed OK ) then
          if ( any character in the section days is not “UMTWRFS”, or a letter is duplicated ) then
               error ( "Days may be one of ‘U’,‘M’,’T’,’W’,’R’,’F’,’S’." )
          elseif ( location is an invalid room number ) then
               error ( "Invalid room number" )
          else
               update database and close the form
          endif
     elseif ( user pressed Cancel ) then
          close the form
     endif
endproc

13. Remove a Lecture Section From a Course

next previous top

Figure:

fig. 7.3.5.2

Inputs:

None.

Outputs:

None.

Security Level:

Administrator.

Description:

When the administrator would like to remove a section of a course, they select the section. The selected lecture will then be removed from the database.

Errors:

If the selected section is not a lecture section, an error is produced.

Pseudocode:

procedure removeLectureSection ( course )
     display ( course name )
     call ( selectSection ( course ) function to retrieve lecture section )
     if ( returned value is null {cancelled} ) then
          close the form and exit procedure
     elseif ( returned value is not a lecture section ) then
          error ( "Invalid section type" )
     endif
     if ( user pressed OK ) then
          query user to confirm deletion
          if ( yes ) then
               foreach ( student registered in associated course )
                    remove course and all corresponding sections from student timetable
               endfor
               update database
          endif
          close the form
     elseif ( user pressed Cancel ) then
          close the form
     endif
endproc

14. Add Prerequisites to a Course

next previous top

Figure:

fig. 7.3.4.2

Inputs:

None.

Outputs:

None.

Security Level:

Administrator.

Description:

When an administrator would like to add a pre-requisite to a course, she selects the course. The selected course will then be updated to have the new pre-requisite.

Errors:

If the pre-requisite is a duplicate, an error will be generated.

Pseudocode:

procedure addPreReq ( course )
     show ( Add Pre-Requisite form )
     display ( course name )
     call ( selectCourse function to retrieve pre-requisite )
     if ( returned value is null {cancelled} ) then
          close the form and exit procedure
     endif
     if ( user pressed OK ) then
          if ( the returned value is already a pre-requisite for course ) then
               error ( “That course is already a pre-requisite” )
          else
               update database and close the form
          endif
     elseif ( user pressed Cancel ) then
          close the form
     endif
endproc

15. Remove Course

next previous top

Figure:

fig. 7.3.6

Inputs:

None.

Outputs:

None.

Security Level:

Administrator.

Description:

When the administrator would like to remove a course, they select the course. The selected course will then be removed from the database.

Errors:

None.

Pseudocode:

procedure removeCourse
     call ( selectCourse function to retrieve course )
     if ( returned value is null {cancelled} )
          close the form and exit procedure
     endif
     if ( user pressed OK ) then
          query user to confirm deletion
          if ( yes )
               foreach ( student registered in course )
                    remove course and all corresponding sections from student timetable
               endfor
               foreach ( other course for which this is a pre-requisite )
                    remove this course from other course's pre-requisite list
               endfor
               foreach ( other course for which this is a co-requisite )
                    remove this course from other course's co-requisite list
               endfor
              update database
          endif
          close the form
     elseif ( user pressed Cancel ) then
          close the form
     endif
endproc

16. Set Trimester Deadlines

next previous top

Figure:

fig. 7.3.7

Inputs:

start date (date).

end date (date).

Outputs:

None.

Security Level:

Administrator.

Description:

The administrator sets the trimester deadlines by entering the start and end dates.

Errors:

If either date is invalid an error message will be produced.

Pseudocode:

procedure setDeadlines
     show ( Set Deadlines form )
     accept input ( start and end registration dates from user via form )
     if ( user pressed OK ) then
          if ( start date is not valid ) then
               error ( "Invalid start date" )
          elseif ( end date is not valid ) then
               error  ( "Invalid end date" )
          else
               update database and close the form
          endif
      elseif ( user pressed Cancel )
          close the form
      endif
endproc

17. Add a Student to the System

next previous top

Figure:

fig. 7.3.8

Inputs:

password (string).

Outputs:

None.

Security Level:

Administrator.

Description:

When the administrator would like to enter a student they must provide a password. The student ID number is automatically assigned.

Errors:

An error will be produced if the password is not between 5 and 15 characters long.

Pseudocode:

procedure addStudent
     show ( Add Student form )
     generate ( new student ID Number )
     accept input ( password from user via form )
     set ( student status to 'Part-time' )
     if ( user presses OK ) then
          if ( length ( password ) < 5 or length ( password ) > 15  ) then
               error ("Length of password must be between 5 and 15 characters")
          else 
                update the database and close the form
          endif
     elseif ( user presses Cancel button ) then
          close the form
     endif
endproc

18. Add an Administrator to the System

next previous top

Figure:

fig. 7.3.11

Inputs:

name (string).

password (string).

Outputs:

None.

Security Level:

Administrator.

Description:

When the administrator would like to enter another administrator they must provide a name and a password. The administrator ID number is automatically assigned, as well as the status.

Errors:

An error will be produced if the length of the password is not between 5 and 15 characters long.

Pseudocode:

procedure addAdmin
     show ( Add Administrator form )
     generate ( new admin ID Number )
     accept input ( admin name, password from user via form )
     set ( admin status to 'Active' )
     if ( user presses OK ) then
          if ( length ( password ) < 5 or length ( password ) > 15  ) then
               error ("Length of password must be between 5 and 15 characters")
          else
               update database and close the form
          endif
     elseif ( user presses Cancel button ) then
          close the form
     endif
endproc

19. Select Student From List

next previous top

Figure:

fig. 7.3.9

Inputs:

ID number (integer).

Outputs:

student (object).

Security Level:

Administrator.

Description:

When the administrator selects a student ID number, the student object will be returned.

Errors:

If the ID number is invalid or there is no student in the system with that number, an error will be produced.

Pseudocode:

function selectStudent : Student
     display ( combo box containing the ID number of each student in the database )
     accept input ( ID number from user via combo box )
     if ( user presses OK ) then
          if ( ID number is not valid ) then
               error ( "The ID number is invalid" )
          elseif ( no student exists with that ID number ) then
               error ( "There is no student with that ID number in the database" )
          else
               close the form and return the ID number
          endif
     elseif ( user pressed Cancel ) then
          close the form and return an empty string
     endif
endfunc

20. Select Administrator From List

next previous top

Figure:

fig. 7.3.12

Inputs:

ID number (integer).

Outputs:

administrator (object).

Security Level:

Administrator.

Description:

When the administrator selects an administrator ID number, the administrator object will be returned.

Errors:

If the ID number is invalid or there is no administrator in the system with that number, an error will be produced.

Pseudocode:

function selectAdmin : Administrator
     display ( combo box containing the ID number of each administrator in the database )
     accept input ( ID number from user via combo box )
     if ( user presses OK ) then
         if ( ID number is not valid ) then
              error ( "The ID number is invalid." )
         elseif ( no administrator exists with that ID number ) then
              error ( "There is no administrator with that ID number in the database" )
         else
              close the form and return the ID number
         endif
     elseif ( user pressed Cancel ) then
         close the form and return an empty string
     endif
endfunc

21. Select Course From List

next previous top

Figure:

fig. 7.3.5.1

Inputs:

course name (string).

Outputs:

Course (object).

Security Level:

All.

Description:

When a course is selected from the combo box, the course object will be returned, giving the method that called it access to the course information.

Errors:

The course name is invalid.

The course does not exist.

Pseudocode:

function selectCourse : Course
     display ( combo box containing the name of each course in the database )
     accept input ( course name from user via combo box)
     if ( user presses OK ) then
         if ( course name is not valid ) then
              error ( "The course name is invalid" )
         elseif ( no course exists with that name ) then
              error ( "There is no course with that name in the database" )
         else
              close the form and return the course name
         endif
     elseif ( user pressed Cancel ) then
         close the form and return an empty string
     endif
endfunc

22. Select Course Section From List

next previous top

Figures:

fig. 7.3.5.1 and fig. 7.3.5.2

Inputs:

course section (integer).

Outputs:

Course section (object).

Security Level:

All.

Description:

This handles the selection of courses from a combo box.

Errors:

The section number is invalid.

No such section number exists for this course.

Pseudocode:

function selectSection ( course ) : Course Section
     display ( combo box containing the number of each section in course )
     accept input ( section number from user via combo box )
     if ( user pressed OK ) then
          if ( section number is not valid ) then
               error ( "The section number is invalid." )
          elseif ( no section with that number exists for the course ) then
               error ( "The course contains no section with that number" )
          else
               close the form and return the section
          endif
     elseif ( user pressed Cancel ) then
          close the form and return null
     endif
endfunc

This section covered some processes and functions that will be used by the Project Atlantis system. The majority of the processes and functions are high-level and are meant to provide a brief outline of the implementation of each section and how various inputs, outputs and errors will be handled.

Summary

next previous top

This technical design document combined our company's Functional Specification and Management Plan, and Conceptual Design Document, as well as critical input from our client. It is the last step before we at WinterSoft build an actual working version of the system.

Based on this document, we feel that any competent team of developers could turn our vision into a functioning system, and that our expert programmers can use it to create a fully operational web-based application.

Glossary

next previous top

[A-C] [D-G] [H-N] [O-Z]

Active Status

In the Project Atlantis system, an administrator is considered "active" if he or she is currently employed by the University of Atlantis. A student is considered active if he or she is currently enrolled in the University of Atlantis.

Administrator

A user with priviledged access to the Project Atlantis system.

Attribute

A quality or characteristic of a thing.

Co-requisite

A course that must be taken concurrently or prior to another.

Concurrent

Occuring simultaneously.

[A-C] [D-G] [H-N] [O-Z]

Database

A computer file that is capable of storing and quickly retrieving large amounts of data.

Data Structure

A conceptual container that holds related data in a computer system.

DFD

Data Flow Diagram - used to show how data is exchanged in a system.

Entity

Something that exists as a particular and discrete unit.

ERD

Entity Relationship Diagram.

Expected Input

Data that a user enters which is considered valid by the system.

Graphical User Interface

A display used to allow humans to interact with computers. The "windows" in Microsoft Windows are graphical user intrefaces.

GUI

Graphical User Interface.

[A-C] [D-G] [H-N] [O-Z]

HTML

"Hypertext Markup Language". This is the scripting language with which web pages are built.

Inactive Status

In the Project Atlantis system, an administrator is considered "inactive" if he or she is no longer employed at the University of Atlantis. A student is considered inactive if he or she is no longer enrolled in the University of Atlantis.

Interface

A point at which different groups interact; in this context, a method for human-computer interaction.

Internet

A global collection of inter-connected computers which would form a sort of "net" if you could see the connections between them, hence the name.

Instructor

Synonymous with administrator; an instructor may have different tasks from an administrator, but has the same type of access to the system.

Login

1) The procedure of gaining access to a secure system by means of entering a valid user name and password. 2) The user name.

[A-C] [D-G] [H-N] [O-Z]

Object

In programming, an object is a discrete unit of data and operations on that data.

Overload (a course)

If a student wishes to register in a course that is full, an administrator may grant the student access, thus "overloading" the course.

Pre-requisite

A course that must be completed prior to taking certain other courses.

Prototype

An early model

Schedule

A plan for performing work in the time allotted.

Student

A user with unprivileged access to Project Atlantis Registration System. This means that he or she can only view and, in some cases modify, his or her own records.

Unexpected Input

Data that a user has entered which, because it is not considered appropriate by the system, has caused an error to result.