Curriculorum : A Computer Science Approach to Curriculum Management - - PowerPoint PPT Presentation

curriculorum a computer science approach to curriculum
SMART_READER_LITE
LIVE PREVIEW

Curriculorum : A Computer Science Approach to Curriculum Management - - PowerPoint PPT Presentation

Introduction Requirements Design Implementation Conclusions and Future Work Curriculorum : A Computer Science Approach to Curriculum Management Bob Lewis School of EECS Washington State University October 10, 2008 Bob Lewis Curriculorum


slide-1
SLIDE 1

Introduction Requirements Design Implementation Conclusions and Future Work

Curriculorum: A Computer Science Approach to Curriculum Management

Bob Lewis

School of EECS Washington State University

October 10, 2008

Bob Lewis Curriculorum

slide-2
SLIDE 2

Introduction Requirements Design Implementation Conclusions and Future Work

Alternate Title

When Computer Scientists Confront the Dark Side (i.e., become administrators).

Bob Lewis Curriculorum

slide-3
SLIDE 3

Introduction Requirements Design Implementation Conclusions and Future Work

Outline

Introduction Requirements Design Implementation Conclusions and Future Work

Bob Lewis Curriculorum

slide-4
SLIDE 4

Introduction Requirements Design Implementation Conclusions and Future Work

Motivation

◮ In 2005, I became Program Coordinator for Computer Science

at the WSU Tri-Cities campus.

◮ I have many of the responsibilities of a Director (whom I

report to on the main campus in Pullman), but none of the

  • authority. (Seriously, I do like the job.)

◮ I needed to manage over time a moderately-sized amount of

curriculum-related data from a variety of sources for planning and reporting.

◮ My approach: Treat the whole thing as a software design

problem.

Bob Lewis Curriculorum

slide-5
SLIDE 5

Introduction Requirements Design Implementation Conclusions and Future Work

A Clarification on Terminology

◮ A class is a set of attributes and behaviors assigned to an

  • bject in an object-oriented system.

◮ A course is a unit of instruction which is (or was) listed in a

catalog.

◮ A session is an instance (but not in an object-oriented sense)

  • f a course. (It “has-a” course. In fact, it may have several.)

Bob Lewis Curriculorum

slide-6
SLIDE 6

Introduction Requirements Design Implementation Conclusions and Future Work

My Goal Today

I’ll talk about the system I developed, but what I really want to emphasize is how I developed it rather than the system itself, so that, as computer scientists, you can build your own if the need arises. So let’s start with the requirements...

Bob Lewis Curriculorum

slide-7
SLIDE 7

Introduction Requirements Design Implementation Conclusions and Future Work

Provide Reports to...

Students What are the course offerings and instructors for next semester? The Bookstore What instructors are teaching what classes? The Registrar What instructors are teaching what classes when? Payroll What adjunct instructors are to be paid how much? Webmaster What are the course offerings for the next two years? Accreditors What courses have been taught for the last seven years? and make sure they’re all consistent!

Bob Lewis Curriculorum

slide-8
SLIDE 8

Introduction Requirements Design Implementation Conclusions and Future Work

Planning Functionality

Some information is for my own use in planning:

◮ inform the (EECS-wide) Curriculum Committee ◮ associate adjuncts with courses they can teach ◮ maintain a record of instructor performance

Bob Lewis Curriculorum

slide-9
SLIDE 9

Introduction Requirements Design Implementation Conclusions and Future Work

Correct for Limitations of My University’s DBMS

WSU has a fairly standard online course management system (“RONET” – Registar’s Office NETwork), but...

◮ I have read-only access. (This is probably a good thing.) ◮ There’s no provision for planning future semesters. ◮ Their schema doesn’t quite do what I need:

◮ missing information on adjuncts, degree programs, other

institutions

◮ one instructor listed per course ◮ same telecourse treated as separate sections on separate

campuses

◮ differing special topics treated as separate sections

◮ The course catalog is sometimes wrong or out-of-date.

Bob Lewis Curriculorum

slide-10
SLIDE 10

Introduction Requirements Design Implementation Conclusions and Future Work

Unusual Requirements

Compare to the usual student-course-instructor-department example given in a lot of database books (to name a few):

◮ All special topics courses have the same number. ◮ Prerequisites are problematical:

◮ may be at different institutions (i.e. community colleges). ◮ may allow “one of” prerequisites.

◮ Some instructors are regular faculty, some are adjuncts. ◮ Each course has a “coordinator”, which may be a regular

faculty member or a committee.

◮ Multiple courses may be taught at the same time in the same

place.

◮ Some data may be missing at a given time (e.g. during

planning).

Bob Lewis Curriculorum

slide-11
SLIDE 11

Introduction Requirements Design Implementation Conclusions and Future Work

Additional Requirements

◮ help me learn about the curricula (hence the name

curriculorum)

