--- old+++ new@@ -1,3 +1,3 @@
In UML, there's no such thing as an associative class; an AssociationClass has both Association and Class aspects.
-The translation should reflect this (the initial ArgoUML <<association-class-name>> approach is very clumsy).+The translation should reflect this (the initial ArgoUML «association-class-name» approach is very clumsy).
Group: --> (none)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed in your House Management example that this approach puts the association name on the class and the class name in a tag, which doesn't appear on the class diagram. Since the class name is (should be) dictated by an analysis of the problem domain, would it not be better to use the reverse approach? I don't know if the stereotype would be required in this circumstance. If it were, maybe it should be called << association-class >> .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this case, the use of an AssociationClass was enforced by the formalism, not by the application (it's an Mc:Mc relationship, must have an associative object). If it was the application that required it it might make more sense to name the associative object visibly and use «association-class-naming» and the tag {association-name=new-name}; perhaps with a comment on the associative class … no, ArgoUML won't let you link a comment to an association or an associative class, just to a class (or perhaps a data type). Huh.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds good. If ColdFrame were to allow both, the analyst/designer would have flexibility to indicate whether the AssociationClass has significance in the problem domain or only exists to formalize the relationship. :)
PS. I see what you mean about the non-attachment of the note. How irritating.
Last edit: Alex Proudfoot 2013-05-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, silly me. I didn't realise that the association-name tag was already available. That solves my problem showing the class name on the class diagram when modelling interactions then.
Last edit: Alex Proudfoot 2013-05-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Diff:
Now using «association-class-naming», which might be considered an improvement :-)
I noticed in your House Management example that this approach puts the association name on the class and the class name in a tag, which doesn't appear on the class diagram. Since the class name is (should be) dictated by an analysis of the problem domain, would it not be better to use the reverse approach? I don't know if the stereotype would be required in this circumstance. If it were, maybe it should be called << association-class >> .
In this case, the use of an AssociationClass was enforced by the formalism, not by the application (it's an Mc:Mc relationship, must have an associative object). If it was the application that required it it might make more sense to name the associative object visibly and use «association-class-naming» and the tag {association-name=new-name}; perhaps with a comment on the associative class … no, ArgoUML won't let you link a comment to an association or an associative class, just to a class (or perhaps a data type). Huh.
Sounds good. If ColdFrame were to allow both, the analyst/designer would have flexibility to indicate whether the AssociationClass has significance in the problem domain or only exists to formalize the relationship. :)
PS. I see what you mean about the non-attachment of the note. How irritating.
Last edit: Alex Proudfoot 2013-05-11
Oh, silly me. I didn't realise that the association-name tag was already available. That solves my problem showing the class name on the class diagram when modelling interactions then.
Last edit: Alex Proudfoot 2013-05-21