FundGoodDeeds App - Version 2.0

NOTE:

Every effort has been made to help the reader notice the changes. Clarification on requirements are in orange; new items or requirements are in blue and deletions are shown by strike through

Requirements (clarification)

Needs Collection

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

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

   n,name,total

   where n is the literal letter n, name is the need name, total is the total cost of one unit of the need. The name may not contain a comma and the numeric fields must all be floating point values.

   Example - Monthly Rent:

   n,Monthly Rent,1200.0

   Example - Bus Pass:

   n,Bus Pass,60.0

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

   b,name,n1name,n1count,n2name,n2count,...,nNname,nNcount

   where b is the literal letter b, name is the bundle name, and the list of name/count pairs gives the names of other needs (either basic or sub-bundles) and the number of units of the need in the bundle being defined. Names may not contain commas, and unit counts must be given as floating point numbers.

   NOTE: Need names in the list must refer to basic needs and bundles previously defined in the file; no forward references are allowed.

   Example – Monthly Essentials Bundle:

   b,Monthly Essentials,Monthly Rent,1.0,Bus Pass,1.0,Grocery Budget,1.0

5. Need names, whether basic or bundle, shall be unique across all entries.
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 need or bundle occurs is defined exactly once) but can appear in the definition of other future bundles as many times as is required.
8. The saved file shall conform to the no forward and no circular reference constraint.

Funding Source Collection

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

3. For a funding source, the CSV line shall be formatted as follows:

   i,name,amount

   where i is the literal letter i, name is the funding source name, amount is the dollar amount received for one "unit" of this source.

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

   Examples:

   i,Student Loan,5000.0

   i,Paycheck,1800.0

   i,Hourly Work,22.50

4. Note: If a user logs 8.0 units of Hourly Work the person will have received:

   22.50 * 8.0 = 180.0 dollars.

5. Funding source 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 funding source occurs exactly once).

Daily Ledger

1. The program shall maintain a CSV format log file named exactly log.csv of the fulfilled needs, available funds, and desired threshold on a daily basis.

2. Available funds are recorded on a line with the following format:

   yyyy,mm,dd,f,funds

   where yyyy, mm, dd specifies the year, month, and day as integers; f is the literal letter f, and funds is the amount of available funds in dollars as a floating-point number.

   Example:

   2025,10,05,f,185.5

3. If the user has entered available funds for the given date, that value should be used in the system. If the user has not input funds for the given date, the amount that was entered on the most recent funds entry should be used. If funds were never entered by the user, the system should default to 150.0 dollars.

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

   yyyy,mm,dd,t,threshold

   where yyyy, mm, dd specifies the year, month, and day as integers; t is the literal letter g, and threshold is the desired threshold as a floating-point number.

   Example:

   2025,10,05,t,1800.0

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

6. Each fulfilled need or bundle on a given day is recorded on a line in the following format:

   yyyy,mm,dd,n,name,count

   where yyyy, mm, dd specifies the year, month, and day as integers; n is the literal letter n, name is the need or bundle name (either a basic need or bundle), and count is the number of units fulfilled.

   Example:

   2025,10,05,n,Monthly Essentials,2.5

   NOTE: Different entries for the sameneed on a given day may not be combined. For example, if the user fulfills two hygiene kits in the morning and one in the afternoon, then there should be two distinct log entries.

7. Each funding source received on a given day is recorded on a line in the following format:

   yyyy,mm,dd,i,name,units

   where yyyy, mm, dd specifies the year, month, and day as integers; i is the literal letter i, name is the funding source name, and units is the number of units received:

   Example:

   2025,10,05,i,Hourly Work,8.0

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

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 needs, funding sources, 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 fulfilled needs list is empty, and no funding sources are recorded.
   • The threshold and available funds are determined using the rules from the Daily Ledger section above.
5. The program shall allow the user to change the daily threshold and available funds for the selected date but only for current or future dates. NOTE: the daily threshold can be set in the future but not in the past. On the current date a previously set threshold can be changed ONLY if nothing else has been entered for that day ( needs or funding sources)
6. The program shall support adding of new basic needs and bundles in a manner consistent with the specifications under Needs Collection.
7. The program shall support adding of new funding sources in a manner consistent with the specifications under Funding Source Collection.

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

   • Each need fulfilled, along with the number of units and total cost.
   • Each funding source received, along with the number of units and total funds received.
   • The total costs fulfilled for the day.
   • The total funds received for the day.
   • The net costs (fulfilled - received) for the day (this may be negative).
   • some indication of whether the net costs exceeds the set threshold.
   • The available funds for the day (the changing of which has no effect on funding source calculations) .
9. The program shall allow the user to add an funding source and the number of units to the log for the currently selected date.
10. The program shall allow the user to add a need and the number of units to the daily log on the currently selected date.
11. The program shall allow the user to delete an funding source item from the daily log. The user shall be able to unambiguously specify which entry to delete even if several entries have the same funding source name.
12. The program shall allow the user to delete need entries in the daily log. The user shall be able to unambiguously specify which entry to delete even if several entries have the same need name.
13. All data and displays of information about the selected date shall immediately reflect the results of additions, changes, and deletions to needs, available funds, or threshold.

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

    • For basic needs, this means the total cost.
    • For bundles, this means adding or deleting needs in the bundle and/or changing the number of units of each need.
15. The program shall allow the user to edit the dollar amount for any funding source (the effects of such changes are immediately displayed if the funding source is in the daily log).
16. The program shall provide a means for the user to save the current system state (the needs collection, and the daily log). In particular, the saved needs collection must be in a form consistent with the no forward references constraint in the Needs Collection 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.

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.

* Approval from instructor is required in order for your team to use a different "front-end" implementation other than Swing. Negotiate this as soon as possible if you plan on deviating from this legacy requirement.
Note: this will also result in additional documentation and must be agreed upon by all team members. MVC must still be clearly identified and described in your document and the platform and your implementation must support it.

REMEMBER the goal of this course and project is not about "fancy views" in the UI as reflected in the grade breakdown below.
Deal with the graphical "bells and whistles" if you have time and ONLY AFTER you are certain the required functionality is fully working and your design and implementation are in sync. Graphs for cummulative data (e.g. more than one day range) are a nice to have *bonus

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

* Be sure to comply with dropbox done requirements, if you have any questions ask instructor for clarifications.

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.