Aggregation and Association proposal

[Paolo F Cantoni]

This is a proposal for the consistent treatment of UML Associations with and without AggregationKind within EA.

(Because of its length, it is split into two parts...)

Firstly, we need to recognize that UML doesn't have what EA calls "Aggregations" and "Compositions".  UML has Associations with shared or composite aggregation.  However, we can use these terms to identify these subtypes of Associations.

In another post Allow replacement of EA Aggregations, I mention the formal replacement of EAAggregations and EACompositions with true UML Associations (and, I guess, that should probably be the eventual aim).  However this proposal takes an intermediate stance - retaining  "Aggregations" and "Compositions" but attempting to provide a degree of consistent behaviour that would make it easy to (eventually) replace them with true Associations should that be the requirement.

In a further post AggregationKind - one end concept?, I suggest that AggregationKind can, by definition, only be applied to one end of the Association at a time.

In EA, although in some contexts, we can talk of Aggregations and Compositions, there is actually only one type of arc - with type "Aggregation" that covers both forms.  It does this by means of the subtype "Weak" for shared aggregation and "Strong" for composite aggregation.  The subtype is automatically maintained by EA - depending on the AggregationKind state of both ends.

At present in EA, you can create an arc of type "Aggregation" with both ends set to AggregationKind none and EA will still render as though it was a shared aggregation (and is so designated by its subtype in t_connector).  In addition, as mentioned elsewhere, you can set both ends of the arc to AggregationKind set to not none and EA will render the the AggregationKind diamond on one end only - according to an internal Algorithm.  Arcs of type "Association", on the other hand will render both ends if AggregationKind is set.   This is, of course, inconsistent and confusing.

My proposal take the form of connecting the processing of the two type of arcs: "Aggregation" and "Association" so that a EA can provide a consistent representation and rendering.

The first part of the proposal is to ensure that EA ONLY allows AggregationKind to be set on one end of the arc.  The last change to AggregationKind would determine which end had the AggregationKind diamond.

The second part is the "unification" of both types so that an arc can change its type depending upon the settings of AggregationKind.  If both ends of the arc have AggregationKind set to none, the arc's type is set to Association.  If either end of the arc have AggregationKind set to not none, the arc's type is set to Aggregation.  The arc's subtype is set depending upon the setting of the only AggregationKind status.

In this way, EA presents a consistent view both in rendering and within the database.  Also, querying if the arc is an aggregation or not is simplified.

Naturally the Automation Interface would respond consistently.

As currently, there will need to be a global setting to control which end of the arc, the AggregationKind diamond is to be placed when drawing the arc (using either the Toolbox or the QuickLinker).  The current [X] Draw Aggregations Reversed would be replaced with [X] Draw Aggregations at Source.  EA would, by default, draw the AggregationKind diamond at the destination end - as at present.

[End of part 1]

[Paolo F Cantoni]

[Part 2]
As I mention in AggregationKind and end shapescripts, arcs of type "Aggregation" and those of type "Association" currently treat the AggregationKind diamond differently, in the "Aggregation", the AggregationKind diamond is part of the target shape while in the "Association" it is separate from the target shape.  My feeling is that the latter form (AggregationKind diamond NOT part of target shape) is preferable.  In theory, this might seem to provide the modeller with less control (by means of shape scripting), but it's my view that if you are using AggregationKind then you are explicitly wanting to render the AggregationKind diamond.  I include the IDEF1X and Information Engineering notations in this.

The last part concerns the use of Navigability arrowheads. In (what is now a LONG standing comment) Directedness and Navigability of Edges, I observe that EA has conflated directionality and navigability.  My suggestion is that the current Direction control of the Arc dialog be renamed Navigability and the <Context Menu>|Advanced>Reverse Direction menu item swap the origin and destination.  I would also add a Reverse Direction button on the  Arc Dialog to perform the same action.  The navigability control would only be active for Associations and Aggregations.

NOTE: This last part of the proposal, is also a free-standing proposal and could be implemented without direct reference to the main proposal.

I believe this proposal retains as much of the existing functionality as is appropriate, but more consistently and correctly provides the modeller with the ability to manage these interrelated concepts.

In passing, EA currently allows pretty much any value for subtype - certainly for Associations.  This subtype is available to the API and shape scripts.  Consequently, to allow the (eventual) use of true UML Associations with and without AggregationKind, EA could just change the type from "Aggregation" to "Association", retaining the subtype to allow easy querying of the AggregationKind state of the arc.  Naturally, I'd prefer the subtype values of "Shared" and "Composite", but I'll take "Weak" and "Strong" as at present.  This would make change over very simple!

Finally, in my view, the AI and the GUI can implement this proposal fairly easily.  However, there is scope for the database to be incorrectly set (that is with both ends having AggregationKind set).  I don't expect EA to provide a database trigger to stop this invalid state being input.  However, as I mention in one of the related posts, EA already has a process for (at least rendering) this situation.  I'd suggest formalising the process, such that if the AI or GUI receive an arc from the DB with both ends having AggregationKind set (to not none) it takes the "stronger" of the two ends as the prevailing AggregationKind.  If both ends are at the same "strength", then the end specified by the [X] Draw Aggregations at Source setting would prevail.  On saving to the DB, the "corrected" arc would be persisted.  (I'm indebted to my colleague Andrew McDonald for pointing out this issue.)

I've submitted this proposal to Sparx as a Feature Request under the title above.  If you support the proposal, please also submit a Feature request under the same name to Sparx - you just have to say you support it.  A mention that you've done that here will allow the user community to track things.

Thoughts?

Paolo

[Geert Bellekens]

Request sent!

Geert

PS. This is really a retarded way of voting for features.

[fwoolz]

Ditto!

Sparx should take a look at the Microsoft Connect site, accessible from within Visual Studio, that provides (IMHO) great support for reporting bugs and workarounds (with feedback from users & support staff) as well as suggestions and feature requests.

Fred

[beginner]

Desperately one more attempt. I sent a Reg. User Support Request and clicked the "Submit Bug" (sic!) button.

Be the force with you.

b.

[Paolo F Cantoni]

Additional issue found with respect to Association Classes and EAAggregations.  See: Association Classes on EAAggregations.

Paolo

[Paolo F Cantoni]

Additional problems with Shapescripts.  See:  MDG Compositions DON'T react to Shapescripts

Even on planet Sparx this inconsistency must be brought under control!

Paolo

[Thelonius]

I'll just throw this in here, in response to reading the above comments. I've been a loyal user of Sparx EA for years. But it's true. The 800 lb gorilla in the room is that Sparx isn't really listening and changing rapidly enough to keep up with the market - let alone loyal users like me, who have attempted to contribute to the development strategy of Sparx EA. My organisation is now looking at Orbus iServer - and the more I look at it myself - the more I'm thinking it's a better solution for Enterprise Architecture. Sparx is evolving too slowly and isn't delivering to market what (my) market needs. If they want to keep the tool small, and focused on software architecture, that's fine, and that's what they seem inclined to do. Small can be beautiful.

[Paolo F Cantoni]

Thelonius,

I'd better not start...

Suffice to say (as as sometimes been my signature), I'm using EA in spite of EA not because of it...  Which it REALLY sad...  

Just fix the bugs!  (Especially the fundamental flaws).

You can't keep building a house of cards on top of a flawed base...  It WILL come tumbling down....

Paolo

[Thelonius]

And I've always said that Sparx is "just a better Visio than Visio" but it seems that time has caught up with the market place and has delivered something closer to what I need.

Sparx will always be a better choice for UML / MDA software engineers.

The flawed, patched-up architecture of the Sparx code base is a separate concern.

I was disappointed when v8 came out. It certainly doesn't seem like a major new release - more a point release.

Funny how all these little things come to the fore suddenly.

[SomersetGraham]

Voted