You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Hi, there are indeed multiple arrays of Entry, one in each subclass (IncomeList, ExpenseList). From the UML diagram, IncomeList and ExpenseList classes both have an attribute of incomeList and expenseList respectively, which is why there is a reference arrow pointing to the Entry class. The EntryList super class does not contain an attribute of entryList, because we want to seperate the income and expense into their respective incomeList and expenseList. The EntryList super class only contains methods that are related to the EntryList class, which will be inherited by the sub classes for their method calls.
Items for the Tester to Verify
❓ Issue response
Team chose [response.Rejected]
I disagree
Reason for disagreement: After seeing your response to my issue about the dependency arrow, I agree this is a duplicate issue stemming from that misunderstanding. It should be classified as such. The multiplicity of the dependencies is a clear error that needs to be remedied because as we have found out it can cause a lot of misunderstanding.
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.
The text was updated successfully, but these errors were encountered: