Home

Healthier Developer Guide

Group CS2113-F10-2
Last update on 12 Apr 2021

Table of Contents

• Getting Started
• Design
  • Architecture
    • Interactions between major components
  • Components
    • UI component
    • Parser component
    • Entity component
    • Command component
    • Storage component
    • Common component
• Implementation
  • Add record feature
  • Set goal feature
• Future Works
• Appendix: Requirements
  • Product Scope
    • Target User Profile
    • Value Proposition
  • User Stories
  • Non-Functional Requirements
• Glossary
• Instructions for manual testing

Getting Started

1. Fork this repo to your GitHub account
2. Clone the forked repo into your machine
3. Ensure you have Java SE 11 installed
4. Import the repo in your Java IDE as project
5. Start hacking!

💡 You are advised to choose JetBrain’s Intellij IDEA as your IDE.

Get back to Table of Contents

Design

This section describes design details of the app Healthier.

Architecture

Figure 1: Architecture Diagram

The high-level design of Healthier is shown in Figure 1: Architecture Diagram given above.

Healthier corresponds to the main class that coordinates the execution of this application. It is where the main method is located. It is responsible for,

• When app starts: Initializes essential data objects from stored files and displays basic information about the status of the app by utilizing the UI component.
• When app is running: Handles user input and coordinates corresponding operations by invoking methods from Parser and Command classes.
• When app ends: Terminates the execution of this app.

Common contains classes that can be repeatedly used by other components.

In addition to that, the app also consists of following components:

• UI: Handles the display of ui messages as well as user input.
• Parser: Processes the raw user input with validations and passes usable info to Command components.
• Command: Performs operations according to the command that the user input.
• Storage: Handles the read & write of various data files created/stored locally.
• Account: Manages the user accounts.
• Entity: Contains data objects that are essential to this app.

💡Healthier is an application that runs locally without Internet connections.
Data files will be stored in the format of plain-text documents for easy inspection and test.

Each of the components has corresponding Java classes that

• Define data attributes and methods in different levels of abstraction.
• Provide various APIs (i.e. public members) that can be utilized by other classes.

More information about the components will be discussed in the Components section.

The interactions between major components

We will take how Healthier handles user’s input as an representative example to illustrate the internal logic of this application.

The Sequence Diagram of the operation is given below:

Figure 2: Sequence Diagram of handling user input

After initialization, Healthier calls the loopCommand() method, which gets user input in a while loop which terminates only when the command is exit, i.e. "exit" is received.
Inside the loop, UI will handle the read of user input, and pass the raw input in String to CommandParser, where the input will be validated and a corresponding instance of Command will be created.
After that, the execute command will be invoked and the returned result in String will be printed by UI. At the end of the loop, the store() method of Storage will be called to update the local files to reflect any changes, and the parsed parameters in CommandParser will be cleared to get ready for next parse.

Components

UI component

API: UI.java

• Provides various public methods defined for displaying messages in the CLI, such as command result & error messages.
• Facilitates getting raw user input in String.
• Instances are primarily utilized in Healthier.java, where the main method is located.

Parser component

API: CommandParser.java

• Gets raw user input in String passed by the UI component.
• Recognizes command patterns from the raw input according to the command syntax.
• Validates mandatory/optional arguments supplied by the user.
• Processes and packages the arguments in the format that can be used by Command components.
• Returns a new Command instance initialized with relevant parameters according to the user input.
• Returns InvalidCommand if an erroneous input is received.

Entity component

APIs: Goal.java,Record.java,GoalList.java, RecordList.java, etc

Figure 3: class structure for entity classes

• EachUser stores a FitCenter object that holds all the records and goals for the user.
• Each FitCenter stores four RecordList and four GoalList for EXERCISE, DIET, SLEEP, BODY_WEIGHT type respectively.
• Record is an abstract class, which is the superclass for different types of records.
• Goal is an abstract class, which is the superclass for different types of goals.
• Each RecordList is composed of Record. Each GoalList is composed of Goal.

Command component

APIs: Command.java, CommandResult.java, etc

Figure 4: class structure for Command

• Command is an abstract class to interact with other components of the system.
• AddCommand,ViewCommand,DeleteCommand,SetCommand,CheckCommand,CancelCommand,HelpCommand,ExitCommand are concrete command classes inherit from Command class to carry out different tasks.
• InvalidCommand represents commands whose syntax are invalid.
• CommandResult stores the feedback message of command execution and will interact with UI to display the feedback.
• Each subclass must implement the abstract execute method, which invokes APIs defined in Entity classes to perform an operation.
• Each subclass has an attribute feedback, which is a String that stores the result of the command execution.

How the command is executed?

1. UI component takes in user’s input, which is then passed to Parser component.
2. Parser component processes the user input and create a Command object initialized with relevant parameters.
3. The Command object is returned to Healthier, in which the execute method is invoked.
4. The execute method returns the execution result in String, which is displayed by UI.

Storage component

APIs: Storage.java, FileInfoReader.java, FileInfoWriter.java

