Delino - Developer Guide

The insert feature allows the user to insert an incoming delivery order into the list using the command line.

The order consists of : Transaction ID, Name, Phone, Address, Email, Delivery Timestamp, Warehouse location, CashOnDelivery

The order also consists of two optional fields that can be added:

The overview of the InsertCommand Activity Diagram is shown below:

After the user calls the insert command, the code will check if the command has all the compulsory prefixes present. The code will throw a ParseException when there are missing prefixes. After that is checked, it will check if the new order added is a duplicate (The Order is already inserted into the application). It will throw a CommandException when the user tries to insert a duplicate order. Otherwise, it will insert the order and prints a success message to the user.

The following diagrams shows the overview of the InsertCommand Class Diagram:

The above class diagram shows the structure of the InsertCommand and its associated classes and interfaces. Some methods and fields are not included because they are not extensively utilised in InsertCommand; such as public static fields and getter/setter methods.

The above class diagram shows the structure of the InsertCommandParser and its associated classes and interfaces. It describes all the class dependencies of the InsertCommandParser class. Some methods and fields are not included because they are not extensively utilised in InsertCommand; such as public static fields and getter/setter methods. As shown in the diagram above, the InsertParser make use of methods from classes such as using the getValue method from the ArgumentMultimap class.

Here is the sequence diagram for the Insert Command as shown below:

The arguments of the insert command will be parsed using the parse method of the InsertCommandParser class.
The InsertCommandParser will tokenize the arguments parsed in using the tokenize method of ArgumentTokenizer class which returns the tokenized arguments. Using the tokenized arguments, the Parser will check if the arguments parsed in matches with the tokenized arguments using the arePrefixesPresent method.

There are two scenarios :

LogicManager will call the execute() method of this InsertCommand object. In the execute() method, it will use the Model class to call hasOrder method to check for duplicates, if it is a duplicate, the order will throw a CommandException which indicates that there is a duplicate order in the OrderBook already. Else, it will successfully inserts the new order using addOrder method. Finally, it return a new CommandResult object, containing a String that indicates a successful insertion.

List feature allows the user to see all the orders from both Delivery Orders and Return Orders.

The user can enter list to display all the orders. Besides that, the user can also input done to display all delivered orders and undone to display all orders that are not delivered.

The above activity diagram shows the logic and the path execution when the list command is executed. There are only three correct syntax available for ListCommand:

The code will check if the input is one of the three mentioned above. If the input is not one of the three, it will cause the code the throw an error message to the user.

The structure of the List Feature is as shown below:

The above class diagram shows the structure of the ListCommand and all its associated classes and interfaces. The ListCommand has dependencies on the Model class as it uses the two methods from it :

There are other variables and strings not shown in this Class Diagrams as they are either static methods or variables.

The sequence diagram for the list command is shown below:

The user first calls the command list.

The LogicManager will call the parseCommand method of DelinoParser, which then passes the second argument into the ListCommand object. This object will then be ultimately returned to the LogicManager. Next, the LogicManager will call the execute(model) method using the ListCommand object. In this method, it wil use the Model object to call the methods : updateFilteredOrderList and updateFilteredReturnOrderList. Since in this case, the argument is empty, the predicate that is parsed to the two methods will always result to true, which means to list everything from the order book and return book. When completed, the execute(model) will return a CommandResult object to the LogicManager, indicating that the command execution is a success.

The clear feature was implemented as a ClearCommand in the logic package.
The clear feature allows the user to remove the orders and return orders by input one command line.

The execution path of the clear command is shown below:

After user enter the clear command, the ClearCommandParser will run the following two checks:

If either one of the conditions occurs, exception will be thrown and the error message will be display to the user. Afterward, the new ClearCommand object will be executed.

During the execution of the clear command:

The following diagrams shows the overview of the clear command Class Diagram:

In the ClearCommand class, there are also some static messages for the different input command the user has key in:

In this section, the interactions between objects when clear command is executed will be display in the Clear Command Sequence Diagram below:

The above sequence diagram illustrate how the clear Command is being processed when the user inputs clear -f to force clear all of the orders and return orders without any prompt.

After the user input. the arguments passed to the clear command will be parsed by the ClearCommandParser class
If the given arguments are valid, a new ClearCommand object will be returned.

In ClearCommandParser, there will be two validation checks:
1. Ensure the flag is one of the three flags: -f, -o and -r
2. Ensure the arguments do not have both -o and -r flags.

After the two validation checks, the flag will be added into HashSet, flags which will then passed to the new ClearCommand object created by ClearCommandParser and it is being returned to the LogicManager. The LogicManager will start to run the execute the clear command, which will be shown in details in below diagram:

After LogicManager call the ClearCommand#execute(model), the clear command will update the model by pass a new OrderBook object and a new ReturnOrderBook object to Model. The Model will then update its own orderBook and returnOrderBook. In addition, the clear command will pass back a new CommandResult object with the success message in it to the LogicManager at the end of the execution.

The delete feature allows the user to delete orders in either the order list or return order list.

The delete feature was implemented as a DeleteCommand in the Logic package.

The delete command has the following format:

In this section, you will learn more about the execution paths for the delete command.

There are four possible execution paths for the delete command

In this section, you will learn more about the relationships between objects related to the delete command.

In the DeleteCommand class, there are also static strings present that represent the various possible messages.
For some of the message strings, there are placeholder %s strings used for including dynamic input
These messages are the following:

In this section, you will learn more about the delete command and its inner workings.

The sequence diagram below shows the interactions for a delete command execution of delete -o 1.
This indicates that the first order should be deleted from the order list.

The arguments passed to the delete command will be parsed by the DeleteCommandParser class.
If the given arguments are valid, a new DeleteCommand object will be returned.
In this class, invalid arguments will result in a ParseException.
Two checks will be done for the arguments:

When the LogicManager runs the execute() method of DeleteCommand, DeleteCommand will first check the list to delete from.

The deleteFromOrderList(model) method of DeleteCommand will then be called and the filtered order list will be obtained from the getFilteredOrderList() method of the model.

The specified order at INDEX 1 will be deleted using the deleteOrder(order) method in the model.

A new CommandResult will be created and returned to the LogicManager.

The sequence diagram below shows the interactions for a delete command execution of delete -r 2.
This indicates that the second order should be deleted from the return order list.

The arguments passed to the delete command will be parsed by the DeleteCommandParser class.
If the given arguments are valid, a new DeleteCommand object will be returned.
In this class, invalid arguments will result in a ParseException.
Two checks will be done for the arguments:

When the LogicManager runs the execute() method of DeleteCommand, DeleteCommand will first check the list to delete from.

The deleteFromReturnList(model) method of DeleteCommand will then be called and the filtered return order list will be obtained from the getFilteredReturnOrderList() method of the model.

The specified return order at INDEX 2 will be deleted using the deleteReturnOrder(returnOrder) method in the model.

A new CommandResult will be created and returned to the LogicManager.

The delivered function allows the user to mark orders or return orders as delivered after delivering an order or a return order.

The delivered feature was implemented as the DeliveredCommand in the logic package.
The delivered function requires a valid FLAG and a valid INDEX.
i.e. delivered INDEX FLAG

The FLAG can either be '-o' or '-r', which indicates which list (order list or return order list respectively) to mark the parcel from. The FLAG is only valid when either '-o' and '-r' is used. All other inputs will be regarded as invalid.

The INDEX is a positive integer that determines which order or return order to be marked as delivered. The INDEX is only valid if it is a positive integer and if it is not bigger than the size of the order list or return order list, depending on the FLAGthat is provided. For instance, if the '-o' FLAG is provided, the INDEX should not be greater than the size of the order list.

The above activity diagram shows the logic behind the DeliveredCommand which is determined in the DeliveredCommandParser class when the user inputs the command word delivered to activate the delivered feature.

