BUG: Attribute/AssociationEnd NOT paired

[Paolo F Cantoni]

Earlier versions of the UML specification had the explicit statement that "a named navigable AssociationEnd is an Attribute"[my emphasis].

Whether the current [size=13]UML 2.1 Superstructure (interim)[/size] Specification says that or not is of no real relevance, since one can deduce this from first principles, and indeed, EA adheres to this for reverse engineering.

The reason for this posting is that EA doesn't adhere to this for the actual modelling...

When you select a role from the Source (or Target) Role drop-down - you are selecting the appropriate Classifier's Attribute!  It makes no sense, therefore, to not make the metadata the same.  If the attribute is private, then the AssociationEnd needs to be made private and so on...  In particular, if I am selecting an attribute, then I'm explicitly saying make this end the same...

If I create a new name, then EA should ask if I want to create the corresponding Attribute and create it using the metadata of the AssociationEnd as I close the dialog.

For an existing Attribute/AssociationEnd pairing, if I change one side, the other side should change correspondingly.

I have been "banging on about this" since I started using EA, but it is now starting to really hurt.  (Besides, the current behaviour is just plain wrong...  If I give such an inconsistent model to a coder, which ambiguous design fact do they code from?)

We are a design shop.  We don't do much coding, our designs are implemented by others (and eventually we hope to write code from high level "intensional" models).  So having to keep this stuff manually in synchronization is error-prone.  We could write some automation to help, but why should we?

This, in my view, should be CORE EA functionality (as should be checking this pairing via the Model Validation [Ctrl+Alt+V] process).

This needs to be fixed urgently.  The current behaviour is unacceptable.

Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[mikewhit]

Would be useful if these caveats found their way into the actual EA documentation.

In fact I would hope (time permitting) that all posts here would lead to either a bug raised, or an EA documentation update to clarify or include extra detail ... unless it was a clear case ^[tm] of RTFM.

[«Midnight»]

Of course we'd be hoping the changes and updated docs would come along before OMG finalizes a data modelling standard and EA moves to that paradigm...  

[KP]

Paolo,

Yes, I pretty much agree, and Ports and Parts need the same treatment too.

The quick fix is in the model validation, as you suggest - we can get that done. The full solution will take longer, but it's certainly in our plans.

Neil

[Paolo F Cantoni]

Paolo,

Yes, I pretty much agree, and Ports and Parts need the same treatment too.

The quick fix is in the model validation, as you suggest - we can get that done. The full solution will take longer, but it's certainly in our plans.

Neil

Thanks for that commitment Neil.

However, some thoughts concerning the validation process.

Detecting the differences is good (and a minimum requirement).  However, being able to rectify would be better...

I won't comment here about Ports and Parts validation - although I agree it needs to be done.  Jim Shaw (among others) can probably add value here.

The mapping between the Atribute and its equivalent AssociationEnd should be fairly straight forward (although we could discuss it here - just to be sure we users and Sparx are on the same page).

It may well be that since the detection and validation is post facto, some changes will need to go in one direction, some in another (on a per item basis).

In terms of the development of the rectifier, the first version could allow a global direction setting:
(*)Atribute always overrides AssociationEnd   ( )AssociationEnd always overrides Atribute

This would allow users to set a policy within the repository and have EA fix things.

The next version would have additional options:
(*)Atribute always overrides AssociationEnd   ( )AssociationEnd always overrides Atribute   ( )Allow me to select
and radio buttons against each item (Attribute/AssociationEnd)
(*)Atribute properties override AssociationEnd   ( )AssociationEnd properties override Atribute

The last version
(*)Atribute always overrides AssociationEnd   ( )AssociationEnd always overrides Atribute   ( )Allow me to select
and radio buttons against each item (Attribute/AssociationEnd)
(*)Atribute properties override AssociationEnd   ( )AssociationEnd properties override Atribute   ( )Allow me to select
would add the choice against the individual differing property within the item.

• Attribute value overrides AssociationEnd   (unchecked: AssociationEnd value overrides Attribute[/font]
  
  HTH,
  Paolo
  [size=0]©2006 Paolo Cantoni, -Semantica-[/size]
  
  

[Paolo F Cantoni]

The new build (EA 6.5(800.)) has some validation built in...

However under some circumstances there are problems...

For any class it only picks first error (and stops checking for that class)...  This needs to be fixed...  

It does not resolve Association end Classifier names properly - doesn't take parentage (including namespace) into account:

MVR030005 - warning (DebugTypeData (Class)): Attribute/AssociationEnd mismatch, debug Level: Type (DebugUtil::EDebugLevel/EDebugLevel)
Validation complete - 0 error(s), 1 warning(s)

In diagram, the (resolved) name of the target class is: DebugUtil::EDebugLevel and therefore should match!

This generates false positives...

Stay behind after class and write 100 times:  I must resolve my types correctly...  

Paolo

[KP]

Stay behind after class and write 100 times:  I must resolve my types correctly...  

10 FOR I = 1 TO 100
20 PRINT "I must resolve my types correctly..."
30 NEXT I

[Paolo F Cantoni]

But did it do any good?  

Paolo

[«Midnight»]

Neil,

10 FOR I = 1 TO 100
20 PRINT "I must resolve my types correctly..."
30 NEXT I

If I understand what Paolo's been trying to tell us, the final line should read:

30 NEXT "I"

The idea is to iterate though the reader community, applying the rule in line 20 for all values of "I."

Have I got it Paolo?