Figure 5: class structure for entity classes

• FileInfoReader reads information stored in text files, hence the status can be resumed when users start the application again.
• FileInfoWriter stores information into text files in real-time, hence users can leave the application at any time without losing any data.
• Storage has a FileInfoReader and a FileInfoWriter to provide a generalized interface.

Common component

API: messages.java

• Classes that can be repeatedly used by other components are located in the seedu.duke.common package.
• Currently used as collection of frequently used messages.

Get back to Table of Contents

Implementation

This section describes details of how some of the important features are implemented, which can give some insights about how features are realized in general.

Add record feature

Adding a record to record list is achieved by AddCommand and RecordList. Records of the same category are stored as a RecordList. A ReocrdList supports the following operation:

• RecordList#addRecord(Record newRecord) — Add a new record of the specified type to the list.

All Record in a RecordList are of the same type so each user has 4 RecordList to hold EXERCISE, DIET , BODY_WEIGHT, SLEEP records respectively.

FitCenter is a uniform interface to manipulate all the RecordList and provide interface FitCenter#addRecordToList(CommandRecordType type, Record record)

Given below is an example of interaction among classes to add a new exercise record:

Step 1. The user enters a valid add command. An AddCommand will be initialized with the parsed parameters from user input.

Step 2. The AddCommand initializes a Record and calls FitCenter#FitCenter#addRecordToList(CommandRecordType type, Record record) to add the record.

💡 If any of the parameters passed are invalid, AddCommand will throw an error and will not call FitCenter#FitCenter#addRecordToList(CommandRecordType type, Record record), so the record will not be saved into the RecordList.

Step 3.FitCenter#FitCenter#addRecordToList(CommandRecordType type, Record record) calls RecordList#addRecord(Record newRecord) to modify the list.

The following sequence diagram shows how the add command works:

Figure 6: Sequence Diagram of adding a record

Get back to Table of Contents

Set Goal feature

The functionality of setting a goal and maintaining the goal in a goal list is achieved by SetCommand.
The realization is facilitated by FitCenter, as discussed previously in the Add record feature .
A goal has the following attributes: dateSet, intervalType, target, and progress.
As a goal corresponds to a kind of record, each goal object will also have a type attribute, which can be EXERCISE , DIET, SLEEP, and BODYWEIGHT.
Hence, once a goal object is created, it will be added to a GoalList in which more operations are defined and utilized by FitCenter, which contains the following method:

• FitCenter#addGoalToList(CommandRecordType type, Goal goal) - add a goal object to the goal list.

How the setting is done?

Take the example of setting a goal:

Step 1. The user enters a valid set command. A SetCommand instance will be initialized with parameters from user input parsed by CommandParser .

Step 2. The SetCommand initializes a Goal with parameters specified by the user, and the command object is returned to Healthier.

Step 3. The execute method of the SetCommand object is invoked, and it calls FitCenter#addGoalToList(CommandRecordType type, Goal goal) by passing the goal object of a particular record type, which adds the goal into the goal list.

Step 4. If the Goal object is not null, FitCenter#addGoalToList(CommandRecordType type, Goal goal) calls GoalList#addGoal(Goal newGoal) to update the list and the progress of the goal (if any).

The following Sequence Diagram illustrates how the set command works:

Figure 7: Sequence Diagram of Setting a Goal

Future Works

1. Smart recommendation for food and workout.
2. Multi-user capability with file separation & encryption.
3. Friend/leaderboard features that encourages user to compete.
4. Some other health indicators for monitoring, such as height and blood pressure.
5. Graphical user interface.

Appendix: Requirements

Product Scope

Target User Profile

• People who care about fitness
• People who exercise regularly (at least 3 times/week) and have diet plans
• Age group:18-30
• People who are proficient in using CLI tools& typing.

Value proposition

• Help users record and analyze daily diet data.
• Help users record sleeping data.
• Help users record exercise data such as calorie burned.
• Help users record basic information (gender, weight, etc).
• Help users set/manage fitness goals (e.g. body-weight, exercise).

Get back to Table of Contents

User Stories

Non-Functional Requirements

• Cross-platform and high compatibility.
• User-friendly and bug-free experience.
• Detailed and easy-to-follow user guide.
• Boost efficiency for people who are familiar with CLI tools.
• Easy maintenance.
• Scalable for additional features.
• Responsive interface.

Get back to Table of Contents

Glossary

• CLI - Command-line Interface.
• Record - Contains all important data of a particular health activity, such as activity name, date, etc.
• Goal - A reminder with desired target that can be completed by adding records.

Get back to Table of Contents

Instructions for manual testing

Given below are instructions to test the app manually.

Note: The instructions serve as a starting point for test, only basic test cases are listed for reference.

Launch and shutdown

1. Initial launch

   1. Download the jar file and copy into an empty folder

   2. Execute the jar file in command line window by command java -jar tp.jar.

2. Use command exit to terminate the application/

Adding a record