◮ allow for incremental year-to-year modifications ◮ provide a way to check for inconsistencies (typos, misspellings,

etc.)

Bob Lewis Curriculorum

slide-12
SLIDE 12

Introduction Requirements Design Implementation Conclusions and Future Work

Is There a Commercial Product That Does This?

There are course management systems (e.g. BlackboardTM) and larger, university-wide (usually custom) systems exist, but I wanted something in between. Such a commercial system is unlikely (see above requirements) but this was irrelevant, because:

◮ I wanted to learn and design the schema, not adapt someone

else’s (assuming that was even possible).

◮ I was not in a position to evaluate how well such a product

would fit my schema when I started.

Bob Lewis Curriculorum

slide-13
SLIDE 13

Introduction Requirements Design Implementation Conclusions and Future Work

Why Not Use a DBMS?

◮ DBMS’s (the ones I know) focus on the wrong thing: tables

with fields of (fixed-width, usually) strings.

◮ None of the classes I envision (instructors, courses, etc.) have

more than about 100 instances.

◮ No GUI required. (Text editors don’t scare me!) ◮ No client-server architecture required. (One user: me.)

This was more of a data structuring problem than a database problem.

Bob Lewis Curriculorum

slide-14
SLIDE 14

Introduction Requirements Design Implementation Conclusions and Future Work

Why Python?

◮ I knew it and wanted to get better at it. ◮ Lots of handy features:

◮ object orientation (classes, inheritance, and polymorphism) ◮ defaultable arguments to functions and methods ◮ built-in sequences (lists and tuples) ◮ excellent string operations (arbitrary length!) ◮ very readable (as we’ll see) ◮ name errors (objects, keywords, etc.) detected by interpreter ◮ comments (!)

◮ No reason why your favorite language (Java, C#, C++, Lua,

Perl, Ruby, etc.) couldn’t work as well. Try it!

Bob Lewis Curriculorum

slide-15
SLIDE 15

Introduction Requirements Design Implementation Conclusions and Future Work

The curriculorum Module

This ∼650-line Python module contains no objects, only class definitions:

◮ curriculum-related classes:

Campus Course Degree Department GraduateArea Institution Instructor Season Semester Session Staff Timeslot

◮ curriculum-related exceptions:

CourseIsNotGraduate NotQualified ImproperPayment

◮ and a simple (L AT

EX) table generation package: Table Column

Bob Lewis Curriculorum

slide-16
SLIDE 16

Introduction Requirements Design Implementation Conclusions and Future Work

UML Class Diagram

curriculorum is installed as a Python module and contains no

Bob Lewis Curriculorum

slide-17
SLIDE 17

Introduction Requirements Design Implementation Conclusions and Future Work

Directory Layout

An important part of the implementation is getting the directory structure right... curriculorum is installed as a Python module and contains no institution-specific data (mostly classes).

Bob Lewis Curriculorum

slide-18
SLIDE 18

Introduction Requirements Design Implementation Conclusions and Future Work

Report Generation

◮ curriculorum generates (L AT

EX) tables.

◮ Tables may be included in L AT

EX documents (see example).

◮ curriculorum can also generate the GraphViz “dot” format

(e.g.) for prerequisite dependency graphs.

Bob Lewis Curriculorum

slide-19
SLIDE 19

Introduction Requirements Design Implementation Conclusions and Future Work

Example: Dependency Graph

Here is the dependency tree (DAG, to be precise) curriculorum automatically derives from prerequisite data:

MTH 231 MTH 232 PHY 201 MTH 243 MTH 155 MTH 157 MTH 233 MTH 234 CS 161 CS 162 MTH 095 PHY 2011 PHY 202 CS 260 PHY 2021 PHY 203 CptS223 CptS224 CptS317 EE234 MTH 246 CptS322 MTH 154 CptS260 CptS355 CptS360 CptS450 CptS451 CptS452 EE214 CptS422 Engl402 CptS460 Stat360 Math172

This includes courses at both WSU and Columbia Basin (Community) College.

Bob Lewis Curriculorum

slide-20
SLIDE 20

Introduction Requirements Design Implementation Conclusions and Future Work

A Guided Tour

Let’s examine some of the files first-hand...

Bob Lewis Curriculorum

slide-21
SLIDE 21

Introduction Requirements Design Implementation Conclusions and Future Work

Conclusions

◮ Curriculorum has more than justified its development time. ◮ It has been in place since 2005, and has adapted to curricular

changes very well.

◮ Side effect: Developing curriculorum has made me a better

programmer.

Bob Lewis Curriculorum

slide-22
SLIDE 22

Introduction Requirements Design Implementation Conclusions and Future Work

Future Work

◮ documenting student specializations (e.g. games, networks,

software engineering) and showing recommended schedules

◮ additional community college transfer equivalencies (i.e. new

Institutions)

◮ HTML output (esp. for student perusal)

Bob Lewis Curriculorum