HealthNCare App - Version 2.0

NOTE:

New items or requirements are in blue; deletions are shown by strike through.

Overview

The program you will create will provide a collection of basic foods, which can be combined to create recipes in the system. Users can also add their own basic foods or recipes to the program by providing the necessary information. For example, this information could be the name of the food, calories, grams of fat, grams of carbohydrates, and grams of protein in the food as well as milligrams of sodium. Users can also use recipes as an ingredient in other recipes they add to the system (sub-recipes). The program should also provide a way to record exercises. The calories expended on exercise should be deducted from the calories consumed in order to compute net calories per day. The user should be able to add to or edit the collection of exercises provided.

Each day, the user can add log entries of the food they consumed during the day, including the number of servings of each food. Based on this information, the program can display totals of nutrients for each day. It could also display graphs showing the distribution of things like fat, carbs, and protein for the day. For example, if a user only logged a piece of bread for a day and bread had 5 grams of carbs and 5 grams of protein, the graph for that day would show 0% fat, 50% carbohydrates, and 50% protein. Total sodium for the day would not be considered (given it is in milligrams) but should be shown separately

Users can also attach other information to their log entries, like their weight or their desired intake of calories. The program should indicate to the user the status of their calorie goal (whether or not their calorie intake for the day meets their desired intake). This helps users to track their weight over time and understand whether they are under or over their goal. The program should display the calorie goal, the calories consumed, the calories expended via exercise, the net calories, and the difference between the goal and net calories.

The program must also save the user’s data. This includes the collection of foods, recipes, and exercises as well as the information on daily consumption, daily exercises, calorie targets, and recorded weights.

Requirements

Food Collection

1. The program shall store a food file named exactly foods.csv with a collection of the foods in the system in CSV (Comma Separated Values) format.
2. Each line in the file shall contain information on a single basic food or a single recipe.

3. For a basic food, the CSV line shall be formatted as follows:

   b,name,calories,fat,carb,protein,sodium

   where b is the literal letter b, name is the food name, calories is the number of calories in one serving of the food, fat, carb, and protein are the number of grams of fat, carbohydrates, and protein in one serving of the food and sodium is the number of millligrams in one serving. The name may not contain a comma and the numeric fields must all be floating point values.

   Example - Hot dog:

   b,Hot Dog,314.0,18.6,24.3,11.4,810

   Example - Hot dog bun:

   b,Hot Dog Bun,145.0,2.0,26.0,5.1,260

4. For a recipe, the CSV line shall be formatted as follows:

   r,name,f1name,f1count,f2name, f2count,...,fNname,fNcount

   where r is the literal letter r, name is the recipe name, and the list of name/count pairs gives the names of other foods (either basic or sub-recipes) and the number of servings of the food in the recipe being defined. Names may not contain commas, and servings must be given as a floating point number.

   NOTE: Food names in the list must refer to basic foods and recipes previously defined in the file; no forward references are allowed.

   Example - Hot dog in bun with mustard:

   r,Hot Dog-Bun-Mustard,Hot Dog,1.0,Hot Dog Bun,1.0,Mustard,1.5

5. Food names, whether basic or recipe, shall be unique across all foods.
6. The file shall be loaded into an appropriate internal data structure when the program executes, and saved to the CSV on exit or when the user explicitly requests the information be saved.
7. The saved file shall not contain any duplicate information (each basic food or recipe occurs exactly once).
8. The saved file shall conform to the no forward reference constraint.

Exercise Collection

1. The program shall maintain an exercise file named exactly exercise.csv with the exercise collection in CSV (Comma Separated Values) format.
2. Each line in the file shall contain information on a single exercise.

3. For an exercise, the CSV line shall be formatted as follows:

   e,name,calories

   where e is the literal letter e, name is the exercise name, calories is the number of calories expended by the exercise in 1 hour for a 100-pound person.

   The name may not contain a comma and the numeric field must be a floating-point value.

   Examples:

   e,Gardening,180.0

   e,Lawn Mowing,250.0

   e,Jogging (5 mph),364.0

   e,Bicycling (14-16 mph),454.0

4. Note:If a 160-pound person engages in 15 minutes of Gardening the person will have expended:

   180.0 * (160.0/100.0) * (15.0/60.0) = 72.0 calories (rounded to the nearest calorie) where:

   180.0 = calories per hour per 100 pounds for Gardening

   (160.0/100.0) = weight in 1/100 pounds

   (15.0/60.0) = fractional hours

5. Exercise names shall be unique.
6. The file shall be loaded into an appropriate internal data structure when the program executes, and be saved to the CSV on exit or when the user explicitly requests the information be saved.
7. The saved file shall not contain any duplicate information (each exercise occurs exactly once).

Daily Log

1. The program shall maintain a CSV format log file named exactly log.csv of the food intake, weight, and desired calorie limit on a daily basis.

2. Weight is recorded on a line with the following format:

   yyyy,mm,dd,w,weight

   where yyyy, mm, dd specifies the year, month, and day as integers; w is the literal letter w, and weight is the recorded weight in pounds as a floating-point number.

   Example:

   2023,10,05,w,185.5

3. If the user has entered a weight for the given date, that value should be used in the system. If the user has not input a weight for the given date, the weight that was entered on the most recent weight entry should be used. If a weight was never entered by the user, the system should default to 150.0 pounds.

4. The calorie limit is recorded on a line with the following format:

   yyyy,mm,dd,c,calories

   where yyyy, mm, dd specifies the year, month, and day as integers; c is the literal letter c, and calories is the calorie limit as a floating-point number.

   Example:

   2023,10,05,c,1800.0

5. If the user entered a calorie limit for a given date, that value should be used in the system. If the user did not enter a calorie limit for the given date, the limit that was entered on the most recent calorie limit entry should be used. If a calorie limit was never entered by the user, the system default should be 2000.0 calories.

6. Each food item consumed on a given day is recorded on a line in the following format:

   yyyy,mm,dd,f,name,count

   where yyyy, mm, dd specifies the year, month, and day as integers; f is the literal letter f, name is the food name (either a basic food or recipe), and count is the number of servings consumed:

   Example:

   2023,10,05,f,Hot Dog-Bun-Mustard,2.5

   NOTE: Different entries for the same food on a given day may not be combined. For example, if the user records two cups of coffee in the morning and one in the afternoon, then there should be two distinct log entries.

7. Each exercise performed on a given day is recorded on a line in the following format:

   yyyy,mm,dd,e,name,minutes

   where yyyy, mm, dd specifies the year, month, and day as integers; e is the literal letter e, name is the exercise name, and minutes is the number of minutes spent on the exercise:

   Example:

   2023,10,05,e,Gardening,15.0

   NOTE: Different entries for the same exercise on a given day may not be combined.

   If the user gardens for 30 minutes in the morning and 20 minutes in the afternoon, then there should be two distinct log entries.

8. The log file shall be loaded into an appropriate internal data structure when the program executes, and be saved to the CSV on exit or when the user explicitly requests the information be saved.

Program Operation

1. The program shall employ a simple user interface that is sufficient to achieve the functionality in this document.
2. When started, the program shall load the food and log data into their internal data structures.
3. The program shall allow the user to select a specific date to log activities for (the default on start-up is the current date No entries allowed for days older than a week. e.g. Today Monday, last Monday allowed ).

4. If the selected date does not already exist in the log, the information shall be initialized as follows:

   • The food intake is empty, and no exercises are recorded.
   • The calorie limit and weight are determined using the rules from the Daily Log section above.
5. The program shall allow the user to change the daily calorie limit and weight for the selected date but only for current or future dates. NOTE: the daily limits can be set in the future but not in the past. On the current date a previously set goal can be changed ONLY if nothing else has been entered for that day (food or exercise)
6. The program shall support adding of new basic foods and recipes in a manner consistent with the specifications under Food Collection.
7. The program shall support adding of new exercises in a manner consistent with the specifications under Exercise Collection.

8. The program shall, by some means, provide the user access to the following information for the selected date:

   • Each food item consumed, along with the number of servings and total calories.
   • Each exercise performed, along with the number of minutes and total calories expended (this depends on the weight).
   • The total calories consumed for the day.
   • The total calories expended in exercise for the day.
   • The net calories (consumed - expended) for the day (this may be negative).
   • The total number of calories consumed for the day and some indication of whether the net calories exceeds the set limit.
   • The weight for the day (the changing of which requires a recalculation of exercise calories).
   • A breakdown of nutrition in terms of the percentage of total grams of fats, carbohydrates, and protein, each to the nearest 1%. The total must be 100%.
   • The total sodium consumed for the day (in milligrams) as well as a percentage of the daily recommended intake of (2,300 mg)

   • A Bar Chart for the currently selected day showing nutrition consumed in grams of fat (red), carbohydrates(green), and protein(blue) from left to right.

     • If no food has been consumed, the chart is blank (no bars are displayed).
     • The bar for the category with the greatest value must extend to the top of the chart; the other category bar heights will be proportional to this.

     • Example: fats = 50 grams, carbohydrates = 100 grams, protein = 75 grams.

       Then red fat bar will be 1/2 the height of the chart, the green carbohydrate bar will be the full height of the chart, and the blue protein bar will be 3/4 of the height of the chart.

     • The bar chart must always display the current information (that is, if a food is added or removed from the log, or if a new day is selected, then the chart must immediately reflect this change).
     • Hint: Use the BarGraphCanvas from the ThermometerMVC example as a model for what you have to do.
