Student Advisement
Assistance System
Intro
This student advisement assistance
system was developed fall semester, 2001.
The purpose of the SAAS is currently to aid Computer Science students at
Kennesaw State University to register for courses from semester to
semester. It was developed using
Dreamweaver and Homesite for the html pages, and JDK for the jsp/java pages and
java beans.
It is based on a three-tier
architecture. The first tier interacts
with the student – the web pages/html interface. Currently, these web pages only contain information from the
2001-2002 KSU course catalog. The second tier consists of jsp pages and java
beans, which gather information the student has entered. The third tier is the database on the web
server. This database is a flat file
that consists of the Computer Science courses offered each semester at Kennesaw
State University. Each semester, the
database will be updated by the system administrator from the information on the
registrar’s web page.
The User Flow
Students will need to follow the links
to view or print out their transcript if they do not already know which classes
they have had. If they have any
questions about which courses are being used for the system, they can follow
the link provided to the 2001-2002 catalog.
When the student is
ready to continue into the system, they would then click the "Student" button to enter the
system.
Next shown is a comprehensive listing
of the Computer Science courses, elective, and upper electives (divided into two
tracts – systems or object oriented programming), available to the
student. The purpose of this page is
allowing the student to select which courses he or she has already successfully
completed – successful typically meaning with a grade of C or better. Once the student has finished selecting the
courses, they continue into the system by pressing the "Submit" button.
The next page shown asks the student
to confirm which classes they selected, so there is no error in the
selection. If the student notices that
they either forgot to choose a course, or chose the wrong course, they can
click the "Reselect"
button and attempt the selection again.
If the student, upon reviewing the selections, wishes to confirm that
they are indeed correct, they press the "Continue" button.
The student will then see a listing of
the courses that they can possibly take (they have successfully passed the
prerequisites AND the course is actually offered in the next semester). The system asks them to choose which of the
courses they are interested in taking.
Once they have chosen the courses, they press the "Submit" button.
The next screen shows the student all sections for each course they were interested in, available the next semester. If the student decides to re-select which courses they want to register for, they can still click the "Back" button and select the new courses, resubmit those courses, and view the new page detailing those available sections. Once the student has decided he or she has selected the correct courses, they can click “Print” and it will send the page to the printer. A notice is also provided that states that the courses are not necessarily open.
The Behind the Scenes
First we will describe the text file databases residing on the server as they populate the Java Beans used for the system. Then we will discuss the Beans and the information provided by the student as this completes the 3-tier archetype, which can be expounded upon.
There are two text file
databases that the system uses. The
first, “Every.txt,” holds ‘every’ class in the BS
of CS listing in the KSU 2001-2002 catalog.
There are 27 courses, currently, in this file. However, of the 27 courses, some have pre-requisites and some do
not. For the ones that do not have pre-requisites,
the course is listed in the file on a line by itself. For the courses that do have pre-requisites, first the course is
listed, then each of its pre-requisites are listed, all delimited by tabs. Example:
CSIS2300
CSIS2301 CSIS2300
CSIS2302 CSIS2301
The “Every.txt” database is used to populate a vector within the
DisplaySchedule.JSP page. We will
discuss this further in another section.
The second, “Classes.txt,” holds the courses and sections,
offered at KSU each semester, from the following majors: CSIS, MATH, ENGL, COM, and PHYS. This information is accessed from:
http://www.kennesaw.edu/registrar/Fall2001/Courses/C_D.htm#CSI
http://www.kennesaw.edu/registrar/Fall2001/Courses/C_D.htm#COM
http://www.kennesaw.edu/registrar/Fall2001/Courses/ENGL.htm
http://www.kennesaw.edu/registrar/Fall2001/Courses/M_MKT.htm#MAT
http://www.kennesaw.edu/registrar/Fall2001/Courses/MUSI_Q.htm#PHY
The text from these pages is easily gathered by
selecting the information and cut-paste into the “Classes.txt” file. Example:
11429 CSIS
1020 01 3.00
Intro Programming Principles
Main Campus
Aug 18, 2001 Dec 13, 2001 TTH 08:00 am - 09:15 am NU
118
Instructor(s): M. Ahmed
11594 CSIS
1020 02 3.00
Intro Programming Principles
Main Campus
Aug 18, 2001 Dec 13, 2001 SAT 08:00 am - 10:45 am KH
1102
Instructor(s): R. Conn
As you can see in this example, and throughout all
of the different majors, there are three lines per course section. When selecting the courses from the web,
ensure that the two following lines after the course/section are also
gathered. In the case of a class that
has been canceled, this is not necessary.
Also, it is only necessary to
cut-paste portions of the MATH, COM, ENGL, and PHY, which hold the courses that
CS majors have to take. For instance,
with ENGL or COM, it would only be necessary to capture the text which holds
the sections for 3140 or 3385, not the entire ENGL and COM files. The “Classes.txt” database is used to populate a
vector within the DisplaySchedule.JSP page.
There
are basically two input sessions from the student that are of importance to the
system. The first of which,
Student_chk.jsp, is the page where student must select the CSIS courses that he
or she has completed successfully (C or better). These selections are captured and stored in “stud” vector. Once we have the ‘stud’ vector populated
with the courses that the student has taken, we compare it to the ‘ev’ vector, which was populated
previously by the “Every.txt” file.
After this comparison, we know which courses of the ‘ev’ vector the student has taken,
and which he/she hasn’t. The indexes
from the ‘ev’ vector, of the courses the
student hasn’t taken, are stored in a “possible” vector.
Now it is necessary to know which
of the “possible” courses the student is able to
take, i.e. do they have all the pre-requisites. We now search the indexes of the ‘possible’ courses in the ‘ev’ vector comparing the ‘stud’ courses with the
pre-requisites. If the student has
already taken all of the pre-requisites, meaning the pre-requisites from the ‘ev’ vector were all found somewhere
inside the ‘stud’ vector, then that particular course is written to the ‘available’ vector.
Now, the ‘available’ vector contains all courses that
the student is eligible to take: it’s a
course he/she hasn’t already had, and they satisfy all pre-requisites for
it. The last and final culling of these
courses is to remove the ones that aren’t offered the next semester, since the
student couldn’t register for these courses anyway. So, the ‘available’ courses are compared with the ‘semester’ vector, which was populated
above from the “Classes.txt.” Any
course in ‘available’ vector that is found in the ‘semester’ vector is added to the ‘offered’
vector.
Now comes the second input session
from the student of importance to the system. The ‘offered’ vector is then displayed to the
student who will select which of these they wish to view sections offered. The courses they select are stored in ‘selectedCourses’ vector. The next page will display all
courses/sections found in the “Classes.txt” which match the ‘selectedCourses’ data, i.e.
“CSIS/MATH/PHYS/COM/ENGL” and “course#”.
There
is a “home” button on the last page that
takes the student back to the Intro.htm page.
On the other pages are various “back” and “reselect” buttons that allow the student
to back track. Each page also has “continue” or “submit” which allows the students to
progress through the system.
It’s nearly always possible to enhance a
system. Therefore, this can’t possibly
be an exhaustive list of enhancements, however it is what we would have done
had there been more time in the semester to do so.
·
Improve the graphical display.
Currently when the dynamic vectors are displayed on the dynamic tables,
they can be longer than the regular page display. However, since the page was set up with layers instead of frames,
they are static. So, converting the
layers into frames could be a viable enhancement.
·
Store the courses that the student provides as “successfully completed”
on the student’s PC. This allows the
student to access the system again later without having to add the courses each
time. However, this would have to
provide a means for the student to select more courses in addition to the ones
they have on the file.
·
Provide an Administrator page that has shortcut links to the registrar
for information gathering, and then offer a page for the administrator to
submit the cut-pasted information. The
old information (from the previous semester) would be cleared, and the
submitted information would append to the blank file.
·
Lastly, this system was set according to the 2001-2002 catalog,
specifically the check boxes on “Student_chk.jsp,” and the information in “Every.txt.” An enhancement would be to add catalog years following the same
archetype as this system has set forth.