[CS2113-W12-1] HealthMate

.gitignore

@@ -13,5 +13,4 @@ src/main/resources/docs/
 *.iml
 bin/
 
-/text-ui-test/ACTUAL.TXT
-text-ui-test/EXPECTED-UNIX.TXT
+

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "java.configuration.updateBuildConfiguration": "interactive"
+}

META-INF/MANIFEST.MF

@@ -0,0 +1,3 @@
+Manifest-Version: 1.0
+Main-Class: HealthMate
+

README.md

@@ -1,4 +1,4 @@
-# Duke project template
+# HealthMate
 
 This is a project template for a greenfield Java project. It's named after the Java mascot _Duke_. Given below are instructions on how to use it.
 

build.gradle

@@ -29,11 +29,11 @@ test {
 }
 
 application {
-    mainClass.set("seedu.duke.Duke")
+    mainClass.set("seedu.healthmate.HealthMate")
 }
 
 shadowJar {
-    archiveBaseName.set("duke")
+    archiveBaseName.set("healthmate")
     archiveClassifier.set("")
 }
 
@@ -43,4 +43,5 @@ checkstyle {
 
 run{
     standardInput = System.in
+    enableAssertions = true
 }

data/user_data.txt

@@ -0,0 +1,5 @@
+180.0
+80.0
+true
+20
+BULKING

docs/AboutUs.md

@@ -1,9 +1,9 @@
 # About us
 
-Display | Name | Github Profile | Portfolio 
---------|:----:|:--------------:|:---------:
-![](https://via.placeholder.com/100.png?text=Photo) | John Doe | [Github](https://github.com/) | [Portfolio](docs/team/johndoe.md)
-![](https://via.placeholder.com/100.png?text=Photo) | Don Joe | [Github](https://github.com/) | [Portfolio](docs/team/johndoe.md)
-![](https://via.placeholder.com/100.png?text=Photo) | Ron John | [Github](https://github.com/) | [Portfolio](docs/team/johndoe.md)
-![](https://via.placeholder.com/100.png?text=Photo) | John Roe | [Github](https://github.com/) | [Portfolio](docs/team/johndoe.md)
-![](https://via.placeholder.com/100.png?text=Photo) | Don Roe | [Github](https://github.com/) | [Portfolio](docs/team/johndoe.md)
+Display |      Name       |            Github Profile             | Portfolio 
+--------|:---------------:|:-------------------------------------:|:---------:
+![](https://via.placeholder.com/100.png?text=Photo) |    Ryan Tan     | [Github](https://github.com/ryan-txn) | [Portfolio](docs/team/ryan-txn.md)
+![](https://via.placeholder.com/100.png?text=Photo) |   Jonas Seet    | [Github](https://github.com/dri-water) | [Portfolio](https://github.com/dri-water)
+![](https://via.placeholder.com/100.png?text=Photo) |   Ryan Leong    | [Github](https://github.com/ryryry-3302) | [Portfolio](https://github.com/ryryry-3302)
+![](https://via.placeholder.com/100.png?text=Photo) | Kenneth Styppa  | [Github](https://github.com/kennethSty) | [Portfolio](https://github.com/kennethSty)
+![](https://via.placeholder.com/100.png?text=Photo) | Deepan Krishnaa | [Github](https://github.com/DarkDragoon2002) | [Portfolio](https://github.com/DarkDragoon2002)

docs/DeveloperGuide.md

@@ -1,22 +1,222 @@
 # Developer Guide
 
 ## Acknowledgements
-
-{list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well}
+ChatParser structure inspired by: 
+[this repository](https://github.com/kennethSty/ip)
+Calorie consumption bar inspired by 
+[this blogpost](https://medium.com/javarevisited/how-to-display-progressbar-on-the-standard-console-using-java-18f01d52b30e)
 
 ## Design & implementation
+### High Level Class Design
+The main classes of this implementation are:
+- HealthMate
+- ChatParser
+- User
+- MealList
+- MealEntriesList
+- Meal
+- MealEntry
+- HistoryTracker
+- UI
+
+In each class we focused on maintaining a tight abstraction barrier between classes.
+This specifically includes adherance to the "Tell Don't Ask" principle which was enforced by
+making most attributes of all classes above private and avoiding getter methods if possible.
+The following diagram illustrates the resulting associations, methods and attributes.
+For the sake of clarity, UI class is omitted since it is used across most classes to systematize any form of
+printing output to the user.
+
+![High Level CD](images/highLevelClassDiagram.jpg)
+
+#### HealthMate
+Entry point to the application is the main function of HealthMate.
+The HealthMate class contains a private ChatParser attribute. This attribute's run function initiates, 
+after an initial greeting to the user, the interaction process. In this process, 
+the user enters commands with additional information into his command line application.
+The content of these commands is parsed by the ChatParser. 
+
+#### ChatParser
+The ChatParser class, instantiated once per application run, manages HealthMates overal usage 
+flow through its main run() method. 
+
+It has two primary attributes: 
+- A `MealEntriesList` object called `mealEntries` 
+  - Contains tracked calorie consumption 
+- A `MealList` object called `mealOptions` 
+  - Contains meals that are presaved by the user for quick selection to track commonly consumed meals
+
+These objects represent the application's underlying data with which the user interacts through the command line.
+To ensure no unintended changes are done, the ChatParser class orchestrates the effects of the users prompts.
+For saving these changes the ChatParser class makes use the `HistoryTracker`  which facilitates the process of 
+storing (and loading) User data, mealEntries data and mealOptions data to their corresponding files. 
+
+More details on the implementation of ChatParser follows in the Feature Section. 
+
+#### MealList
+The MealList class contains a private ArrayList of Meal object.
+Further, it encapsulates behaviour to operate on this list of meals. Most notably, 
+this adding or deleting a Meal to/from the list. 
+
+#### MealEntriesList
+The MealEntriesList class extends the MealList class. It overwrites the extractAndAppendMeal(...) method,
+and additionally includes methods specifically tailored to providing helpul user feedback, as the MealEntries stored 
+within its instance, signify the users calorie consumption. 
+As a MealEntry object differs from a Meal object by the additional timestamp attribute, this includes
+computations based on the time dimension. More specifically, the printDaysConsumptionBar() uses the UIs class'
+methods in the background to visualize the percentage of a certain days total consumption versus the idaeal consumption
+of a User class. 
+
+#### Meal
+The Meal class encapsulates the concept of a meal. As the purpose of this application 
+is to track calorie consumption, this consists of a mandatory calorie entry. The meal's name attribute, 
+is however an Optional<String> allowing a case, where no meaningful label can be attached to a certain consumption.
+![User SD](images/addMeal.png)
+
+#### MealEntry
+The MealEntry class extends the meal class and contains an additional field timestamp. 
+This distinction was made, as objects of the Meal class will represent possible meal options to choose form, 
+while a mealEntry is a concrete calorie consumption the user wants to track. The latter makes a timestamp indispensible. 
+
+#### HealthGoal
+The HealthGoal class manages a user's health goal and calculates target calorie intake based on user data such as height, weight, age, and gender. 
+It offers three main health goals: weight loss, steady state, and bulking, each with a corresponding calorie modification factor. 
+The class supports setting, storing, and retrieving the health goal. 
+Additionally, it provides a method to compute target calories using the Harris-Benedict Equation, modified by the current health goal. 
+This allows the class to adapt the calorie calculations according to the user's health objectives, making it versatile for various fitness plans.
+
+#### User
+The user class encapsulates all necessary information for computing an ideal daily calorie consumption. 
+This includes:
+- Height (in cm): Double 
+- Weight (in cm): Double
+- Age: Integer
+- Gender: Boolean
+- Health goal: HealthGoal
+- Ideal calorie intake: Computed based on the information above 
+- Date: LocalDateTime specifying the date of the above information
+More details follow in the Features section of this guide. 
+
+#### HistoryTracker
+The HistoryTracker class is responsible for managing the persistence of data in the HealthMate application. It handles the saving and loading of user data, meal entries, and meal options to and from files. This class plays a crucial role in maintaining the application's state across different sessions.
+
+Key features of the HistoryTracker class include:
+
+1. Data Persistence:
+   - Saves user data, meal entries, and meal options to separate files.
+   - Loads existing data from these files when a new usage session is initiated.
+
+2. File Management:
+   - Creates and manages the necessary files for storing application data.
+   - Handles file I/O operations, ensuring data integrity during read and write processes.
+
+3. Data Formatting:
+   - Converts complex objects (like User, MealEntry, and Meal) into a format suitable for file storage.
+   - Deserializes stored data back into usable objects when loading the application state.
+
+HistoryTracker allows for the persistance of user inputted data between sessions by storing it in a local csv file.
+
+## Features
+
+This section will document the contributions made by each team member regarding the implementation or planned feature enhancements, detailing the design and thought processes behind them.
+
+---
+### Creating a User Profile
+To create or load a user profile the `User` class provides the method `checkForUserData` which loads 
+saved user information if available from an existing file usingn the `HistoryTracker` or prompts the user
+to input new information for creating a new profile as shown in the sequence diagram below.
+![User SD](images/userSequenceDiagram.jpg)
+Reference diagrams used
+![User SD](images/askForUserDataSD.png)
+![Read User SD](images/readUserDataFromFileSD.png)
+
 
-{Describe the design and implementation of the product. Use UML diagrams and short code snippets where applicable.}
+### ChatParser Input Handling
+The 'ChatParser' class has the responsibility of parsing user input to steer the 
+application logic based on predefined commands specified in the `CommandMap' class.
+Therefore, the ChatParser class acts as the main interface between user input and command execution. 
+This includes extracting and routing commands, as well as exception handling for 
+false input. 
 
+#### Feature Implementation
+The `ChatParser class:`
+1. Accepts user input. I.e. it reads input from the command line
+2. Tokenizes commands and identifys one- and two-token commands
+3. Routes commands based on the identified command tokens which are specified in the `CommandMap` class. This is done 
+using methods such as `multiCommandParsing` for 2-token commands and `run` which encapsulates the main loop of
+user interaction until the exit command "bye" terminates the application.
+4. Logs command routing and its effects on a high level to enable tracking of the application's activity.
+
+#### Why It Is Implemented This Way
+The ChatParser class was implemented in the above manner for three reasons:
+1. It allows create one abstract unit for handling the responsibility of orchestrating usage flow.
+2. As a high-level abstraction layer it improves readability by bundliing the overall application logic in one place.
+3. Its modularity allows for easy extensions or modifications to `CommandMap` and `multiCommandParsing`. 
+
+#### Alternatives considered
+Direct command handling in the main loop. Reduces the depth of the application, 
+but comes at the cost of reduced readability and higher cohesion. 
+
+#### Extensions for v.2.1
+Seperating the responsibilities of reading and preprocessing user input from the responsibility 
+to steer command routing. This could improve the maintainability of the ChatParser class in the future. 
+
+### Command Handling with CommandMap Class
+
+#### Overview
+
+The `CommandMap` feature enhances the system's command handling by centralizing the lookup, and
+storage of commands. It allows users to efficiently view commands usage within the HealthMate application.
+
+#### Feature Implementation
+
+The `CommandMap` class in the `seedu.healthmate.command` package maps command names to their corresponding
+`Command` objects using a `HashMap<String, Command>`. This ensures fast retrieval and allows users to explore
+commands with ease.
+
+#### Why It Is Implemented This Way
+
+Using a `HashMap` allows efficient command lookups with a constant time complexity of O(1). Centralizing all
+commands within `CommandMap` simplifies the system's command handling process and makes it more maintainable  as new
+commands are added.
+
+#### Alternatives Considered
+
+An alternative was storing commands in a list and iterating through them sequentially to find the matching command.
+However, this approach was less efficient for frequent lookups compared to the `HashMap`.
+
+#### Proposed additions for v2.1
+
+The `CommandMap` can be built upon to support saving and usage of user created scripts as commands. For example
+using a user could possibly create an add morningRoutine command by creating a command that runs multiple add
+mealEntry commands of their regular breakfast as well as triggering the updateUser data command.
+
+#### Sequence Diagram TBD
+
+1. **Command Lookup Process**: Illustrate the flow from when a user enters a command to when `CommandMap.
+getCommandByName()` retrieves the command and the UI displays the results.
+   - Components: `UI`, `ChatParser`, `CommandMap`, `Command`.
+   - Highlight how `CommandMap` retrieves the appropriate command based on user input.
+
+---
 
 ## Product scope
 ### Target user profile
 
-{Describe the target user profile}
+The target user profile for HealthMate includes:
+- Health-conscious individuals who want to monitor their daily calorie intake
+- People trying to lose weight or maintain a healthy weight
+- Fitness enthusiasts who want to balance their calorie consumption with their exercise routines
+- Individuals with specific dietary requirements or restrictions
+- Anyone interested in developing better eating habits and nutritional awareness
 
 ### Value proposition
 
-{Describe the value proposition: what problem does it solve?}
+HealthMate solves the following problems:
+- Difficulty in tracking daily calorie intake: Users can easily log their meals and snacks
+- Lack of awareness about calorie consumption: The app provides visual representations of daily intake
+- Inconvenience of manual calorie calculations: Pre-saved meal options make tracking quicker and more efficient
+- Inability to see patterns in eating habits: Historical data allows users to analyze their consumption over time
+- Struggle to maintain consistent healthy eating habits: Regular tracking encourages mindful eating and helps users stay accountable to their health goals
 
 ## User Stories
 
@@ -27,12 +227,52 @@
 
 ## Non-Functional Requirements
 
-{Give non-functional requirements}
+1. Usability: The command-line interface should be intuitive and easy to use, even for non-technical users.
+2. Reliability: The application should not lose any user data during normal operation or unexpected shutdowns.
+3. Compatibility: The application should run on common operating systems (Windows, macOS, Linux).
+4. Maintainability: The code should be well-documented and follow clean code principles for easy future enhancements.
+5. Portability: User data should be easily exportable and importable for backup purposes or switching devices.
 
 ## Glossary
 
-* *glossary item* - Definition
+* *Meal* - A food item or combination of food items consumed at one time, with associated calorie information.
+* *MealEntry* - A record of a meal consumed by the user, including the meal details and a timestamp.
+* *MealList* - A collection of pre-saved meals that users can quickly select from when logging their food intake.
+* *MealEntriesList* - A chronological list of all meals consumed by the user.
+* *ChatParser* - The component responsible for interpreting user commands and executing the appropriate actions.
+* *HistoryTracker* - The component that manages the storage and retrieval of user data, meal entries, and meal options.
+* *HealthGoal* - The class that manages functions pertaining to setting of user health goal as well calculating ideal caloric intake based on various factors.
 
 ## Instructions for manual testing
 
-{Give instructions on how to do a manual product testing e.g., how to load sample data to be used for testing}
+1. Installation and Setup:
+   - Ensure Java Runtime Environment (JRE) is installed on your system.
+   - Download the HealthMate application JAR file.
+   - Open a terminal or command prompt and navigate to the directory containing the JAR file.
+
+2. Running the Application:
+   - Execute the command: `java -jar HealthMate.jar`
+   - Verify that the application starts and displays a welcome message.
+
+3. Testing Basic Commands:
+   - Try entering the command `help` and verify that usage instructions are displayed.
+   - Test the `bye` command to ensure the application exits properly.
+
+4. Adding a Meal:
+   - Use the command `add mealEntry [name] [calories]` (e.g., `add meal "Chicken Salad" 350`)
+   - Verify that the meal is added successfully and displayed in the meal list.
+
+5. Logging a Meal Entry:
+   - Use the command `log meal [name/index] [portion]` (e.g., `log meal "Chicken Salad" 1`)
+   - Check that the meal entry is recorded with the current timestamp.
+
+6. Show Historic Caloric Trend:
+   - Use the command `show historicCalories [no. of days]` (e.g., `show historicCalories 5`)
+   - Check that the calories added previously are shown and that all the stats displayed are correct
+
+7. Testing Data Persistence:
+   - Exit the application using the `bye` command.
+   - Restart the application and check if previously added meals and logged entries are still present.
+
+8. Error Handling:
+   - Try entering invalid commands or data to ensure the application handles errors gracefully and provides helpful error messages.

docs/README.md

@@ -1,4 +1,4 @@
-# Duke
+# HealthMate
 
 {Give product intro here}