Deliveria - Developer Guide

Every Driver keeps track of a Schedule class, which is backed by a naturally sorted, TreeSet of EventTime objects.

Before a new EventTime is added to the schedule, the method checks against the TreeSet of EventTime to ensure the addition will not result in overlapping EventTime in the schedule. This operation works in logarithmic time thanks to the tree structure.

In order to better utilise a driver, we implement a method to suggest an earlier alternative time slot in a schedule. When adding a time to a schedule, this method will:

In order to enforce the optimised scheduling method above, the program will block every assign command that has a suboptimal proposed time, unless the user uses the force argument. Moreover, the assign and free command are the only commands that modify the Driver and EventTime attributes of a Task, so that all drivers will have an optimised schedule, unless force assign is used.

The following activity diagram summarizes the checks happened when user executes an assign command.

After the above checks has passed, assign command will:

Similarly, calling free command will:

The ScheduleOptimizer class is a component in the Logic Layer, that have access to the entire model, in order to gather information about all drivers and tasks. The object instantiates with Model and Task, and is designed to be discarded after use.

It will return a Candidate object, which is a wrapper class of javafx.util.Pair<Driver,Optional<EventTime>>. This can be used by the caller to assign the task to the suggested driver at the suggested time.

It exposes a convenient ScheduleOptimizer#start method, to start optimizing, based on the rules implement in the Optimizer. The start method uses a functional pipeline approach, by piping the Optional output of the rules. It is implemented so that, the next stage of the pipeline will only be triggered when this stage of the pipeline fails to find a candidate (ie. returns an empty Optional).

The Optimizer consists of two rules as of now: ScheduleOptimizer#driverEarliestFit and ScheduleOptimizer#prioritizeSameCustomer. Both methods are nullary functions that return a Optional<Candidate>.

Any new rule just need to follow the same method signature as the existing rules, and be added to the pipeline in the ScheduleOptimizer#start method.

The Add Delivery Task feature adds a new task into a task list.
It uses the AddTaskCommand, which extends Command, to add a Task into the TaskManager. AddTaskCommandParser is also utilised to parse and validate the user inputs before sending it to AddTaskCommand to execute. 'AddTaskCommand' requires the following fields: Task, customerId. The attributes of Task is as follows:

As seen in the above class diagram, driver and eventTime are optional fields that are not mandatory when adding a task. They will be assigned subsequently using assign command. (Refer to Assign feature) The mandatory fields for users are: 'description', 'date' and 'Customer'. After the validation is completed, AddTaskCommand will fetch Customer using the customerId through the CustomerManager. A unique id will also be allocated to the task for differentiation.

The following sequence diagrams show how the add task operation works:

Generation of PDF documents is handled by PdfManager. It is responsible in taking the essential inputs required to generate the document. The following inputs are required to generate a PDF document such as a PDF Delivery Order:

The PdfManager utilizes PdfCreator to create and save the PDF document as well as formatting the layouts. It is implemented with the help of an external library, iText7.

To show how the PDF document is generated, generating PDF Task Summary will be used as an example for this showcase. The following sequence diagram shows how the user command savepdf is being executed and handled.

Notice that only the filepath and the date of delivery is needed when calling generateTaskSummaryPdf. This is because only the saving location of the PDF file and the date, where the task summary will be based on, are the only fields needed for the PdfManager. The rest of the components, such as fetching of the tasks, will be handled in the Model while the formatting will be handled by PdfCreator.

The following sequence diagram shows how the model interact with PdfManager to generate the PDF task summary.

The PdfWrapperLayout provides a outer canvas to encapsulates all the layouts. The following layouts are mainly what makes up the task summary:

The following activity diagram shows what happens when a user executes the savepdf command:

The undo/redo mechanism is facilitated by VersionedAddressBook. It extends AddressBook with an undo/redo history, stored internally as an addressBookStateList and currentStatePointer. Additionally, it implements the following operations:

These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() respectively.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedAddressBook will be initialized with the initial address book state, and the currentStatePointer pointing to that single address book state.

Step 2. The user executes delete 5 command to delete the 5th person in the address book. The delete command calls Model#commitAddressBook(), causing the modified state of the address book after the delete 5 command executes to be saved in the addressBookStateList, and the currentStatePointer is shifted to the newly inserted address book state.

Step 3. The user executes add n/David …​ to add a new person. The add command also calls Model#commitAddressBook(), causing another modified address book state to be saved into the addressBookStateList.

Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoAddressBook(), which will shift the currentStatePointer once to the left, pointing it to the previous address book state, and restores the address book to that state.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redoAddressBook(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the address book to that state.

Step 5. The user then decides to execute the command list. Commands that do not modify the address book, such as list, will usually not call Model#commitAddressBook(), Model#undoAddressBook() or Model#redoAddressBook(). Thus, the addressBookStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitAddressBook(). Since the currentStatePointer is not pointing at the end of the addressBookStateList, all address book states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/David …​ command. This is the behavior that most modern desktop applications follow.

The following activity diagram summarizes what happens when a user executes a new command: