Attributive Associations & Associative Attribu

[Paolo F Cantoni]

The UML 2 specification (correctly) defines:

... because an association end owned by a class is also an attribute. (ptc-04-10-02.pdf:7.3.3 Association (from Kernel))

EA (like most - probably all - supposedly UML 2 compliant tools) does not formally support this yet.

For the conceptual models I'm creating, I'm putting in both the associations and the attributes.  Actually, I'm eventually going to get my automatic model checker (not yet ported from Rose) to sort this out.

I intend to mark those associations that I have formally linked to specific attributes as «attributive» and ensure that the target role name is the same as the attribute name.  I also intend to mark the referenced attribute as «associative» once I've created the appropriate association.  I can then formally (eventually via the automated checker) ensure that the multiplicity of the association and attribute are the same and that other properties are consistent.

Eventually, I would expect any UML 2 compliant tool to have only one (UML) element that can be rendered in either form as per the UML 2 specification.  I could create the element either by drawing the association or by adding the attribute.  If I added the attribute and the target class was on the current diagram, I would expect the association to be automatically rendered (under option control) onto the diagram.

Note: the UML 2 specification does not (as far as I can tell) formally require that associations be "inherited" via Generalization relationships - whereas it does require attributes and operations.  In this way, I can get (at least certain) associations inherited...

Thoughts anyone?

Paolo

[Pascal]

Hi Paolo,

I'm curious why you would duplicate associations into attributes and vice versa. What are you trying to gain from that? Conceptually this is incorrect, so there must be a lot to gain from this would I ever considering doing this.

What limitations do you experience when you just model the association without the corresponding attribute(s)? Do analysts experience limitations in their comprehension of the model? Or are you having problems generating other models or code from this?

Pascal.

[Paolo F Cantoni]

Hi Paolo,

I'm curious why you would duplicate associations into attributes and vice versa. What are you trying to gain from that? Conceptually this is incorrect, so there must be a lot to gain from this would I ever considering doing this.

I don't WANT to duplicate attributes and associations.  UML 2 explicitly (and for that matter UML 1.x - implicitly - if anybody read it correctly) defines that an association end owned by a class IS an attribute.  

The problem is EA doesn't support this!  

When EA (and other tools - so I'm not just singling EA out) say they support UML 2 what they mean is: "we support UML 2 to the absolute minimum we can get away with".

What limitations do you experience when you just model the association without the corresponding attribute(s)? Do analysts experience limitations in their comprehension of the model? Or are you having problems generating other models or code from this?

Pascal.

As I said in my original post, you can't inherit associations under UML.  I'm sure OMG would argue - there's no need to the - equivalent attributes are inherited.  This is true, but NOT if your tool doesn't render associations as attributes!

SO... I'm in a catch 22!

One problem with all tools that started off life as a code generator is that they tend to be limited to the semantics and syntax of programming languages.  If that's all you want to do, and not do any more serious modelling then you aren't affected since you are working at the "physical' level.

I'm working at the conceptual level, I have generalizations nesting commonly up to 5 levels deep and often much deeper.  With attribute inheritance I can see the effect at the deeper levels, without association inheritance (via attributes) I can't!

In my Rose model, I had a whole raft of cross-checks that would ensure model validity.  I don't have that yet in EA,  I need to port the checker code (in Summit Basic - YUK!).

So.. Until EA correctly supports association<->attribute, I am manually making this happen.  Believe me, the effort involved (as you indicated) is such that I wouldn't do it unless there was a direct benefit to me!  I hope to automate this soon, that's why I raised the question so what I build may be more generally useful or better built as a result of suggestions from the user community.

Paolo

[Pascal]

Hey Paolo,

You point out that EA "doesn't render associations as attributes".  I then presume you mean that there are views on attributes that do not list associations in some similar way. In case of inheritance: do you mean that if you inherit class B from A and A has attribute X and association Y, you will only see attribute X and not association Y when you select the "Feature visibilty / Inherited features / Show attributes"? Or are there other areas where this is a problem for you?

Pascal.

[Paolo F Cantoni]

Hey Paolo,

You point out that EA "doesn't render associations as attributes".  I then presume you mean that there are views on attributes that do not list associations in some similar way. In case of inheritance: do you mean that if you inherit class B from A and A has attribute X and association Y, you will only see attribute X and not association Y when you select the "Feature visibility / Inherited features / Show attributes"? Or are there other areas where this is a problem for you?

Pascal.

Yes Pascal, if I understand what you mean by "views on attributes" that is less than (not  more or less   I'm saying.  To use your example:  Class A has association (with named target role Y) and therefore it HAS attribute Y.  It also has attribute X.  If I inherit from A then Class B should also show attributes X & Y.  EA currently won't show an attribute named Y, so I am creating one.  But I need to indicate that this attribute is here because of the association and not for another reason - hence the stereotype «associative».

There is NO: visibility | Inherited features | Show associations  As I previously argued, if association Y was rendered as attribute Y, there wouldn't be any need to have such an option.

Does that clarify matters?

Paolo

[Pascal]

Hey Paolo,

Glad we iteratively came to a common understanding of your point!  

I think in this case we would have to distinguish between the implementation of EA´s metamodel and the view on that model. Theoretically, an association can still be implemented as an attribute on metamodel level (thus complying to the OMG standards), but in the view layer they could have made the choice to make a clear distinction between attributes and associations. I don´t find anything wrong with this, because in most cases you would want associations to be rendered differently than attributes for readiblity sake.

BUT... I completely agree that in some parts of this view layer,  an attribute-like representation of assocations would be very welcome, like in the example.

So to basically summarize my thoughts: I don´t think we can simply conclude here that the way EA handles some views on attributes and associations contradicts with OMG´s specifications, as long as EA's underlying metamodel can easily be opened to render associations like attributes in every way.

Pascal.

P.S. Maybe a Jerry McGuire-like quote would be welcome here: "SHOW ME THE ASSOCIATIONS!"  

[Paolo F Cantoni]

Hi Pascal,

thanks for your prompt replies...

Hey Paolo,

Glad we iteratively came to a common understanding of your point!  

Yes!  But I'm not sure I agree with the consequences you discuss below...

I think in this case we would have to distinguish between the implementation of EA´s metamodel and the view on that model. Theoretically, an association can still be implemented as an attribute on metamodel level (thus complying to the OMG standards), but in the view layer they could have made the choice to make a clear distinction between attributes and associations. I don´t find anything wrong with this, because in most cases you would want associations to be rendered differently than attributes for readability sake.

In principle, I think you are correct, however there is an added complication.  Not all associations are "attributive" (to use my language), nor all attributes "associative".  I might not wholly agree with the UML 2 specification here, but it is explicit on this point!  Only SOME associations ARE attributes and only some attributes ARE associations.  Those features MUST be rendered in BOTH forms (because they are the same thing)!

BUT... I completely agree that in some parts of this view layer,  an attribute-like representation of associations would be very welcome, like in the example.

See above...

So to basically summarize my thoughts: I don´t think we can simply conclude here that the way EA handles some views on attributes and associations contradicts with OMG´s specifications, as long as EA's underlying metamodel can easily be opened to render associations like attributes in every way.
[SNIP]

If the underlying metamodel is expressed in the database design, then you should have a look (using the appropriate RDBMS) and draw your own conclusions...

Paolo