> > AndroMDA does generate a PSM instance per cartridge, which can be > controlled > > by tagged values in the PIM (UML), but the PSMs are never written to > file > > (we could do that though, we're just not doing it :-)) > > I guess the advantage to writing them to files has to do with tinkering > with it before it goes to code. And there's no tinkering to be done if > from a user's perpective if it's model->code as all the tinkering is done > in the code itself. > [WZ> ] yes, but the disadvantage is that it is *very* complicated to propagate changes in the PSMs back into the PIM. It's complicated because there needs to exists a two-directional mapping between each 2 different models (model2model transformation). Most of the time you add refinements to the next PSM, so how are updates to those refinements reflected into the original PIM ?
I personally don't see how having PSMs on files can be interesting without this feature. IMO AndroMDA attracts people because it's easy to tune the transformation process (by means of templates, properties, ...), tuning model2model transformation rules is very different and difficult, but you would need to if you would ever want to make changes to the transformation process in an MDA system with full tracability. Basically it would require everyone using the transformation and wanting to tune it to get into the gory details and know-how of the PSM-specific internals. This is *much* easier to accept when the transformation process is unidrectional as with AndroMDA. -- Wouter ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-user mailing list Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
