How to convert class attribute into composition?

[volenin]

Hi. Another question I can't find an answer to... Say, I have a Classifier (eg, of type 'Class') named ClassA. Within the class I have an attribute defined typed as ClassB:

Code:

//pseudocode: ClassA {  ClassB b }

Now, in any OO language, the construct above is a composition and in some other tools I've seen a possibility to switch between different visual representations - as a ClassA with a ClassB attribute OR as a ClassB with a 'composite' association towards ClassB. I can't find this within EA Sparx. From all practical prospective what I'm looking for is a way to get Sparx to automatically generate 'composite' or 'nested' (not sure if this is the right one though) relationship for the typed attributes (so that I can use them in relationship matrix, traceability window, etc).

The closest I could get is to define a relationship between ClassB and ClassA.b at the attribute level (as a source/target role for the association), though the problem is it has to be done manually... I always though typed attributes and composition association are kind of interchangeable...

Thanks!

Vlad
[original message]

[MREA]

OK if I understand you right.

The first thing is, if you use C then you could use OO-support or if you do not wanna use OO-support you need an attribute like

attr:Class

e.g. � myCar:CAR

Is that what you are looking for?
[original message]

[Bellekens@localhost Geert Bellekens]

Vlad,

There's a part of your question missing.
What exactly are you trying to do?
Reverse engineer code?

For me that piece of code doesn't reveal the nature of the relationship between ClassA and ClassB.
It certainly isn't nesting as that would you you define ClassB inside of ClassA.
But you can't be sure whether or not it is a composite or not.
If there's code like


Code:

ClassA a1 = new ClassA(); ClassA a2 = new ClassA(); a1.b = new ClassB(); a2.b = a1.b;

Then it can't be a composition as there are more then one wholes (ClassA) to the part (ClassB).

Geert

PS. You can find more details on the nature of the different types of assocation in:
UML Composition vs Aggregation vs Association (http://geertbellekens.wordpress.com/2010/12/20/uml-composition-vs-aggregation-vs-association/)
and my recommendations regarding the use of attributes or associations: UML Best Practice: Attribute or Association (http://geertbellekens.wordpress.com/2011/08/10/uml-best-practice-attribute-or-association/)

[original message]

[volenin]

Thanks for the answers. To reiterate, here is a quote from the comments to the article Greet posted the link to:


Quote:

I�d like that tools like EA would be able to automatically show the associated classes as attributes of the class. This would be very helpful when dragging a class to another diagram.

To address some of the questions above:

i do talk about the composition in this particular case, so my example would be more accurately described as (even though it involves the instantiation of a classifier - can't find another easy way to describe it...):

Code:

//pseudocode: ClassA { ClassB b = new ClassB() }

Ie, ClassA as the composite object has responsibility for the existence and storage of the composed objects (parts - in this case, ClassB). But generally it doesn't matter much in the context of my question. I'd expect the same principle working working for the aggregations as well (as in your example).

As for the reason or intent of why i need it. It's not to reverse engineer the code, but to 'traverse' the UML model in order to do a sort of 'impact analysis'. I was hoping that if classifier is a composite object defined through typed attribute, i still would be able to traverse the model from ClassA to ClassB through 'composite' or 'aggregate' association. Or yet in other words, when traversing the UML model from an arbitrary element, I need to trace all classifiers of type 'X' which are 'reachable' from that selected element. Similar to what 'Tracability' window within Sparx does, but in a more readable format, with an ability to set various filters. From what I understand, if I just traverse JUST the associations / links, I won't be able to find the references to 'attributes' of type 'X' (same as 'Traceability' tool won't be able to find these relationships to the attributes).

Another thing I can't understand is the 'owns' association. If I drop one classifier within another (eg, Class2 into Class1), Class2 will be 'contained' within Class1 in the project browser, the Traceabiltiy tool will show the relationship between Class1 and Class1.Class2 as 'owns' (ie, <Class1> [owns] <Class1.Class2>), but the Relationship tool will NOT show this relationship. On the other hand, if I define explicit 'nesting' relationship between Class1 and Class2 as 'Class2' nested in 'Class1', the tracability tool will show this relationship in exactly the same fashion (<Class1> [owns] <Class2>), but this time around the relationship WILL be shown in the relationship tool as 'Nesting'. I thought that 'Traceability' and 'Relationship' tools use the same approach when they derive the relationships between the elements... Seems like they are not.

Vlad
[original message]

[MREA]

I've done the comosition for C, but in the Model it should be the same

so you have

Class A                                           Class B

<<Stereo>> ClassA                   <<Stereo>> ClassB
-attr1:int                                            -attr1:string
-attr2:string                                        -attr2:string
-composit:ClassB                                       ...

Is that what you wanna now?
[original message]

[Bellekens@localhost Geert Bellekens]

Vlad,

Attributes and Associations (be it composite or not) are different things in UML (and in EA).
So indeed, if you traverse all associations to another element you won't find the attributes using the other element as type, nor will yo find the operations that have a parameter using that other element as type.

If that is what you are after I suggest you have a look into my EA Navigator addin (http://geertbellekens.wordpress.com/ea-navigator/). That allows you to see the links between two classes made by attribute or parameter type.

Since the add-in is open source you are free to borrow the code you need.

With regards to the nesting relation. Be careful with the terms you are using. This relation is no Association.

But indeed, there's no relationship between nesting an element under another element and having a nesting relation

You can have a nesting relation without actually nesting the two elements, and you can nest elements without having a nestion relation.

Geert
[original message]

[M@localhost Simon M]

65474750560C60474E4E4749474C51220 wrote:

Attributes and Associations (be it composite or not) are different things in UML (and in EA).

In EA there is very little connection between the two, but this doesn't come from UML. In UML they are extremely closely related. An association is two or more attributes although they may be owned by the class at either end.
[original message]

[volenin]

Thank you for clarification, Simon. As to my knowledge it really has little to do with uml but rather with the specific tool implementing the uml. Can you also Pls clarify, in case I assign a target / source role for the association as classifier attribute, how this relationship will be traversed in the uml model (eg, if I'm to 'walk' the dependency tree). Would The 'attribute' be on the 'path' or it's rather 'offside' (ie, the relationship is always between classifiers, and if you want you can query the 'details' of the relationship to get the details to wich particular attributes it is attached to).
[original message]

[N@localhost Marian N]

13090D0F0E0D600 wrote:

[quote author=65474750560C60474E4E4749474C51220 link=1352177357/0#5 date=1352272273]Attributes and Associations (be it composite or not) are different things in UML (and in EA).

In EA there is very little connection between the two, but this doesn't come from UML. In UML they are extremely closely related. An association is two or more attributes although they may be owned by the class at either end.[/quote]

Hi All,

As defined by the UML spec. and also clarified on this site http://www.uml-diagrams.org/property.html,
"Note that an attribute is semantically equivalent to a composition association; however, the intent and usage is normally different." - UML 1.4.2 Specification
"UML 2.x specifications allow to show an attribute using notation for association"
Association end could be owned either by
- end classifier, or
- association itself.

If we refer to the examples shown on the above website, the questions is:
If we have Diagram 1, with the homeAddress and visits attributes of the Patient class
shown using the association notation, is it possible to see them in Diagram 2 just as attributes within the Patient class compartment because Address and Visit Classes are absent?


[original message]

[qwerty]

The page you refer to is just another interpretation of Superstructures. OMG is very unclear in respect to connectors (and a lot of other things). Just from a practical use an association between two classes and one or the other having an attribute type with the opposite class you can see them as different rendering of the same thing. While the connector stays on a more abstract level the attribute is more concrete. So from a tool I would expect that the existence of such an attribute would automatically render a connector. But in EA connectors are 2nd class citizens. Probably Sparx is not to blame completely since OMG has produced such a bad paper.

My 2 cent

q.
[original message]