The above class diagram shows the structure of the DeliveredCommand and its associated classes and interfaces. Some methods and fields are not included because they are not extensively utilised in DeliveredCommand; such as public static fields and getter/setter methods.

The sequence diagrams for the delivered command are shown below.

The arguments typed into Delino by the user will first be done by the execute method in LogicManager. After which, an DelinoParser object will be created to parse the input which is determined by the command word via the parseCommand method. In this case, it is the delivered command word that will be parsed.

Then, a DeliveredCommandParser object will be created to parse the arguments after removing the command word delivered from the user’s input. Based on the command word delivered, a DeliveredCommand object will be created.

Subsequently, the parseCommand method in LogicManager will continue to create a CommandResult based on the validity of the user’s input; which is determined by the execute method in DeliveredCommand.

The execute method of DeliveredCommand will first check if a valid FLAG is present in the user’s input. If the FLAG is not valid, a CommandException will be thrown to the user to tell him/her that their input was invalid and tell them the format which their input should follow.

If a valid FLAG is present, this will trigger the processDeliveryOfOrder method in DeliveredCommand which will check if a valid INDEX is present in the user’s input.

If the INDEX is not valid, processDeliveryOfOrder method will throw a CommandException to the user; telling him/her that their input was invalid and the format that their input should follow. i.e. delivered FLAG INDEX

If both FLAG and INDEX are valid, an Order or ReturnOrder object will be created based on the FLAG. The INDEX will determine which order or return order to take from the order list or return order list respectively using the appropriate getter method. The Order or ReturnOrder object will be checked to see if it was delivered using the checkIfOrderWasDelivered(model) method.

If the Order or ReturnOrder was already delivered, this will call the updateOrderList(model) or updatedReturnOrderList(model) method respectively in DeliveredCommand and a new instance of CommandResult will be created to tell the user that the order or return order was delivered.

If the Order or ReturnOrder was not delivered, this will call the deliverAndUpdateOrderList(model) or deliverAndUpdateReturnOrderList(model) respectively in DeliveredCommand. In these methods, the particular Order or ReturnOrder will be retrieved from the model using the getFilteredOrderList() or getFilteredReturnOrderList() method. Based on the retrieved Order or ReturnOrder, a new Order or ReturnOrder with the delivered delivery status will be instantiated using the createDeliveredOrder or createDeliveredReturnOrder methods respectively.

Then, the setOrder or setReturnOrder method will be called to replace the original Order or ReturnOrder object respectively in model. The deliverOrder or deliverReturnOrder method will be called to to set the delivery status of the object to delivered. Then, the updateFilteredOrderList() method or updateFilteredReturnOrderList() method to update the list in the model.

Based on the new updates, a new CommandResult object will be instantiated to print the message success to the user.

The edit feature was implemented as EditCommand in the Logic package.

edit feature format : edit INDEX FLAG ORDER_ATTRIBUTE_PREFIX/NEW_VALUE [ORDER_ATTRIBUTE_PREFIX/NEW_VALUE]

The edit feature allows the user to edit any field except delivery status of the order or the return order. However, user must provide a FLAG and INDEX.
FLAG to indicate which parcel type to edit; -o and -r FLAG to represent Order or Return Order respectively.
INDEX to indicate which parcel the user wants to edit.
The list of the different parcel fields are listed in Appendix E: Glossary.

The above figure illustrates the execution path of edit command when performed by the user.

Input when received, will be parsed by the DelinoParser. DelinoParser will check if command word matches any features command word.
In this feature, the command word is edit. If no command word is detected, a exception class should be generated for displaying of error message. CommandException is used in this feature to achieve that function.

Once validated, user input is once again parse and check for validity. At this step, if user have provided input not matching the valid edit format, an exception class is thrown.
Furthermore, if NEW_VALUE is invalid an exception should be thrown as well.
ParseException class is used in this scenario.

Some invalid NEW_VALUE:
1) Editing delivery date or return date to the past.
2) Change the transaction id of one parcel to match another parcel.
3) Violation of any field(s) restriction.

