Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Modesto Vega on January 14, 2022, 11:07:59 pm
-
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?
-
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.
-
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.
-
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
-
Geert, you should link your article about this topic. A good read!
q.
-
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/ (https://bellekens.com/2011/08/10/uml-best-practice-attribute-or-association/)
Geert
-
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.
-
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
-
[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. 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.
-
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 (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
-
[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
-
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).
-
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
-
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 (https://imgur.com/a/EfDjMpQ)
(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
-
I'll try to come up with a meaningful example but it will take time. We definitely no modelling twice, just adding more detail to the model to remove ambiguity. These diagrams, https://i0.wp.com/bellekens.com/wp-content/uploads/2011/08/assocciationsandattributesmeta2.png?resize=600%2C567&ssl=1 and https://imgur.com/a/EfDjMpQ, are high level designs, they are very conceptual, there are many ways to implement them. Sparx Systems has chosen a particular implementation, it may have some annoying idiosyncrasies but it is not a bad implementation.
I am certainly not proposing to have all attributes in high level diagrams like those but that level of detail may be necessary in more detailed diagrams.
By the way, since you are setting cardinality, you are using some of the functionality provided by this feature. You are just not using the functionality that allows you to set class attributes as MemberEnd properties of associations.
-
By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.
Paolo
-
By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.
Paolo
Yes, but they use yet another mechanism to model that.
Geert
-
By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.
Paolo
No. The foreign key is some attribute which refers to another class (table) and it will be the name of the column. Just the name of the key in the external table would be needed. That could be modeled with a stereotyped association end that has stereotype properties like isForeignKey and nameOfForeignKey (since linking to attributes is not possible with UML). But definitely you don't need the foreign key twice.
q.
-
By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.
Paolo
Exactly, and I would read this post in conjunction with by other post "Overlaying configurable business logic into a physical data model" (https://sparxsystems.com/forums/smf/index.php/topic,46496.0.html). They are 2 facets of the same problem. But explain it could be a very long story.
[SNIP]
No. The foreign key is some attribute which refers to another class (table) and it will be the name of the column. Just the name of the key in the external table would be needed. That could be modeled with a stereotyped association end that has stereotype properties like isForeignKey and nameOfForeignKey (since linking to attributes is not possible with UML). But definitely you don't need the foreign key twice.
In a nutshell, yes. But Sparx implementation is (unfortunately) much more complicated than just that. A Foreign Key, or FK to follow Sparx's own language, is both a relationship (specifically, an Association stereotyped as FK) and a type of Constraint (also stereotyped as FK). In turn, constraints are a type of Operation. Of course, operations do not have an independent existence, they are an operation of a class.
The ends of the association representing a (physical) foreign key must be constraints (not columns), one constraint must be unique index, which is also modelled as an operation, and the other an operation stereotyped as FK. The result is that it is impossible to draw an FK association without using these 2 types of operations. If you attempt to draw an FK association without having an FK operation in the target end, Sparx will create it for you, thus altering the structure of your table. Whoever, thought about this approach had not reversed engineered too many databases where the business logic is configurable and, therefore, do not have foreign keys.
Health disclaimer: Although related, this is not the reason why I wrote this post.
-
Use the right terms and you'll be able to better understand things.
(It only took me thirty years to realise I'd been using the wrong term all that time!)
HTH,
Paolo
-
May I ask which term? (But in general I know what you mean)
q.
-
May I ask which term? (But in general, I know what you mean)
q.
Just to be clear the correct term is Foreign Key Constraint! As such. there is NO requirement that the name of the constraint bears any relationship to the (possibly many) attributes that comprise it[1].
They are correctly named as Foreign Key Constraints because they are a constraint on the origin table that the values of the attribute(s) in the origin table must be the values of a uniqueness constraint (typically implemented as a primary or alternate key) of the destination table. There is no requirement that the origin attributes be a key in the origin table, although Inversion Indexes (NOT Keys) are often implemented to make it easy to traverse joins from the destination to the origin table across the Foreign Key Constraint.
Hopefully, that should settle the matter.
Paolo
[1] Indeed, many RDBMSs generate random names for them.