FitBiz - Developer Guide

This command history mechanism is facilitated by the logic class CommandHistory, which controls both the model class CommandHistoryState and the storage utility class StorageReaderWriter.

In designing the model CommandHistoryState, we had to decide on the underlying data structure to store the user’s command history. We currently use the Java native ArrayList<String>, where each line of command is stored as an individual entry. Another alternative that we have considered is to store the commands in a LinkedList<String>:

In the interest of saving developement time and better code readability, we decided to use an ArrayList to store the commands. Since we have decided to cap the maximum size of the list, should this limit be exceeded, we would then need to remove the first item (or the zeroth index) from the list to free up space. Of course, doing a remove(0) on a n-item ArrayList will require that all remaining items in the list be reassigned to new indices, and thus incur an O(n) time operation. However, we found out through extensive testing that this causes no observable nor significant lag when the maximum capacity is reached.

Moreover, there is also a need to overwrite the whole storage file command.txt whenever this maximum size is reached. Before this maximum size is reached, we can easily append to the existing file the new command that the user has just entered. However, after this limit is exceeded, we must remove the first line stored in command.txt, shift all remaining lines up, and then append that new line. Hard disk operations like writing to storage is many order of magnitudes slower than memory operations like the reassignment of indices as discussed above. Since the much larger bottleneck is in the storage, this effectively nullifies the time complexity comparison that a LinkedList is faster than an ArrayList in removing the first item.

In choosing the maximum size of the command history, we have to take note of some important caveats:

Ultimately, we felt that 100 is a very generous estimate given that a user really only needs the past few commands at any point of time.

This feature is facilitated by the logic found in the Autocomplete class. Before we dive into the implementation, let us first define what unambiguous and ambiguous commands are:

As discussed in the implementation section, we have decided to use a Trie data structure. Of course, we have also considered other much simpler alternatives like simply storing all available commands in a native Java List. A quick summary of the pros and cons is given here:

As such, the choice of implementing our own Trie data structure is obvious. As this app grows bigger in the forseeable future, the number of commands as well as the number of things we would want to autocomplete would increase. Overall, we felt that the Trie data structure will scale much better as compared to a List.

Exchanging some initial development time for future scalability of our app will ensure that we, or future developers, do not end up wasting time refactoring what could have been done in the first place. Moreover, the Trie data structure is much more effective and computationally inexpensive in finding the longest common prefix of all ambiguous commands. The same cannot be said when using a List.

Also, since we have implemented our own Trie data structure, it would also allow more custom logic to be added later, and allow more creative freedom with respect to the features that we, or future developers would want to add. For example, future version of this application might want to also include the autocompletion of frequently used parameters by the user.

This scheduling mechanism is facilitated by ScheduleCommand which extends Command. The format of the command is given by:

schedule INDEX sch/DAY-STARTTIME-ENDTIME [sch/DAY-STARTTIME-ENDTIME] …​

When using this command, at least one valid complete schedule parameter must be specified. The user can follow up with additional optional valid schedule parameters in order to assign more schedules to the same client. The following 3 examples are all valid usages of the schedule command:

Example Commands

Elaboration on Example Commands

Do note that the schedule parameters given in the schedule command will entirely overwrite the client’s current list of schedules.

The list of schedules of each client are structured as a ScheduleList, which is a wrapper class for an ArrayList of Schedule objects. Each Client contains one ScheduleList attribute to keep track of all Schedule assigned to it. If there are no assigned Schedule for the Client, then the ScheduleList simply contains an empty ArrayList of Schedule.

Schedule comprises three attributes:

Day wraps the enum DayEnum.Weekday and represents the day of the week the schedule takes place on.

StartTime and EndTime represent the start time and end time of the schedule in the "HHmm" format respectively.

The relations between these classes are shown in the class diagram below.

These attributes are bounded by these characteristics:

Here is an activity diagram displaying the steps taken when FitBiz receives a user input for the schedule command:

In the following sequence diagram, we trace the execution for when the user decides to enter the command schedule 1 day/mon st/1100 et/1200 into FitBiz. For simplicity, we will refer to this command input as commandText:

This sequence diagram shows how the schedule command is processed in FitBiz. The LogicManager receives the input commandText and parses it with FitBizParser to obtain arguments that are then parsed into ScheduleCommandParser to construct a ScheduleCommand. This ScheduleCommand is returned back up to the LogicManager which then executes it with reference to the model argument. Subsequently, the Model is updated with a new Client with the schedule changes through a series of commands as shown in the right hand side of the sequence diagram, and control is return back to LogicManager.

In designing this feature, we had to consider the alternative ways in which we can choose to store the information of a schedule. One option of storing the relevant information (day, start, end times) for a schedule was simply to concatenate these values into a single String, for example, monday-1100-1200. However, we found that this did not exploit the desirable principles of Object-Oriented Programming. As respective sanity checks had to be done for the day and timing, wrapping each of these properties into their wrapper classes allowed for better modularity and organisation of these attributes. For example, Day#isValidDay handles the validation of the input for day and Time#isValidTimingFormat handles the validation of time.