9. The program shall allow the user to add an exercise and the number of minutes of exercise to the log for the currently selected date.
10. The program shall allow the user to add a food item and the number of servings to the daily log on the currently selected date.
11. The program shall allow the user to delete an exercise item from the daily log. The user shall be able to unambiguously specify which exercise to delete even if several entries have the same exercise name.
12. The program shall allow the user to delete food items in the daily log. The user shall be able to unambiguously specify which food to delete even if several entries have the same food name.
13. All data and displays of information about the selected date shall immediately reflect the results of additions, changes, and deletions to foods, weight, or calorie limit. This includes the Bar Graph.

14. The program shall allow the user to edit information related to a food (the effects of such changes should be immediately displayed if the food is in the daily log):

    • For basic foods, this means the calories, grams of fat, grams of carbohydrates, and grams of protein in a serving.
    • For recipes, this means adding or deleting foods in the recipe and/or changing the number of servings of each food.
15. The program shall allow the user to edit the number of calories per hour per 100 pounds for any exercise (the effects of such changes are immediately displayed if the exercise is in the daily log).
16. The program shall provide a means for the user to save the current system state (the food collection, exercise collection, and the daily log). In particular, the saved food collection must be in a form consistent with the no forward references constraint in the Food Database section.
17. At your discretion the program may include additional features. However, these will not be considered as possible improvements to your grade unless: all other features above are implemented (Minimum Valuable Product) and you have conversed with your client stakeholder about these additions. (e.g. ask your stakeholder about workout routines for bonus)

Design Constraints

1. The design must build on the foundation provided by version 1.0 of the program (no complete rewrites permitted).
   Must take into account previous feedback and augment/improve/enhance the design document and static and dynamic models.
2. The design must incorporate the Composite pattern in an appropriate and visible manner.
3. The design must incorporate the MVC architectural pattern with an appropriate specification of which classes belong to the Model, the View, and the Controller subsystems.

4. Use of other patterns in an appropriate way (in particular, for reasons other than impressing your instructor with all the patterns you can cram in) will lead to higher design grades. Any usage must be properly documented and justified
   Hint: observer may be a good candidate.
   

Deliverables (see calendar on the course web site for dates)

1. Initial Design Document incorporating the enhancements given above. This must:

   • Be a PDF file named exactly preliminarydesign2.0.pdf.
   • Be placed in the doc directory.
   • Be tagged in Repository as exactly V2.0-PreliminaryDesign

2. Skeleton code for the enhancements above. This must:

   • Be in the src directory.
   • Conform closely to the preliminary design above.
   • Be tagged in Repository as exactly V2.0-CodeSkeleton.

3. Final Presentation:

   • This will be given on the final day of class.
   • Each team will prepare a 10-15 minute presentation of its project.
   • The presentation slides must include or address:
     1. A title page with the name of your program/team and the names of all team members.
     2. An overview of the final system design. This shall include up-to-date class and sequence diagrams, but keep these as simple as possible (they must be readable at the back of the classroom).
     3. The good: a discussion of the strong points of the design & implementation, as well as what went well during development.
     4. The bad: a discussion of the weaknesses of the design & implementation, as well as things that were problematic during development.
     5. A demonstration of the final product.

4. Final Design and Implementation:

   • The final design and implementation must be tagged in Repository as V2.0-Final
   • The doc directory will contain:
     1. A file named exactly presentation2.0.pdf containing a PDF version of the slides used in the presentation.
     2. A PDF file named exactly finaldesign2.0.pdf containing the final design documentation.
   • The src directory will contain:
     1. The final versions of all the Java source files comprising the version 2.0 delivery.
     2. A text file named exactly README2.0.txt -or- a PDF file named exactly README2.0.pdf containing:
        • Instructions on running the final product. Clearly identify an executable jar file for starting the application (i.e. "double click this").
        • A guide to using the product so it can be assessed and graded for functionality and completeness. Clearly identify functions that have not been completed.