JERPA: A Distance-Learning Environment for Introductory Java Programming Courses*

Transcription

1 JERPA: A Distance-Learning Environment for Introductory Java Programming Courses* David Emory and Roberto Tamassia Department of Computer Science Brown University Providence, RI {demory, rt}@cs.brown.edu Abstract This paper describes a Java-based distance-education tool, called the Environment for Remote Programming Assignments in Java (JERPA), for use in computer science courses with Java programming assignments. JERPA reduces the demand on the university's computing infrastructure while providing instructors with an easy system to deploy and distribute assignments, and allowing students greater flexibility as they work on the assignments. JERPA yields immediate advantages to traditional oncampus CS courses and provides a key functionality to programming courses offered in a distance-education setting. 1 Introduction As the popularity of distance education rises, a number of software applications have been developed to address the need for tools that port existing course content to an online setting. Examples include Georgia Tech's eclass project, which allows for streaming, annotated broadcasts of lectures over the Internet [1], and the eorrmaercial systems Blackboard [2] and WebCT [5], which port to the web course materials such as syllabi, lectures, assignments, and tests. * Work supported in part by a gift from MicrosoR Research However, most of these existing tools are designed with traditional course formats in mind, and they typically do not support specialized formats such as computer science courses that rely on programming assignments rather than traditional written assignments. JERPA was specifically developed to serve Java programming courses whose assignments are not handled effectively by traditional distance-education tools. While Java has emerged as the language of choice for many CS 1 and CS2 courses, there are clear drawbacks as novice programmers experience the language for the first time. Writing even the simplest program requires knowledge of the inner workings of the Java development and lruntime environment, such as the package-based code organization and the virtual machine environment settings (e.g., CLASSPATH). Typically, these details, though important to the successful compilation and execution of Java programs, are not the focus of introductory computer science courses. Usually, for Java-based CS1 and CS2 courses, every effort is made to hide technical issues such as CLASSPATH management and package-based code organization from the students. Indeed, the goal is to teach the principles of object-oriented programming without overwhelming the students with the technical idiosyncrasies of Java. For example, this can be accomplished through a series of student account login scripts and assignment "stencils" (i.e., partially coded classes that are provided for students as they begin an assignment), which are continuously maintained by the teaching assistants and other system administrators. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires pr/or specific permission and/or a fee. SIGCSE'02, February 27- March 3, 2002, Covington, Kentucky, USA. Copyright 2002 ACM /0~ $5.00. The above approach works well in the context of a Unixbased programming lab, where course administrators can control and customize all aspects of the students' programming environment. However, this s~ategy does not transfer well to environments outside of this main lab, where students are ler with two options: recreating the lab 307

2 environment, which is usually beyond the technical sophistications of students, or remotely logging in to a lab workstation, which requires the installation of complex applications on the student's computer (e.g., an SSH client and an X server), and is effective only if a reliable and continuous broadband connection to the lab is available. JER_PA was developed to provide greater flexibility for students wishing to work outside the default on-campus computing lab environment, while minimizing the technical obstacles otherwise faced by students working at home. A programming course that uses JERPA offers three major advantages: 1. The demand for campus/departmental computing resources is diminished as more students have the option of working outside of the lab. The reduced strain on campus resources has been identified as a key benefit for universities that use distance-education technology [4]. 2. Students are no longer confined to the campus network when working on CS assignments, ideal for those who live off-campus or travel frequently. The increased flexibility (in terms of both schedule and computing platform) has also been cited as a major student-side advantage in previous CS1 distance-education experiments [3]. 3. Instructors can design programming assignments that incorporate a variety of support material, such as class libraries, suites of test data, and auxiliary applications, without having to worry about the complications of distributing the material to the students and explaining to the students how to install it. JERPA has been fully implemented and is available for download from The rest of this paper is organized as follows. In Section 2, we overview the functionality and architecture of JERPA. Classroom experience with JERPA over three semesters is discussed in Section 3. Future research directions are addressed in Section 4. 2 System Overview JERPA is a web-based system in which the assignments of a course (specifically, Java programming assignments) and their associated support material (class libraries, test data, and auxiliary applications) are made available online by course administrators, allowing students access to the material from any Java-enabled computer with Internet access. Standard HTTP connections are used for data transfer. 2.1 The Student Client The Student Client (Figure 1) is the software that enables students to interact with the online content maintained by the system. A stand-alone Java application, the client provides a simple graphical interface with which students can effectively manage their work for one or more courses that support JERPA. A student can "subscribe" to a course by providing the client with the HTTP address of the repository of course materials. Assignments and related!1 Figure 1: The Work Manager frarne is the key GUI component of the Student Client. 308

3 information for that course will then be displayed each time the client is run. The ability to download and install assignments represents the core functionality of the JERPA Student Client. For each course to which a student is subscribed, the client will display all available assignments that have been provided by the course administrators. Students may perform a number of operations for each assignment: Install - This operation must be performed before any other operation can take place. Installing an assignment on a student's machine involves copying all relevant materials from the server to the student's local hard drive. This includes not only the assignment "stencil," if applicable, but also any support code packages that may be necessary to run the assignment. Compile - This function will attempt to compile all Java files contained in the assignment install directory, using the local version of Sun's JDK compiler. The client will handle any special compiler settings, such as support libraries that must be appended to the CLASSPATH. Run - This operation invokes the local installation of the Java virtual machine to execute a student's compiled code. Again, the client handles all runtime options and parameters. Run Demo - If course administrators decide to include a working demo of the finished program with the assignment, the application can be invoked at home using this function. IDE Export - This operation is used to export an assignment to third-party Integrated Development Environments, such as WebOain, VisualAge, and CodeWarrior. Prepare Handin - When students have finished coding an assignment, this operation is used to compress their code into a single ZIP file, which is suitable for either "handing in" their finished assignment or for transferal to a different platform for testing. The client's most powerful functionality takes place behind the scenes. When an assignment is installed on the student's machine, the following steps are executed to ensure that the assignment's original runtime environment is accurately recreated on the student machine.. The first step is to copy basic assignment properties from the HTTP server to the client machine. These properties include the assignment package name, the package's "main" (executable) class, and any runtime arguments (other than CLASSPATH, which is handled separately). These properties are stored online as an XML file, and an XML file is also created locally for each installed assignment. 2. After basic assignment information is in place, the next step is to check that all up-to-date versions of all required support code packages are in place locally (each assignment may specify an arbitrary number of required support packages in its properties XML file). Some background on the environment's support code management system is necessary, as it is one of JERPA's more sophisticated features. 3. The support package "library" is the online collection of all support packages used by a group of one or more courses. Seeing as many assignments may share the same support package(s), the library is maintained as an entity separate from the collection of courses, thereby eliminating the possibility of multiple copies of the same package being downloaded for multiple assignments that depend upon it. Each library "entry" (a specific support code package) has a distinct text key, which is used as its identifier in both the library itself and in any assignments that reference it. 4. When the client encounters a request for a specific support code package while installing an assignment, it first checks to see if the package has already been installed locally for a previous assignment. If so, the client simply checks that the local copy is as recent as the online version (if not, the more recent version is downloaded), and proceeds to the next request. If the requested entry is not found locally, the client creates a new local entry by downloading the package (typically a JAR file) from the course server. A local XML file is used to keep track of which library entries have been installed on the student machine. 5. Upon installing any required support packages, the client must then create the assignment's source directory and code structure on the student machine. A subdirectory is created for the assignment source, into which any "stencil" code (if provided) is unpacked. Once the above steps are complete, the client has copied all necessary information from the server to the local machine, and the student is ready to begin work on the assignment. Students may use any application they like to edit their code, though it is expected that they will not move the code to a different location on the filesystem. Since third-party class libraries are sometimes updated by their authors (often the course administrators) after students install a dependent assignment, precautions must be taken by the client to ensure that students are using up-to-date versions of all support code. As part of the "startup" process whenever the client is run, the timestamp of each local support code library entry is checked against that of the "master copy" of the entry on the course server. Should 309

4 a more recent version be discovered online, the entry is automatically copied to the local machine. Students also have the option of invoking this feature at any time when the client is running via a menu command. 2.2 The Administrator Client In addition to the student client, another soflware tool is included with the environment. Course instructors and administrators define the assignments and their support material, and install them on the JERPA server using the JERPA Administrator Client. While custom-defined XML files are used to store and transfer information regarding courses, assignments, and support packages from the JERPA server to the Student Clients, the Administrator Client makes any knowledge of XML on the part of course administrators unnecessary. The Administrator Client (Figure 2a) provides an intuitive graphical interface for the management of course resources. Specifically, the Administrator Client handles the following environment components: Courses (Figure 2c) Administrators may create an unlimited number of courses for storage on a particular JERPA server. While a course is essentially a collection of assignments, the client also allows for the specification of supplemental course information (such as instructor/professor info, home page URL, a text description, etc.). Assignments (Figure 2b) For each assignment, the instructor may specify stencil code, class libraries, and other auxiliary information (runtime arguments, etc.). Support Library (Figure 2d) Administrators may use the client to package auxiliary material such as test data, images, JAR files (among other supported formats) into support library entries. "Requests" for these entries may then be specified for dependent assignments. Upload Options - Since upload procedures vary widely among platforms, custom upload scripts may be written and invoked from the client. (a) The Administrator Client Interface - Overview.....'- ['.. ~ ~=.=*'....,=:" :..'..... ": ~... :.. 1 i-;.:" ~ ;... ~...:.ill::.!::... ;~'' :..; :I!~:~:::~ :.=!.i::::." J (b) The New/Edit Assignment Dialog or,mmizltm,::.." : ~~ctm:...: :.: :~'.~:.!.TeJm:.. :=~,..: ::.,:~ Bro'~~.~. ~ ] Univ. ~.. = T. Roberto R~bu~ ~ ~ Tamas~a B m w~ n Sprlng H,Dn~.Pa~],e LIRL; ".. " i.. "... '= " :... " : f ~'e ~. ~ ulc a u rse.~c ~,016 CC~eD,~.ii~llc, rc.... "......:... :. nlrc, duce~ funcler'r~nial ~chl~lques for probierri so,,/irlg by cernpl.~tel'll~al are elevant to I"~o~. areas of cornputer SgglellCe, both lheoreticel end aploii~d. ~lgoriti)ms "and Oala struc!ures for so#.ing, ~arching, fjraph problerr~,.:m~ leo~nal.ri~ problems are ccversd. Prograr'm~np assignrr~.n!; conform with the.f ~.,_,~::=~:=:-: ~.. i~.~:... ~-:1:~-!...:...:..=...:: :~: (e) The New/Edit Course Dialog (d) The New/Edit Library Entry Dialog Figure 2: Examples of GUIs from the Administrator Client 310