Considerations also then had to be made for how to contain multiple Schedule. The current implementation uses the ArrayList data structure to hold multiple Schedule. Other considered alternative for ScheduleList was HashSet.

Displaying the Schedule Panel

The schedules of all the clients are displayed in a time-sorted manner on the SchedulePanel of the main FitBiz GUI as shown in the picture below, demarcated by the red rectangle:

The SchedulePanel extends UiPart<Region> and takes in a ScheduleDay class. ScheduleDay is similar to ScheduleList, the difference being:

As the nature of the SchedulePanel was to display a sorted collection of Schedule, we chose ArrayList as the underlying data structure, due to the ability to sort the ArrayList via a comparator that compares Schedule according to their Day and StartTime. The code snippet below shows how the Schedule are being sorted using an anonymous comparator in the constructor for ScheduleDay:

In addition, we also harnessed the capability of the HashSet to ensure no overlaps between Schedule within each Client, which is implemented by ScheduleCommandParser#checkIfOverlaps. As the ArrayList of Schedule is being populated in the constructor of ScheduleDay, we used a HashSet to check for any overlapping Schedule. The equals method of Schedule was overriden to consider overlapping timeframes between StartTime and EndTime to be equal.

This section explains the our design considerations and analysis for the storage of exercises.

We decided to use the first approach of storing the exercises with the associated client and have all the clients data in one JSON file. Codewise, each JsonAdaptedClient will have a list of JsonAdaptedExercise.

We want to keep the implementation of reading and storing of data simple. The first approach is the most simple. When reading the data, it removes the need to associate the exercises to the client. A client might potentially have a large amount of exercises, resulting in the reading process to be extremely slow. Therefore, a bad user experience.

Moreover, storing the exercise data from client data does not provide any performance benefits. Due to time constraints, we decided that the application should store all the data everytime it closes. This is regardless if the particular exercise or client data has been changed. Having to keep track of which data is edited and only overwrite those data would greatly increase the complexity of the application. Therefore, keeping exercises data separate from client data would be unnecessary and provide little additional functionality/benefits to the user.

Lastly, we foresee that it is improbable for the data size of both clients and exercises to exceed the maximum size limit of a JSON file. With the target user in mind, it is unlikely that he will have an enormous amount of clients. The application is meant to be used by a single user and not an organisation. Even though each client might have many exercises, the information of each exercise is relatively small. For now, collectively, the client and exercise data is unlikely to exceed the JSON size limit. We might consider to have multiple JSON files if the data size gets too big in future versions.

Indeed, JsonAdaptedClient having a list of JsonAdaptedExercise would violate separation of concerns. JsonAdaptedClient is now in charge of the client’s information and the exercises. However, we felt that the benefits outweighted the costs and proceeded with the first choice.

The personal best feature is facilitated by the model PersonalBest, and the logic behind it is in PersonalBestFinder. The behaviour of this feature determines the personal best of each exercise done by the client based on these considerations:

A simplified class diagram of the classes involved in this feature is given below:

In the following sequence diagram, we trace the execution for when the user decides to enter the command view-c into FitBiz:

The explanation for the sequence diagram is as follows: when the user inputs view-c, add-e, edit-c or delete-c, PersonalBestFinder#generateAndSetPersonalBest is called, taking the client currently in view as the parameter. PersonalBestFinder#generateAndSetPersonalBest then retrieves client’s list of exercises using Client#getExerciseList and creates a new HashMap, where the key is ExerciseName and the value is Exercise. Then the personal bests of each exercise of the client in view are generated using the above considerations. Finally the list of personal bests is set using PersonalBest#setPersonalBest.

In designing this feature, we had to decide on the placement of the PersonalBest class in the model to comply with the OOP standards. Currently, the PersonalBest model has a whole-part relationship with Client, with Client being the whole and PersonalBest being a part of Client. The alternative is to consider PersonalBest as a part of Exercise instead.

We decided to use the first approach of placing PersonalBest as a part of Client instead of Exercise. There are multiple reasons for our choice as mentioned below.

We want to maintain the OOP structure of the program. Logically, the personal best should belong to the client as the list of exercises belongs to the client. As the list of exercises is unique to every client, the personal best should also be so. We also do not want to increase coupling of the program as mentioned in the table above.

Moreover, even though personal best is generated using the list of exercises in the client, it can be instantiated even without an exercise list. Therefore it does not require the exercise class to exist and does not have a whole-part relationship with exercise. Coupling will also be increased as the client will be relying on the exercise class to generate the personal best. Therefore, the final choice was to place the personal best under client, with every client having their own personal best attribute.

This personal best feature also leads into the Graph feature, which will be discussed in the next section, where we plot a graph of the client’s progress of a specified exercise.

The graph mechanism is faciliated by the model class Graph, which contains the details of the graph. These include ExerciseName, Axis, StartDate and EndDate. The figure below is a UML class diagram to illustrate the Graph model.