A correct input will prompts Delino to carry out the rest of the steps according.
1) Checking of the FLAG
2) Edits the the parcel. 3) Display edit success message.

The class diagram above depicts the structure of EditCommand. As per any Command class, EditCommand needs to extend the abstract class Command.
Information that are left out in this class diagram are the common messages used in EditCommand.

The above figure illustrates the important interactions of EditCommand when the user successfully edit the first displayed order name to Alice.

The handling of breaking down the user input is done in the EditCommandParser class which is called upon by the DelinoParser after an initial check for correctness of the command input.

The EditParcelDescriptor class is a static class contained in the EditCommand class. It act as a helper class to allow the setting of all the NEW_VALUE to the corresponding ORDER_ATTRIBUTE_PREFIX in the EditCommandParser class. The EditParcelDescriptor object is then passed back as a parameter to instantiate an EditCommand. In the diagram above, the EditParcelDescriptor object is named as epd. The EditCommand object is then passed back as e to the LogicManager which will then call EditCommand#execute. This execute method mainly calls the 3 helper method, not shown, EditCommand#createEditedOrder/EditCommand#createEditedReturnOrder and EditCommand#generalSetParcel. The main function of these methods are to help EditCommand in updating the ObservableList in the Model class which is responsible for the updating of list displayed.

The ObservableList is a JavaFX class which listens and automatically changes the list once an update is performed.

The return feature allows the user to either:
1. Create a new return order from his/her input parcel attributes.
2. Convert an existing delivered order to a return order.

The return feature was implemented as a ReturnCommand in the Logic package.

The return command has two possible formats:

In this section, you will learn more about the execution paths for the return command.

There are three possible execution paths for the return command

The above class diagram shows the structure of the ReturnCommand and its associated classes and interfaces. Some methods and fields are not included because they are not extensively utilised in ReturnCommand; such as public static fields and getter/setter methods.

The sequence diagrams for the Return Command are shown below.

The sequence diagram for converting an order into a return order are shown below.

The arguments typed into Delino by the user will first be done by the execute method in LogicManager. After which, an DelinoParser object will be created to parse the input which is determined by the command word via the parseCommand method. In this case, it is the return command word that will be parsed.

Then, a ReturnCommandParser object will be created to parse the arguments after removing the command word return from the user’s input. Based on the command word return, a ReturnCommand object will be created.

Subsequently, the parseCommand method in LogicManager will continue to create a CommandResult based on the validity of the user’s input; which is determined by the execute method in ReturnCommand.

The execute method of ReturnCommand will first check if the return order in the constructor of ReturnCommand is present. In this case, since we are converting an order into a return order, the return order will not be present in the constructor of ReturnCommand and the isReturnOrderNotPresent() method will return true.

If the given TRANSACTION_ID exists in the order list, the getOrderByTransactionId(model) method will attempt to create a new Order object from the model’s Order list based on the given transaction ID, i.e. orderToBeReturned.

The checkIfOrderWasDelivered(model) method checks if the newly created Order is delivered. If the order was not delivered, it will throw a command exception and display an error message to the user.

If the order was delivered, Delino will proceed to check if the timestamp input was valid. If it was invalid, an exception will be thrown and an error message will be displayed to the user.

If the order was delivered and the timestamp input was valid, the deleteOrder(orderToBeReturned) method will be triggered to delete the order from the model’s order list. Also, a new return order will be created based on the ReturnOrder’s constructor that takes in an Order, i.e. ReturnOrder(orderToBeReturned). This creates a new Return Order object, toBeCreated.

Subsequently, this newly created ReturnOrder object toBeCreated, will be checked against the model’s return order list using the hasParcel(toBeCreated) method. If it exists, a command exception will be thrown and an error message will be displayed to the user.

If the ReturnOrder does not exist in the model’s return order list, the newly created ReturnOrder object, toBeCreated, will be added to the model’s return order list using the addReturnOrder(toBeCreated) method.

Finally, a new CommandResult will be created to display the success message to the user for converting a delivered order to a return order.

The sequence diagram for creating a new return order are shown below.

The arguments typed into Delino by the user will first be done by the execute method in LogicManager. After which, an DelinoParser object will be created to parse the input which is determined by the command word via the parseCommand method. In this case, it is the return command word that will be parsed.

Then, a ReturnCommandParser object will be created to parse the arguments after removing the command word return from the user’s input. Based on the command word return, a ReturnCommand object will be created.

Subsequently, the parseCommand method in LogicManager will continue to create a CommandResult based on the validity of the user’s input; which is determined by the execute method in ReturnCommand.

The execute method of ReturnCommand will first check if the return order in the constructor of ReturnCommand is present. In this case, since we are creating a new return order from the given parcel attributes, a return order will be created and it will be used in the constructor of ReturnCommand and the isReturnOrderNotPresent() method will return false.

Also, a new return order will be created based on the ReturnOrder's constructor that takes in an Order, i.e. ReturnOrder(orderToBeReturned). This creates a new ReturnOrder object, toBeCreated.

Subsequently, this newly created ReturnOrder object toBeCreated, will be checked against the model’s return order list using the hasParcel(toBeCreated) method. If it exists, a command exception will be thrown and an error message will be displayed to the user.

If the ReturnOrder does not exist in the model’s return order list, the newly created ReturnOrder object, toBeCreated, will be added to the model’s return order list using the addReturnOrder(toBeCreated) method.

Finally, a new CommandResult will be created to display the success message to the user for creating a new return order with the given parcel attributes.

The nearby feature allows the user to view all orders that are located at a particular area based on a given search criteria.

The nearby feature was implemented as a NearbyCommand in the Logic package.

The nearby command has two possible formats:

In this section, you will learn more about the execution paths for the nearby command.

There are four possible execution paths for the nearby command

The matching orders are determined based on the given user argument.
If a two digit integer is given, searching of nearby orders will be based on their postal sector.
Else, searching of nearby orders will be based on their area.
There are currently five areas that are searchable:

In this section, you will learn more about the relationships between objects related to the nearby command.

In the NearbyCommand class, there are also static strings present that represent the various possible messages.
For some of the message strings, there are placeholder %s strings used for including dynamic input
These messages are the following:

In this section, you will learn more about the nearby command and its inner workings.

The sequence diagram below shows the interactions for a nearby command execution of nearby -o 14.
This indicates that the order list should be operated on and all orders in the order list that have a POSTAL_SECTOR of 14 should be displayed to the user.

The arguments passed to the Nearby Command will be parsed by the NearbyCommandParser class.
If the given arguments are valid, a new NearbyCommand object will be returned.
In this class, invalid arguments will result in a ParseException.
Two types of invalid arguments are checked for: empty arguments and arguments with only whitespace characters.

The execute() function of the NearbyCommand will first check if the given arguments are in the format required for postal sector search (the argument can be converted into an integer). If the first check is successful, the argument will be converted into an integer and a second check is performed via the isValidPostalSector(Index postalSector) function of the NearbyCommandUtil helper class.

The model will then be updated by the updateFilteredOrderList(orderPredicate) function.

A CommandResult is then generated and returned to the LogicManager.

The sequence diagram below shows the interactions for a nearby command execution of nearby -o central.
This indicates that the order list should be operated on and all orders in the order list that have an AREA of central should be displayed to the user.

The NearbyCommandParser will check for invalid arguments given by the user.
Invalid arguments can be either empty arguments or arguments with only whitespace characters. A ParseException will be generated if an invalid argument is present.

A new NearbyCommand will be created and returned to LogicManager.

LogicManager will then call the execute() function of the NearbyCommand.
There will then be a check for whether the given argument is a valid area with the function isValidArea(area) present in the DistrictInfo class.

The model will then be updated using the updateFilteredOrderList(orderPredicate) function.

A new CommandResult will be created and returned to the LogicManager.

The sequence diagram below shows the interactions for a nearby command execution of nearby.
This will result in a ParseException as invalid arguments are provided.

The exception will be thrown in the NearbyCommandParser.

