Sparx Systems Forum

Enterprise Architect => Bugs and Issues => Topic started by: Paolo F Cantoni on December 17, 2009, 01:08:32 am

Title: Browser and t_xref inconsistent after Transforms
Post by: Paolo F Cantoni on December 17, 2009, 01:08:32 am
I've just spent 8 hours today tracking down what I consider a very serious bug in the MDA transformation process.  It's after 10pm so I'm going to bed to rest.  I'll document the details tomorrow.

If you try to apply the same transform from the same source package to multiple target packages, weird things happen.

Has any one else tried that before?  I suspect not - because of this bug - but I thought I'd ask just in case anyone got it to work.  (Can't see how, but you never know with EAUI).

Anyway, if you attempt to perform (what I consider a reasonable use case) you'll find that the transformation information in t_xref no longer matches what is going on in the browser.

Steps:
Create a simple transform.
Run it
Pick one of the transformed elements, drag it to another package (say not in the transform)
Rerun the transform
The "missing" item will not be created
Change the target package
Rerun the transform
Nothing is created in the new package.
Open t_xref, create a view joining Client and Supplier to t_object and Link to t_package - select only the transform entries - for the namespace of your transform. Observe that t_xref claims that the items should be in the second package, but they haven't moved in the browser!
See my tag line...

Now, I suspect some aspects of the bug are due to the underlying data model used for transformations, but the principal cause is just code that doesn't work...

Paolo
Title: Re: Browser and t_xref inconsistent after Transfor
Post by: Paolo F Cantoni on December 17, 2009, 09:27:39 am
Before I submit the bug report, can anyone (preferably a Sparxian), confirm that the use case:

Create the same transform from the same source onto several targets within the same repository.

Is actually supported by EA?

There's a bug here regardless, but I'd like to investigate how to support the above use case given the current constraints.

TIA,
Paolo
BTW: the transform - when it works correctly does exactly what is required.  So the problem isn't in the generation code, but the synchronization.
Title: Re: Browser and t_xref inconsistent after Transfor
Post by: Eve on December 17, 2009, 10:31:58 am
I can confirm that it isn't.

A transformed object is unique on the source object, the transform it is generated from and the name given to the transformed object in the transform.

When you run the transform subsequent times EA will synchronize with the elements that were created previously, but will not move their package.  The updated x_ref represents the location the source object was targeted to for that transformation for the purposes or allowing the transform to be automatically run to the same location.  It is not storing the actual package the object is in.  (Even in the basic case this will likely be different if your transform creates packages.)
Title: Re: Browser and t_xref inconsistent after Transfor
Post by: Paolo F Cantoni on December 17, 2009, 12:15:57 pm
Quote
I can confirm that it isn't.

A transformed object is unique on the source object, the transform it is generated from and the name given to the transformed object in the transform.

When you run the transform subsequent times EA will synchronize with the elements that were created previously, but will not move their package.  The updated x_ref represents the location the source object was targeted to for that transformation for the purposes or allowing the transform to be automatically run to the same location.  It is not storing the actual package the object is in.  (Even in the basic case this will likely be different if your transform creates packages.)
I suspected this, so then what is the purpose of the target package specification?  If I change the target of the transform, surely I'm asking for the transform to be routed to the new target?  EA doesn't create new or move the existing elements to the new target.  If I delete the old elements manually, then the elements are created in the new target.

NOWHERE in the documentation that I read does it mention this behaviour - it is NON-sense.

So, not withstanding the lack of support for the use case I need, the EA behaviour is still broken - yes?   Once I set the target, I can never change it, without manually deleting the previously transformed items.

If you don't agree (that the behaviour is broken), please outline the use case the current behaviour DOES support?

I'll put in a feature request for the support of the use case I need after we've sorted out the desired behaviour for the current use case (whatever it is).

(Not happy Jan)
Paolo
Title: Re: Browser and t_xref inconsistent after Transfor
Post by: Paolo F Cantoni on December 17, 2009, 12:28:28 pm
Quote
[size=18]...[/size]
A transformed object is unique on the source object, the transform it is generated from and the name given to the transformed object in the transform.
[size=18]...[/size]
Is this by Sparx's design or by external constraint (such as UML infrastructure)?

Is there any other way to determine if an object has been created by a transform other than by interrogating t_xref?  If not, then shouldn't the Link column hold the value of the last successful transform (and not the pointer to the last, unsuccessful, one)?

Similarly, is there any other way to determine if an object has been used in a transform?

Paolo
Title: Re: Browser and t_xref inconsistent after Transfor
Post by: Paolo F Cantoni on December 18, 2009, 12:13:38 pm
[size=18]BUMP...[/size]  Sparxians, do you agree there's a bug here and I should report it?

The bug, as I now see it, is that you can change the specified target but the transform will not generate into the new target - but t_xref will contain metadata suggesting that the transform did generate into the new target.

I accept that (for the present) the ability to generate more than one output from a transform is not (notionally) supported.

If NOT a bug, why not?

Paolo