arif-khalid/pe

pe's Issues

Uneccessary and innacurate information in DG EntryList UML diagram

The reference arrows from EntryList to Entry already implies the reference that ExpenseList and IncomeList have to Entry, there is no need to draw more reference arrows from those specific classes. This in fact implies that there is multiple Arrays of Entry, one in EntryList and one in its child.

I can edit expense to 0

I can edit my expense to 0 by inputting 0.001 into the editted new amount. This is something that is not handled and should not happen since it is explicitly stated that amounts less than or equal to 0 is not allowed in an expense.

Typo in DG EntryList component UML diagram

It writes EntryXYZComparatord instead of EntryXYZComparator

Program crashes do not save data

After all my data has been inputted, doing cntrl-C, simulating an unexpected crashed, does not save any of my data.
This is a major bug as it will cause valurable data that the program is supposed to track being lost. This makes the program risky to use for a significant purpose. I suggest saving the data at every command

Decimal places for total Expense is not standardized

If I do not add any single digit cents to my expenses, the total expenses show only one decimal place which is inconsistent with common displays of finances.

Adding spaces to time input to addExpense command results in wrong time format

I suggest warning the users about this specific error or accepting additional spaces since spaces are specified as the correct delimiter.

Complicated addExpense Command

The addExpense Command requires users to type in a very long command, causing inconvenience since none of the parameters are optional. Parameters such as HH-mm are too specific and a user would not care so much about tracking the specific timing of their expense in my opinion. I suggest limiting the time to either just months or days, perhaps making some of the parameters optional with a default value for ease of use.

Income is not loaded on restart

Despite having income stored when I exitted the program, it is not loaded when I restarted the program

Parser class UML class diagram errors

Parser class is labelled abstract but is not abstract. In addition, static methods are not underlined.

Adding large total expense causes hard to read format of total expense

I suggest making the format more readable, especially for people who are unaware of the mathematical notation of E.
In addition, this is an uncommon way of showing a dollar amount that users will not be used to.

Error in Command Component Sequence Diagram

Lifelines should not continue past X deletions

Incorrect Dependancy arrow in EntryList UML diagram

The dependency should not have the * as you cannot depend on multiple of the same enum class. It is an incorrect notation.

Missing arrow heads in UI UML diagram

There should be arrow heads at the end of those lines.

Grammatical error in intro message

Prevent you to become broke like me is a grammatical error. I suggest something like prevent you becoming broke like me

Type SALARY of addExpense does not fit its use case

As a user, I would not classify my salary as an expense, even if I am an employer that is paying salaries, it would probably be something like a work expense instead since salary implies a gain in income. I suggest removing SALARY from the available types in addExpense

EntryList UML diagram has incorrect UML notation

The dotted arrows are meant to display dependencies, the arrow to entry should be solid to show reference.

Wrong arrow notation used in UML diagram for UI

The dependency arrow from BrokeMan to UI should be not have any numbers.

UI class diagram errors

UML is labelled abstract but is not abstract. In addition, the static methods in UI are not underlined in the class diagram. This could lead to serious misunderstanding for new developers.

Categories for addIncome does not fit its use case

Currently I can put the type of income added to be categories I would spend on such as GROCERIES, while I as a user would not be gaining income from groceries. If I worked at a supermarket it would be of type income. It is unnatural for income to have these available types. I suggest limiting the types of income to a more select few

Time format differences between commands

Different time formats that users have to type between commands make things confusing and the program hard to use. I suggest standardising the formats