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