Phoebe Chan Kar Hui - Project Portfolio

To toggle between the main list and the list of items to be replenished, you can use the command view|<list name>. This shows you all the items in the list automatically sorted by their name (lexicographical order) then date (chronological order).

Examples:

Let’s say that you have completely depleted some items, namely Cherry and Coco Crunch in the main tracking list, and you wish to view these items that have been automatically shifted to the replenish list. You can do so by typing view|replenish in the command box to change your current list view to that shown in the figure below.

Perhaps after viewing all your items in the replenish list, you wish to return to the main tracking list to add some items that you have recently purchased. You can easily return to the main list, by typing view|main in the command box. This is also depicted in the figure below.

To view all the items in the current list, you can simply enter the command view.

Example:

Let’s say that you have been searching for an item in the main tracking list, and you are shown the item found. To return back to the main list that displays all the items tracked, you can simply enter the command view.

As shown in a snippet of the Logic class diagram below, both XpireParser and ReplenishParser implement the interface Parser. In particular, ReplenishParser is the one that parses and handles the commands in the replenish list.

The activity diagram below follows the general path of a command executed in either the main tracking list Xpire, or the replenish list.

In the event that ReplenishParser is selected, it will prevent any invalid or prohibited commands and also check for spelling mistakes in the user input. This will be further explained to you in a later section.

When designing the replenish list, I had to make decisions on how best to parse and execute commands in an efficient manner that would minimise code repetition and delay in runtime. The following is a brief summary of my analysis and decisions.

As mentioned previously, items in both lists are automatically sorted by their name then date. This auto-sorting mechanism is facilitated by SortedUniqueXpireItemList and SortedUniqueReplenishItemList that both implement SortedUniqueItemList, in a relationship summarised in the class diagram below.

In both SortedUniqueXpireItemList and SortedUniqueReplenishItemList, items are stored in a SortedList<Item> and subsequently sorted based on the comparator defined. SortedUniqueXpireItemList supports a new function, SortedUniqueItemList#setMethodOfSorting(), that specifies the MethodOfSorting and comparator to be used for the list.

The following sequence diagrams break down the intricacies in the view operation that works to display the sorted items in each list:

The figure above shows a view|replenish command executed to change the current view from that of the main tracking list Xpire to the replenish list, while the figure below initialises this process.

LogicManager creates and allocates a parser to parse commands entered by the user each time. It does so by first identifying the current view displayed. In this example, the current view is found to be XPIRE, and thus XpireParser is selected. Following that, new objects ViewCommandParser and ViewCommand are created and returned to LogicManager to be used in the execution of the view|replenish command. The figure below pictures the process of retrieving the internal sorted list of items in ReplenishList.

As items in the replenish list lack expiry dates, the command to sort by date is rendered irrelevant and thereby disallowed entirely in the replenish list. Instead, items are automatically sorted by their names. Therefore, in the diagram above, a nameComparator is always returned by default.

this.internalUnmodifiableList = FXCollections.unmodifiableList(this.sortedInternalList);

In the process of actualising this feature, I contemplated on when items should be automatically sorted by their names and displayed. I also tried and tested varied options to derive an optimal data structure to store the sorted items. The following is a brief summary of my analysis and decisions.

Invalid commands are checked for spelling mistakes. The spelling correction mechanism is based primarily on the Damerau–Levenshtein distance algorithm, which computes the edit distance between two strings. This distance is based on the number of substitutions, deletions, insertions or transpositions of characters, needed to convert the source string into the target string. Relevant functions supporting this operation are implemented in StringUtil.

As shown in the diagram below, Banana was not recommended even though it exists in the original list. This is because it had been filtered from the previous list prior to when the second search command was executed. On the other hand, if green was misspelled as gren, the algorithm will be able to identify green as the closest match, as Green Apple is present in the previous list.

The figure below presents what happens when a user executes a command with invalid arguments.

In the example below encapsulated in a sequence diagram, the user has misspelled "date" as "dat" in a sort command.

The sequence diagram titled find similar words below expands on the process omitted above.

The function findSimilar in StringUtil is called upon to return a set containing strings that are most similar to the misspelled argument, "dat". In this process, "dat" is compared with a set of valid inputs, i.e. both "name" and "date", and the corresponding edit distances are stored. getSuggestions("dat") then filters the results and finds "date" to be the best match.

At last, a ParseException which contains the recommendation "date" is then thrown to the user as feedback.

When tasked to implement this feature, I had to decide on what was the best way to display any form of recommendations to the user. I also evaluated multiple options to derive an optimal data structure to store the recommendations. The following is a brief summary of my analysis and decisions.