These attributes are bounded by these characteristics: . ExerciseName can only be alphanumeric characters . Axis can either be reps or weight only, case insensitive (sets are not considered due to the same reasoning in the above section) . Earliest StartDate possible can only be one year before the current date and cannot be after EndDate. StartDate also cannot be a future date . Earliest EndDate possible can only be one year before the current date and cannot be before StartDate. EndDate also cannot be a future date

Here is an activity diagram displaying the steps taken when FitBiz receives a user input for the graph command:

The behaviour of this feature determines the graph plotted of the exercise specified based on these considerations:

The flow of the program is illustrated using the sequence diagram below:

The explanation is as follows: when the user inputs graph with all relevant arguments input correctly, a new GraphCommand() is created, taking the newly created Graph object as parameter.

GraphCommand#execute() then retrieves the exercise list from the client currently in view and checks if there is at least one exercise with a matching exercise name. If there is no exercise to plot, then an error GraphCommand.MESSAGE_EXERCISE_NOT_IN_LIST will be thrown. Next, the list of exercises to be plot will be generated using Graph#generateGraphList(). Once again, there will be a sanity check to see if the list size is zero, which means that no graph cannot be plotted.

In designing this feature, we had to decide on the implementation of certain classes like Axis to comply with the OOP standards of Abstraction.

We decided to use the approach of abstracting the axis types away into AxisType enum class. As the graph implementation will require a substantial amount of equality checks, especially for the attributes of Graph to make sure that we are drawing the correct graph for the user. As such equality checks are made, it makes it difficult to keep checking String equality as regular data types like String would allow invalid values to be assigned to a variable.

As our axis values can only be REPS, WEIGHT or NA, we can check for each case using the switch case method instead of checking for equality using raw types. This is also much more efficient than using multiple if-else statements. For example, in the code snippet below, the method fillSeries() uses switch case statements to add data values depending on the AxisType.

Moreover, to keep in line with the OOP standards, we decided that it will be better to abstract away data types like AxisType into its separate class instead of storing it as a raw type in Axis. This ensures the code quality of our program and reduces complexity (especially in terms of equality checking as mentioned above) by abstracting away the more complex details into classes of a lower level. The consideration of abstracting details away is also used for creating StartDate and EndDate classes as attributes of Graph, instead of using the Java in-built LocalDate.

By considering the above two factors, despite having to put in the extra effort to create a new AxisType class and thus requiring extra methods like getters and setters, we decided to move with the approach of creating the AxisType enum class and refactor to accomodate for the additional data type.

This filtering mechanism is facilitated by TagAndSportContainsKeywordsPredicate, that implements Predicate<Client> which is a wrapper class for a boolean. FilterCommand is associated with Model is responsible for calling Model#updateFilteredClientList based on TagAndSportContainsKeywordsPredicate. TagAndSportContainsKeywordsPredicate will call test on Client to check if the clients Tag and Sport contains all the keyword. the relations between these classes are shown in the class diagram below.

To further elaborate, TagAndSportContainsKeywordsPredicate contains 2 booleans:

If there is no keyword specified for either Tag or Sport, the corresponding boolean will return true. There must be at least 1 keyword specified, regardless of whether it is a Tag or Sport. TagAndSportContainsKeywordsPredicate will then evaluate and return the logical addition of hasTag and hasSport.

In the following sequence diagram, we will be tracing the execution of the command filter t/obese s/swim entered by the user.

We decided to use the first approach of checking if the client contains Tag specified and Sport specified separately.

Firstly, by separating the checks for each attributes, a correct implementation of checking Tag against the keywords will allow us to easily duplicate the logic to be done for Sport. This makes the code easier to debug as we can simply check the hasAttribute boolean to see if it gives the correct value.

Secondly, separating the checks for each attributes will allow us to add attributes of different types stored in different data structure easier. We could simply add another check on the attribute against the keyword specified then do a logical addition of the result against the others.

Therefore, as we foresee us adding more attributes to be filtered increasing the need to ensure logical correctness, the first approach is the most ideal.

The view client’s information feature is primarily facilitated by the model Client. The details for list of exercises done and personal best will be discussed in section 3.7 and not be covered here. The client’s INDEX in the clients list will be used to identify and retrieve his information. Additionally, only when a client’s information is being viewed, graph of his exercises can be plotted.

In the following sequence diagram, we will be tracing the execution when the user enters the command view-c 3

We decided to use the first approach of using the client’s INDEX to view his information.

Firstly, as the client’s INDEX is unique, view-c will only be responsible for retrieving and displaying the client’s information and will not need to resolve clients with the same names.

Secondly, for clients with the same name, INDEX qill be used to specify the client to be view. This causes extra work for the implementation. Furthermore, in cases where users manage many clients and some with same names, there are functions like find and filter which allow users to scope the clients list and easily find the desired client’s INDEX.

Therefore, viewing a client by his INDEX minimises the responsibility of the command and will not need to resolve conflicting clients and is the most ideal.