Salvador Palma
Salvador Palma

Reputation: 162

What's the difference between these types of association in an UML Class Diagram?

I never understood the difference between these types of association. How should I interpret and in which scenarios should I use each one?

enter image description here

Upvotes: 2

Views: 292

Answers (3)

Salvador Palma
Salvador Palma

Reputation: 162

So, according to my college teacher, the first and second one are equivalent. The second one would be "more correct" if the purchase had other atributes, since it doesn't you would opt for the first.

The third one differs a bit from the rest in the way that there can be multiple purchases where the User X bought the Product Y.

So, the first and second would be useful if we only want one record of a purchase between a User and a Product, and the third if we wanted to keep a purchase history for example

Upvotes: 1

Axel Scheithauer
Axel Scheithauer

Reputation: 3680

Given your diagrams all three cases are equivalent. So, I would go with the simplest version.

Adding a Purchase class allows to define features and behaviors of the link objects.

In the second case, Purchase is classifying the binary links between User objects and Product objects. That means each Purchase object is the link between exactly one User object and exactly one Product object. The outcome is the same as in the third case. Only there you have two link objects and one regular object, making the model a little more complicated. On the other hand, in this case you don't need to explain to your readers what an AssociationClass is.

In earlier versions of UML the two latter cases had a subtle difference. If the two ends of the AssociationClass are unique, each pair of User and Product can have at most one link. For a Purchase this is probably not what you want, because the user might buy the same product multiple times. But a stack overflow user can earn each badge only once. The AssociationClass would allow to model this.

Unfortunately this distinction has been thrown out. Therefore, AssociationClasses now don't have more expressive power than regular Classes, making them obsolete. I wrote a specification issue asking to put uniqueness back in.

Upvotes: 2

qwerty_so
qwerty_so

Reputation: 36313

The first one is a named association. The name of the association (being purchase) is pretty pointless unless you are doing some exotic stuff. In this case User and Product have both some array referencing objects on the other side.

The second and third are just alternative notations for the same thing. That is you have an association class Purchase which in this case connects User and Product by adding some (not shown) functionality/attributes. Here the classes left/right do not see each other. It's only Purchase which makes the references.

Edit As noted by @JimL. the 2nd and 3rd differ in one respect: #2 has two* left and right where there should be a 1 to make it a match for #3. This would be the usual use for an association class. The * would make it different and probably very uncommon for the obvious application here.

Upvotes: 0

Related Questions