1 course scheduling software progress presentation december 22, 2004

56
1 Course Scheduling Software Progress Presentation December 22, 2004

Upload: marianna-fisher

Post on 05-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 1 Course Scheduling Software Progress Presentation December 22, 2004

1

Course Scheduling SoftwareProgress Presentation

December 22, 2004

Page 2: 1 Course Scheduling Software Progress Presentation December 22, 2004

2

Customer:

Jed Lippard, Upper School Director,Prospect Hill Academy Charter School

Team [email protected]

Glen Winston Robert McKeever

Steve MoranValdeva Ives

Page 3: 1 Course Scheduling Software Progress Presentation December 22, 2004

3

Agenda• Project Status• Risk Update• Architectural Overview• GUI Walkthrough• Model Overview• Scheduling

– Proof of Concept– Constraint Programming– Technology Alternatives– Drools pros & cons– Drools Example– Scheduling API

• Deployment Plan

Page 4: 1 Course Scheduling Software Progress Presentation December 22, 2004

4

Project Status

Presented by

Glen Winston

Page 5: 1 Course Scheduling Software Progress Presentation December 22, 2004

5

Project Status

Page 6: 1 Course Scheduling Software Progress Presentation December 22, 2004

6

Process Overview• Project Phases: Fall

– Initiation (100% complete)– Analysis (100% complete)– Functional Design (100% complete)– Technical Design (70% complete)

• Project Phases: Spring– Completion of Technical Design– Development– Testing– Deployment

Page 7: 1 Course Scheduling Software Progress Presentation December 22, 2004

7

Process Overview: Technical Design• Key Deliverable of this phase

– Technical Specifications Document• Document all non-trivial classes in the system.• Informative sequence diagrams of key controllers

in the system.• Document and prove algorithm for scheduling

classes.

Page 8: 1 Course Scheduling Software Progress Presentation December 22, 2004

8

Risk Update

Presented by

Steve Moran

Page 9: 1 Course Scheduling Software Progress Presentation December 22, 2004

9

Risks• Scheduling technology implementation – higher

– Advancing Rule Base during semester break– Continuing Research into Production Systems & Constraints– Assigning 50% of team to task

• Scheduling technology choice – moderate– Several well understood alternatives available

• Post-Deployment Maintenance & Support – low to moderate– Specification biased toward currently stated requirements– Will rely on actual implementation

• Added Requirement to schedule individual students – lower– Students primarily move in groups – Believe less involved than class scheduling

• Feature creep – lower– Detailed documentation & customer contact

• Insufficient time - lower– Following regimented process

Page 10: 1 Course Scheduling Software Progress Presentation December 22, 2004

10

Component Overview

Presented by

Glen Winston

Page 11: 1 Course Scheduling Software Progress Presentation December 22, 2004

11

Architectural Overview

View Controller

Model

Scheduler

javax.swingjavax.swing

Scheduler API

State ChangeState Query

Change Notification

View Selection

User Gestures

Update State

Page 12: 1 Course Scheduling Software Progress Presentation December 22, 2004

12

GUI Walkthrough

Presented by

Dee Dee Ives

Page 13: 1 Course Scheduling Software Progress Presentation December 22, 2004

13

Model Overview

Presented by

Glen Winston

Page 14: 1 Course Scheduling Software Progress Presentation December 22, 2004

14

Model Overview

View Controller

Model

Scheduler

javax.swingjavax.swing

Scheduler API

State ChangeState Query

Change Notification

View Selection

User Gestures

Update State

Page 15: 1 Course Scheduling Software Progress Presentation December 22, 2004

15

Subject

name : String

Course

name : Stringsubject : SubjectblocksPerWeekdoubleBlocksPerWeekdepartments : List

Instructor

departments : ListmandatoryAvailability : WeeklyScheduledesiredAvailability : WeeklySchedulemaximumDailyClasses : int

Block DoubleBlock

Department

name : String

WeeklySchedule

days : ListperiodsPerDay

Day

name : Stringperiods : List

Period

day : DaytimePeriod

name : String

Page 16: 1 Course Scheduling Software Progress Presentation December 22, 2004

16

Cohort

students : Listgrade : Grade

Student

firstName : StringlastName : Stringgrade : Grade

SchoolClass

course : Courseinstructors : Listcohorts : Liststudents : List

Grade

name : String

Course

name : Stringsubject : SubjectblocksPerWeekdoubleBlocksPerWeekdepartments : List

Page 17: 1 Course Scheduling Software Progress Presentation December 22, 2004

17

Room

building : Stringfloor : Stringnumber : Stringcapacity : intavailability : WeeklySchedule

Block DoubleBlock

Period

day : DaytimePeriod

name : String

SchoolSchedule

