Clone this wiki locally
RPI Planner is sponsored by the Rensselaer Center for Open Source, generously funded by Sean O’Sullivan, Class of 1985.
Motivation & Relevance
Many students at RPI do not follow their intended major’s plan of study template due to a variety of circumstances. Some students arrive with AP credit, others are working towards co-terminal degrees, and some just choose to take different courses. However, it can be quite time-consuming and error-prone to develop your own customized plan of study that properly satisfies prerequisites, ensures you are taking classes in the semester(s) they are offered, and achieves your goals. This is a problem that is much easier to solve with a hybrid human/computer effort, with the computer handling the rules and the human deciding what courses to take.
RPI Planner will allow students at RPI to bend their plans of study more and still stay within graduation requirements. RPI is trying to encourage more students to seek co-terminal degrees, but the steps to get from freshman year to the end are not so clear. With RPI Planner, students will feel more confident in their plans of study. This will help more students seek co-terminal degrees and graduate on time, which is a great benefit to the school.
More successful engineering graduates with higher degrees means a stronger engineering workforce in the United States. Many, including Dr. Shirley Ann Jackson, have commented that we need more competent engineers, and RPI Planner will contribute one small bit of effort to making that happen.
I have presented RPI Planner to the Rensselaer Center for Open Source twice during the Fall 2008 semester. These presentations are available via slideshare.net.
Java is my language of choice for this project for two reasons: I’m already quite competent in it, and it provides a cross-platform, interactive runtime. I considered writing a pure web application, but this restricts interactivity and forces me to use DHTML (terrible) or Objective-J (questionable performance). Instead, the application will initially run standalone and eventually run hosted as an applet with the ability to save plans of study to a database on the server. This way students aren’t responsible for keeping track of their own files over long periods of time.
However, I like Ruby a lot. JRuby provides a great way to embed Ruby into a Java application, and I hope to use it in some way in this project. It seems like using it for the rule definitions of course dependencies might make sense, but that may be better served by a static database.
See Domain Model as well
The two major parts to the application are the course database and the user interface. The UI needs to be flexible, responsive, and intuitive. It would be nice to import the course database from some material RPI has, but for the early versions it will be defined manually. The course database contains basic information like department and course number, but it also must contain rules for how courses depend on each other. These rules must be maintained by the application in the process of creating a plan of study, but it also must be possible to bend them if need be.
A full rules engine is unnecessary in this application because there are a limited set of types of rules (prerequisite, corequisite, spring only, etc) and the course definitions are tied directly to them. All you really need is an object graph with the rules as the links between courses. To decide how the plan of study works, walk the graph. This graph can easily be serialized to XML for persistent storage. There are actually two possible graphs to serialize: the course database and the customized plan of study. The course database holds a number of Course objects connected by Rule objects. The plan of study contains “instances” of Course objects, and possibly other data.
I’d like to try my hand at implementing a domain-specific language using JRuby for this project, but I’m not sure I see an opportunity to do so yet. The application must be usable by average students, and they have no interest in “programming” anything, no matter what the language is. However, there is the matter of the course database. This must be a pluggable backend, because it will hopefully be imported in the future, but for now it has to be hand-entered by somebody. This seems like a good opportunity for a DSL at first glance, but users are going to need to be able to edit courses and the rules that govern them from the GUI interface. No DSL opportunity there.