N-Ary Associations and Association Class

[Paolo F Cantoni]

Over the weekend, I had occasion to attempt the attaching of a Class to an Association "lozenge" (the big diamond thing - to be fully technical  ).  It can't be done in EA.

I fired off a bug report and temporarily used a «represents» dependency to hold the linkage.

Today I had occasion to look at this again and noticed that I need to keep two lots of things synchronised.  The "lozenge and it's associations (if that's what they are)" and the class and it's associations (because that is what they are) - remember any attribute can be rendered as a named navigable association role.  After the third one of these I got annoyed and thought this is probably the wrong way to look at it.

After thinking for a while, it struck me that the Association Class is just a different rendering of the Association (lozenge).  In fact, the Association Class is just a different rendering of the binary association!  It's just that with only a single line between the classes involved, the current UML rending of the class linked to the association line is adequate.  You could just as easily render it as an interposed class with the two "identifier" associations completing the link.  Those of us from a Data Management background immediately associate Association Classes with Intersector Tables.

In the case of the n-ary association, the analogy is even stronger, in my view.  What I intend to do therefore is to use only the Association Class and formally ask Sparx to provide an alternate rendering as the lozenge.  Anybody come up with a reason why this wouldn't work?  It would sure save me a pile of extra effort if it does...

BTW: by rendering I mean the equivalent of dragging an Interface onto the diagram and saying Use Circle Notation in this case, you would say Use Lozenge Notation.

Cheerz,
Paolo

[Kevin Brennan]

Isn't the Association Class a different entry on the selection list from the structure diagram? It's just below the Aggregate link on mine.

Or did I misunderstand you?

I do know that once you have an association present, you can't attach an association class to it. You have to delete the original association and replace it.

[Paolo F Cantoni]

Isn't the Association Class a different entry on the selection list from the structure diagram? It's just below the Aggregate link on mine.

Or did I misunderstand you?

I do know that once you have an association present, you can't attach an association class to it. You have to delete the original association and replace it.

No, you didn't misunderstand me Kevin.  

The Association Class in (EA) is BOTH a predefined package of objects (located where you said) which will draw the binary Association and add the Association Class in one go, AND the result of a process where you can attach an existing Class to an existing Association and thereby create an Association Class (Right-Click|Advanced Settings|link Class to Association).  In both cases, after the process completes, you bring op the properties of the Class and it reads Association Class : <Name>.

My thesis: For an N-ary Association I should be able to have an option:  Right-Click|Advanced Settings|Change Class to Association Class. Then I can chose to render the Associating Class as a box or Lozenge.

The N-ary Association is the one I described.  I'm suggesting (strongly) that the N-ary Association and the Association Class are one and the same.

Does that clarify matters?

Thanx,
Paolo

[Kevin Brennan]

Yes, it does. Yes, I can see why you want to do that. No, I can't find a way to do it either short of deleting the original and creating a new one.  :-/

[sargasso]

Although I cant understand the "why", it appears to me that the lozenge and the association class aren't the same thing ... according to the OMG.

Sup 2

Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association end connecting the diamond to the classifier that is the end’s type. An association with more than two ends can only be drawn this way.

IOW a binary association is a special case of an n-ary association.  Also, it appears that the diamond/lozenge itself has little or no semantic value.

An association class on the other hand does have semantic value in that it describes classifier like properties of the association.

Sup 2

A model element that has both association and class properties. An AssociationClass can be seen as an association that also has class properties, or as a class that also has association properties. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not to any of the classifiers.

(I love the second sentence in the above btw)

What is incorrect, IMO, is that you cannot connect a class to the lozenge as an association class (I think thats what you meant in your initial sentence).  EA allows you you to conect the putative association class to any one of the ends of a "lozenged" association, but not the lozenge itself.  If it did, it would allow us to properly set up lozenged associations as association classes.

OTHO I note you can connect the putative association class class to the lozenge using a realization link.  I'll leave the semantic interpretation of that to better minds (a classifier that realises an association???).

Interestingly (or not), I cant find anything in the spec on this type of structuring.

bruce

p.s. Paolo, could you provide definition of "represents" as you have used it - looks more promising than realizes.

[Paolo F Cantoni]

Hi bruce,

thanks for the research...

Although I cant understand the "why", it appears to me that the lozenge and the association class aren't the same thing ... according to the OMG.

Sup 2

Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association end connecting the diamond to the classifier that is the end’s type. An association with more than two ends can only be drawn this way.

The key for me are the words association end.

IOW a binary association is a special case of an n-ary association.  Also, it appears that the diamond/lozenge itself has little or no semantic value.

Well, yes and no (IMHO:))... You're absolutely right when you say a binary Association is a special case of the N-ary Association. the reason is that it can be represented as a lozenge with two associationEnds!  That's why I said I wasn't sure the "spikes" were Associations - in UML, they're NOT, they're associationEnds!  This wasn't clear to me until your quote!  By convention, UML allows the "degeneration" of the lozenge to a point in the case of the binary association, but, in my opinion it's still there!

An association class on the other hand does have semantic value in that it describes classifier like properties of the association.
Sup 2

A model element that has both association and class properties. An AssociationClass can be seen as an association that also has class properties, or as a class that also has association properties. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not to any of the classifiers.

(I love the second sentence in the above BTW)

Yes, OMG are being very twee here (as you indicate below on not being able find anything in th specification on this structuring).
The specification says nothing about the AssociationClass being restricted to binary Associations (as far as I can see).

What is incorrect, IMO, is that you cannot connect a class to the lozenge as an association class (I think thats what you meant in your initial sentence).  EA allows you you to connect the putative association class to any one of the ends of a "lozenged" association, but not the lozenge itself.  If it did, it would allow us to properly set up lozenged Associations as AssociationClasses.

Yes, I now agree that EA shouldn't have allowed me to connect the AssociationClass to the lozenge, but precisely because the lozenge IS the AssociationClass - exactly as you say!  Those lines (spikes) are associationEnds NOT Associations!  I think we need EA to support the AssociationClass as the lozenge under a different rendering and to support the spikes as associationEnds (basically the TargetRole of an association ONLY.

OTHO I note you can connect the putative association class class to the lozenge using a realization link.  I'll leave the semantic interpretation of that to better minds (a classifier that realises an association???).

Interestingly (or not), I cant find anything in the spec on this type of structuring.

bruce

p.s. Paolo, could you provide definition of "represents" as you have used it - looks more promising than realizes.

I'm no longer using the «represents» dependency - it was merely a "placeholder" until the EA functionality was rectified.

As I've tried to emphasise, I'm NOW of the view (reinforced by what you discovered in the specification) that a named, navigable associationEnd IS an attribute (and vice versa) and that an AssociationClass IS the N-ary Association lozenge and in the case of the binary Association is the hidden lozenge in the middle.

BTW: if the AssociationClass has (itself) Associations with other Classes (which it must if has attributes) then which Associations are the one that make up the N-ary bit and which ones aren't?  under my proposal, those associationEnds that make up the N-Ary are only associationEnds, the others are true associations!  I've got a special stereotype «end» which designates the "association" as an associationEnd ONLY... (Therefore only the TargetRole has meaning and must be singular mandatory etc etc etc)

When we separately render the AssociationClass we can put in the "link" we see now - not because the AssociationClass is linked to the Association but precisely because it is the Association (the lozenge) - whether degenerate or not...

I think this all makes consistent sense to me...

What do you (and others) think?

Paolo

[sargasso]

Lessee...


--------<<end>>---------[size=28]&#9674;[/size]---------- <<end>>------------

