Association class - multiple associations

[Glassboy]

Strictly speaking should an association class be able to linked to multiple associations?

[Paolo F Cantoni]

Strictly speaking should an association class be able to linked to multiple associations?

Strictly speaking, I believe, YES!
The Association Class is an anaemic form of the N-Ary Asscoation (the Lozenge)  with the two association ends (links / access functions) overlayed as the dotted line to the association.

In our MDG, we have a new type of relationship the N-ary AssociationEnd - these represent the two access functions connecting the intersector Association Class to its two "owners / identifiers".  The AssociationEnd relationships are used to distinguish between those relationships that are used to provide identity to the N-ary Association and those that are just normal relationships between the Association Class and other Classes.

Accordingly, we use the AssociationEnd relationships to link the lozenge N-ary relationship to the identifying endpoints in the same way.  There's just more of them.  We've thrown away the Lozenge shape for the N-ary Association objects and instead made all associative classes (2-ary Association Class to 2+-Ary Associations) to display a lozenge in the top left corner to indicate their special status.

We also automatically create the AssociationEnds where appropriate.  So that if you place only one end and the Association Class on a diagram you can see they are related.  We also, in the past, found a way to actually link multiple Associations to the AssociationClass (by some SQL "sleight of hand"), but I can remember if Sparx fixed the anomaly that allowed us to do that, or we just found it wasn't that useful.

Finally, when we create an AssociationClass for a binary relationship, we also indicate the "materialization" of the Association into an AssociationClass by a complementary lozenge on the Association arc so that if you ONLY place the two end-points on a diagram, you can see there is an "off-diagram" AssociationClass defined.

HTH,
Paolo

[Simon M]

No. Strictly speaking, the class, association and link between them are a single entity. There are just multiple parts to the notation for a single element.

You could inherit multiple association classes from a common class (or a common association) and there's no reason that you couldn't connect to a ternary¹ association.

¹ Shorthand for an association using diamond notation. Actually can be n-Ary, where n > 2.

[Paolo F Cantoni]

No. Strictly speaking, the class, association and link between them are a single entity. There are just multiple parts to the notation for a single element.

You could inherit multiple association classes from a common class (or a common association) and there's no reason that you couldn't connect to a ternary¹ association.

¹ Shorthand for an association using diamond notation. Actually can be n-Ary, where n > 2.

Well, as you can see, that's debatable...   

I forgot to mention in my original argument that one can / should view the binary relationships between any two endpoints of an 2+-ary relatinship as 3rd normal form restrictions on a 4th or 5th normal form.  If the AssociationClass is the Lozenge then it is appropriate to link it to the binary associations involved.


Paolo

[Simon M]

Well, as you can see, that's debatable...   

You can debate if OMG should have allowed it. Not if they did.

An association class inherits from both an association and a class.

UML 2.5 says,

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 Association itself and not to any of the associated Classifiers.

An AssociationClass is a declaration of an Association that has a set of Features of its own. An AssociationClass is both an
Association and a Class, and preserves the static and dynamic semantics of both.

Both Association and Class are Classifiers and hence have a set of common properties, like being able to have Features, having a
name , etc. These properties are multiply inherited from the same construct (Classifier), and are not duplicated. Therefore, an
AssociationClass has only one name , and has the set of Features that are defined for Classes and Associations.

Emphasis mine shows that it is always refering to the singular for both the class and association portions.

At a metamodel level, for an association class to be able to link to multiple associations, you would need to inherit only from Class, and then have an association to Assocation with a multiplicity of 1..*. There are probably other ways, but none of them are what you find in the specification.

[KP]

My turn...

Strictly speaking should an association class be able to linked to multiple associations?

In UML, no. One AssociationClass = One Association + One Class

In EA, perhaps. If an Association has more than two ends, it will need to be represented in an EA model by multiple Association connectors, and each connector will need to know it's part of the single entity, however you choose to model that.

Why do you ask?

[Glassboy]

Why do you ask?

Well consider the following associated entities (that all extend 'real person')

Employee ----- Dependent
Employee ----- Emergency Contact

Both of the associations describe a human relationship and if expressed as an association class would be exactly the same.

[KP]

Well consider the following associated entities (that all extend 'real person')

Employee ----- Dependent
Employee ----- Emergency Contact

Both of the associations describe a human relationship and if expressed as an association class would be exactly the same.

If the two Associations are the same, I would model them as a single Association (or AssociationClass) between Employee and an abstract super-class of Dependent and Emergency Contact.

[Geert Bellekens]

Also look at the party-partyrole pattern.
That is in most cases an elegant solution for this type of situations.

Geert

EDIT: PS. I haven't found a decent reference to this, pretty much well known pattern. Maybe I should write something about it myself one day

[Paolo F Cantoni]

Why do you ask?

Well consider the following associated entities (that all extend 'real person')

Employee ----- Dependent
Employee ----- Emergency Contact

Both of the associations describe a human relationship and if expressed as an association class would be exactly the same.

Only if you don't separate the associations into different instances within the AssociationClass by providing a discriminator characteristic that indicates the different semantics involved.   Typically, this would be a type characteristic.  So first association above would be of type: Dependent , the second of type: Emergency Contact.

Formally, the (UML) AssociationClass is the materialization of the (generic) Association between persons (to which you alluded).  The two semantic variants of the generic Association are specializations (restrictions) on the generic Association.  According to what's been said, you should be creating three Associations and three related AssociationClasses, but what is really going on, is that the generic AssociationClass should have the discriminator and the two specialized AssociationClasses would be merely restrictions (using the discriminator) on the generic - thus mirroring the semantics of the binary Associations.

So, as with ArchiMate, UML's restrictions may be self-defeating.  If the intent is accurately and effectively model the semantics, you have to go past the "standards".

HTH,
Paolo

[Glassboy]

If the two Associations are the same, I would model them as a single Association (or AssociationClass) between Employee and an abstract super-class of Dependent and Emergency Contact.

Probably should just have an association class between Natural Person and itself for that matter :-)

[Paolo F Cantoni]

If the two Associations are the same, I would model them as a single Association (or AssociationClass) between Employee and an abstract super-class of Dependent and Emergency Contact.

Probably should just have an association class between Natural Person and itself for that matter :-)

What do you mean should have?  You do have.  You just may not have included it in your repository.

It's all about the semantics.

I've played around with a concept I call Sematypes.  I haven't fully conceptualised it, but it is needed because EA only allows rendering via shapescript for stereotypes.  Basically, you have metatypes which have distinct behaviours, based on the basic type.  For example, we have generic Specialization which separates into the two forms we assert (others may not agree, but it works for us):  Inheritance and Restriction.   They are metatypes because Inheritance is "IS_A_TYPE_OF" whereas Restriction is "IS_A_WHERE".  On the other hand, we have various types of Associations that are used frequently and need to be named because they're semantically different from another Association.  Your example is a case in point, you have two sematypes: "dependent_of" and" emergency_contact_for".

In our specification process, we denote which shapescripts are for metatypes and which are for sematypes.  Sematypes are given their own "stereotype" but not because they are inherently a different metatype, but because they occur often enough that we wish to give them a unique rendering.  EA defines a metatype: a unique combination of type and stereotype and , as I said, you can only create a shapescript for a stereotype so we create a synthetic stereotype for that sematype.

After being forced to use it by EA, I think that there's actually some merit in considering them a real concept.

Thoughts?
Paolo

[Simon M]

What do you mean should have?  You do have.  You just may not have included it in your repository.

It's all about the semantics.

Semantics - Does an association class already exist before creating a UML representation of something? Is every system/environment being modeled a UML model before someone creates that abstraction? If there are multiple correct ways to model something, does that mean that you automatically have all of them if the model describes something a different way?

From reading your thoughts on sematypes, I can't see how what you are describing is much different from a stereotype. EA uses stereotypes as the extension method, including for defining new metatypes. But that doesn't mean that all stereotypes represent a metatype. UML does sometimes specify a different keyword or rendering to denote that a specific property is set, but they could be specified as a stereotype (or extended stereotype) instead. BPMN uses different icons/decorations to show different properties, they could be expressed by stereotypes or enumeration properties on the base metatype as easily as they could be specified as a new metatype.