5 3 Classroom Experience JERPA has been used successfully with two courses at Brown (CS2, and more recently, CS1) over the past two academic years. The environment made its debut in the spring of 2000 with the Data Structures and Algorithms course. Typical assignments involve student completion of partially-coded algorithm and data structure classes, with code templates as well as TA-written testing and visualization utilities provided as a basis for student work. The JERPA assignment representation model handled this format well. The pre-defined data structure templates could easily be adapted to the JERPA assignment "stencil" model, and the supporting utilities were also integrated into assignment packages to allow for easy deployment and testing of student work at home. When introduced in CS2, JERPA was a new software utility that had never been tested with students, so a small subset of the course's enrollment was recruited to take part in a semester-long "trial run" of the environment. These students volunteered to use JERPA on their home machines and in a special Windows lab rather than work in the department's Solaris-based laboratory. Several course TA's were assigned to this group to provide technical assistance. The response to the environment was generally positive. At the end of the semester, students who participated in the experiment were surveyed for their opinions. The general sentiment was that once technical issues had been resolved, the environment provided an attractive alternative to the department's standard lab-based setup. Students appreciated the flexibility in work environment offered by JERPA, and respondents seemed eager to see the environment expanded to other courses and platforms. In the fall of 2000, a more refined version of the software was introduced for use with the CS1 course. For this course, JERPA was provided as an optional alternative to the computing lab, but there was no organized group of users as was the case in the spring. Though usage was somewhat limited, those that did try the environment were pleased with its operation, and some students used it as their primary means of completing assignments throughout the semester. Students who used JERPA cited several advantages to the environment in a questionnaire distributed at the end of the semester. Many students enjoyed being able to work in the comfort of their own rooms, even if they lived on campus and had the computing lab as an option. In addition, students who lived off-campus appreciated the stand-alone nature of the environment (the only other option for off-campus students, remote login, requires that a constant connection be kept open to the departmental servers). Most recently, in spring of 2001, the environment was again used with CS2. This time JERPA was the default interface not only for home users but also those who chose to work in the lab - a Solaris version of the Student Client was unveiled specifically for this purpose. Under this approach, students were provided with a common interface for assignment management, regardless of their location and platform. 4 Future Directions The environment described in this paper is still relatively new, and its use has so far been confined to a single institution. Several additions are being considered that would not only improve the effectiveness of the environment but also make it more flexible and thus more appealing to potential users at other institutions. A first direction for future work is support for user mobility. While it is designed to run on any networked PC, JERPA is best suited for students who do most of their work on a single machine (regardless of location). Ideally, we would like to add "roaming-profile" support, similar to systems used for web-based and online file storage. Students would be given secure accounts on a centralized file server, and whenever they run the Student Client, their account data (including all current coursewnrk) would be copied to the local machine. Once the session is complete, the updated local data would be copied back to the server. Another goal is to support languages other than Java. The concepts and architecture of JERPA are applicable to other languages used in programming courses, such as C/C++. References [1] Abowd, G. D. "Classroom 2000: An Experiment with the Instrumentation of a Living Educational Environment." IBM Systems Journal, Special issue on Pervasive Computing, Vol. 38, No. 4, (1999), [2] Blackboard. [3] Carrasquel, J. "Teaching CS1 on-line: the Good, the Bad, and the Ugly." Proc. 30 th SIGSCE Tech. Syrup. Computer Science Education, (1999), [4] Preston, J.A. and Wilson, L. Offering CS1 Online: Reducing Campus Resource Demand while Improving the Learning Environment. Proc. 32 "~ SIGSCE Tech. Symp. Computer Science Education, (2001), [5] WebCT