name : StringclassSchedule : ClassSchedule

saveToFile()exportTeacherView()exportStudentView()importStudents()

ClassPeriod

schoolClasses : Listroom : Roomperiod : Periodfixed : booleanscheduled : boolean

ClassSchedule

classPeriods : List

findAvailableRooms(filter)findPeriods(filter)findClassPeriods(filter)

Created by Scheduling Algorithm

Page 18: 1 Course Scheduling Software Progress Presentation December 22, 2004

18

Scheduling Proof of Concept: Project Goal

Presented by

Glen Winston

Page 19: 1 Course Scheduling Software Progress Presentation December 22, 2004

19

Scheduling Proof of Concept: Project Goal

Scheduler Component is highest area of risk in technical design.

Risk Mitigation Plan

• Proof of concept• Two exclusive resources• Hand written algorithm fallback plan

Proof of Concept is complete, we learned

• We were able to create periods in a rules engine.

• We were able to fill periods in a rules engine.

Page 20: 1 Course Scheduling Software Progress Presentation December 22, 2004

20

Scheduling Proof of Concept: Approach

Presented by

Steve Moran

Page 21: 1 Course Scheduling Software Progress Presentation December 22, 2004

21

Scheduling Problem To Solve• Students, Teachers, & Subjects,• in 7 grades, subdivided into cohorts (groups),• into classrooms of various sizes & locations,• with 7 daily schedule blocks,• with a rotating class schedule,• with 81 initial constraints.

Page 22: 1 Course Scheduling Software Progress Presentation December 22, 2004

22

Technology Alternatives• DROOLS – actively being prototyped

– “understandable” XML style rules in java

• JESS – capable, but licensing issues • CLIPS – “lisp style” rules implemented in C• JClips – directly runs CLIPS files in java

– testbed for existing CLIPS.clp example files

• Prolog – inefficient backward chaining• Brute force - inefficient backward chaining

Page 23: 1 Course Scheduling Software Progress Presentation December 22, 2004

23

Rete-based Inference Engine• Declarative programming – “what is”• Forward chaining rules – “data driven”

• Fast in-memory network – “The only algorithm for implementing production rules

whose performance is demonstrably independent of the number of rules.”

• Rules can change without recompiling

Page 24: 1 Course Scheduling Software Progress Presentation December 22, 2004

24

<parameter>

Domain

<condition>

Boolean

<consequence>

java

Rules Working MemoryFacts

Assert

Retract

Modify

Facts Rules

Ordered by Salience

Rete

AlgorithmCollections of Objects

Classes

Rooms

Blocks

In a nutshell, we want to schedule Classes into Rooms with Blocks

Page 25: 1 Course Scheduling Software Progress Presentation December 22, 2004

25

RoomsRooms

Blocks

222

101 - 8AM

101

222

101

101 - 9AM101 - 10AM

222 - 8AM222 - 9AM

222 - 10AM

Before Rule Fires After Rule Fires

<parameter> Room </parameter>

<condition> none </condition>

<consequence>

assert(new Block(room.num,8))

assert(new Block(room.num, 9))

assert(new Block(room.num, 10))

</consequence>

Working

Memory

Page 26: 1 Course Scheduling Software Progress Presentation December 22, 2004

26

room 101 has block at 8

room 101 has block at 9

room 101 has block at 10

room 222 has block at 8

room 222 has block at 9

room 222 has block at 10

Page 27: 1 Course Scheduling Software Progress Presentation December 22, 2004

27

Rooms ClassBlocks

222101 - 8AM

101

Math

English101 - 9AM

101 - 10AM

222 - 8AM222 - 9AM

222 - 10AM

Working Memory

<parameter>

Room

Block

Class

</parameter>

<condition>

block.class = null

class.numStudents < room.capacity

class.isScheduled == false

</condition>

<consequence>

class.isScheduled = true

modify(class)

block.class = class.id

modify(block)

</consequence>

Page 28: 1 Course Scheduling Software Progress Presentation December 22, 2004

28

Scheduling class: 5 in room: 101 at: 8

Scheduling class: 15 in room: 101 at: 9

Scheduling class: 6 in room: 101 at: 10

Scheduling class: 8 in room: 222 at: 8

Scheduling class: 16 in room: 222 at: 9

Scheduling class: 20 in room: 222 at: 10

Page 29: 1 Course Scheduling Software Progress Presentation December 22, 2004

29

Scheduling Proof of Concept: Challenges

Presented by

Bob McKeever

Page 30: 1 Course Scheduling Software Progress Presentation December 22, 2004

30

Constraint Programming Problem• Scheduling is an NP Complete Problem.• Requires polynomial time to solve. • Could be solved trivially by using a systemic

search. • Generate and test until a solution is found.

Page 31: 1 Course Scheduling Software Progress Presentation December 22, 2004

31

Constraint Programming Solutions • Backtracking.• Backtracking with Forward Checking. • Backtracking with Forward Checking and

Heuristics. • Tic, Tac, Toe as an example

Page 32: 1 Course Scheduling Software Progress Presentation December 22, 2004

32

Drools Negatives • Very little documentation.• Does not have all the same features as

CLIPS. (At present “not” is not supported.)• Can not directly convert from CLIPS code to

Drools code. • Small user community.• Just out of Beta.

Page 33: 1 Course Scheduling Software Progress Presentation December 22, 2004

33

Drools Negatives (Con’t)• Team members have no experience with

Drools programming.• 3 Team members have no experience with

programming expert systems.

Page 34: 1 Course Scheduling Software Progress Presentation December 22, 2004

34

Drools Positives • Handles the constraints well. Much better

than nested if statements. • Open source.• Seems to have a lot of “buzz”.• Did I mention it was free?

Page 35: 1 Course Scheduling Software Progress Presentation December 22, 2004

35

Drools Positives (Con’t) • We are starting to get up to speed with it.

Now have some working examples.• May be able to post our work as an example

on their web site to have others carry on. May help on maintenance issues.

Page 36: 1 Course Scheduling Software Progress Presentation December 22, 2004

36

Scheduling Proof of Concept: Drools Sample

Presented by

Bob McKeever

Page 37: 1 Course Scheduling Software Progress Presentation December 22, 2004

37

<?xml version="1.0" encoding="UTF-8"?>

<!--

The definition of a RuleExecutionSet is not within the scope of the JSR 94.

The implementation given in this file is written for the reference

implementation. A rule engine vendor verifying their rule engine should

modify this file to their specific needs.

-->

<rule-set name="Scheduler"

xmlns="http://drools.org/rules"

xmlns:java="http://drools.org/semantics/java"

xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"

xs:schemaLocation="http://drools.org/rules rules.xsd

http://drools.org/semantics/java java.xsd">

<java:import>java.util.*</java:import>

<java:import>org.drools.examples.schedule.model.Block</java:import>

<java:import>org.drools.examples.schedule.model.ClassInfo</java:import>

<java:import>org.drools.examples.schedule.model.ClassToSchedule</java:import>

<java:import>org.drools.examples.schedule.model.Room</java:import>

<java:import>org.drools.examples.schedule.model.RoomCourseRelation</java:import>

<java:import>org.drools.examples.schedule.model.RoomInfo</java:import>

<java:import>org.drools.examples.schedule.model.SchoolClass</java:import>

Page 38: 1 Course Scheduling Software Progress Presentation December 22, 2004

38

<!--

Create the blocks

-->

<rule name="generate blocks" salience="40">

<parameter identifier="roomInfo">

<class>RoomInfo</class>

</parameter>

<java:consequence>

System.out.println("Making block " + roomInfo.number);

drools.assertObject(new Block(roomInfo.number, 8));

drools.assertObject(new Block(roomInfo.number, 9));

drools.assertObject(new Block(roomInfo.number, 10));

</java:consequence>

</rule>

Page 39: 1 Course Scheduling Software Progress Presentation December 22, 2004

39

<!--

Schedule.

-->

<rule name="schedule" >

<parameter identifier="roomInfo"> <class>RoomInfo</class> </parameter>

<parameter identifier="block"> <class>Block</class> </parameter>

<parameter identifier="classInfo"> <class>ClassInfo</class> </parameter>

<java:condition> block.schoolClass == 0 </java:condition>

<java:condition> classInfo.numStudents &lt;= roomInfo.capacity </java:condition>

<java:condition> classInfo.isScheduled == false </java:condition>

<java:consequence>

classInfo.isScheduled = true;

drools.modifyObject(classInfo);

block.schoolClass = classInfo.id;

drools.modifyObject(block);

System.out.println("Scheduling class: " + block.schoolClass +

" in room: " + block.room + " at: " + block.time);

</java:consequence>

</rule>

</rule-set>

Page 40: 1 Course Scheduling Software Progress Presentation December 22, 2004

40

Scheduling API

Presented by

Bob McKeever

Page 41: 1 Course Scheduling Software Progress Presentation December 22, 2004

41

Scheduling API

Scheduler

View Controller

Model

javax.swingjavax.swing

Scheduler APIScheduler API

State ChangeState Query

Change Notification

View Selection

User Gestures

Update State

Page 42: 1 Course Scheduling Software Progress Presentation December 22, 2004

42

Page 43: 1 Course Scheduling Software Progress Presentation December 22, 2004

43

Deployment Plan

Presented by

Bob McKeever

Page 44: 1 Course Scheduling Software Progress Presentation December 22, 2004

