DeliveryMANS - Developer Guide

The main class containing the states of the data in the app is UndoHistory. The history is represented as a list of states. It includes the following methods:

ModelManager contains an UndoHistory, and exposes its functionality via similarly named methods. When undo() or redo() of ModelManager is called, it sets its own data to that returned by the respective methods of UndoHistory.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step. The model data mentioned below encapsulates the data stored in the model (such as the restaurant, customer, and deliveryman data).

Step 1. The user launches the application for the first time. The UndoHistory will be initialized with the initial address book state, and the current state pointer pointing to that single model data state.

Step 2. The user executes the delete 5 command to delete the 5th customer in the address book. After each command, LogicManager calls Model#notifyChange(), causing the modified state of the data after the delete 5 command executes to be saved in the history list, and the current state pointer is shifted to the newly inserted model data state.

Step 3. The user executes add u/David …​ to add a new person. LogicManager calls Model#notifyChange() again, causing another modified state to be saved into the history list.

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

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redo(), which shifts the current state pointer once to the right, pointing to the previously undone state, and restores the data to that state.

Step 5. The user then decides to execute the command list. If a command does not modify the data, it will not be stored in the undo history as UndoHistory checks for equality with the previous state. Thus, the history list remains unchanged.

Step 6. The user executes clear, which calls Model#notifyChange(). Since the current state pointer is not pointing at the end of the history list, all model data states after the current state pointer will be purged. We designed it this way because it no longer makes sense to redo the add u/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:

This section discusses current and possible alternative methods to design the undo/redo function.

The autocomplete mechanism is facilitated by the KeyListener and a Trie, a tree-like abstract data type (ADT). The KeyListener passes the current input text in the input command box to the TrieManager via LogicManager#getAutoCompleteResults(). The TrieManager calls Trie#autoCompleteCommandWord() and a sorted list of matching commands is passed back to the CommandBox and is displayed on the Ui via a dropdown box below the user input command box.

The underlying data structure used is a directed Graph with the Trie as a Node and HashMap<Character, Trie> to represent all outgoing edges. The Keys in the HashMap are Characters in the command words while the Values are the Tries containing the subsequent Characters in the command words. Each Trie contains a List<String> of command words, which is returned when Trie#autoCompleteCommandWord() is called.

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

Step 1: You launch the application. The TrieManager initializes the respective Tries with their context-specific command words using Trie#insertCommand(). The Trie adds each Character of the input String and new Tries into the HashMap<Character, Trie>, as well as the command word into the List<String>, recursively as illustrated by the activity diagram below.

Step 2: You want to add an order to the database, however are uncertain how to spell the command and type in ‘order’. The KeyListener passes the String in the CommandBox to the Trie via the LogicManager and TrieManager. The trie searches for relevant commands and pass them as a list back to the CommandBox via Trie#getAutoCompleteCommandWord(), Trie#search() and Trie#getAllCommandWords(). The ‘Ui’ displays the relevant results in a dropdown box below the user input command box.

Step 3: You can now complete the command you want by entering the relevant command shown in the dropdown box.

Below are a few design considerations of the autocomplete commands feature.

Listed are the implementations of each command. The sequence of command execution for Orders is as follows: the LogicManager receives input from the user and calls UniversalParser#parseCommand(). The UniversalParser calls the respective OrderCommandParser#parse() to create new OrderCommand objects. The object is passed back to the LogicManager, and executed through OrderCommand#execute(). The ModelManager is used for the storing of changes to Orders (if any), and the CommandResult is passed back to the LogicManager to be displayed on the Ui for the user.

Add command: -add_order

The add command adds an order to the ModelManager and UniqueOrderList. The UniversalParser invokes AddOrderCommandParser#parse(), which parses the target customer, restaurant, food and quantity from a String into Name and Integer objects.

Only valid customer, restaurant, food and quantity are allowed. This validation is done through accessing UniqueCustomerList and UniqueRestaurantList through ModelManager#getFilteredCustomerList(), ModelManager#getFilteredRestaurantList() and calling their respective isValidName() methods. Food validity will be checked through retrieving the respective using Restaurant#getMenu() and Menu#isValidName().

Duplicated Order will be checked for using ModelManager#hasOrder() and is then added to the UniqueOrderList via ModelManager#addOrder().

Delete command: -delete_order

The delete command deletes an Order from the ModelManager and UniqueOrderList by a specified index. The UniversalParser invokes DeleteOrderCommandParser#parse() and user input is used to get the index of the Order to be deleted.

Edit command: -edit_order

The edit command edits an Order in the UniqueOrderList of the ModelManager by its specified ORDERNAME. The UniversalParser invokes EditOrderCommandParser#parse() which parses the target customer, restaurant, food and quantity (if present) from a String into Name and Integer objects.

