2

So I have an association class C that is an association between classes A and B. Class D is a subclass of class C as it contains data from class C. Is it possible? and can it be represented as a diagram? If yes then how can I associate class D with class A and B too since class D is also an association class to classes A and B?

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
beginnernoob
  • 21
  • 5
  • Why did you flag this with ìnheritance`? – qwerty_so Apr 07 '22 at 20:09
  • Why do you think that the fact that D is an association class for the A-B assocation prevents D from also having an association with A or B? – www.admiraalit.nl Apr 08 '22 at 07:14
  • 1
    Also of interest: https://stackoverflow.com/q/62973692/3723423 – Christophe Apr 09 '22 at 13:20
  • Hello beginnernoob, are you satisfied with one of the answers? Then please check that answer as 'accepted'. Otherwise, please let us know what you need. – www.admiraalit.nl Apr 13 '22 at 10:29
  • @Christophe: I think your conclusion in your answer (in https://stackoverflow.com/q/62973692/3723423) that a simple class rectangle cannot be used for specializing an association class rectangle was premature. Using this notation, as in admiraalit's answer below, simply implies that the class rectangle represents an association class that inherits the association. There is no need to re-draw the association line. – Gerd Wagner Apr 13 '22 at 20:21

2 Answers2

1

Let's take an example:

  • A = Person
  • B = Team
  • C = Membership
  • D = Leadership

cd

You have two questions:

  1. Is it allowed to have the generalization between C and D, i.e. between Membership and Leadership?
  2. Is it allowed to have an association between A and D, i.e. between Person and Leadership, like association 'assists' in the diagram?

Ad 1: The UML 2.5 specification, section 11.5.3, last sentence, reads:

An AssociationClass cannot be a generalization of an Association or a Class.

That is why people say the answer is 'No' and I think they are right. However, one might argue that Leadership inherits all properties of Membership, even the fact that it is an assocation class. I don't see any problem with this interpretation. It prevents the need for modeling an extra association, just to let Leadership be an assocation class by itself. So, I would say it is allowed.

Ad 2: Yes, it is allowed to have an association between a normal class and an assocation class, like association 'assists' in my example.

www.admiraalit.nl
  • 5,768
  • 1
  • 17
  • 32
  • Inheriting a metaclass would be a completely new kind of Generalization. I'm not sure, whether such an unconventional modeling element should be introduced. Of course, we could simply say that this notation _means_, that `Leadership` is an AssociationClass in the model. However, the problem remains, that a Property can only be linked to one Association. I think, changing this would have a large impact and doubt, that it would be worth it. Especially, since AssociationClasses can easily be replaced with a normal Class and two Associations. – Axel Scheithauer Apr 11 '22 at 08:38
  • @AxelScheithauer Could you explain the problem? Leadership does not introduce an extra association. Every link (instance of association) between Person and Team is either an instance of Membership or an instance of Leadership. – www.admiraalit.nl Apr 11 '22 at 20:53
  • 1
    The problem is the abstract syntax, that follows from this notation. How would you define it? Both Membership and Leadership would be `AssociationClasses`. As such they must have at least two `memberEnds`. Those cannot be shared by multiplice Associations, since each `Property` that is a `memberEnd` has an `association:Association[0..1]`. In your model, it would need to have 2 Associations. Yes, you can derive it from the `Generalization`, however, this derivation would need to be standardized. Otherwise, there would be no standard way to find the possible Associations for a given `attribute`. – Axel Scheithauer Apr 12 '22 at 08:43
  • @AxelScheithauer: What do you mean with "abstract syntax"? I can just see ordinary UML syntax: `Membership` is specialized by `Leadership`, implying that the latter is also an association class. – Gerd Wagner Apr 12 '22 at 19:33
  • @GerdWagner The concrete syntax (notation) for the abstract syntax (instance of the metamodel) of an AssociationClass in the model is a line connected to a rectangle with a dashed line. This is not shown here. Therefore, `Leadership` is apparently not an AssociationClass. We could change the concrete syntax, to _mean_ that it is one. But then the problem is, where are the two Properties used as memberEnds for the AssociationClass? We could again change this, but is it worth the effort? – Axel Scheithauer Apr 13 '22 at 08:24
  • There is no need for expressing the association-classness of `Leadership` by means of the dashed line, since it is implied by the generalization arrow. Therefore, where you see a probelm, there isn't really a problem. – Gerd Wagner Apr 13 '22 at 10:43
  • @GerdWagner I understand that you could make this interpretation based on the impossibility of a class to inherit from an association class. However, I think that this is a personal interpretation, and that the shortcut in the notation is at best ambiguous and at worst inconsistent. I see the problem exactly as Axel. I’d be ready to change my mind if your claim would be backed by authoritative quotes of the specifications. – Christophe Apr 13 '22 at 20:50
0

If, as you say, Class D is an AssociationClass as well, it is possible.

However, a simple Class cannot be a subclass of an AssociationClass.

Where is the problem representing this in a diagram? Simply show the Generalization between the two AssociationClasses. Please note, since Associations are Classifiers, even simple Associations can have a Generalization. enter image description here One problem is, that the AssociationEnds of D will be separate Properties. You want them to be the same Properties as the ends of C. The only way to achieve this, as far as I can see, is to make them subsets, and derive them.

Edit: To completely avoid the problem, you could simply use a normal class and two associations: enter image description here Since the UML-taskforce has unfortunately removed the only reason for the existence of AssociationClasses, there is no disadvantage in doing so.

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • In your model, D would have four attributes: it would inherit a and b, and in addition have a1 and b1. That's probably not what you've intended? – Gerd Wagner Apr 10 '22 at 12:02
  • D doesn't have any attributes - memberEnds are not attributes. I agree, that there are too many attributes, owned by A and B. Therefore, I made them derived. I don't see another possibility. – Axel Scheithauer Apr 11 '22 at 08:02
  • Member ends are properties, which are attributes of a class partipating in the association when they are owned by it. Since you didn't specify the ownership of the association ends, it's not clear if they are attributes of A or B, or of C and D. – Gerd Wagner Apr 12 '22 at 19:30
  • @GerdWagner You are right, I didn't specify ownership. It is not mentioned in my answer and not needed for my argument. Even when the Association owns its ends, they don't become attributes of it. That may sound strange, but it's defined like this. And this also doesn't change the fact, that the memberEnds of D cannot be the same as those of C. So we have two superfluous properties. PS: I changed the term "attribute" to "Property" in the answer, to make it more clear. – Axel Scheithauer Apr 13 '22 at 08:12
  • When an Association owns an end, the end becomes a Property of the Association, and all properties of a classifier are called *attributes* (see 9.2.3.1 of the spec). – Gerd Wagner Apr 13 '22 at 11:04
  • @GerdWagner `Classifiers` have `features` and `attributes`, both are derived unions. `Class::ownedAttribute` is a subset of `attribute` and `Association::ownedEnd` is a subset of `feature`. Therefore, an `ownedEnd` cannot be an `ownedAttribut`. The sentence in the specification is misleading. The only subsets of `attribute` defined are `ownedAttribute` for `Classes`, `Interfaces`, `Datatypes`, `Signals` and `Artifacts`. This is not changed for `AssociationClass`. Maybe it should be - at least SysML had to introduce «participant property» for this purpose. – Axel Scheithauer Apr 13 '22 at 20:44
  • Okay, thanks for the explanation. It shows that the property/attribute terminology used in the spec's formal metamodels is not consistent with the informal property/attribute terminology used in the spec's sentence "A Classifier has a set of Features, some of which are Properties called the attributes of the Classifier" in 9.2.3.1. That's quite confusing! Btw, what is the only reason for the existence of AssociationClasses that has been removed, as you say above? – Gerd Wagner Apr 13 '22 at 22:00
  • The specification says: "_NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end_". Before the addition of this sentence it was commonly interpreted otherwise. There are good reasons for the clarification. However, I now can't see any difference to normal classes (with the exception that AsscociationClasses can get used as types of connectors). I wrote issue [UMLR-757](https://issues.omg.org/issues/UMLR-757) about this. – Axel Scheithauer Apr 14 '22 at 08:21