Suppose you have a ERM containing about 40 Classes / Entities. Most of them in quantified relations to others, some of them as standing there alone.

How to deal with a very often used relation/attribute called image of type Image?

I am afraid, because I have so many entities that own an Image the diagram will be cluttered with lines denoting the relation.

Is it good practice to put the Image entity as a "standalone" class somewhere and just use it as an attribute?

The two images show the difference.

enter image description here enter image description here

2 Answers 2


In short

In fact the two notations are semantically almost equivalent. The only thing that is missing, is that in the second diagram you also express the multiplicity that you would have on the association end, with:

image: Image [0..1]

Additional explanations

Section 9.5.3 of the UML specifications explain that:

A Property may represent an attribute of a Classifier, a memberEnd of an Association, or in some cases both simultaneously.

The difference between the two is about ownership (by the class vs. by the association) being understood that in a binary association like yours, the property could be owned by both at the same time.

Preferring the member end (first diagram) over the attribute (second diagram) is only a convention that does not need to be enforced:

A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.

Indeed, a «dataType» is like a class, but with a value semantic: instances are only distinguished by their values (typical behavior of build-in types in many languages).

This is why you almost always see primitive UML types (String, Integer, Real, ...) and built-in language types (assuming a language specific UML profile is used) as attributes, and all the classes as associated elements. But you're not required to do so, and your example is a perfect illustration, why it makes sense to sometimes derogate from the convention.


Where’s your String relationship? I can see you using the String class but you haven’t shown the relationship.

A UML diagram is best used when you have a point to make. Something you’re trying to show. Focus on that. Don’t try to cram everything on the page or you’ll end up showing nothing but confusion.

So unless Image is the point you’re trying to make here it’s ok to leave off its lines. Show it to us elsewhere.

As for how to get rid of the lines, you get rid of them the same way you got rid of the lines to String.

If you have a diagram of Image somewhere, say on page 42, where it is the point of the page, then you could add a note that says, “see page 42”.

  • String is just a standard Datatype in most UML implementations, like a number. That's why you don't see it in my chart. If I get you right: The question about images doesn't have to be answered, cause images don't interest us right now. OK. BTW. UUID is also not an Entity in my diagram. It is a Datatype. You can also define own Datatypes. The difference is datatypes are used for attributes and there are no relations possible to or with them. That's why I asked this question. Entities/Classes can be related in two ways. And I am asking how to get rid of dozens of lines to the Image entity. Oct 10, 2022 at 13:47
  • Ok, better now? Oct 10, 2022 at 17:15
  • What are you trying to show with the UML? do the lines help? just leave them off and go rogue
    – Ewan
    Oct 10, 2022 at 17:31
  • 2
    @Ewan that’s not going rogue. That’s the tradition. All classes are data types. That isn’t the point. You don’t ignore String because of its type. You ignore String because it isn’t the point you’re trying to make. Oct 10, 2022 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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