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?


  • 2
    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.
    – Thomas Owens
    Mar 21, 2016 at 12:08
  • I want to know is that a good relationship between Expense and Category?
    – CrushJelly
    Mar 21, 2016 at 12:17
  • 2
    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.
    – Thomas Owens
    Mar 21, 2016 at 12:18
  • 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
    Mar 21, 2016 at 12:24
  • Yeah that's what I want, because you can register DailyExpense whitout a Category.
    – CrushJelly
    Mar 21, 2016 at 12:30

2 Answers 2


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.
  • 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
    – Onic Team
    Sep 22, 2019 at 18:03
  • 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.
    – Christophe
    Sep 22, 2019 at 18:17
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.