FundGoodDeeds App - Version 1.0

Overview

* Disclaimer: This academic exercise and any views expressed or interpreted within its content are in no way intended to suggest, recommend or require life-style or behavior changes, or otherwise offend the reader, users or implementers of the system.

A Community Empowerment Consortium has received funding to contract the development of software that will enable individuals to monitor and improve their financial resilience through daily tracking and goal-setting.

The program you will create will provide a collection of basic needs, each representing a specific financial requirement such as housing, transportation, or healthcare. These basic needs can be combined to form bundles—comprehensive packages of support tailored to specific situations. Users can also define their own needs or bundles by entering the necessary financial details. For example, this information could include the name of the need, total cost, fixed cost, variable cost, and any associated fees. Bundles may include previously defined needs or other bundles as components.

Each day, the user can record a ledger of fulfilled needs, specifying the quantity of each need or bundle addressed. Based on this information, the program can display daily totals and generate visualizations showing the distribution of spending across fixed costs, variable costs, and fees. For example, if a user logs a $10 fulfillment toward transportation, with $5 in fixed costs and $5 in variable costs, the graph for that day would show 0% fees, 50% fixed costs, and 50% variable costs.

Users can also attach additional information to their ledger entries, such as their available funds or their desired funding goal for the day. The program should indicate whether the user is on track to meet their goal, helping them assess whether they are underfunded or operating with surplus. This supports long-term financial awareness and planning.

The program must also save the user’s data. This includes the collection of defined needs and bundles, as well as the information recorded in the daily ledger, including funding goals and available balances.

Requirements

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 financial goal.

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

   n,name,total,fixed,variable,fees

   where n is the literal letter n, name is the need name, total is the total cost of one unit of the need, fixed and variable are the dollar amounts for fixed and variable costs, and fees is the number of dollars in optional or administrative fees. 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,1000.0,150.0,50.0

   Example - Bus Pass:

   n,Bus Pass,60.0,30.0,20.0,10.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 exactly once).
8. The saved file shall conform to the no forward reference constraint.

Daily Ledger

1. The program shall maintain a CSV format log file named exactly log.csv to record fulfilled needs, available funds, and desired daily funding goals 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 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 daily funding goal is recorded on a line with the following format:

   yyyy,mm,dd,g,goal

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

   Example:

   2025,10,05,g,1800.0

5. If the user entered a funding goal for a given date, that value should be used in the system. If the user did not enter a funding goal for the given date, the goal that was entered on the most recent funding goal entry should be used. If a funding goal 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 same need 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. 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.

Design Constraints

1. The design must incorporate the Composite pattern in an appropriate and visible manner.
2. The design must incorporate the MVC pattern with an appropriate specification of which classes belong to the Model, the View, and the Controller subsystems.

3. 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.

BE AWARE THE ABOVE REQUIREMENTS MIGHT CONTAIN AMBIGUITIES OR MAY OTHERWISE BE SUBJECT TO CHANGE. DESIGN WITH THAT IN MIND AND, WHEN IN DOUBT, MAKE SURE TO REACH OUT TO YOUR "CUSTOMER" TO CLARIFY.

Deliverables (follow this link)

Suggested Design Approach

Design is inherently a creative activity; as such, it is impossible to give a formula or algorithm that ensures success. However, there are some rules of thumb that typically result in an acceptable, even superb, object-oriented design.

1. Read the project description carefully, and extract all the nouns and noun phrases. These form the basis for initial selection of the problem classes (be sure to detect synonyms and only use one of the names). In some cases you'll find that a noun actually refers to a simple attribute of a class.
2. Adjectives and adverbs often point to information that defines the state of the objects in a class. As you identify such state information, assign it to what appears to be the most appropriate class. Don't worry if an attribute seems equally appropriate to two or more classes; just choose one at this point.
3. Verbs are signs of the methods that must be implemented. For each verb that seems appropriate, create an associated method name and associate it with a candidate class. As with state information, don't obsess at this point over whether or not you've identified the optimal class.
4. Sketch an initial class diagram (pencil and paper are fine), showing interconnections among classes that are drawn from the implications of the problem statement. This is a good point at which to try to identify an initial set of patterns appropriate to your system.

5. Now comes the hard but rewarding part - iterate until an adequate design is achieved.

   • For each of the user operations the system must support, trace a flow through the system objects to be sure the operation can be done. Sequence charts can help here, but don't get hung up on formality - paper and pencil are easier to work with (and easier to discard if things don't go well).
   • For each of the inter-class connections, ask whether the coupling could be reduced. In the extreme case, two classes could become totally uncoupled, but this is unusual. Instead, look for ways to reduce the amount of information about other classes that is implicit in the coupling. For instance, if you moved some responsibilities from one class to another is the coupling reduced?
   • Try to improve each class's cohesion, and make sure each class carries its own weight. A class that is just data members with getters and setters is rarely optimal. If you can't think of any "real" responsibilities to assign to the class, perhaps you don't need it.
   • Look for classes that address several concerns and try to separate these (either by assigning responsibilities to existing classes or inventing new ones).
   • Roughly estimate the size and complexity of each class. Strive for balance, where the responsibilities defined in the problem statement are dispersed in roughly equal portions to the classes in your design.
   • The goal is "balance", which can't be formally described. YKIWYSI - You'll know it when you see it.