I have a class which has an inner (nested) class. I have shown this relationship between the two classes in my class diagram. However, I am also using the inner class within the outer class… do I show another relationship for this or is the containment relationship enough?
UML Diagrams – Can a Class Diagram Show Two Different Relationships?
class-diagramdiagramsuml
Related Solutions
Your UML diagram is ambiguous about the relation between Expense and Category:
- you use an aggregation, which suggest that there could be several
Categoryinstances related to oneExpense. But the signature of theGetCategory()suggests that there is only one possibleCategoryfor a anExpense - 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
Expenseside and 1..* onCategoryside - 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
categorylabel on theCategoryside 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
Expenseis anExpenseOperationHandler". - 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.
instanceandgetInstance()), 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.
There are a few options.
You could leave these classes out entirely. It would greatly simplify your diagram, but if you have classes that inherent from, extend, contain compositions or aggregations of, or otherwise have similar relations, then this may lead to ambiguities in your digram.
You could include a package on your diagram. Any class that has a relationship to one of these classes could have a relation to the package. Again, this may leave ambiguities in the eyes of the reader.
You could include these classes on the diagram, but have no attributes or methods shown. This way, your classes (which would likely be shown in more detail) will have specific relations to classes in this library. If you choose, you can put all of these classes inside of a package contain to indicate that they all belong to a package, although I find that decreases readability.
Keep in mind that you may not need to show these classes on a class diagram at all. Depending on how you are using them and how they are related to your classes, it may just decrease readability. Use your own judgement as to what features to show on different diagrams.
Best Answer
I would say no. You don't have to specify another relationship.
Inner classes AFAIK are implied to be used by their container. That's why they're an inner class. No one else needs to know about this class and no one has a use for it. This inner class is separate from it's containing object because it's different from the containing object, yet the container has an explicit need for this class and only this object has this need. Therefore, specifying a relationship between the containing class and inner class is enough to inherently imply these two classes are communicating with each other.
If the container class and inner class WEREN'T communicating with each other or worse yet, another object was calling directly to the inner class would show a clear design flaw of ever having this class as an inner class because its design purpose of being an inner class was not being correctly fulfilled.
If you wanted to go deeper in your design at some point you'd specify how the containing class is using the inner class and not just specify the container is using this inner class.