Elements.AttributesEx vs. multiple inheritance

[Rouven]

Hello everyone,

I am currently evaluating the use of the AttributesEx-collection (http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/element2.htm) on the Element-class to determine all the attributes from a hierarchy that may be relevant to me.
Now I now that multiple-inheritance brings along a range of problems - still, since our UML model allows for this structure I need to make certain decisions during the evaluation. Either I do it all by hand and move through the hierarchy manually, or I use the AttributesEx collection and have the attributes handed to me.
What I am unsure of after reading the documentation is how Enterprise Architect deals with the same attribute inherited on two different paths along the chain. My first experiment seems to suggest it may use something like a "least hops" strategy, so if I have a class A->B->C and A->X and both C and X define an attribute of the same name, it prefers the definition from X because it is only one hop away compared to two hops for C.
Does anybody know if this is true? Or what the algorithm is? How reliable is the result?

Thanks for any input!

Cheers,
Rouven

[qwerty]

If the algorithm is not published by Sparx I wouldn't give a cent for it's reliability. However, if your empirical research shows some stable behaviour you should simple use it.

But be warned: the next (major) release might change this. I have seen it with Package.Element which in earlier released returned ALL elements (including nested) but now only the first level elements are returned. IIRC neither is described in detail (current help: A collection of elements that belong to this package - this does not mention that embedded elements are not returned).

q.

[Geert Bellekens]

Rouven,

I have never use the attributeEx collection, and certainly never in a case of multiple inheritance, but my gut feeling says EA will report all attributes of all parents, including the duplicates.

If you find out, let us know...

Geert

[Rouven]

Hi Geert,

what I can say for sure is that AttributesEx does NOT report duplicates but makes some sort of decision (unfortunately quietly, which is why I am leaning towards not using it, I need to log a warning to the end user).
I used the following for testing:
A->B->C
 |->X
I declared attribute a in class C with type Date and redeclared it

• in X as int: EA return the int-field
• in B as int: EA returned the int-field

As I said, to me preferring X over C could indicate a "number of hops" or "length of inheritance chain"-like approach, but I do not want to conduct hundreds of experiments just to find out that the result is based on rows returned from query or something.
As I said, the algorithm seems to be too quiet for my purpose of showing the conflict. However I would assume that you can safely use the method if you are limited to single-inheritance as it actually obeys overriding.

Thanks for your input though!
Rouven

[Geert Bellekens]

Hmm, then EA still amazes me.
I agree with you, it it probably safer (and faster in terms of development) to apply your own algorithm.

Geert