The help feature was implemented as the HelpCommand in the logic package.
The help feature allows users to save the trouble of adding the delivery orders and the return orders one by one when they have large amount of delivery orders or return orders to add into Delino.

The execution path of the HelpCommand is shown below:

After the user enters the help command word, there will be a validation check to ensure that there are no non-whitespace characters following after the help command word so that the help command can be processed as a valid command.

If there are non-whitespace characters following help command word, a ParseException object will be created and thrown to the user by displaying an error message.

If there are no non-whitespace characters following the help command word, a new HelpCommand object will be created and a CommandResult object will be created subsequently to display the success message to the user.

The following diagram shows the overview structure of the HelpCommand Class Diagram:

The above class diagram shows the structure of the HelpCommand and its associated classes and interfaces. Some methods and fields are not included because they are not extensively utilised in HelpCommand; such as public static fields and getter/setter methods.

The sequence diagrams for the help command are shown below.

The arguments typed into Delino by the user will first be done by the execute method in LogicManager. After which, an DelinoParser object will be created to parse the input which is determined by the command word via the parseCommand method. In this case, it is the return command word that will be parsed.

Then, a HelpCommandParser object will be created to parse the arguments after removing the command word help from the user’s input. Based on the command word help, a HelpCommand object will be created. The parse() method in HelpCommand will check the validity of the user’s input to see if there are any non-whitespace characters following the help command word.

Subsequently, the parseCommand method in LogicManager will continue to create a CommandResult based on the validity of the user’s input.

If the user input is invalid, i.e. there are non-whitespace characters after the help command word, a ParseException object will be created in the parse method in HelpCommandParser and an error message will be displayed to the user.

If the user input is valid, i.e. there are no non-whitespace characters after the help command word, the parse method of HelpCommandParser will return a new HelpCommand.

Then, a new CommandResult will be created based on the user input. This will then display the success message to the user.

The import feature was implemented as the ImportCommand in the logic package.
The import feature allows users to save the trouble of adding the delivery orders and the return orders one by one when they have large amount of delivery orders or return orders to add into Delino.

The execution path of the ImportCommand is shown below:

After the user enter the import command, there are three validation check for the file based on the input argument, FILE_NAME:

Afterward, a new ImportCommand will be created and executed. For every data inside the list, either order or return order will be added into the order book and return order book respectively based on the orderType value. If the orderType is invalid, add the data into the result, which will be displayed to the user after processing.

The following diagram shows the overview structure of the ImportCommand Class Diagram:

In the ImportCommand Class, there are also a few static message to display to the user for the various scenarios occurred during the importing of data from the CSV file:

In this section, the interactions between the objects when ImportCommand is executed will be shown in the Import Command Sequence Diagram below:

The arguments passed to the import command will be parsed by the ImportCommandParser class.
Then, the ImportCommandParser will called the ParseUtil#parseCsvFile() to get the filePath based on the input the user provides. Afterward, CsvProcessor will be called to retrieve the data from the csv file and return the processed fileData back to ParseUtil. The fileData will be further pass to ImportCommandParser and to the constructor of ImportCommand.

Afterward, the ImportCommand object is being returned to the LogicManager and the LogicManager will start to run the execute the ImportCommand, which will be shown at the diagram below.

The ImportCommand#execute() will first check if the data given starts with order or return and pass to the InsertCommandParser or ReturnCommandParser respectively.

Afterwards, InsertCommandParser or ReturnCommandParser will return a new InsertCommand or ReturnCommand respectively if it successfully parse the data. The ImportCommand will then call the InsertCommand#execute() or ReturnCommand#execute() depend whether it is delivery order or return order. This will cause a delivery order or return order being added into the Model.

The ImportCommand will call its own printResult() function and return a String message to the CommandResult object which is then pass back to the LogicManager.

The search feature was implemented as the SearchCommand in the logic package.

The search feature allow users to search for any orders according to the provided input.

search feature format: search [FLAG] [ORDER_ATTRIBUTE_PREFIX]/[KEYWORD]

There are two mode of searching, general search or specific search.
If the user does not provide any ORDER_ATTRIBUTE_PREFIX, a general search mode will be performed on orders, return orders, or both depending on the FLAG.

The [FLAG] -o when given, searches only for parcels in the order list.
The [FLAG] -r when given, searches only for the parcels in the return order list.

If the user provide any ORDER_ATTRIBUTE_PREFIX, a specific search will be performed.

The above activity diagram illustrates the different execution paths of search command.
Whenever a user keys in an input with the search keyword, the SearchCommandParser class will handle the parsing of input.
User input will be validated in the SearchCommandParser class.

Input is deemed as invalid and ParseException is thrown under these scenarios:
1) FLAG given is not -o or -r.
2) Multiple FLAG detected.
3) No KEYWORD is given after search.

View the list of allowed prefixes in this search command here.

The above class diagram depicts the structure of the class SearchCommand. As per any Command class, SearchCommand needs to extend the abstract class Command.
Information that are left out in this class diagram are the common messages used in SearchCommand.

The sequence diagram above illustrates the interactions between objects when search command is performed by the user.
Particularly, the interactions shown is a success search command executed by the user and only an abstract view is shown.

LogicManager first calls parseCommand with arguments representing the user input, Alice. The SearchCommandParser will then check for any invalid arguments passed by the user.

The SearchCommandParser will then checks for the presence of any FLAG. The presence of one will result in different SearchCommand constructor being called.
The SearchCommandParser will call the both the OrderContainsKeywordsPredicate constructor and the ReturnOrderContainsKeywordsPredicate if no FLAG is given.
However, if a FLAG is given, the corresponding predicate will be instantiated and passed as an parameter for the SearchCommand constructor with the other left as null value.

The parsing of user input utilises ArgumentTokenzier (not shown in sequence diagram) to process and split each KEYWORD to it’s corresponding ORDER_ATTRIBUTE_PREFIX, if given any.

If the preamble to any ORDER_ATTRIBUTE_PREFIX is not empty, a general search will be performed in which KEYWORD will be searched through all fields of parcel.
However, if ORDER_ATTRIBUTE_PREFIX is given and the preamble is empty, the specific search will be performed. Only parcel fields that correspond to the given ORDER_ATTRIBUTE_PREFIX will be searched and matched with the KEYWORD.

The order and return order list updates automatically as the JavaFX class ObservableList is used to listen to any changes.

The show feature allows the user to see the statistical information of all the orders for both Delivery Orders and Return Orders.

There are a few ways in which the user can input to the command box to execute the show command:

The above activity diagram shows the logic and the path execution when the show command is executed.

The main logic of the ShowCommand is to check if the number of arguments in the input besides show is one or two. If it is neither, the code will throw an exception. If there is only one argument, the code will check if the word provided is either all or today or simply just a DATE the value of DATE will be validated to check if it is a valid date. It throws an error if it is invalid. When its correct, the code will execute the input accordingly. If the number is two arguments, it will check if the dates provided are valid or invalid date. It throws an error for the latter. The code will then ensure that the START_DATE is before the END_DATE. Once the input passes all the validations in the ShowCommand code, the command will then be executed and it prints a success message to the user.

The structure of the show feature is as shown below:

The above diagram shows all the methods and variables that the ShowCommand class is using when the command is executed. All the static methods and variables are not mentioned in this diagram. Furthermore, there are some methods and variables omitted from this diagram as it is irrelevant to the ShowCommand class.

The sequence diagram for the show command is shown below:

The user first calls the command "show all".

The LogicManager will call the parseCommand method of DelinoParser, which then passes the second argument into the ShowCommand object. Within the object, it will call the parseData method to make sense of the dates given. After that, it returns the object to the LogicManager. Next, the LogicManager will call the execute(model) method using the ShowCommand object. When completed, the execute(model) will return a CommandResult object to the LogicManager, indicating that the command execution is a success. In this case where the input is "show all", it will have a message that indicates that the command is showing all information.