2

For example I have a relationship like this: user (0..*) buys product (0..*)

Which results in an association class, called sale, which has the userID and productID. Just for the question's sake, imagine this sale class has NO other attributes, except for these IDs.

My question is, should I show this sale class in my class diagram? Or can I just leave it and only show the relationship.

Although I have never seen this done before, I am asking because someone told me you don't need to show the association class if it has no relationship attributes.

4

According to the UML 2.5 specifications:

11.5.3.2: An AssociationClass is a declaration of an Association that has a set of Features of its own.

This means that a many-to-many association with no features of its own is not an association class. Hence it should not be represented as an association class on the diagram.

The fact that in a database it would be implemented as a "relation" (in the RDBMS sense, i.e. a table) does not change the way the model should be represented: This is an implementation detail.

You could event have an N-ary association (associating more than 2 classes). It would be represented with a diamond as N-ary connector, but if it has no set of features of its own, it would still not be considered as an association class.

Conversely, if there is a set of feature of its own, then it is an an association class, and then this should be represented on the diagram:

11.5.4. An AssociationClass is shown as a Class symbol attached to the Association path by a dashed line.

| improve this answer | |
  • Thank you for a very good answer. But I have one doubt. By features does it also include relationships? Imagine that I need to create a relationship with that sale class. I think then I will need to show that class. Am I right? – imran.razak May 20 '17 at 13:11
  • Excellent question ! I was expecting it; this is why I added the paragraph about N-ary associations. Your comment refers to a ternary association, i.e. an association between three classes. But if it still has no feature of its own, it's still no association class. You'll nevertheless have a diamond to connect more than 2 items. – Christophe May 20 '17 at 20:49
  • So do you mean that if I have a many-to many relation between two classes and then if I need to create an association with the resulting class then it means that I should have a ternary relationship? For example: user buys product, results in the sale class. Now if I need to create a relation between the sale class and a provider class for example then does it mean I should have a ternary relation originally? Like this user buys product that belongs to a provider which results in the sale class. – imran.razak May 21 '17 at 11:14
  • If we take the UML standard by the letter, yes it should be like this. However, ternary associations are rarely used in practice. In addition, the standard says that a property could be represented by an association and conversely, leaving you the choice on how to represent it. Otherwise stated, you may just show a ternary association, or you may consider the additional association as a property and use an association class. So here, you have the choice. – Christophe May 21 '17 at 11:46
2

This depends on the purpose of your UML diagram:

Are you modelling, illustrating, or analysing the problem domain? Then don't invent extra concepts. Only show the relevant relationships. Using an n:m relationship as you suggested is probably clearest.

Are you creating a concrete design, or are you documenting existing code? Introducing a Sale concept is an important design decision that should be included in the diagram. Simple classes with no extra properties aren't a problem – simple classes are clean. Showing a direct relationship when you've implemented that relationship with a class could be misleading, but that depends on the context.

For the special case of a relational database design, I would usually not show the association class in most cases. It is clear from the n:m relationship that this relationship will be implemented with a separate table, assuming a sufficiently normalized database. But if you want to document the relationships of existing tables, showing a class per table including a class for the Sale would be the clearest approach.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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