What is so different about sematypes that won't be understood by anyone not already familiar with the modeling paradigm in your environment?

[Paolo F Cantoni]

What do you mean should have?  You do have.  You just may not have included it in your repository.

It's all about the semantics.

Semantics - Does an association class already exist before creating a UML representation of something? Is every system/environment being modeled a UML model before someone creates that abstraction? If there are multiple correct ways to model something, does that mean that you automatically have all of them if the model describes something a different way?

[SNIP]

I'm going to split my response since there are two distinct points you are making.
I guess I didn't explain myself well enough.  The semantics part is about the fact that you have more than one semantically unique relationship between Persons.  As soon as you do that, the you have three effective relationships:
Dependent_of
Emergency_contact_of
and, as a consequence:
Associated_with

Associated with is NOW a derive relationship, derived by the Union of the other two.  The semantics of this setup require that there be a discriminator for which instance you are discussing at any point  in time.  The use of a discriminator, effectively, requires an n-ary relationship element (such as an AssociationClass - which in UML is used solely for binary (2-ary) relationships) to hold the discriminator.

As far as I can see, this is a form of the "Eric Morecombe Gambit" (he used to put a finger up to Ernie Wise's chin and say:  "Get out of that without moving!")

If this isn't the case, I'm happy to continue discussing.  The stuff I mentioned before (about materialization of Associations) is created because of this.

Paolo

[Paolo F Cantoni]

[SNIP]

From reading your thoughts on sematypes, I can't see how what you are describing is much different from a stereotype. EA uses stereotypes as the extension method, including for defining new metatypes. But that doesn't mean that all stereotypes represent a metatype. UML does sometimes specify a different keyword or rendering to denote that a specific property is set, but they could be specified as a stereotype (or extended stereotype) instead. BPMN uses different icons/decorations to show different properties, they could be expressed by stereotypes or enumeration properties on the base metatype as easily as they could be specified as a new metatype.

What is so different about sematypes that won't be understood by anyone not already familiar with the modeling paradigm in your environment?

Second part...

When we started to try and formalise our MDG and its related conceptual metamodel, we found a couple of problems.  We liked the mechanism that Sparx provides; of a unique combination of Type and Stereotype denotes a metatype - which will be inserted in place of the type in most circumstances.  Our users could therefore worry about what metatype am I using rather than having to worry about the specific stereotype involved - they just looked n one field instead of having to join two.

The metamodel uses metaclass and stereotype, but the metaclass is the EA type, and you can't extend that (AFAIK). For example, we wanted (ArchiMate) Assignment to be a metaclass. Anyway, we decided we need to understand what a metatype was (outside EA)  Unfortunately, the only references and definitions we could find were biological:
Metatype: a topotype or homeotype determined by the original author of its species.
or to do with knowledge representation:
Metatype: the type of a type

So we decided that a metatype was the first order specialization of the metaclass - so (as I noted before) if Specialization is the metaclass then Inheritance and Restriction are the two metatypes.  NOTE: this is taking place in a conceptual metamodel, the limitations of the Sparx metaclasses aren't relevant here.
The requirement for being a metatype became: "Your nature must be different from another metatype for the same class".
The combination of Sparx Type and Stereotype enabled us to implement this model as three distinct types:Specialization, Inheritance and Restriction

Then along came these semantic variants of Associations - they're not (by nature) different from the other Associations, but their meaning (semantics) are specific.  As you correctly observe, the same stereotype technology will allow us to implement and render these semantically specific variants.  But conceptually they aren't metatypes according to our definition.  So we invented sematypes:  A type whose nature is the same as its metaclass (or even metatype) but whose semantics are specific and unique.

From the inside out, all of these concepts are just types and stereotypes, but from the outside in, they are conceptually different and it appears possible for the non-modeller users to appreciate and understand the distinction and use them meaningfully.

YMMVWFUs...

Paolo