UW Registration Helper Life Cycle Objectives Review Chris

UW Registration Helper Life Cycle Objectives Review Chris Bradley Group 403 o Last Updated: February 3, 2003 2 -4 -02 UW Registration Helper

Operational Concepts • Current registration resources make it easy to find the class you want • A new system is proposed to allow continuous monitoring of classes – The system will be able to monitor for changes to: • • 2 -4 -02 seat availability classrooms class times instructors UW Registration Helper

System requirements • User requirements: – – – easy selection of classes for monitoring selection of specific aspects of a course to monitor setting for maximum frequency of notifications acceptable battery use an interface for class registration • Network requirements: – No excessive load on datasources • Caching • Use of multiple datasources – server side settings to limit network traffic. 2 -4 -02 UW Registration Helper

System and Software Architecture • A servlet parses data from 3 sources: – the main time schedule pages: www. was…. edu/students/timeschd/<quarter>/<department>. html • provides room, time, and credit information for all SLN in a department. • Supports HTTP range requests – per SLN (schedule line number) information: sdb. admin. wa…. edu/timeschd/public/sln. asp? QTRYR=<qtr>+<year>&SLN=<sln> • Provides room, time, credits, seat availability, enrollment, instructor for a specific sln. – Department summaries: – sdb. admin. wa…. edu/timeschd/public/tsstat. asp? QTRYR=<qtr>+<year>&CURRIC=<dept> • provides seat availability and enrollment for every SLN in a department. 2 -4 -02 UW Registration Helper

System and Software Architecture (cont) • A midlet takes user input and retrieves data from the servlet in one of two potential ways: – A custom text stream protocol • Minimal overhead, data is only transmitted initially and when course information has changed • Must be built from scratch, implementation barriers unknown • Continuous connection may drain batteries – Periodic HTTP get requests • Higher overhead, less responsive • HTTP support is built in and known to work • Non continuous connection may be better for batteries • The midlet will connect directly to the myuw pages for secure course registration. 2 -4 -02 UW Registration Helper

Lifecycle Plan • The system would need to be maintained for compatibility with any future changes to the datasources and registration system. 2 -4 -02 UW Registration Helper

Feasibility Rationale • Demand is questionable – Limited benefits • Immediate response to new openings in a course is often unnecessary – Some classes allow overloading – More space usually opens up later – Data transfer on cell phones is expensive – Not many students have compatible cell phones – Battery use will deter potential users 2 -4 -02 UW Registration Helper

Feasibility Rationale (cont) • Class registration interfaces may not be possible – no built in HTTPS support in J 2 ME – likely University opposition, especially to automated use • Network use goals can be met – under high load, use of the per department data sources and caching will increase efficiency – the system will reduce the number of using browser reloads to monitor a course 2 -4 -02 UW Registration Helper

Recommendation • It is recommended that the project not go forward at this time. – Current cell phone service and battery life are prohibitive to this kind of application – Without official university support, and with likely opposition, the project is doomed to failure. 2 -4 -02 UW Registration Helper