Tags not preserved across chained transformations

[danm]

It appears that tags aren't being preserved across chained transformations, at least operation tags. Major oops - this kills my ability to use the tool for real code gen.

Any help sparxians?  :-/

[thomaskilian]

I simply started writing my own code generation and transformation using the automation interface. That gave me the flexibility to act on tags as I like it. Quite some initial work but it pays off if you are using it often.

[danm]

Hi Thomas,
  Thanks, I know you take this approach. I've considered it several times, well here are my thoughts.

   I have to support many languages (4 or 5), and user customization for a team of users (possibly will be quite large eventually). I found that the existing system can work very powerfully and easily, as long as you understand how to work with it, not against it.

  For instance, some information wants to be expressed as a stereotype, while other wants to be in a tag. And you need to elaborate the right information at the right point in the transformation. Such as generate linked attributes at code gen time, not MDA transformation time.


  This is all fine, with some EXEC_ADD_IN help the system seems to work quite powerfully, with lots of flexibility and giving the users the ability to tweak. But - and I don't understand why this hasn't een found before (maybe I'm doing something wrong) - this requires that tags propagate from MDA transform to another for operations! The docs say that that all information is copied, but I don't see tags.

  Without them I can't give the proper hints from a top level MDA xfrm to the code generation engine.

  Anyhow, if I rolled my own I would have to replicate all of the functionality which already exists. And with some small Add-In help nearly everything can be handled. Even this, I suspect I can manually copy all the tags in the intermediate transformations, but that rather defeats the purpose doesn't it?

I simply started writing my own code generation and transformation using the automation interface. That gave me the flexibility to act on tags as I like it. Quite some initial work but it pays off if you are using it often.

[«Midnight»]

...The docs say that that all information is copied, but I don't see tags.
...

The way I see it, regardless if this can be done another way, we have a bug.

If the docs say that everything is copied, and it is not, then there is a bug in the documentation or in the feature. If the documentation is in error - if the intent is that not everything gets copied in a transform - there is also a bug in the software, since there is no way to copy some of the available information. Otherwise we're left with a broken feature.

Either way, this merits a bug report to Sparx.

Please submit the report Dan, since you are in a position to attach a sample project where this is happening. As usual, please quote the title of this thread, and past in the URL. And please let us know what Sparx has to say on the matter.

David

[danm]

I just submitted the bug report. No two ways about it, looking further into it this morning the docs say everything is copies, and at least for operations the tags are very clearly not. By any of the transformations.

This is trivial to reproduce. Create a diagram with tags on any operation. Transform to C# or whatever, look at the transformed model. No operation tags.

Luckily we have the Add-In interface. I was able to make a function to return all the tags for an operation, and by modifying all the transformation templates to call this during op generation, can 'hand carry' the tags down to code gen. So I can keep working for now.

But I'm really surprised - this seems like such an obvious use case. Tags are necessary to help code gen. Has nobody tried this? Amazing ...

[danm]

Oh dear lord - it gets worse ... parameter tags aren't preserved either. So I dig into an add-in trying to hand carry them across a transformation - but they aren't available there. So unfortunately parameter tags are lost and can't be kept or recovered at all.

In another thread I found that parameter stereotypes are ignored, so I'm in a tight corner. I need to communicate to a parameter (about it's multiplicity), but the tags are blasted, I can't get them from the add-in, and stereotypes are ignored in the templates. LUCKILY, I think I can actually get the stereotype from an add-in, then check that explicitly myself ...