Course Scheduling Support System Roy Levow, Jawad Khan, and Sam Hsu Department of Computer Science and Engineering, Florida Atlantic University Boca Raton, FL 33431 {levow, jkhan, samh}@fau.edu Abstract - The Course Scheduling Support System is designed to facilitate manual generation of the faculty course schedule. It aids in assigning faculty to courses and assigning each course section to a time block. It captures historic and current scheduling information in an organized manner making information needed to create new schedules more readily available. The interaction between user and database is made as friendly as possible so that managing, manipulating, populating and retrieving scheduling data is simple and efficient. We have implemented an open source web-based prototype of the proposed system using PHP, MySQL, and the Apache Web Server. It can be invoked with a standard Web browser and has an intuitive user interface. It provides tools for customizing web forms that can be easily used by non-technical users. Our department plans to deploy this system by Fall 2006. Index Terms - Faculty Course Scheduling, Open Source. INTRODUCTION Scheduling is a very broad term that can be applied to all kinds of tasks. The American Heritage Dictionary defines the verb schedule as to make up a schedule and defines the noun schedule as a plan for performing work or achieving an objective, specifying the order and allotted time for each part. The components of a schedule vary from one type of establishment to another. In a technical support business, such a component would be forwarding incoming calls to an available agent on a first come first serve basis. Likewise a city s public transport system would usually consist of three inter-related components. First, the creation of timetables for buses and subway trains which the public can refer to; second, assigning vehicles to certain routes which the vehicle must complete within a time block; third, designating drivers to each bus and subway train. Scheduling in the university primarily deals with classes and term examinations. Entities involved within scheduling classes include courses, faculty, students and rooms which should be optimally assigned to each other in order to create a class schedule. This thesis focuses on systems that support faculty and course scheduling. Faculty need to be assigned to teach courses and each section within a course need to be assigned to days and times. In this paper we propose the Course Scheduling Support System as a viable alternative to other systems. Choosing a scheduling support system has certain implications. The system will alter the manual process and the results can affect not only an establishment s bottom line but also the people involved. It may require a change in the Information Technology infrastructure since better solutions are not always available in the set of technologies currently being used. This could mean increased costs and training hours spent in buying and learning to use such a product. Commercial scheduling systems are rarely cheap and come with the additional onus of performing a cost-benefit analysis to analyze whether the benefits outweigh the cost [1]. Publicly available solutions for university course and faculty scheduling provide many features to support those scheduling services in general. However these solutions also bring up issues including cost of purchase and maintenance, amount of training needed, technological requirements to use the system, and adaptability of product to distinct university scheduling needs. Four other solutions were studied and compared to our system. Table 1 summarizes the comparison. These solutions are IQ.Session, Cyber Matrix Class Scheduler, imagic Timetable Master and Free Evolutionary Timetabling. IQ.Session is the product of ComQuip, Inc. [2] and is developed with Visual Basic and Microsoft Access. It can schedule classes taking faculty preferences into account. Schedule reports can be printed as text reports, Crystal reports or viewed as HTML reports. IQ.Session provides no support for the CSV file format and cannot scan a web page for information. The Cyber Matrix Class Scheduler is developed by CyberMatrix Corporation, Inc. [3]. It provides services for scheduling students, rooms and faculty to classes, and has a CSV import/export feature for extracting data from the database into CSV files. It can only be installed and used on a Windows machine. It provides no mechanism for autopopulating database tables through scanning web pages. imagic Timetable Master is developed by imagic Software [4] to perform course, faculty and room scheduling. Features include an export function to integrate into software applications like Excel and the Web to output timetables for courses and faculty. It only provides the option of viewing generated schedules on the web and is not entirely web based. It is also reliant on Microsoft technology and provides no support for the CSV file format. It provides no mechanism for reading information from a web page. Free Evolutionary Timetabling is open source free software developed by Liviu Lalescu [5] which uses genetic algorithm to generate course, faculty, student and room schedules. The user can either manually provide or submit an xml file for the system to read from. Even though Free Evolutionary Timetabling is not entirely web based, it is not reliant on Microsoft and provides T4K-18
distributions for all major operating systems. However it provides no support for the CSV file format and no services for scanning web pages for scheduling information. TABLE 1 (PART 1) UNIVERSITY SCHEDULING SOFTWARE COMPARISON TABLE Features OS Support Input Source (Format) Solutions IQ.Session Windows Manual (Application GUI) Cyber Matrix Windows Manual (Application Class Scheduler GUI), File (CSV) imagic Timetable Windows Manual (Application Master GUI) Free Evolutionary Windows, Mac OS X, Manual (Application Timetabling Linux, Unix GUI), File (XML) Course Scheduling Windows, Mac OS X, Manual (Web Forms), Support System Linux, Unix Web (HTML) and filtering tables, and a facility to archive faculty and course records when deleted. Internet Users Internet FAU Course Listing Web Page Server Incoming requests authenticated with web server s built in user authentication system Operating System Solutions IQ.Session TABLE 1 (PART 2) UNIVERSITY SCHEDULING SOFTWARE COMPARISON TABLE Features Output Format Cyber Matrix Class Scheduler imagic Timetable Master Free Evolutionary Timetabling Course Scheduling Support System Plain text, HTML, Crystal reports CSV Scheduling Support Courses, Faculty, Students, Rooms Features Accessible through Web Finished schedules Courses, Faculty, None Students, Rooms Excel, HTML Courses, Faculty, Finished Students, Room schedules XML, HTML, Courses, Faculty, Finished ical Students, Rooms Schedules CSV, HTML Courses, Faculty All System Features The remaining sections of this paper introduce the Course Scheduling Support System by describing its requirements and implementation details. We take a look at the system design at the modular level and explain how each module in the system interacts with one another to make the system work. SYSTEM REQUIREMENTS The high level system view shown in Figure 1 is an overview of the environment under which the Course Scheduling Support System operates. Since our system is accessible through the web, security is an important issue but the requirement is rudimentary. Therefore existing security protocols need to be utilized to secure the scheduling system from unauthorized access. Most web and database servers have built in security features that provide authorization, authentication and access control. Other requirements include an open source web based solution, a mechanism to distinctly identify courses with the same prefix and number, the ability to display records for only a specific term and year, a utility to scan scheduling information from course listing web pages to auto-populate the Schedule table, a utility to extract course listing web page information and database table records into Comma Separated Value (CSV) files, a utility to duplicate schedule records from one term/year to another, user friendly web forms for ordering FIGURE 1 SYSTEM INFRASTRUCTURE The system needs to be able to connect to the Florida Atlantic University course schedule listing web page server to retrieve scheduling information and automatically populate the Schedule table with that information. At the same time the system should produce a CSV file containing all schedule related and non-schedule related information. This task can be achieved by scanning the webpage line by line to find a schedule record and then parse the schedule record to extract field information for the Schedule database table. Database Web Server Database access Authenticated with DB server s Username and password Schedule Database Database tables with just a single field are used to populate drop down lists in web forms for other database tables. This provides an easy way of maintaining drop down list values without changing any code in the web form itself. To add, delete or update any values in this drop down list, a user just needs to update its corresponding table. Other significant tables needed in the database include Course, Faculty, Preference, and Schedule. The Course table is for mainstream courses that have their own unique course id. Maintaining historic course records are important so no Course record should be physically deleted. Instead they will get deactivated by switching a Boolean value. The Faculty table will store information about each faculty in the Computer Science and Engineering department who teaches its courses. Like Course records, Faculty records also hold historic importance and should not be physically deleted. The Preference table will T4K-19
store information about the courses that a faculty can teach or prefers to teach in a particular term and year. The last and most important table in the database is the Schedule table which will hold scheduling information such as the days, times, locations for each course section and the faculty teaching it. A PROTOTYPE The Course Scheduling Support System prototype includes a web based user interface developed in HTML, CSS and JavaScript. Its processing logic is developed in PHP and it includes a MySQL database system. As illustrated in Figure 2, the system has a Front End and a Back End composed of modules. The Front End is defined by the User Interface Module which determines how the user interacts with the system and ensures users can access the entire system through any web browser that supports viewing through HTML, CSS and JavaScript. The Back End is a combination of the Form Processing Module and the Database Module. FIGURE 2 SYSTEM ARCHITECTURE Figure 3 provides a detailed view of the system architecture with insight into each system module and how they interact with each other to make up the entire system. The system modules are denoted in bold letters. The dashed line delineates the boundary for the User Interface Module, Web Form Module and Form Processing Module to indicate which parts of the system architecture are its components. field information for the Schedule database table. User Interface Module The user interface to the system includes text information, html links and web forms. There is a home page containing links to all web forms for all database tables as well as other services. The user interface of the database table web forms allow users to insert, update and delete database records. It also allows user to sort, filter and copy records based on the requirements of certain tables. Each function has its own web form for input and display of information related to that web form. The User Interface Module sets the standard for the Maintenance Support Module and the Web Form Module so that their user interface features remain consistent. Maintenance Support Module The Maintenance Support Module is part of the Front End and helps the user control certain front end features such as drop down lists and field name abbreviations. It reduces the amount of time needed to update changes to these features. The drop down list values come from a table specifically created to hold its values. Therefore any updates made to these tables affect what user sees in the drop down list. Like any other table, these tables also have their own web forms which the user can use to insert, update and delete values in order to update the values in a drop down list field of another web form. Field names for all tables in the database are stored in the Abbr table which consists of two fields, Field_Name and Field_Abbr. Web forms for all other tables use this table to determine the abbreviated versions of their field names to display for the user. This allows user to customize meaningful filed names and control the display width of a column which may expand with a long field name. Web Form Module The Web Form Module is also part of the Front End and it ensures that web forms are created and displayed based on schema information retrieved from each table that the web form represents. The module ensures all web forms are generated automatically and changes made to the existing database tables are automatically reflected in the front end web forms. This procedure is implemented by first collecting all schema information such as field names, field types, field lengths and number of fields into variables which are then used wherever they are needed to generate a web form. No value is hard coded except for the table name for which the web form is being built. This module is also responsible for colleting user input and passing it to the Form Processing Module. The components within the Web Form Module shown in the detailed system architecture view of Figure 3 represent all the operations that can be performed on these web forms. The operations are labeled by the purpose that they serve. The lines connecting these components illustrate the sequence of operations that are called in order to gather user input before transferring that input to the Form Processing Module. Even though each one of these operations serve a different purpose, the implementation logic behind them are similar since they all have the same goal. The goal is to gather information inputted by the user in the forms and send them to the Form Processing Module so that it can process them into queries for the database to execute. When a user is finished entering all data into the forms, the Form Processing Module takes over to gather and process this input. The following list T4K-20
explains what each component in the Web Form Module of Figure 3 does in their correct sequence of occurrence as connected by the lines. FIGURE 3 DETAILED VIEW OF SYSTEM ARCHITECTURE a) Preference Filter by Course ID This component brings up the Preference Filter web form for the purpose of allowing the user to filter Preference records by Course ID. b) Select Course ID to filter by This is the input box of the preference filter web form where the user inputs the course id that the resulting set of Preference records should have. All other Preference records not having this course id will not be listed. c) View Filtered Preference Table This component transfers the user input to the Form Processing Module so that the course id inputted by the user can be used to construct the filter query for the Preference table. d) Schedule Filter and Order This component brings up the Schedule Filter and Order web form for the purpose of allowing the user to filter and order the Schedule records based on the values provided for the Schedule fields Days1 and Days2 and values provided for the sequence of Schedule fields that the Schedule records need to be ordered by. e) Select Filters Campus, Days1 and Days2 and the Ordering Sequence These are the input boxes of the Schedule Filter and Order web form where user enters values for Campus, Days1 and Days2 that the resulting set of Schedule records should have, and values for the ordering sequence where user enters the field names of the Schedule table based on which the Schedule records should be ordered. f) View Filtered and Ordered Set of Schedule Records This component transfers the user input to the Form Processing Module so that the course id inputted by the user can be used to construct the filter and order query for the Schedule table. g) Copy Schedule This component brings up the Copy Schedule web form for the purpose of allowing the user to copy old Schedule records as new Schedule records. h) Select Old and New Term/Year Values These are input boxes for the Copy Schedule web form where user enters values for Old Term/Year and New Term/Year. i) Copy Old Schedule to New Schedule This component transfers the user input to the Form Processing Module so that the Old and New Term/Year values can be used to construct the insert statement for the Schedule table. j) Insert/Update/Delete This is a common component in all table web forms allowing user to insert new records, update current records or delete current records. k) Provide Values for Insert and Update There are web forms for only Insert and Update since they both require more information from user to generate the appropriate query. These forms are generated automatically based on schema information of the table in question. Once user inputs all the data necessary, the information is sent over to the Form Processing Module so that the values provided can be used to construct the insert or update statement for the table. l) Download From OASIS This component brings up the Download From OASIS web form where user can specify the course listing web page from which to gather scheduling information from. m) Select Year and Term These are input boxes for the Download From OASIS web form where user can enter the year and term of the course listing web page that the system should connect to and gather scheduling information from. n) Create CSV and Insert Schedule Records or Update Enrollment - This component transfers the user input to the Form Processing Module so that the Year and Term T4K-21
values can be used to locate the course listing web page and connect to it for scheduling information. o) Export Table to CSV This component brings up the Export Table to CSV web form where user can specify the table for which to create the CSV file for. p) Select Table and Export This component presents an input box where user can enter the table name for which the system should generate CSV file. This information is passed on to the Form Processing Module so that it can generate a query to extract all data from the specified table and create a CSV file. Form Processing Module The Form Processing Module takes care of backend processing tasks which include processing user input to generate SQL queries, communicating with the database to execute queries and display database results including error messages, retrieving data from web pages to auto populate the Schedule table and generate CSV files, and error handling to keep the system from crashing due to erroneous user input. In forms that need to process queries, when the user hits the Update or Delete button on a web form, the form does a post back which means updates and deletions are taken care of in the same web form. Each record in the web form is preceded with the check box form element whose value is all the field values in the record the checkbox represents, concatenated with the asterisk. Once the field values are received, they are used to construct a query. This is done simply by concatenating field values with the general query which could either be an update, insert, delete or other query. Once the query is constructed, it is executed and the results displayed on the web page. Automatically populating the Schedule table is performed by connecting to the university course listing web page and reading the page as a set of lines and characters. Each line is stripped of any HTML tags and regular expressions are used to identify lines containing scheduling information. Those lines are then parsed to extract information for each field in the Schedule table and to create the CSV file. Database Module The Database Module defines the tables in the database, the relationships between them and rules that describe how data is to be inserted, updated or deleted from each table. It forms the backbone of the Course Scheduling Support System and is needed by all the other modules as illustrated in Figure 4. The Web Form Module relies on the database for table schema information to create and process web forms for each table. The Maintenance Support Module has specific tables in the database that it uses to manage the content of drop down lists and the size of table field names in the web forms. The Form Processing Module communicates with the database to process user queries and display information returned such as query results and error messages. Finally the User Interface Module provides the user a medium through which to interact with the database. FIGURE 4 INTERACTION BETWEEN SYSTEM MODULES A WALKTHROUGH We will walk through one major feature of the Course Scheduling Support System and see how the system works. This feature is called the Download From OASIS utility service, illustrated with the flow chart in Figure 5. OASIS is the name given to our university s student academic information web pages which include course schedule listings. This service is requested when the user selects the academic year of the course schedule listing web page that the user wants information from. The user then needs to indicate the term of the year. The system then presents a web form consisting of a drop down list and three buttons to choose from, which are Create CSV/Insert Records, Update Enrollment, and Home. Values for the drop down list consist of the three academic terms, Fall, Spring and Summer which the user can select from. The user can then choose to create a CSV file and insert records into the Schedule table, update only the enrollment information in the Schedule table, or go back to home page. When user decides to either update enrollment or create CSV file and insert records, the system checks to see whether a course schedule listing page for the academic year and term selected exists. If it does not, an error message is displayed. If it does, then the system connects to the course schedule listing web page, gathers all the relevant information needed, disconnects from the course listing web page and populates or updates the schedule table. It also creates a CSV file and a Log file and provides the user with a link to these files so that they can be downloaded. The CSV file will contain all scheduling information in the comma delimited format. The log file will contain any error messages generated while performing this task and while communicating with the database. T4K-22
REFERENCES [1] D. Montana, So you want to build an automated scheduling system, BBN Technologies, 2002, pp. 1 3. [2] IQ.Session, ComQuip Inc, Key benefits, February 2006. http://www.comquip.com/iq%20session.htm [3] CyberMatric Class Scheduler, CyberMatrix Corporation Inc, Benefits/Features, December 2005. http://www.cyber-matrix.com/csched.html [4] imagic Timetable Master, imagic Software, Product overview, 2006. http://www.imagictimetablesoftware.com/ [5] Free Evolutionary Timetabling Software, Liviu Lalescu, Features, April 2006. http://www.lalescu.ro/liviu/fet/features.html FIGURE 5 FLOW CHART FOR DOWNLOAD FROM OASIS UTILITY CONCLUSION The Course Scheduling Support System addresses the issues presented in the introduction. This system has no cost of purchase since it was built as on open source thesis project. It has been designed and implemented to reduce cost of maintenance such that certain changes like schema changes to the database, addition of new tables or deletion of old tables, and updating drop down lists in web forms, are automatically reflected by the system without the need for code changes. Since the system has an interactive user friendly interface, and is built on the existing scheduling process used by our department, there is hardly any training needed for a user to use this system. Technological requirements to deploy this system anywhere is not an impediment since open source technology such as PHP, MySQL and Apache are used to build the system. These technologies provide builds for all major operating systems and only need to be installed on one server machine. Finally, since the system is web based, the user interface to the system can be accessed from any web browser. T4K-23