The Scheduler Sub System

General:

The Scheduler tracks customers in the system and finds cabs for them when appropriate.

Preconditions:

A Model is needed to communicate customer data to the Scheduler and to communicate data between the Scheduler and the CabConsoles.

Responsibilities:

· Store customer data until the customer is picked up

· Be able to perform, on customers within the system:

o Adds

o Lookups

o Removals

· Schedule a customer to a cab when appropriate and communicate the ride request to the Model

· Ensure that the system will not stall when communicating or looking for cabs

Architecture:

Use case descriptions:

Use case number 1:

· Model sends a Customer object to the Scheduler

· Scheduler sets the customer’s zones by:

o Converting the addresses to Zone Ids

o Retrieving the specified zone from the Model

· Scheduler sets the customer’s status to WAITING

· Scheduler adds the customer to its CustomerCollection object

· Scheduler estimates ETA by cases:

o If the pickup time is more than 1.1 * min_ETA in the future, return the pickup time as the ETA. The 1.1 factor is used when scheduling cabs as well. It is a ‘fudge-factor’: it allows cabs to be scheduled slightly before they are needed. Feedback on this would be appreciated.

o Else, if there is a cab available in the pickup zone, return min_ETA + pickup time

o Else, return average_wait * number_of_customers_waiting + min_ETA + pickup time

Use case number 2, Scheduler side:

· Every ‘so often’ (currently 10 seconds for testing purposes), SchedulerTask calls the Scheduler’s scheduleAllCustomers function. The default time is set in the SchedulerTask class. This could become a manager-defined parameter.

(The Scheduler has a number of nested function calls here; for simplicity, I will treat them as one)

· Scheduler creates an array to store zones that have no cabs in them. This is used to ensure fairness among customers – if a customer is passed over for pickup because the zone is devoid of cabs, and then a cab becomes available in that zone, it would not be fair to schedule a new customer with a later pickup time to that new cab.

· Scheduler retrieves high priority queue from the CustomerCollection. This is copied to ensure that no synchronization errors occur. The high priority queue consists of all customers who have been removed from the normal waiting queue due to the fact that their pickup time is soon or has passed.

· Scheduler iterates through the queue as follows:

o Dequeue the first element

o Attempt to schedule by:

· Check the empty_zones list for the pickup zone:

· If in list, fail scheduling & enqueue customer

· Check to see if there is a cab in the customer’s zone

· If no cabs, add zone to empty_zones list, fail scheduling, and enqueue customer

· Set customer status to COMING

o Add CabCommunicationTask to perform communication operations

· Scheduler finds new customers to schedule by:

o Get reference to customer with soonest pickup time from CustomerCollection

o Check if pickup time is within 1.1 * min_ETA from now

· If so, remove customer from CustomerCollection

· Else, stop looking for more customers

o Attempt to schedule by:

· Check the empty_zones list for the pickup zone:

· If in list, fail scheduling, set customer status to HIGH_PRIORITY & enqueue customer

· Check to see if there is a cab in the customer’s zone

· If no cabs, add zone to empty_zones list, fail scheduling, set customer status to HIGH_PRIORITY and enqueue customer

· Set customer status to COMING

o Add CabCommunicationTask to perform communication operations

Use case 2, CabCommunicationTask side:

· Empty cab is found within zone

· Cab is checked to ensure that it is not being communicated with

· Cab is added to ‘communication_limbo’ list

· Cab is communicated with via the Model’s communication function

· Response is looked at:

o If reject, call cabRefusedRide in Model

o If accept:

§ Set customer status to SCHEDULED

§ Set customer cab

§ Set cab’s customer

§ Call cabIsScheduled in Model

· Find new cab, if customer is not scheduled

Use case 3:

· Customer object is passed to Scheduler with valid LastName & Phone fields

· Scheduler looks up customer in CustomerCollection

· Scheduler returns customer object found, with valid Status & Cab fields

Use case 4:

· Cab ID passed to Scheduler by customerPickup method

· Scheduler removes customer assigned to cab from CustomerCollection

· Customer is now not referred to within the Scheduler – totally removed

· Scheduler returns true if the customer was found