1.        Introduction

Managing online assignment submissions made via email becomes a real challenge (especially when class sizes are large) because it requires huge amounts of storage space and file management skills to process submissions efficiently. The problem is aggravated when more assignments are given as the course progresses. Distributing the responsibility of evaluation amongst staff may alleviate the problem of submission management to some extent, but this requires managing the collation of assignment marks. Centralized management of marks is also desirable to assess student progress in a course.

Our Web-based course management (WBCM) system provides easily navigable structure to all online submissions and a centralized web-based interface for submission evaluation. A customized online submission interface is generated in accordance with requirements for each assignment as specified by the staff concerned. Student progress tracking, group and individual assignment organization, assignment evaluation and marking, grade maintenance and distribution, online submission, online attendance are the important features of WBCM. In essence WBCM automates and integrates several diverse aspects of course management.

After discussing the motivation behind WBCM, subsequent sections describe the system architecture and important technical details and features of the implemented WBCM. The original intention of the developers was to evolve the tool into a complete learning management system for release as open-source. However, with the recent trend towards open standards for learning management systems, a path has opened up for developing this tool into a standards-compliant component for use alongside other LMS components.

The paper concludes with a discussion of planned further development of the tool using a web-services model and notes the relevance of recent open standards for learning management systems.

2.        Motivation for a Web-based system

There were several motivations behind developing this system. The work started as a system to ease the handling of laboratory based courses. The requirements, however, turned out to be fairly general and minor additions were required to make the system handle almost any kind of course. We also had the need to handle courses running at a distance at the various extension centres. After developing two versions of this system we decided that another version with comprehensive features was required. These are described in more detail below.

2.1         Laboratory courses

Although not unique to laboratory-based courses, several factors that require significant administration are often concentrated in such courses (especially when there are multiple assignments given throughout the course, each having its own deadline and guidelines for completion). Completed assignments need to be collected, evaluated and marked for assessing students’ progress. Assignments may be given to individuals or groups. To further assess students’ progress examinations and online tests may be conducted. Attendance records may need to be kept and some marks may be awarded for attendance. The marks for each student need to be tabulated and at the end of the course grades need to be distributed. Physical dissemination of material is difficult and involves generating and handling a lot of paper. Keeping a record of the attendance is costly in terms of time. It is also extremely difficult to keep track of individual progress manually. Such a situation is a clear case for the need of automated support through an electronic course management system.

2.2         Distance education

There are additional benefits that may be had from managing a course over the internet using a web-based course management (WBCM) system. Such a system can be highly effective in bridging geographical distance, which is an important concern in India.

In the Indian Institute of Technology, Kharagpur University we run a distance education programme. We have several centres where this programme runs and it has been extremely difficult to manage the programme running over these centres and monitor the progress of students at there centres centrally from our main campus.

Our web-based course management system has provided an excellent solution to this problem. Teachers, too, tend to get geographically separated from the students for other reasons, such as having to travel to conferences. As a result, they either have to curtail their travel or make complex arrangements to deal with the absence. Here again a web based course management scheme has provided useful advantages.

2.3         Development of WBCM

We have already implemented and used three versions of WBCM. Two earlier versions were a success with staff and students, further motivating us to add more features. The packages were used for large classes. Courses run with these packages helped in reducing logistic problems for assignment from near impossible to trivial. Logistics for evaluation were simplified as submissions were available online all the time and transparent evaluation meant more student satisfaction. Dependence on printers was almost completely removed.

The third version, in particular, supports sections within a large class and distributed storage repositories. The earlier versions relied on all the submissions and databases being located centrally. This scheme has its advantages and disadvantages. Centralized data storage takes off all responsibility of storage management from the end users (in the capacity of instructors). However, it does increase the burden of storage on the central server. Also, end users sometimes feel out of control of the submissions of their courses.

Support for sections in the third version enabled common or distinct assignments to be given for separate sections. Also, students may work individually or in groups. This affects the assessment mechanism, but that is supported. Support is also available for moving students between sections.

3.        Architecture of WBCM and technical details

The distributed databases (Postgres) and file (Linux) repositories, the web server (Apache) and the corresponding cgi-scripts and the http clients (tested with Netscape, Konqueror, IE) are the main components of WBCM architecture. To describe the WBCM architecture, shown in Figure 1, we divide it into two parts: Distributed architecture for data storage, and Client-Server architecture for providing the human interface (the web based aspect of the utility). We also give details of the important components: the database design, the cgi-scripts (which form the backbone of the system), the authentication mechanism, the repository directory structure and the distributed storage mechanism.

3.1         Distributed architecture for data storage

WBCM manages course data for many courses and multiple runs of each course.

A schema and directory structure (for storing scripts and assignments) is created for a course run and replicated to manage multiple course runs.

In addition to having an independent database for each course run, a database which we call the “course database” is used for keeping data about all the course runs (list of courses, list of course runs).

Figure 1: Architecture of WBCM package

Thus we have a cluster of database, instead of single database which allows

§                the databases to reside on different hosts;

§                the use of simple common schema for each course except for the “course database”.

For each course run, assignments and the submissions are stored directly as files in the file system, under suitable directory structure, which allows reconstruction of a path to them independent of their content. Other information, relating to courses, students, staff, etc. is also stored in databases. This may be considered as “control” information. Whenever there is a choice between storing information in a file or a database, the later is preferred, as operations on a database are performed at a high level.

Our experience with previous versions of WBCM, which had a centralized architecture for data storage has guided as to adopt a distributed architecture for the same. The following observations were of critical importance during the run of previous versions of WBCM, convincing us of the need to change to a distributed data storage scheme:

§                The disk and database storage requirements grows considerably with increase in the number of courses managed by WBCM.

§                Classes may have very large numbers of students -e.g. for interdisciplinary courses, translating into large storage requirements.