(for earthlings that dont have browsers that properly render extended character sets where you see &#9674 see a large diamond).                                                                            

Agreed!  "Ends" aren't associations.  But I differ in that my interpretation is that the lozenge is the <<association>> element whether it is visible or not.

Disagreed!  The attached class is not the <<association>> element.  My interpretation is that an association element plus a dotted line plus a class is in fact a different thing - callled by OMG (to keep things as clear as usual) an <<association class>> element.  

Rationale for disagreement: nothing logical at the moment only a sneaky feeling that one day I may need to delineate between the two elements and thus EA should
1) keep the current notation
2) allow association classes to be constructed between the class and the diamond.

bruce

p.s.  around that section is some trooly interesting reading about inheritibility aspects of associations.  I am now converted - associations should be inherited, and EA should support the constrained inheritence annotations.

p.p.s.  I cant move / format the bl**dy labels on the diamonds either (as well as labels on interface elements).

[Paolo F Cantoni]

Lessee...
[SNIP] ... and thus EA should
1) keep the current notation
2) allow association classes to be constructed between the class and the diamond.

bruce

p.s.  around that section is some trooly interesting reading about Inheritability aspects of associations.  I am now converted - associations should be inherited, and EA should support the constrained inheritance annotations.

p.p.s.  I cant move / format the bl**dy labels on the diamonds either (as well as labels on interface elements).

bruce, I'll settle for 1) & 2)

But, with respect, if you read the quotes you provided, and the general section there around, you'll see it says these things may be drawn in a certain way.  If you define an AssociationClass as a Class which must have at least two associationEnds attached that define the endpoints of the (N-ary) Association, it all "falls out in the wash"

That way:

• EA's existing functionality of drawing the line and the (separately rendered AssociationClass) is still valid.
• The existing functionality of attaching a (normal) Class to an existing binary Association is still valid.  What's actually happening is that the Class is being converted to an AssociationClass (with the minimum of two associationEnds)
  
• We can (easily) add the ability to link an existing Class to an existing N-ary Lozenge.  Again, converting the Class to an AssociationClass.  I think that's what you mean with 2) above - please clarify if it isn't.
  
• We can (optionally) render the lozenge as the box rendering.
  
• AND... we can apply Association inheritance using the existing Generalization mechanisms via the AssociationClass wot iz the Association!  Like you wanted!
  

I'm now modelling as though this is the way it will behave and it seems to work a treat.

Paolo

PS - I too noted the fact you can't move/format the labels

[rty]

Just for the records: it's possible with EA 12.1. Solution described at "3-way Association Class" thread (http://sparxsystems.com/forums/smf/index.php/topic,15474.0.html).

[StefanPears]

ten years after (alvin lee) 

[Geert Bellekens]

N-ary associations have been supported for quite a while now. I'm guessing it must have been version 8 or 9 when they were introduced.

Geert

[Paolo F Cantoni]

Just for the records: it's possible with EA 12.1. Solution described at "3-way Association Class" thread (http://sparxsystems.com/forums/smf/index.php/topic,15474.0.html).

Actually, rty

Your solution is, unfortunately, incorrect from a modelling point of view.  The lozenge IS the association class.  So you are actually missing the AssociationEnd between the lozenge and the class Job. The lozenge should, by the way be, formally named: Person in Job for Company - since it is the ternary relationship linking the three classes).  You should NOT use the binary AssociationClass mechanism to model ternary or greater relationships.

Since then I have formalised the notation in the following way:
N-ary associations (including binary) have identifying AssociationEnds (that define the "ary" nature of the Association(Class)).  The AssociationEnds are represented by suitably modified Associations to indicate that they are actually representing AssociationEnds.
For Binary Associations, if an AssociationClass is defined, they are decorated with a small lozenge shape in the centre - where the dotted line joins the Association.  That lozenge shape is NOT the AssociationClass, but indicate one exists, even if not present on the diagram.
Similarly, n-ary (including binary) AssociationClasses are adorned with a small lozenge to indicate that they are Associative, and further decorated with a second included lozenge to indicate if they are bound to a binary association.

This conceptualization and rendering has worked extremely well for the last 5 years or so and is fully consistent with the n-ary relationship conceptualisations I've documented in various posts onthe forum.

HTH,
Paolo