Nadia Atiqah Project Portfolio

The add command allows the user to add an eatery to our food diary application. The user can specify the name, address, category, and tags for the eatery when adding the eatery. Being a food diary application, the add command is one of the most important commands in the application as without it, the user would not be able to manage and keep track of any food places. The add command already came with the original Address Book code. Hence, all I needed to do was to add a Category field into the add command argument parameters and making the Tag field in the original add command argument parameters optional.

The edit command allows the user to edit an existing eatery. To edit an existing eatery, the user would need to specify the index of the eatery and other parameters that they would like to modify. Similarly, the edit command is one more important command in the application as there is a possibility that the user might have entered the eatery information wrongly. The edit command also came with the original Address Book code. Hence, all I needed to do was to enable the user to edit the Category field in the existing eatery.

The stats command allows the user to generate statistics about the eateries they have visited and the reviews they have made at those visited eateries. The stats command is not one of the most crucial commands in the application, however, it is still useful for users as it gives them a breakdown of their eateries and reviews. Unlike the add and edit commands, stats command did not come with the original Address Book 3 code. Hence, it required an in-depth analysis of possible design solutions and alternatives.

The edit feature allows the user to edit any fields from the selected eatery i.e. Name, Address, Category, and Tag field(s). This feature would replace existing Name, Address, Category, and Tag associated with the eatery, with the new ones inputted by the user. Hence, this feature is not advised for users who wants to add more tags to the current list of tags. The edit mechanism is facilitated by EateryList. It implements the following operations:

These operations are exposed in the Model interface as Model#setEatery().

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

Step 1. The user launches the application for the first time. The EateryList will be initialized with the initial json data stored.

Step 2. The user executes edit 1 \a 116 Commonwealth Cres, #01-140 to edit the address of an existing eatery. Before executing the command, the command would need to be parsed first. Hence, the EatMeParser would create EditCommandParser.

Step 3. EditCommandParser creates EditEateryDescriptor using the parameters specified (i.e. address, in this scenario).

Step 4. EditCommandParser returns a new EditCommand with the newly created EditEateryDescriptor as a parameter.

Step 5. EditCommand creates a new Eatery using the existing Eatery to be edited and EditEateryDescriptor.

Step 6. If the newly created Eatery is not a duplicate of the existing Eatery, EditCommand calls Model#hasEatery to check if the eatery exists in the list. If the eatery is a duplicate or it exists in the list, EditCommand will throw a CommandException specifying that there’s already a duplicate eatery in EateryList. Else, EditCommand will call Model#setEatery to modify the eatery.

Step 7. After successfully editing the eatery, EditCommand will return the CommandResult to the Ui.

The following sequence diagram shows how the edit eatery feature is executed.

The following sequence diagram shows the reference sequence diagram for creating an EditEateryDescriptor e.

The reference sequence diagram for creating Eatery edited has been omitted as the steps are the same as the reference sequence diagram for add command above.

The stats feature allows the user to generate statistics about the eateries they have visited and reviews they have made at those visited eateries.

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

Step 1. The user launches the application for the first time. The EateryList will be initialised with the initial or previous json data stored.

Step 2. The user executes stats to generate statistics for the current application state. The EatMeParser would return a StatsCommand to execute the command.

Step 3. StatsCommand then creates Statistics to generate the different types of statistics needed. To create the different types of statistics, Statistics would, first, sort the eateries in EateryList based on different conditions i.e. categories, total expense, total number of visits. After sorting the eateries, Statistics would then use these sorted lists to generate the appropriate statistics.

Step 4. StatsCommand would then call Model#setStatistics() with Statistics as a a parameter.

Step 5. After successfully generating the statistics, StatsCommand will return the CommandResult to the Ui.

The following sequence diagram shows how the statistics feature is executed.

Since the statistic feature has a different user interface compared to the other commands i.e. AddCommand, AddTagCommand, etc., it would be useful to explain how the different user interface components work.

Step 1. When the Ui receives the CommandResult from StatsCommand, the Ui will call MainWindow#showStats().

Step 2. MainWindow#showStats() will check if `StatsWindow is already open. If it is opened, it will call StatsWindow#initStats() and focuses the window. Else, it will call StatsWindow#initStats() and displays the window.

Step 3. In StatsWindow#initStats(), StatsWindow will create a CustomLayeredGraph and CustomPiechart to create the graph and pie chart needed for the statistics report.

The following sequence diagram shows how the statistics feature shows the statistics to the user.