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?

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.

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.