1. Adding an exercise record

   1. Test case: add t/E a/walking d/40
      Expected: A record of walking for 40 minutes on the current system date is added.

   2. Test case: add t/E a/abc d/40
      Expected: An error message is displayed since “abc” is not a valid workout type.

   3. Test case: add t/E a/running d/40 date/10-04-2021
      Expected: A record of walking for 40 minutes on 10/04/2021 is added.

2. Adding a diet record

   1. Test case: add t/D f/fruit w/50
      Expected: A record of having 50g fruit on the current system date is added.

   2. Test case: add t/D f/fruit w/abc
      Expected: An error message is displayed since “abc” is not a food amount value.

   3. Test case: add t/D f/fruit w/50 date/10-04-2021
      Expected: A record of having 50g fruit on 10/04/2021 is added.

3. Adding a sleep record

   1. Test case: add t/S d/8
      Expected: A record of sleeping for 8 hours on the current system date is added.

   2. Test case: add t/S
      Expected: An error message is displayed since the syntax for add command is invalid.

   3. Test case: add t/S d/8 date/10-04-2021
      Expected: A record of sleeping for 8 hours on 10/04/2021 is added.

4. Adding a sleep record

   1. Test case: add t/W w/68
      Expected: A record for body weight of 68.0kg on the current system date is added.

   2. Test case: add t/W w/abc
      Expected: An error message is displayed since “abc” is not a valid value for body weight.

   3. Test case: add t/W w/68 date/10-04-2021
      Expected: A record for body weight of 68.0kg on 10/04/2021 is added.

View record lists

1. View exercise records

   1. Test case: view t/E
      Expected: All exercise records are displayed.

   2. Test case: view t/E a/running
      Expected: All exercise records of running are displayed.

2. View diet records

   1. Test case: view t/D
      Expected: All diet records are displayed.

   2. Test case: view t/E f/abc
      Expected: An error message is displayed since “abc” is not a valid food type.

3. View sleep records

   1. Test case: view t/S
      Expected: All sleep records are displayed.

   2. Test case: view t/S date/10-04-2021
      Expected: All sleep records on date 10/04/2021 are displayed.

4. View body weight records

   1. Test case: view t/W
      Expected: All body weight records are displayed.

   2. Test case: view t/W date/2021-04-10
      Expected: An error message is displayed since the date is not in the supported format.

Delete a record

1. Delete a record of specific type

   1. Prerequisites: List all records using view command.

   2. Test case: delete t/E i/1
      Expected: First exercise record is deleted from the list.

   3. Test case: delete t/D i/0
      Expected: An error message is displayed since 0 is out of valid range of record index.

   4. Test case: delete t/S i/2
      Precondition: The sleep record list has at least 2 records.
      Expected: The second sleep record is deleted from the list.

   5. Test case: delete t/W
      Expected: An error message is displayed since the syntax for delete command is invalid.

Setting a goal

1. Setting an exercise goal

   1. Test case: set t/E p/D target/300
      Expected: A goal of taking exercises to burn 300Kcal every day is set.

   2. Test case: set t/E p/W target/3000
      Expected: A goal of taking exercises to burn 3000Kcal every week is set.

2. Setting a diet goal

   1. Test case: set t/D p/D target/1500
      Expected: A goal of taking in 1500Kcal every day is set.

   2. Test case: set t/D p/W target/abc
      Expected: An error message is displayed since “abc” is not a valid value for target calorie input.

3. Setting a sleep goal

   1. Test case: set t/S p/D target/8
      Expected: A goal of sleeping 8 hours every day is set.

   2. Test case: set t/S p/A target/8
      Expected: An error message is displayed since “A” is not a valid goal type.

4. Setting a body weight goal

   1. Test case: set t/W p/W target/60
      Expected: A weekly goal of reaching the body weight of 60kg is set.

   2. Test case: set t/W p/W target/abc
      Expected: An error message is displayed since “abc” is not a valid body weight target value.

Checking progress of goals

1. Checking progress of goals of a specific type.

   1. Test case: check t/E
      Expected: Progress of all exercise goals are displayed.

   2. Test case: check t/D p/D
      Expected: Progress of all daily diet goals are displayed.

   3. Test case: check t/S p/W
      Expected: Progress of all weekly sleep goals are displayed.

   4. Test case: check t/W
      Expected: Progress of all body weight goals are displayed.

   5. Test case: check t/W p/a
      Expected: An error message is displayed since “a” is not a valid goal type.

Canceling a goal

1. Delete a record of specific type

   1. Prerequisites: check the list of all goals using check command.

   2. Test case: cancel t/E i/1
      Expected: First exercise goal is cancelled and removed from the list.

   3. Test case: cancel t/D i/0
      Expected: An error message is displayed since 0 is out of valid range of goal index.

   4. Test case: cancel t/S i/2
      Precondition: The sleep goal list has at least 2 goals.
      Expected: The second sleep goal is cancelled and removed from the list.

   5. Test case: cancel t/W
      Expected: An error message is displayed since the syntax for cancel command is invalid.

Get back to Table of Contents
Home