44

Deployment Plan Goals

• Keep customer informed. • Get buy in from customer’s IT administrator. • Create Windows executable.• Provide physical program to the customer.• Provide documentation to the customer. • Give the program the Windows look and feel.

Page 45: 1 Course Scheduling Software Progress Presentation December 22, 2004

45

Deployment Plan Actions• Use launch4j to create a Windows executable

with Splash screens and icons.• Meet with customer’s IT administrator.

Request computer that has been backed up. • Create set up program using Wise for install

and uninstall. Burn onto a CD.• Test!, Test!, Test!

Page 46: 1 Course Scheduling Software Progress Presentation December 22, 2004

46

Deployment Plan Actions (Con’t)• Develop documentation and detailed

installation instructions.• Provide professional documentation and CD.• Meet at Customers Site for installation. • Provide a Jar file version on the Web site of a

generic scheduler. (One that does not have the customer’s logos on it and is not dependent on Windows to run.)

Page 47: 1 Course Scheduling Software Progress Presentation December 22, 2004

47

Q & A

Page 48: 1 Course Scheduling Software Progress Presentation December 22, 2004

48

Backward & Forward Chaining

Presented by

Steve Moran

Page 49: 1 Course Scheduling Software Progress Presentation December 22, 2004

49

Two Approaches

• Backward Chaining– Imperative based systems – how to– Queries fact space for goal ‘truth’– Mechanism used in most most logic programming, i.e. Prolog

• Forward Chaining– Declarative based systems – what is– Triggered on fact space information– A data driven technique to reach inferences from a set of facts

Page 50: 1 Course Scheduling Software Progress Presentation December 22, 2004

50

Backward vs. Forward Chaining• Backward-chaining means that no rules are fired upon assertion of new

knowledge. When an unknown piece of knowledge is detected all rules relevant to the knowledge in question are fired until the question is answered, if possible. Thus, backward chaining systems normally work from a goal state back to the original state.

• Forward-chaining implies that upon assertion of new knowledge, all relevant rules are fired exhaustively, effectively making all knowledge about the current state explicit within the state. Forward chaining may be regarded as progress from a known state (the original knowledge) towards a goal state(s).

• The branching factor (the number of considerations at each state) may vary between forward and backward chaining and thus determine which method is most efficient.

Source: http://ai.eecs.umich.edu/cogarch0/index.html

Page 51: 1 Course Scheduling Software Progress Presentation December 22, 2004

51Source: http://www.cise.ufl.edu/class/cap6685sp03/Lectures/ES-CH4b.pdf

PatientDiagnosis

Page 52: 1 Course Scheduling Software Progress Presentation December 22, 2004

52

Backward vs. Forward Chaining• Backward-chaining means that no rules are fired upon assertion of new

knowledge. When an unknown piece of knowledge is detected all rules relevant to the knowledge in question are fired until the question is answered, if possible. Thus, backward chaining systems normally work from a goal state back to the original state.

• Forward-chaining implies that upon assertion of new knowledge, all relevant rules are fired exhaustively, effectively making all knowledge about the current state explicit within the state. Forward chaining may be regarded as progress from a known state (the original knowledge) towards a goal state(s).

• The branching factor (the number of considerations at each state) may vary between forward and backward chaining and thus determine which method is most efficient.

Source: http://ai.eecs.umich.edu/cogarch0/index.html

Page 53: 1 Course Scheduling Software Progress Presentation December 22, 2004

53Source: http://www.cise.ufl.edu/class/cap6685sp03/Lectures/ES-CH4b.pdf

Page 54: 1 Course Scheduling Software Progress Presentation December 22, 2004

54Source: http://www.cise.ufl.edu/class/cap6685sp03/Lectures/ES-CH4b.pdf

Page 55: 1 Course Scheduling Software Progress Presentation December 22, 2004

55Source: http://www.cise.ufl.edu/class/cap6685sp03/Lectures/ES-CH4b.pdf

Page 56: 1 Course Scheduling Software Progress Presentation December 22, 2004

56

Backward vs. Forward Chaining• Backward-chaining means that no rules are fired upon assertion of new

knowledge. When an unknown piece of knowledge is detected all rules relevant to the knowledge in question are fired until the question is answered, if possible. Thus, backward chaining systems normally work from a goal state back to the original state.

• Forward-chaining implies that upon assertion of new knowledge, all relevant rules are fired exhaustively, effectively making all knowledge about the current state explicit within the state. Forward chaining may be regarded as progress from a known state (the original knowledge) towards a goal state(s).

• The branching factor (the number of considerations at each state) may vary between forward and backward chaining and thus determine which method is most efficient.

Source: http://ai.eecs.umich.edu/cogarch0/index.html