ExerHealth - Developer Guide

The undo/redo mechanism is facilitated by the events package consisting of EventHistory, EventFactory, EventPayload and the various Event classes.

The EventHistory is a singleton class used to store a history of successfully executed commands as Event objects. Instances of Event are stored in either the undoStack or the redoStack depending on the user’s course of action.

The EventHistory class has two primary methods namely undo(Model model) and redo(Model model):

These operations are utilised in the UndoCommand and RedoCommand respectively.

The following steps will describe the full life-cycle of executing an UndoableCommand, and subsequently the UndoCommand and RedoCommand.

Step 1: When an UndoableCommand is executed, relevant information will be added into a newly initialized EventPayload.

Step 2: The EventFactory takes in the UndoableCommand and generates an Event using the EventPayload stored in the UndoableCommand. The Event is then added to the undo stack of the EventHistory.

Step 3: To undo the latest UndoableCommand the user executes the UndoCommand by entering undo into the command box.

Step 4: The UndoCommand executes eventHistory.undo(model), which prompts the EventHistory instance to pop the next Event to undo from the undo stack. Once the Event is undone, it will be pushed to the top of the redo stack.

Step 5: To redo the command that has been undone, the user executes the RedoCommand. This execution behaves similarly to step 4, except that the next Event is taken from the top of the redo stack instead of the undo stack.

The following two Sequence Diagrams show a sample flow of the execution when an EditCommand, which is an UndoableCommand, has been executed and subsequently undone.

The first diagram (Figure 9) describes the process of storing an EditEvent to EventHistory during the execution of the EditCommand. The EventPayload is only initialized when the EditCommand is executed. The EventPayload is subsequently used for the initialization of the EditEvent.

The second diagram (Figure 10) here describes the process of undoing the EditCommand executed above using the UndoCommand. When the UndoCommand is executed, the EventHistory calls the undo method of the next Event in the undo stack (i.e. the EditEvent).

Given below is a Class Diagram (Figure 11) to show the associations between Event, Command and Model. It is specifically designed such that only objects that implement the Event and Command interface will need to handle the model class.

The following Activity Diagram (Figure 12) summarizes what happens when a user enters undoable commands, the undo command and the redo command.

The Undo/Redo feature implementation is based on the Singleton, Command, and Factory design patterns

There are multiple times where if the user wishes to schedule a regime, they find themselves in trouble over which kind of exercise regime they can fit into their schedule. The motivation behind this feature is so that users can customise their own schedules to their own liking. The alternative of an auto scheduler will restrict users from having the regime of their liking be scheduled. Instead of forcing users to adhere to some pre-generated resolution, we allow the users to make their own choice and choose their own exercise regime to be scheduled.

The resolve feature is used when there is a scheduling conflict that happens within ExerHealth. This feature will alter the state of the program. The state is known by MainApp and it is either State.IN_CONFLICT or State.NORMAL. Only when the state is State.IN_CONFLICT will resolve commands be allowed.

For the implementation of the resolve feature, the ResolveCommand will hold a Conflict object which is then passed into Model. The concrete implementation, ModelManager then resolves the conflict that is being held there. Each Conflict object will hold 1 conflicting schedule and 1 schedule that was originally scheduled on the date.

Shown below is the class diagram for the implementation of the Resolve feature.

With regards to the flow of the program for a scheduling conflict, the steps are laid out below:

Step 1. User enters a schedule command that will cause a scheduling conflict. The ScheduleCommand will change MainApp state to State.IN_CONFLICT.

Step 2. A CommandResult object is returned to MainWindow where the flag showResolve is set to true.

Step 3. Upon receipt of the object, MainWindow will show the resolve window and the user is required to resolve the conflict.

Shown below is the sequence diagram for when a scheduling conflict happens:

Step 5. When the user is prompted with the ResolveWindow, all the conflicting exercises will be shown in one page. The previously scheduled regime on the left and the conflicting regime on the right.

Step 6. Once the user issue a resolve command correctly, the model and storage of ExerHealth will be updated to reflect the changes. A new regime will be added for the user from the resolve.

Step 7. The ResolveWindow then closes upon successful resolve and the application continues.

The following activity diagram summarizes what happens when a user enters a schedule command:

A quick conversation with a few of our friends revealed that there are many properties which they intend to keep track for exercises. However, it is unlikely that we can implement all of these properties for the exercises as there may be too much overhead and we can never be certain that we have met all of the users' needs. As such, we decide to allow users to define their own properties should they require them. These custom properties can then be applied to all of the exercises, providing more flexibility in terms of tracking the exercises' properties.

Furthermore, as noted by one of our user stories, there are users that love customisations too. This can also come in handy when they want to define their own properties for the exercises.

This feature is facilitated by both PropertyBook and CustomProperty. Whenever a user adds a newly defined custom property, a CustomProperty object will be created which is stored in PropertyBook. Its corresponding prefix and full name will be tracked by PropertyBook to avoid clashes in their uses.

CustomProperty encapsulates a single custom property that the user defines. It contains information such as name, prefix and parameter type of the custom property. The parameter type is supported by an enumeration class ParameterType and is restricted to one of the following 3 types: Number, Text, Date.

PropertyBook serves as a singleton class that helps to manage all of the custom properties that have been defined by the user. This class acts as an access point for any information relating to the creation or deletion of custom properties.

To keep track of the custom properties and its relevant information, the following are used:

Custom names and prefixes are separated from its default counterparts to ensure that the default names and prefixes will always be present when the PropertyBook is first initialised.

To help facilitate PropertyBook in its custom properties management, the following main methods are implemented:

Method 3 is implemented to ensure that the name of a default property is not removed by mistake if the user chooses to remove a predefined custom property.

All of the crucial associations mentioned above are summarised in the next class diagram (Figure 16).

Beginners now have a plethora of choices and may be overwhelmed when deciding on what exercises to do. Thus, we decided to provide users with sample exercise routines to reduce the inertia of starting this lifestyle change. On other hand, regular gym goers may face a repetitive and mundane exercise routine or may want to experiment with different exercises. As such, put it briefly, we decided to give users the ability to discover exercises based on the characteristics they are interested in.

This feature presents a cohesive function that all users can benefit from. This also makes our application well-rounded so that users can better achieve their fitness goals.

The sample exercise routines are currently implemented in ExerHealth’s database as a hard-coded set of exercises. More importantly, the SuggestPossible command which caters to more experienced gym goers utilises the exercises that the user has already done, in addition to ExerHealth’s database. Hence, we allow users to search for suggestions based on Muscle and CustomProperty.

The SuggestBasic command displays a list of exercises from our database to the user. The SuggestPossible command is created by parsing the user’s inputs to form a Predicate before filtering ExerHealth’s database and the user’s tracked exercises.

The following activity diagram (Figure 21) summarizes what happens when a user enters a suggest possible command:

In detail, when a SuggestPossibleCommand is entered, the Logic component is responsible for parsing the inputs into a Predicate. The Predicate is then used to instantiate a SuggestPossibleCommand, and later used to filter a list of Exercise when the command is executed. The interactions between the multiple objects can be captured using a sequence diagram.

The following sequence diagram (Figure 22) shows the sequence flow from the when a user enters a valid SuggestPossibleCommand:

From the sequence diagram:

In step 3, the process in which the ExercisePredicate object is created can be explored deeper (Figure 23).

From the sequence diagram above:

The diagram below shows the structure of a ExercisePredicate object. A ExercisePredicate contains a list of BasePropertyPredicate, where each contains a Collection of Muscle or CustomProperty.

Creating classes such as ExerciseCustomPropertyPredicate and ExerciseMusclePredicate allow us to conduct better testing because we can compare the Collection of Muscle/CustomProperty being considered.

Statistics of exercises will be displayed in charts. Supported chart types are Pie Chart, Line Chart and Bar Chart. StatsFactory will create Statistic using given parameters. The figure (Figure 24) below shows the class diagram of statistics:

The next figure (Figure 25) shows the activity diagram when user enter a stats command:

Given below is an example usage scenario of statistics feature.

Step 1: User enters a stats command to see statistics of exercises.

Step 2: ExerciseBookParser will receive command from LogicManager and pass command to StatsCommandParser.

Step 3: StatsCommandParse will parse the command and creates a StatsCommand.

Step 4: StatsCommand calls Model#getExerciseBookData to get data of all exercises.

Step 5: StatsCommand creates a StatsFactory and pass exercises data, chart and category to StatsFactory.

Step 6: StatsFactory will then generate Statistic and return to StatsCommand.

Step 7: StatsCommand then calls Model#setStatistic to set the Statistic in Model.

Step 8: StatsCommand creates a new CommandResult and return to LogicManager.

Shown below is the sequence diagram (Figure 26) when user enters a valid stats command: