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?

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 '16 at 12:08
I want to know is that a good relationship between Expense and Category? — CrushJelly, Mar 21 '16 at 12:17
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 '16 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 '16 at 12:24
Yeah that's what I want, because you can register DailyExpense whitout a Category. — CrushJelly, Mar 21 '16 at 12:30
Just because there's a relationship doesn't mean it should show up on every diagram. It seems this diagram is trying to show an Expense module. Thus, there's no reason for the CategoryList or Search classes to be in this diagram. Those belong in some other diagram where they are more applicable. Showing multiplicities can also be helpful. Because the aggregation diamond is not filled in then that specifies that Category can exist on its own, like you want. Without knowing all that this module needs to do, it looks fine. Class diagrams don't need to show everything. Just enough to implement. — Dunk, Jul 19 '16 at 21:58
@CrushJelly Are your "Categories" configurable or dynamic? If not you could potentially define an Enum to take the place of your Category object since it looks like it is only holding a "title" string. — Adrian, Dec 15 '16 at 22:59

score 2 · Accepted Answer · edited May 23 '17 at 12:40

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 '19 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: https://www.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 '19 at 18:17

score 1 · Answer 2 · answered Aug 17 '16 at 20:27

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.

How to improve this UML class diagram?

2 Answers2