CourseForge
Chris Schlechty, Kenneth Kuan, Scott Clifford, Guanyu Chu,
Kansu Dincer, Sarah Tachibana, Andy Hou
System Design Specification and Planning Document
Draft 1.09
paneApril 25, 2007
CSE 403 - CSRocks Inc.
Revisions
Version
Primary Author(s)
Description of Version
Date Completed
1.09
All
Initial draft.
04/25/07
System Architecture
1.Introduction
CourseForge relies on a LAMP architecture. User and course information is stored in a MySQL database, which is accessed via AJAX XMLHttpRequest calls to PHP functions which make queries and convert the result to XML. The XML data is parsed and put on screen via Javascript/DOM modification.  The database itself is populated using both data given to us by UW, as well as data collected using a Java screen scraper to parse professor ratings information.
The modular breakdown of CourseForge follows: prior to interacting with the scheduling system, users must login. The Login module manages authentication, new user registration, and password recovery. The rest of the interface is represented through a Student module, which contains a VisualSchedule and a Search module. The VisualSchedule module manages individual Tabs, while the Search module handles queries and addition of courses to the schedule.
2.
Implementation view
3.Design view - UML class diagram
4.Process view – UML sequence diagrams
5.
Database Schema
6.
Design Alternatives and/or Assumptions
We considered a few alternative representations and implementations of CourseForge before settling on the current version with our customer. These included:
∙Information Gathering: We weren’t originally sure whether UW would provide us the course information necessary to implement our system, so we put thought into a screen scraper module that would periodically parse the online course catalog. This would of course be more inconvenient, but for the time being UW has given us a copy of a quarter’s worth of course information. We assume that, should CourseForge see widespread use, UW will continue to give us access to the necessary information
∙Schedule Representation: Given the limited screen estate available to us, we tried to think of other ways to represent the visual schedule. One was have a separate graph for each day. Times would be aligned horizontally, and each row would consist of a class, with a horizontal bar representing that class’ duration. However, this view doesn’t allow for a holist
ic week view, and students are presumably already used to the day-per-column view used in the current Visual Schedule, which we decided to stick with.
General assumptions for this architecture include:
∙We assume that Javascript, AJAX, and PHP will all support our object-oriented design. Javascript in particular is a more procedural language, and may require extra effort to fit into the rest of the framework.
∙We assume that Google Web Toolkit will provide us with coherent modules to piece together. GWT makes creating AJAX applications much easier, but depending on the resulting modules, it may be difficult to test and/or modify in the future.
Development Plan
1.Team Structure
Courseforge will be divided into three main teams for the work up to the beta release: test t
eam, AJAX team, and serverside/database team.  There is member crossover between teams, and the serverside/database team will all be assimilated into the other teams once their work is complete.

The test team is responsible for unit testing, user testing, and system testing, though everyone is expected to run prelim tests on their own code.  This team is composed of: Kansu, Scott, Kenneth, and Andy.  The AJAX team is responsible for java coding, HTML, CSS, and other UI-related features.  It is composed of: Scott, Kansu, Andy, and Kenneth.  Finally, the database team is responsible for the PHP coding and the setup/maintenance of the database.  It is composed of: Chris and Guanyu.  Chris is primarily database; Guanyu is primarily PHP.