Repositories in CS Courses - An Evolutionary Tale

Edward L. Jones & Clement S. AllenFlorida A&M University

Tallahassee, FL USAejones@cis.famu.edu

ITiCSE 2003 Thessaloniki, GreeceJune 30 - July 2, 2003

7/1/03 ITiCSE2003 2

Outline

Introduction to my Repository / Architecture Evolution of my Repository Why This Approach? Automated Repository Generation User Views - Student / Faculty Technology Transfer Lessons & Impacts Conclusions & Future Work Demo (screen images)

7/1/03 ITiCSE2003 3

Introduction – Basic Idea

Instructor

Get/view file

Submission Submit fileGet/view file

Post grade

Public

Post assignment

Student

Get assignment

7/1/03 ITiCSE2003 4

Course Repository Architecture

.master_schedule

.submitslog

.class_roll

.program_pairs

~course/

bin/RepositoryCommands

Zxxxx

term/

submits/

RCS/

StudentFiles

RCS/

public/

CourseFiles

RCS/

team/

Team Artifacts

Information Hiding!!

Hiding!!

7/1/03 ITiCSE2003 5

Evolution of Repository Concept

Capstone Course (1995 - 1998) Public = Bank of examples, standards, procedures Team = Archive of team project artifacts Submission = On-line tests & homework

Programming Courses (1997 - present) Public = Program stubs and data sets Submission = Automated grading & plagiarism

monitoring

Technology Transfer (2002- )

7/1/03 ITiCSE2003 6

Why This Approach?

Simple, basic functionality.

Extensible to instructor preferences.

Open source -- no license fees.

Legacy -- evolution of author’s system.

Increased chance of technology transfer

Unix a core skill in our environment.

7/1/03 ITiCSE2003 7

Automated Repository Generation

InstallLinkedRepositoryCommands

Zxxxx

~/bin/

Student Account

RepositoryCommands

Zxxxx

~/bin/

Admin Account

CreateGenericRepositoryCommands

Xxxxx

~/bin/

Course Account

Repositories

~term/

InstantiatedRepositoryCommands

Zxxxx

~/bin/

7/1/03 ITiCSE2003 8

Student View

Simple Repository Installation Log into Unix account Type 2 commands

Private read-write store

~course/bin/Z_Install

rehash

Unlimited submissions till deadline

Private back-up of submitted work

7/1/03 ITiCSE2003 9

Student View - Commands

Extended Unix Commands: <ID><type><verb>

Small set of CommandsXSstatus List names of student’s files stored in

repository.

XSmview Display contents of student’s repository file(s).

XSmcopy Copy student’s repository file(s) into the current Unix directory.

XSsubmit Store student’s file into (submission) repository.

XSclean Remove student's file from repository.

XSrestore Retrieve specific version of file from repository.

7/1/03 ITiCSE2003 10

Student View – Assignment Scenario

Program Specification Course with repository Z Program # 3 Required file name: myprogram.cpp

Program Submission / VerificationZSsubmit 3 myprogram.cpp

ZSstatus .cpp

Email notification of program submission

7/1/03 ITiCSE2003 11

Instructor View - Repository Management

Creation (one-time):

~admin/bin/Xrepos_Create

rehash Archival/Initialization (at start of new term):

Za_archive

Za_initialize

Maintenance Patch (as needed):~admin/bin/Xrepos_Patch

Default administrative commands

7/1/03 ITiCSE2003 12

Impact on Courses

Reduced time for program grading (prep)

Consistency across multiple sections

Better record keeping reduces disputes

Increased use of automated grading Instructor MUST write a good specification

Enforcement of naming rules and deadlines

Encourages giving more assignments

7/1/03 ITiCSE2003 13

Technology Transfer - Challenges

Risks Success – More work for me! Failure – Bruised ego, no second chances!

Questions/Doubts Will colleagues think tool is worth trying? Will students accept or sabotage? Will I be able to “sell” the benefits … quickly? Can I convince colleague to ignore pimples?

7/1/03 ITiCSE2003 14

Technology Transfer - Lessons

Goal: Adoption by non-author. Success Keys

Focus on one immediate benefit -- efficiency Be available and willing to help Go the extra mile (customizations) Transfer responsibility to adopter ASAP Document to support evolution Automate to simplify usage Promise the next release!

Adoption stimulates evolution.

7/1/03 ITiCSE2003 15

Conclusions

Student adoption straightforward due to few commands and information hiding.

Adopter customizations evolve to repository defaults (e.g., auto-grading)

Technology transfer is challenging, even with simple tool, within same department.

Repositories reduce faculty workload.

Faculty need hand-holding – to avoid wasted effort!

7/1/03 ITiCSE2003 16

On-Going / Future Work

E-Mail/Web interfaces Flexibility for “registered” students Subject Line = Repository Command

Genericize my grading scripts into repository templates

Menu Interface for Instructor

Repository provides “observation window” into student debugging practices

7/1/03 ITiCSE2003 17

Demo

Student View Installing repository Submitting a program Copying files from repository

Faculty View Creating course repository Adding an assignment Auditing student’s submission history Retrieving submitted programs Applying a repository command patch

7/1/03 ITiCSE2003 18

Student - Installing Repository

7/1/03 ITiCSE2003 19

Student - Submitting an Assignment

7/1/03 ITiCSE2003 20

Student - Late Submission

7/1/03 ITiCSE2003 23

Instructor - Creating Course Repository

7/1/03 ITiCSE2003 24

Instructor - Adding an Assignment

Command: Za_edit_schedule

7/1/03 ITiCSE2003 25

Instructor - Confirming Student Submission History

7/1/03 ITiCSE2003 26

Instructor - Retrieving & Renaming Submitted Programs

7/1/03 ITiCSE2003 27

Administrator - Applying a Command Patch

7/1/03 ITiCSE2003 28

End of Demo

Questions?

Questions?

Interested? Send me email.

7/1/03 ITiCSE2003 29

Other Comparable Approaches?

Email based system

Auto-grading approaches

Commercial (e.g., Blackboard).

Integrated Development Environments (e.g., Visual XYZ)

Unix based system

Few reports of technology transfer.

7/1/03 ITiCSE2003 30

EXTRAS

7/1/03 ITiCSE2003 31

Design Highlights - Simplicity

Unix Development Environment Departmental computing platform Unix a required skill

Information hiding Location of repository Unix RCS provides version/access control Access only through repository commands

Ease of Installation/Maintenance Centralized management Soft links facilitate maintenance

7/1/03 ITiCSE2003 33

Master Assignment Schedule

NUM DESCRIPTION MM DD HH FILENAMES

--- --------------- -- -- -- ------------------

#0# Test0_Program 1 8 24 test0.cpp

#1# Play_Program 6 26 24 test1.java

#3# Add_Program 3 8 17 test3a.cpp add.cpp

#10# Programming_Test 12 1 24 finalprog.cpp

7/1/03 ITiCSE2003 35

Instructor View - Audits

ZSasubmitslog Check/verify submissions by studentor per assignment.

ZSaaudit Prepare reports showing all submittedand graded work per student.

ZSagrdaudit Prepare reports showing scores on allgraded work per student.

ZSapgmaudit Prepare reports showing allsubmission attempts and repositoryholdings per student.

7/1/03 ITiCSE2003 37

Student - Checking Grading Reports

7/1/03 ITiCSE2003 38

Student - Copying Files from Repository

7/1/03 ITiCSE2003 39

MASTER ASSIGNMENT SCHEDULECOURSE: ITiCSETERM: summer2003 NUM DESCRIPTION MM DD HH FILENAMES--- --------------- -- -- -- ---------------------#0# Test0_Program 1 8 24 test0.cpp #1# Test1_Program 8 8 0 test1.java sub1.java#2# LabTest1 8 9 14 lab1.cpp#3# Test2_Project 9 2 24 proj2.java