Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: jeshaw2 on August 24, 2005, 07:43:18 pm
-
The OMG UML 2.0 Superstructure Specification, Sect 7.3.2 says:
...An association end is the connection between the line depicting an association and the icon (often a box) depicting the connected classifier. A name string may be placed near the end of the line to show the name of the association end. The name is optional and suppressible.
Various other notations can be placed near the end of the line as follows:
• A multiplicity.
• A property string enclosed in curly braces. The following property strings can be applied to an association end:
• {subsets <property-name>} to show that the end is a subset of the property called <property-name>.
• {redefined <end-name>} to show that the end redefines the one named <end-name>.
• {union} to show that the end is derived by being the union of its subsets.
• {ordered} to show that the end represents an ordered set.
• {bag} to show that the end represents a collection that permits the same element to appear more than once.
• {sequence} or {seq} to show that the end represents a sequence (an ordered bag).
• if the end is navigable, any property strings that apply to an attribute. ...
Where do I enter property strings for association ends?
-
In the conector "role" tabs.
bruce
-
In the Criteria field? Seems inconsistant to put it thete there; in the Parts element, property strings go in the tagged values field.
And, Where do I specify that the association is derived?
-
[size=13][SNIP][/size]
And, Where do I specify that the association is derived?
As one of our former Prime Ministers (Robert Gordon Menzies) was want to say when presented with a problematic question:
"Good question. Next?" ;D
Paolo
-
a) Hmm, guess not then.
b) Wot's a derived associaton? Do you mean the end is a derived attribute?
bruce
-
a) Hmm, guess not then.
b) Wot's a derived association? Do you mean the end is a derived attribute?
bruce
Since I'm very interested in Jim's views and definitions, I'll let this one go "through to the keeper" (Cricketing term for you infidels... ;D).
Paolo
-
Although I doubt if I'm the keeper, I would like to add some thoughts. Jim, since it is a quite complex subject, I will try to make myself more clear this time ;)
1. Difference between role names and string properties
In my opinion the UML superstructure defines that you can place 3 sorts of things at an association end:- a role name
- a multiplicity
- property strings
A property string is hence different from a role name. Role names and multiplicities can be determined in EA by the Association properties window (double click the association). However this window does not provide an input control for property strings. You could define them by means of tagged values, but I don't know how you would do it. I can add tagged values to the association but not to the association end.
2. Derived associations
According to the UML definition a derived association is an association that can be derived from other associations or constraints. Again the association properties window in EA does not allow you to indicate if an association is derived. Nevertheless the automation documentation regarding elements of type association shows the existence of a boolean attribute IsDerived. So EA knows the concept of a derived association but you cannot manage it by means of the user interface (or at least I did not find a way to do it).
Hope this helps,
Maarten
-
[size=13][SNIP][/size]
2. Derived associations
According to the UML definition a derived association is an association that can be derived from other associations or constraints. Again the association properties window in EA does not allow you to indicate if an association is derived. Nevertheless the automation documentation regarding elements of type association shows the existence of a boolean attribute IsDerived. So EA knows the concept of a derived association but you cannot manage it by means of the user interface (or at least I did not find a way to do it).
Hope this helps,
Maarten
Hi Maarten,
I couldn't find it a) in the Help file, and b) on the EA.ConnectorClass. The only reference to IsDerived (via Help search) is on the Attribute.
Can you point me to it? I'm emitting the model through the AI and one of the principal features of my modelling technology is the creation of derived and inferred connections (of all types).
Cheerz,
Paolo
-
Begining on page 37 of The OMG UML 2.0 Superstructure Specification, Sect 7.3.1 (speaking on associations) says:
Attributes
• isDerived : Boolean Specifies whether the association is derived from other model elements such as other associations or constraints. The default value is false.
Associations
• memberEnd : Property [2..*] Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.
Issue 6243 - add new information about navigable ends
• ownedEnd : Property - The ends that are owned by the association itself. This is an ordered association. Subsets Association::memberEnd, Classifier::feature, and Namespace::ownedMember.
• navigableOwnedEnd : Property - The navigable ends that are owned by the association itself. Subsets Association::ownedEnd.
• / endType: Type [1..*] References the classifiers that are used as types of the ends of the association.
Constraints
[1] An association specializing another association has the same number of ends as the other association.
self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size())
[2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end.
[3] endType is derived from the types of the member ends.
self.endType = self.memberEnd->collect(e | e.type)
I believe I'm trying to do [2] above, but I'n not sure; the specification language is very obscure to me.
Where I'm going with all of this is the development of an abstract composite class, lets say Vehicle (whose parts and associations are also abstract and not owned by the composite), which is then specalized in several ways into more concrete classes (e.g.; Cars, Boats, Airplanes), all the while keeping myPowerSource (e.g.;myEngine or myRubberBand) connected to my PowerTransmitter (e.g.;myWheels or myPropeller) and not connected to yourPowerTransmitter. Therefore, I may need to derive the entire association, other times just an end of the association. If I understand the OMG UML spec correctly, both are possible.
I will also need to apply property strings to subset, redefine and specify a union at the association ends. This is the genisis of this thread.
In addition, the PowerSource and PowerTransmitter parts are Interfaces to parts which are wired in at execution time via the Spring Framework. Since Interfaces are inheritable, I can speculate a need to specalize them also, but I havn't gotten to that in EA yet and I'm not sure the UML spec allows it. I'll be back on that question later...I'm still learning all of this stuff.
I appreciate the interest you all have taken in this effort. I don't know how I got promoted to Junior member status, I still feel like a Newbie. I've worked with OO Concepts before, but I'm new to UML and I'm still trying to find out where to go to accomplish things in EA. I guess EA is intuatively easy to UML gurus, but it is obscure to those who aren't. You guys are awsome in your knowledge.
-
Maarten !
Right on! You stated my problem much more precisely than I.
-
[size=13][SNIP][/size]
I guess EA is intuitively easy to UML gurus, but it is obscure to those who aren't. You guys are awesome in your knowledge.
Au contraire, due to EA's UI (Unique Interface ;D) things aren't necessarily intuitive... We always recommend searching for previous posts on a subject as typically there is usually a way to do what you want, it's just not readily apparent...
HTH,
Paolo
As for promotion, the board has a conceptual modelling failure...
500 questions, complainings and exasperations is getting me Guru status ;D (in mock Indian accent with waggling of head - with apologies to those from the sub-continent)
-
2 corrections
Hi Maarten,
I couldn't find it a) in the Help file, and b) on the EA.ConnectorClass. The only reference to IsDerived (via Help search) is on the Attribute.
Can you point me to it? I'm emitting the model through the AI and one of the principal features of my modelling technology is the creation of derived and inferred connections (of all types).
Cheerz,
Paolo
Paolo,
my mistake. You are right. I thought I was looking up Association information but it appeared to be Attribute information.
However this window does not provide an input control for property strings. You could define them by means of tagged values, but I don't know how you would do it. I can add tagged values to the association but not to the association end.
By means of the tagged values window you can define tagged values for the association or one of its ends. (However, this does not mean that I think this is the best solution).
Sorry for the confusion!
Maarten
-
By means of the tagged values window you can define tagged values for the association or one of its ends.
I just tried this. I selected an association and was able to add a tagged value to an association end, but it didn't appear in the diagram. :(
-
Exactly. That's why I think this is not the best solution.
-
Superstructures is not quite expressive in respect to Tags. Has anybody found a reference on how to represent tags at all?
-
Property Strings can be made to appear by putting the text in the Constraint field of the appropriate AssociationEnd.
HTH,
Paolo
-
I think the notation question is moot (except for use as a work-a-round). Given this excerpt from the EA Help file, I don't think property strings belong in the tagged value control.
Tagged values are a convenient way of adding additional information to an element outside that directly supported by UML. The UML provides the Tagged Value element for just this purpose.
Property Strings are directly supported in the UML. It goes on to say that tagged values are most often used by code generators and other tools. From this I assume that tagged values are not meant for display in diagrams.
The UML spec does provide presentation descriptions for property strings; IMHO t'would be helpfull if EA were to support it as well as the property string element. The concepts of subset, redefinition, and union are important components of specalization. I would also suggest the same for GeneralizationSets and the more generalized concept of PowerTypes.
-
I think the notation question is moot (except for use as a work-a-round). Given this excerpt from the EA Help file, I don't think property strings belong in the tagged value control.
Property Strings are directly supported in the UML. It goes on to say that tagged values are most often used by code generators and other tools. From this I assume that tagged values are not meant for display in diagrams.
The UML spec does provide presentation descriptions for property strings; IMHO t'would be helpful if EA were to support it as well as the property string element. The concepts of subset, redefinition, and union are important components of specalization. I would also suggest the same for GeneralizationSets and the more generalized concept of PowerTypes.
Well, you got the nudge-nudge-wink-wink in my last post...
GeneralizationSets and PowerTypes were also the subject of one of my earliest posts. In my view they are very powerful constructs that make models more "natural". Shouldn't be too hard to implement, I would have thought...
Paolo
-
Seriously (for a change)
I still don't understand what a derived association is. Could someone provide a world example.
please
bruce
-
Seriously (for a change)
I still don't understand what a derived association is. Could someone provide a world example.
please
bruce
OK... When considering models, one can look at a set of elements and their relationships and make an assertion about them. Each relationship is either Canonical or Derived. That is, between any three nodes (say classes A B C) there may be three relations A-B B-C A-C. It may well be that A-C is the transitive closure of A-B-C thus A-B and B-C are Canonical and A-C is Derived. If you think in terms of ORM functional notation it's more obvious.
Two examples: the grandparent_of(x) ::= parent_of(parent_of(x)). manager_of_worker(x) ::= manager_of_unit(organisational_unit_worked_for(x)). grandparrent_of and manager_of_worker are both derived associations.
This allows you to show whatever information is meaningful for a diagram. It's great for showing information at different levels of detail - so long as you can clearly show which associations are Canonical and which aren't. For my models, I use a "/" at the front of the name to indicate "IsDerived" and use the database to adorn these lines differently.
HTH,
Paolo
-
Far out and solid! Right on baby. ;D
I have always "seen" these without actually drawing them. Now I know what they are .....
bruce
-
Far out and solid! Right on baby. ;D
I have always "seen" these without actually drawing them. Now I know what they are .....
bruce
For my next trick...
If you put the formal definition of the derivation somewhere, you can have a checkable model... In your refactoring, did you accidentally delete one arc of the transitive closure (3 diagrams away) so that you no longer have the canonical relations to support the derivation? Or, it's more usual use is that multiplicities multiply along the path so you can confirm that not only is the pathing right, but that the multiplicities at both ends are correct. Both are required for "functional identity". The test for derivation.
Finally, you can pick two classes and ask for the canonical and derived associations. If there aren't any derived associations, you can ask the model to "infer" them and then confirm later...
Paolo
-
For my models, I use a "/" at the front of the name to indicate "IsDerived" and use the database to adorn these lines differently.
and
If there aren't any derived associations, you can ask the model to "infer" them and then confirm later...
Can you please elaborate on these?
-
Let me try another example of derived associations. Consider these classes:
and these associations:
- A car Has_a Engine (Composition)
- A car Has_a wheels (Composition)
- An Engine Powers the Wheels (association)
Constraints on the Powers association, written in OCL, specify that the Engine and Wheels, related by the Powers association are in the same Car.
When the car is instantiated, I would postulate that the Powers association is derived from the global Powers association in Car and the OCL constraints on Powers.
-
[size=13][SNIP][/size](sub-quotes lost by board... :()
Can you please elaborate on these?
John,
The first is accomplished by a simple update query on the t_Connector table. If the first character of the name is "/" (in my case) set LineColor to xxxxx. Reload the form and voila!
The second would be done by automation. I haven't got there yet for EA, but I've done it in the past for my own conceptual modeling tool (Not UML). Its a combinatorial explosion, and you want to make sure you have the shorter/st path/s. The point being, you can usually get anywhere from anywhere else. The issue is: Is it meaningful for you to want to get from there to here? If so, the model should be able to tell you how to do it.
HTH,
Paolo