How to improve this UML class diagram?

Question

How can I improve this UML class diagram?

I'm really confused about the relationship between Expense and Category, because Category and Expense can exist by themselves: you can register Expense and not assign a category, you can add new Categories to the categories list, and so on...

Do I really need separate List classes?

Diagram

• Thomas Owens: What, exactly are you trying to improve - the diagram or the design? Also, what do you mean by "Category and Expense can exist by themselves" - according to this model, and Expense cannot live outside of an ExpenseList and a Category must be part of a CategoryList to exist. It does agree with you that you can have an Expense without a Category, though.
• CrushJelly: I want to know is that a good relationship between Expense and Category?
• Thomas Owens: Define "good". Right now, the diagram says that Expense has zero or more Categories. Is that what you want? Without knowing what your objective or requirement is, no one can tell you if your design is good.
• CrushJelly: I want to know is that a good relationship between Expense and Category? When you fill in expense information you can assign it to a category, or you can skip this step. When you register Expense it goes to expense list, when you add new category it goes to category list.
• CrushJelly: Yeah that's what I want, because you can register DailyExpense whitout a Category.

Answer 1

Your UML diagram is ambiguous about the relation between Expense and Category:

• you use an aggregation, which suggest that there could be several Category instances related to one Expense. But the signature of the GetCategory() suggests that there is only one possible Category for a an Expense
• the aggregation also suggests a part/whole relationship which is not the case here. So I'd suggest to use a relationship with cardinality 0..* on Expense side and 1..* on Category side
• you show the relation to Category twice: once via the graphical connection, and once as an explicit property. I'd suggest removing it from the list of properties, and add a category label on the Category side of the association, to convey the naming of the relation.

Your diagram is ambiguous about the relation between Expense and ExpenseOperationHandler :

• you use a generalization relationship, which says basically "an Expense is an ExpenseOperationHandler".
• But semantically it appears that an Expense could use/have an ExpenseOperationHandler, or that it could implements/provides such a handler. So I'd suggest to use a doted line going to the triangle to show that it's about realization rather than a conceptual inheritance, at least from the design point of view.

Do you need ExpenseList and CategoryList ?

• You could imagine to have several distinct category lists (e.g. for different users, or depending on which context the expense is used) or expense lists (e.g. personal expense vs. professional expense). In this case you'd need these classes wihich would be part of your domain model.
• But looking at properties and operations of your classes, it appears that you intend to implement them as singleton (e.g. instance and getInstance() ), so that there is only one such list, containing all the related items. In this case it depends of the purpose of your diagram: the answer would be no for domain modeling, but it could be yes, for design (e.g. you'd need these classes in you UI design) or implementation details.

• Onic Team: I'm mid level developer (expertise in java, Spring,hibernate ) My Problem is I want to create a web application project from scratch for my self practice but I'm confused when I completed my configuration because of I don't have idea about UML diagram ER diagram (How to think about it) and very serious problem when i started to create POJO-> here i confused which class is abstract whichn one is parent or child relationship. I request to you please guide me. I have tried lot of times to improve my architecture design but every time got failure
• Christophe: If you're in OO, concenterate on UML. ER is excellent for database schemes, but a n UML clas sdiagram can show everything that an ER diagram can show, and more. Here the abstract handler is a problem since it's not really an abstraction from Expense. Better look at Expense which is the more general concept above DailyExepense and MonthlyExpense. If you want to know more, look here: uml-diagrams.org/class-diagrams-overview.html - It's an excellent site about UML diagrams. If you have a question, just create one here on StackOverflow.

Answer 2

• It would be nice that the Search interface have void filter methods that filter the ExpenseList instead of returning a List<Expense> and ExpenseList should be iterable. What sense makes a class called ExpenseList implementing methods to return List<Expense>. An alternative whould be the filter methods returning a new filtered ExpenseList object, if we want to keep things inmutable.

enter image description here