Specialization, inherited attributes and attribute aliasing

[Modesto Vega]

I just tried to do the following in Sparx with partial success.

I have 2 classes, ClassA and ClassB. ClassB specializes ClassA, inherits all attributes from ClassA and it started without additional attributes.

ClassA has a number of attributes: attr1, attr2, attr3 and so on.

When I specialised ClassA, I overrode the attribute initialisers for attributes attr2 and attr3 as follows attr2 = AB and attr3 = ZW.

The problems arose when I tried to create an association between ClassB and a 3rd class, ClassC. ClassC has also a number of attributes - e.g. attrA, attrB, attrC and son on. I would really like to create an association with ClassA.attr1, the inherited attribute, and ClassC.attrA in the roles but I cannot because the inherited attribute, attr1, from ClassA does not show up in the drop down list.

The only alternative I can think of is creating an attribute on ClassB which mirrors the attribute on ClassA. I would like this new attribute on ClassB to alias the matching attribute on ClassA.

Other than creating a relationship between both attributes and, perhaps, using an MDG. Can anybody else think about another way to achieve this?

[qwerty]

I can't completely follow, but regarding the dropdown you probably use a bad feature from EA. You either have a property or you have a role on an association (and preferably set the dot). Having both is not right and that's some heritage (or even basically wrong implementation) here.

q.

[Modesto Vega]

This will be easier to explain if this forum allowed uploading images, and I don't have the type to find a 3rd party site.

[SNIP]
You either have a property or you have a role on an association (and preferably set the dot).

Not sure what you mean here. But to explain further, the Role(s) section of the Association properties dialog has 2 dropdown boxes SOURCE and TARGET, these boxes allow the selection of one attribute for the SOURCE and TARGET roles.

[Geert Bellekens]

But t explain further, the Role(s) section of the Association properties dialog has 2 dropdown boxes SOURCE and TARGET, these boxes allow the selection to select one attribute for the SOURCE and TARGET roles.

I agree with q. on this one. I think you better not use that feature at all.
It's a bad idea to have to representations of the same thing. If you have a relation between two classes I would choose either an attribute or an association. Having both seems redundant

Geert

[qwerty]

Geert, you should link your article about this topic. A good read!

q.

[Geert Bellekens]

Geert, you should link your article about this topic. A good read!

q.

You mean this one I guess: https://bellekens.com/2011/08/10/uml-best-practice-attribute-or-association/

Geert

[Modesto Vega]

Not entirely sure we are on the same page here but it worth exploring. If you take the last diagram of your article, https://i0.wp.com/bellekens.com/wp-content/uploads/2011/08/assocciationsandattributesexample2.png?ssl=1.

I am also not sure why you and qwerty have concluded so quickly that I am trying to miss the 2 approaches you described in your replies.

You have an association between Order and Product. It does not appear, from the diagram, that any attributes have been used to set the MemberEnd properties of the association. Are you suggesting that attributes should not be used to set the MemberEnd properties of the association?

Product.Category has a type of ProductCategory and Order.MoneyAmount has a type of MoneyAmount. I don't have a problem with this concept. But the relationship between these Classifiers are not associations, they look like dependencies, and, in addition, using cardinality in this case doesn't make too much sense.

[Geert Bellekens]

Not entirely sure we are on the same page here but it worth exploring. If you take the last diagram of your article, https://i0.wp.com/bellekens.com/wp-content/uploads/2011/08/assocciationsandattributesexample2.png?ssl=1.

I am also not sure why you and qwerty have concluded so quickly that I am trying to miss the 2 approaches you described in your replies.

You have an association between Order and Product. It does not appear, from the diagram, that any attributes have been used to set the MemberEnd properties of the association. Are you suggesting that attributes should not be used to set the MemberEnd properties of the association?

Product.Category has a type of ProductCategory and Order.MoneyAmount has a type of MoneyAmount. I don't have a problem with this concept. But the relationship between these Classifiers are not associations, they look like dependencies, and, in addition, using cardinality in this case doesn't make too much sense.