A new distributed architecture was developed to alleviate load on a single host in the third version. Thus avoiding the impact of an increase of courses managed by WBCM creating a bottleneck. WBCM data are stored in multiple hosts as shown in Figure 1. The host used for storing either a database, or a file repository, is decided by the administrator. A database and a file repository may reside on the same host, as shown in Figure 1 where Host-1 has both a Postgres database and a file repository, Host-2 has only a file repository, Host-3 has only a Postgres database. A host may be used for storing data about more than one course run.

3.2         Client-Server architecture for interface access

There are two kinds of CGI resources for WBCM, namely authenticated and unauthenticated. We use an authentication mechanism provided by the Apache web server.

As shown in Figure 1 a web client makes requests via an HTML interface to WBCM generated by Perl scripts on the web server. All the HTML pages of the system are dynamically generated (i.e. when they are requested, the corresponding CGI script is run on the server and result is displayed). This is desirable as up-to-date information must be made available. For authenticated resources, when the web client makes a request, the server sends a response requesting authentication information. The user is prompted to enter their username and password and this information is submitted to the server for verification. If the information is correct, the server sends a response to the original request made by the web client.

To obtain the response for the web client request, the web server executes an appropriate WBCM script, which in turn queries the database and accesses the file repository to generate a dynamic HTML page.

Dynamically generated pages require server resources. The scripts can be executed from different web servers, distributing the server burden. Automatic distribution of the server load is an interesting topic for improving performance of the system. Currently, we are expecting users to move to a different server whenever performance degrades considerably or they may be instructed to use different servers when all (or most of) the possible users are at one place (e.g. during a class test)

3.3         Database design

WBCM manages a huge amount of information. The following entity-relationship diagrams and description of the tables gives an overall picture of the database design for WBCM. The ER diagram in Figure 2 shows relationships that affect online assignment submission. Each assignment comes under an assignment category, which may be an online test, an exam, a lab assignment, etc. Each section should have assignment categories associated with it. Student groups can be made for assignment submission that are under the same assignment category. Student cohorts may be divided into sections and an assignment may require individual and/or group submission.

All the information about each course is distributed between two databases.

Figure 2: Online submission relation.

 

3.4         CGI scripts

CGI resources are distributed among directories to facilitate www authentication. Directories are for admin, faculty, faculty and supporting staff, student and public access. For each course run, a soft link is created to each of above-mentioned directories except the public access directory. The course run directory also stores all the necessary files for www authentication.

The web pages are generated dynamically by querying the database for up-to-date information. A Perl DBI module is used to make connections (remote/local) to Postgres databases. Perl eval statements along with Postgres support for commit and rollback are used for transaction control

3.5         Authentication

User authentication is an integral aspect of such a system. We extensively use the authentication mechanism provided by Apache (based on .htaccess). We do not describe the mechanism used by Apache here. Instead the interested reader is referred to the Apache documentation available at http://httpd.apache.org/docs/.

Use of http authentication requires some pre-planning by the programmer. Planning starts with the identification of different groups of expected user who should authenticate themselves. For WBCM these different groups are “administrator”, “faculty”, “evaluator” and “student”. All the cgi resources used by these groups are kept in their respective directory (i.e. each group has a different directory).

Each course has its own group of “faculty”, “evaluator” and “student”. When a course is started by an administrator, a local course directory is created under the above-mentioned directory as a link. Under these directories a course-specific password file is maintained which contains a user name and encrypted password for each of the group members. In our scheme the password file is maintained by a script, as group members may change. We make sure that for students who already have an account on the system hosting WBCM, the username and password for WBCM authentication is the same. Otherwise the students are given a roll/user name and some initial password automatically. For the current scheme staff should have an account with the system hosting WBCM.

3.6         File repository directory structure

The submission directory structure is shown in Figure 3. In addition to this we have a similar assignment description directory structure. As shown in Figure 3, the submissible directory structure may keep submissions for different runs of courses. That is why the immediate sub directory is named ”course run (1..n)”. This should be the identifier of the course run - in our case, a combination of the course code, year and semester. Classes are divided into sections, requiring a sub directory for each section (sec-1, sec-1..sec-m). For each section we have an assignment category having assignments, giving: category-1..category-o followed by asgn-1..asgn-2 levels of sub directory. Assignments are organized individually or in groups, so submissions are kept under roll and group subdirectories for individual and group submissions respectively. It is possible to distribute the repository over several machines.

Figure 3: Repository directory structure.

 

4.        Key features of WBCM

The purpose of our web-based utility is to provide a simple yet powerful interface for managing courses, along with the flexibility of online submission for the students. The top-level course management access page is shown in Figure 4. The interfaces are either public or protected and they are linked as shown in Figure 5. Note that the users of WBCM are: course administrator, staff (teaching and/or supporting) and students. WBCM has few publicly viewable pages, which are mainly logs of important information pertaining to a course.

The current WBCM has the following features: admin, course table, assignment management, student/staff management, assignment/submission evaluation and submission log. The admin feature allows courses to be added or deleted and initial staff to be assigned to a newly added course. The course table lists all the courses currently availing of the course management facility and also has navigation buttons for staff, students or the submission log of each course. Assignment management allows for the addition, modification and deletion of assignments. Necessary consistency guards are enforced. Student/staff management allows for the addition or removal of staff/student from a course. Students can submit assignments via a submission link in an assignment table which lists all the assignments currently in the course. Assignment evaluation allows staff to evaluate assignments and provide comments or justifications for the evaluation. Submissions may be re-evaluated, keeping a record of older evaluations. A particularly useful feature is the submission log which shows the status of all submissions and evaluations at a glance.

Figure 4: Course Management Web page

Figure 5: Interface navigation diagram.