Target Class as Aggregate

[Paolo F Cantoni]

Hi,

Below is a quote from the new Build 766 Help file:

Draw Aggregations Reversed - By default, aggregate and composite connectors are drawn in EA from Source to Target. In some modelling tools they are drawn in the opposite direction. When this option is set, EA will mimic those other tools. (ab All tools will have the parent as the target and the child as the source of the connector, that is a requirement of UML; only the direction of dragging the mouse to draw the connector is changed).

While I appreciate the need for the option (and indeed, it would be nice to be able to use it dynamically  - say CTRL+Drag will reverse the current direction);  I can't find where in the UML specifications it says that the target is the parent (aggregate) and the source is the child.

If you find the reference can you quote the section with respect to the ptc-04-10-02.pdf (Revised Superstructure) document.

Why is this important (at least to me)?

Well, for a start, if UML requires that, why do ALL tools allow you to set either end as the aggregate?

But, more importantly for me, I may need to internally refactor a large model I've imported into EA from Rose  - where it was originally sourced from an ER diagram.

Over the last few years I've been developing a Conceptual (Domain) Modelling technology that allows me to develop "industrial strength" domain models.  

Part of the process is the ability of the model to generate synthetic narrative by traversing the model connectors (both associations and relations).  The model contains both the name of the 'forward' and 'inverse' associations (actually called 'access functions' in the original terminology - related to ORM), but only displays the 'forward' access function name.

But which direction is "forward"?  Source to destination?
It hasn't been all that obvious to me in the past.
I standardised on deciding which access function was the "stronger" and drew the link from the "weaker" source to the "stronger" destination, and so visibly named it.  For the vast majority of the associations and aggregations in the model, this poses no problem, but most of the aggregations are named and drawn in the "wrong" direction" if the UML requirement is actually true.

I think I can locate and refactor these "errant" associations, but I'd rather be sure it needs to be done first.

Any input appreciated.

Paolo

[Eve]

This option makes no difference to your existing model.  It simply changes EA's behaviour when drawing aggregations to what many people are used to.

If it hasn't been bothering you, then it isn't important to you and you can safely ignore the option.

Simon

[KP]

Paolo,

No, I couldn't find it explicitly stated in UML 2.0 either, but UML 1.5 defines "aggregation" as

When placed on one end (the “target” end), specifies whether the class on
the target end is an aggregation with respect to the class on the other end
(the “source”end). Only one end can be an aggregation. Possibilities are:
• none - The target class is not an aggregate.
• aggregate - The target class is an aggregate; therefore, the source class
is a part and must have the aggregation value of none. The part may be
contained in other aggregates.
• composite - The target class is a composite; therefore, the source class
is a part and must have the aggregation value of none. The part is
strongly owned by the composite and may not be part of any other
composite.

and UML 2.0 (a) wouldn't have changed anything as fundamental as this, or (b) would have said so if it had. Probably.  :-/

[Paolo F Cantoni]

Paolo,

No, I couldn't find it explicitly stated in UML 2.0 either, but UML 1.5 defines "aggregation" as:

When placed on one end (the “target” end), specifies whether the class on the target end is an aggregation with respect to the class on the other end
(the “source” end). Only one end can be an aggregation. Possibilities are:
• none - The target class is not an aggregate.
• aggregate - The target class is an aggregate; therefore, the source class is a part and must have the aggregation value of none. The part may be contained in other aggregates.
• composite - The target class is a composite; therefore, the source class is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other
composite.

and UML 2.0 (a) wouldn't have changed anything as fundamental as this, or (b) would have said so if it had. Probably.  :-/

Thanks for your repose KP.  Three things:

1)  I see the use of "target" in the above as descriptive rather than normative.  If the specification had required aggregation at the target end, it would have used more prescriptive language.  In any event, the section is actually dealing with the types of aggregation.  If UML2 doesn't explicitly mandate the target as aggregate, then you can safely put money on it (I would) that it isn't required.  UML2 is, in my view, much more careful with its specifications in the normative documents.  Further, being normative, if something is prohibited, it has to be explicitly prohibited (even if collectively).

2)  UML2 has actually changed the definition of types of aggregation changing the section above to use AggregationKind, defined as: none, shared or composite.

3)  I don't have Rose installed here at home (it's the foundation day public holiday here), but from memory (and the evidence of my existing model).  Rose forces you to draw the aggregation from the aggregate end to the non aggregate end (in EA terms the aggregate is on the source, and the direction is source->destination - at least that's how it was imported!).  So I don't think the initial assertion about ALL tools is true.  later today, I should be able to confirm or otherwise the situation with NoMagic's MagicDraw - which I believe Sparx has...

I welcome further discussion on this.

Further thoughts anyone?

Cheerz,
Paolo

[Paolo F Cantoni]

This option makes no difference to your existing model.  It simply changes EA's behaviour when drawing aggregations to what many people are used to.

If it hasn't been bothering you, then it isn't important to you and you can safely ignore the option.

Simon

Thanks Simon, I did understand the impact of the option,  but my question related to the nature of the aggregation association.  See my response to KP.

With respect to bother, it will affect me almost immediately, as I have to decide how I draw (and internally represent) new aggregations in the domain model I've imported.  This is for three reasons:

1)  I have verbalisation technology that allows the domain model to "describe itself narratively" so I can give the narrative description to domain experts for validation, without requiring them to understand modelling.   This is based on a certain view of how the model represents the business rules of the real world.

2)  I have embarked on the process of generating code, test scripts and documentation (etc) directly from a conceptual model (without an underlying physical expression - where the model classes are explicitly set to some target language).  I've had some inital success - enough to prove the concept.  This also is affected by the way in which aggregations are represented.

3)  I have to be self-consistent!  I can't help myself!  Whenever I spot inconsistency I have to fix it (or get it fixed - as you are well aware... )

Regardz,
Paolo

[Paolo F Cantoni]

OK,

I've done some checking and testing here are the results of the various tools I currently have access to:

Now to be REALLY clear here (for reasons you'll see below) The SOURCE is defined to be the class I drew FROM.  the TARGET is defied as the class I drew TO.

Rose (2003) draws from source to target, Role B = source, Role A = target, aggregation is at source.
MagicDraw (9.5) draws from source to target, Role A = source, Role B = target, aggregation is at source
Visio (10) draws from source to target, End1 = source, End2 = target, aggregation is at source
EA (5.0 default...) draws from source to target, source role = source, target role = target, aggregation is at target
EA (5.0 with reversed drawing...) draws from source to target, source Role = target, target role = source, aggregation is at source

Now why is it we poor modellers are confused?

Could I suggest that the semantics of the checkbox be reconsidered to make sure it complies with the other tools?

Thoughts anyone?

Suggestively,
Paolo

[sargasso]

I have always considered that EA was right wrt UML 1.5, ergo the other tools were wrong.

Having said that, I will reconsider against UML 2.0 and your comments and report back forthwith sah!

bruce

[Paolo F Cantoni]

I have always considered that EA was right wrt UML 1.5, ergo the other tools were wrong.

Having said that, I will reconsider against UML 2.0 and your comments and report back forthwith sah!

bruce

Hi bruce,

I have no real issue (any more) with EA specifying that its default is that the aggregate will be at the target end.  Sparx are quite within their rights to make that the default operation.

My problem is with the semantics and implementation of the checkbox I initially mentioned.  If I'm a user of these other tools, I'm used to their semantics.  The aggregate is on the source.  If I have to switch between these tools and EA, it makes sense to make it easy for me.  If I could change Rose to have EA's semantics, I probably would, but I can't.

Instead EA said they would make life easy for me by making EA "mimic" Rose.

The problem stems from the assertion that the other tools draw in the other direction.  This they surely do, but they also implement (as a consequence) different semantics - the aggregate is on the source end.  Thus it's not just a drawing issue its a semantic issue.

When you draw with the option set, the aggregate "appears" as though it's at the source end, but it's actually at the target end - open the association and see...  I meant the class I drew to to be the target class.  If EA insists on making the source class the target class because that's where it wants to put the aggregate then we're better off to forget the checkbox.  I then explicitly draw the correct semantics.  I am cognisant of the fact that the help system says that's what will happen, I just can't see the point (Basil Fawlty...)

Look carefully at the testing I did and tell me that the portion in red actually makes sense to you as a user of Rose and how it helps you.  Especially, if like me, you need to use both tools for a considerable period.

Paolo

[Paolo F Cantoni]

See: Aggregation and Association proposal for a proposal to provide consistent processing and rendering of EA Aggregations, Compositions and Associations.

HTH,
Paolo