Yes, the idea is to use either attributes (for relations to datatypes) or associations (for relations to other classes)

The dependencies I've drawn are only there to show the actual dependency (created by the attribute using the datatype as Type) visually on the diagram.
They are completely optional and only needed if you wanted to make dependency more obvious on a diagram.

Geert

[Modesto Vega]

[SNIP]
Yes, the idea is to use either attributes (for relations to datatypes) or associations (for relations to other classes)

Without using the attributes of a class  to set the MemberEnd properties of associations?

[qwerty]

Yes. Is that so difficult to understand? Use either the one representation or the other but not both. The gimmick from EA is just plain wrong. Attribute and role are two renderings of the same thing. Having both makes duplicates which is nothing you want to have.

q.

[Paolo F Cantoni]

Not entirely sure we are on the same page here but it is worth exploring. If you take the last diagram of your article, https://i0.wp.com/bellekens.com/wp-content/uploads/2011/08/assocciationsandattributesexample2.png?ssl=1.

I am also not sure why you and qwerty have concluded so quickly that I am trying to miss the 2 approaches you described in your replies.

You have an association between Order and Product. It does not appear, from the diagram, that any attributes have been used to set the MemberEnd properties of the association. Are you suggesting that attributes should not be used to set the MemberEnd properties of the association?

Product.Category has a type of ProductCategory and Order.MoneyAmount has a type of MoneyAmount. I don't have a problem with this concept. But the relationship between these Classifiers are not associations, they look like dependencies, and, in addition, using cardinality, in this case, doesn't make too much sense.

Hi Modesto,
FWIW, in these types of cases, I fall back on a UML "first principle" - which used to be explicitly stated in earlier versions.  "A named association end IS an attribute."  Consequently, we allow either or both (but only if the association end is named).  Along similar lines, we render many of EA's "hidden" relations as arcs.  Thus the typing (a form of classification) relationships you mention, we might implement as realization relationships with the attribute selected as the source with a "link to Element feature" via a bit of "black magic".

It's unfortunate that EA doesn't allow you to apply consistent functionality across the various types if you really need it.

NOTE: if you are generating code, using both may not be acceptable to the current implementation of the code generator.  But my point still applies, if the first principle is valid, then the generator should handle it.

So as you can see I differ from qwerty and Geert, but we don't generate code using EA in our models.

Does that help?
Paolo

[Geert Bellekens]

[SNIP]
Yes, the idea is to use either attributes (for relations to datatypes) or associations (for relations to other classes)

Without using the attributes of a class  to set the MemberEnd properties of associations?

Yes, I've never used that myself, or seen it used by any of my clients.

Geert

[Modesto Vega]

Thank you Paolo for providing a somehow dissenting voice. We are not intending to generate code from these models, just model a rather complex structure. I can see, with some difficulty, why if we were going to generate code we may want to follow one of the 2 approaches suggested by qwerty and Geert.

I need to do some research but would also love to hear from Sparx EA. The functionality that allows settings class attributes as the source and target as the MemberEnd properties of associations is pretty critical for the non-UML modelling capabilities of Sparx and cannot remember anything in the UML specification preventing its use (but I could be wrong).

[Geert Bellekens]

I don't really get the why you would want to use this feature.

What is the benefit of effectively having to model things twice?
Or are you making some kind of hybrid logical/technical model where you model both an association between classes A and B (for the logical relation) and an attribute classA_ID in class B, and/or attribute classB_ID in class A to show how the association is technically implemented?

Geert

[Geert Bellekens]

In defense of this approach, this is how the OMG are modelling the UML metamodel as well

Als you can see in this diagram for example: https://imgur.com/a/EfDjMpQ

There are only attributes defined on the (meta) classes for Datatypes such as String or VisibilityKind

All the links between classes are represented with associations (without linking memberends to some attribute)

The new "dot" notation indicates if an attribute is involved, but they never create an extra redundant attribute as well.

Geert