This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Class Diagram I: Association

A private preface:

It took me some time to continue the blog, as I was pondering about 'associations'. Still I think I did hit a big point in doing graphical OOP. In retrospective, the challenging issue is that I can easily write/draw properties or classes in a programming language, while I don't know a language construct for an association.

As a LabVIEW programmer, drawing a line between nodes is something concrete, and I couldn't get an association drawn at all. In uml an association is a full featured element: it is a specialization of the classifier. As such it can own features (properties and operations) and is subject to inheritance.

Let's start:


The class diagram is a really important concept, so I devided it into several posts. At first I go for the Association:

  • An Association connects 2 or more properties.

  • The Properties are also called 'association ends'. The Properties are associated as memberEnd.

  • The instance of an Association is called a 'link'.

  • An Association can be derived. This is denoted by a slash in front of the name of an association.

  • An Association has the type(s) of it's properties.


  • A property is either owned by a Class or by an Association.

  • If they are owned by the Association, they are associated as ownedEnd.

  • If an Association links more than 2 Properties, they must all be owned by the Association.

  • Only if a Property is owned by a class, the class can access this property directly. An association end owned by a class is also an attribute. It is listed as an ownedAttribute (shown in the class node).

I don't understand how a class can access a property that is owned by the Association (this is important, because it can be navigable).


Property owned by a class:

  • If the property is owned by the class, it's navigable (from the class). Then it's also listed as a      property of the class.

  • If both properties are owned by classes (hence they are navigable), the operation opposite returns      the other end.

Property owned by the Association:

  • If the property is owned by an Association, it depends if it's listed in navigableOwnedEnd. This implies that a non-navigable end must be owned by the association.

  • As said above, I do not yet understand the meaning of a property that is not owned by a class and navigable by the association. This is related to the fact, that I don't know of a language construct that represents an association.

  • If a property is navigable is returned by the isNavigable() operation of a property.

  • To add more to the confusion, a non-navigable property cannot be marked as readOnly.

A summary of what I don't understand yet:

  • How to realize a property (in a programming language) that is owned by the association and navigable.

  • What is the meaning of an Association where both ends are not navigable.

  • Why is a non-navigable property never readOnly.

In the sematics section, there is a nice explanation of the keywords that deal with inheritance:

  • A classifier can specialize a classifier by adding or redefining features. (As an association as a classifier, it can specialize another association, redefining the properties at the association ends).

  • Features (not classifiers) are redefined.

  • Subsetting means the set-theoretic concept (big word for something I learned back in school: {A,B} are a subset of {A, B, C}). This mechanism is applied to the association ends/properties, not to the association.


The only way I see how we draw associations is by putting an object (or an reference to an object) in the classes private data cluster. So the property is owned by the class.

For bidirectional associations and self-referencing associations, we need to use a more generic type and a type cast. If you'd try to reverse engineer a LabVIEW class structure, you wouldn't get the correct association but two of them, at least one linking to a parent class of the other.

0 Kudos
Message 1 of 3

Re: Class Diagram I: Association

Some new insights: I was wondering why the Association inherits from Classifier and not from Relationship. During this discussion on LAVA, I realized a simple explanation: An Association needs to own properties (structural features), including to provide the option to redefine the properties.


0 Kudos
Message 2 of 3

Re: Class Diagram I: Association

0 Kudos
Message 3 of 3
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.