Only valid customer, restaurant, food and quantity are allowed. This validation is done through accessing UniqueCustomerList and UniqueRestaurantList through ModelManager#getFilteredCustomerList(), ModelManager#getFilteredRestaurantList() and calling their respective isValidName() methods. Food validity will be checked through retrieving the respective using Restaurant#getMenu() and Menu#isValidName().

Valid edition of Orders will be checked through AddOrderCommand#isValidOrder().

Assign command: -assign_order

The assign command assigns an unassigned Order to a random available deliveryman in the UniqueOrderList of the ModelManager by its specified ORDERNAME. The UniversalParser invokes AssignOrderCommandParser#parse() which parses the target Order from a String into a Name object.

The deliveryman will then be allocated using ModelManager#getOneAvailableDeliveryman().

Complete command: -complete_order

The complete command completes an Order that is already assigned by its specified ORDERNAME in the UniqueOrderList of the ModelManager. The UniversalParser invokes CompleteOrderCommandParser#parse() which parses the target Order from a String into a Name object.

Validation will be done through checking the Name of the assigned deliveryman to ensure that it is not unassigned, as well as checking the completion status of the order using Order#isCompleted().

It also updates the restaurant and its quantity through ModelManager#getFilteredRestaurantList() and Restaurant#updateQuantity().

List command: -list_order

The list command lists all orders currently in the ModelManager. The UniversalParser creates a new ListOrderCommand object, which changes the Context of the ModelManager to Context.GLOBAL.

This then updates the Ui to display the order list.

Below are a few design considerations of the Order manager class.

The statistics feature is primarily managed by the StatisticsManager, which has access to the status of every deliveryman in the database through the 3 status lists - lists of available deliverymen, unavailable deliverymen and delivering deliverymen respectively. The StatisticsManager obtains these 3 status lists from the StatusManager and passes it to the Analyzer to compute the relevant data, which in turn returns a filled StatisticsRecordCard containing the computed statistics.

From the status lists, the Analyzer computes two data:

With this structure, it implements the following operation:

This feature requires a high degree of interaction between the Status component and Statistics component of DeliverymenDatabase. This interaction of the relevant classes are illustrated in the class diagram below.

The DeliverymenDatabase acts as an agent for both components to parse information around. This helps to maintains a clear separation of concerns to carry out different functions.

The following sequence diagram shows how the stats operation works:

As seen in Figure 10, for every use of the stats command, a RecordCard object is created. The Analyzer will take in the status lists and the RecordCard to compute and record the results onto the RecordCard. Subsequently, it will return the edited `RecordCard to the StatisticsManager.

The Tag of the Customer is related to the Tag of the Restaurant. If an Order has been added to the database, the Tag of the Restaurant will be added to the Tag of the Customer. If the Customer has multiple Orders, the Tag that will be shown on the CustomerCard will be the highest two Tags. This is the main process on how the application automatically tags the customers.

An activity diagram below shows the automated tagging process when adding an order:

Another function called changeMainTag() is used to change the main Tags of the Customer to show on the CustomerCard. The activity diagram below shows how the application determines the top two Tags:

Aspect: Method of editing Customer's Tags

We chose to go with the first alternative as Customer class will have lesser dependency with other classes when editing tags. In addition, displaying the Customer's order history will only require Customer to access the OrderDatabase to get the list of orders. Both of these requirements together still makes the Customer class have lesser dependency with other classes compared to implementing the second alternative that makes the Customer class have dependencies with every Order related classes.

Aspect: Method of storing Tags

We chose to go with alternative 1 as we believe speed is more important to the user and sacrificing memory space is the better choice.

Model:

In addition to the filteredRestaurantList that contains all the restaurants in the restaurant database, ModelManager now contains a editingRestaurantList, which holds and allows access to the single restaurant currently under EditMode.

When user inputs the editmode INDEX command:

Logic:

The Logic for EditMode is facilitated by Context enum type, which contains the following constants: GLOBAL, CUSTOMER, RESTAURANT, DELIVERYMEN and EDITING. It determines the Context the application is in, as well as the commands the user can access. It is contained inside LogicManager as an attribute. EditModeCommand is only accessible in Context.RESTAURANT, and entering a valid EditModeCommand will change the Context to Context.EDITING.

The following class diagram shows the relevant structure of Logic and Parser:

When the user inputs a command:

The following activity diagram summarises what happens when the user enters a command:

When user inputs the editmode INDEX command:

UI:

Commands that change the UI will either:

as the second parameter of the CommandResult returned by the command.

When MainWindow receives the CommandResult, it will extract out either the command class or Context from CommandResult and make changes to the UI accordingly via the function call MainWindow#changeDisplay(Context context) or MainWindow#changeDisplay(Class commandClassName).

When user inputs the EditModeCommand:

The following sequence diagram summarises how the EditModeCommand changes the UI: