Getting started: Custom Transformation Template

[Bokkie]

I'm trying to get started writing custom transformation templates. The information I find on this subject is a bit scattered.

E.g. one thing I would like to do is transform a class with a stereotype into a package that contains a component.

Can anyone give me a very simple example how to transform a class into something different?

Thanks!

M.

[Bokkie]

Ok, I have managed to make a start. Works fine. There are a few things I can't get working the way I want 'm to work:

I would like to transform class its statemachine into a state-pattern. I managed to create classes for the states and the state base class. However I am having problems creating the generalization between the base and the derived states. Since base is 'automagically' created by the template I do not know its GUID.

Further: is it possible to specify the colour of the generated items?

Also: How do I create a diagram from a transformation and how to specify its content?

Where do I find the exact specification of the intermediary file format?

Thanks!

M.

[«Midnight»]

Hey Bokkie,

I do not have the answers to your other questions, but regarding this:

Since base is 'automagically' created by the template I do not know its GUID.

Check out:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=Automation;action=display;num=1140091052;start=4#4

Hope this moves you forward,
David

[Bokkie]

Thanks,

I have had a look at it am affraid that is does not solve my problem.

In the example, an n-m Connector is transformed into two 1-n Connectors and a cross-table.

My case is a little different: I have n States which are transformed into Classes. All generated 'state'-classes must derive from a common baseclass (generated by the transformation also). :-/

M.

[Bokkie]

To make it more concrete here's my template:

Class template:

Code: [Select]


%if elemType == "Class" and classStereotype =="LPC"%
$baseclass=%TRANSFORM_REFERENCE("StateBase", classGUID)%

Package
{
 name=%className%
 stereotype="PC"
 Class
 {
   name="%className%Executer"
 }
 Class
 {
   name="%className%State"
   $baseclass
 }
 %list="Class__State" @separator="\n\n" @indent="  "%
}
%endIf%


And the Class__State template:

Code: [Select]


%if elemType == "State"%
$stateA=%TRANSFORM_REFERENCE("State", classGUID)%
Class
{
 name="%className%"
 stereotype="state"
 $stateA
}

Generalization
{
$stateA
   direction="Source -> Destination"
Source
{
 $stateA
}
Target
{
 ***WHAT TO DO HERE****
}
}
%endIf%


[«Midnight»]

Oh well,

I was hoping you could use the tweak in the other thread to somehow catch the GUID of a newly generated element. You'd still need to massage the Sparx-provided code from earlier in the thread. But, if the necessary information is not there then it would not help.

I think some means of 'grasping' a generated element on the fly would be useful for complex transforms. You should consider using the Help / On-line Resources / Request a Feature item from within EA. These requests go directly into the hopper for consideration at Sparx.

In the meantime, could you solve your immediate by kluding together a couple of transforms? The first might set up some unattached (or whatever) classes derived from the states etc. you have now. The second (and subsequent?) transforms would grab these - they are not newly-created when this transform starts - and link them up, etc. You would probably have to add some attributes to the original elements that could be carried through the first transform, and used by later stages to identify elements for later processing. Any of these attributes could (probably) be cleaned up at the final stage. Not elegant, but perhaps it would get you past this roadblock.

David

[Bokkie]

Thanks for the tip.

Indeed, it could be solved using a two-stage transformation but that would not win the beauty contest. For this time I'll leave it as it is

I have posted the Feature Request. Hoping a patch will come soon.

Martin,

[«Midnight»]

I agree on both counts. But just think of all the time we'll save through not having to discuss how elegant it would have been  ;-)

This is one area where I'd like to see improvement. There are several other spots where - from an automation or extension standpoint - we have to essentially save our work (to a file or whatever), and then reopen it and start again, in order to achieve a goal.

I've been staying out of the way on these since Sparx is clearly pushing hard to get 6.5 out the door. Still, I think you are right to get these things on the list now so that they get into the product before (or at least 'for') the next major release.

Scripting in particular is one area where much could be done, without abandoning the core language that Sparx has built. With that in mind I sometimes find myself deciding to wait a few months to see if Sparx attacks a 'missing' capability, rather than investing substantial time searcing for a work around that might quickly become obsolete.

Perhaps we could collectively come up with some kind of coherent set of 'missing' scripting functionality and present it to Sparx as a whole. It might give them a clearer goal, thus making it easier to get a suite of functions added, in a consistent manner.

The EA User Group - get the link from the top of the Automation theme if anyone is interested - might be the place to discuss this.

Who knows...

[Eve]

If I understand correctly, your problem is that each inner class needs to know its parent GUID before it can reference it using the TRANSFORM_REFERENCE.

I see two alternatives.  One would be to use an EXEC_ADD_IN call to traverse to the parent and get its guid.

The other is probably a bit easier.

Where you want to refer to the parents guid in the Class__State template, simply use some constant such as #PARENT_GUID#.  Then do a replace on the result of the list.

Class__State template

Code: [Select]


%if elemType == "State"%
$stateA=%TRANSFORM_REFERENCE("State", classGUID)%
Class
{
 name="%className%"
 stereotype="state"
 $stateA
}

Generalization
{
$stateA
   direction="Source -> Destination"
Source
{
 $stateA
}
Target
{
 %TRANSFORM_REFERENCE("StateBase", classGUID)%
}
}
%endIf%

Class template

Code: [Select]


%if elemType == "Class" and classStereotype =="LPC"%
$baseclass=%TRANSFORM_REFERENCE("StateBase", "#PARENT_GUID#")%

Package
{
 name=%className%
 stereotype="PC"
 Class
 {
   name="%className%Executer"
 }
 Class
 {
   name="%className%State"
   $baseclass
 }
$states=%list="Class__State" @separator="\n\n" @indent="  "%
%REPLACE($states, "#PARENT_GUID#", classGUID)%
}
%endIf%

That should get you the result you want.  Another version of this would be replacing #PARENT_STATE_REFERENCE# with $baseclass.

Diagrams and display properties of the created elements can't currently be set by a transformation.  It currently focusses only constructing the correct model.

[Bokkie]

Thanks, I've got it working now!

There are some errors in your example. Here is the correct code:

Class__State

Code: [Select]


%if elemType == "State"%
$stateA=%TRANSFORM_REFERENCE("State", classGUID)%
Class
{
 name="%className%"
 stereotype="state"
 $stateA
}

Generalization
{
$stateA
   direction="Source -> Destination"
Source
{
 $stateA
}
Target
{
 %TRANSFORM_REFERENCE("StateBase","#PARENT_GUID#")%
}
}
%endIf%


Class

Code: [Select]


%if elemType == "Class" and classStereotype =="LPC"%
$baseclass=%TRANSFORM_REFERENCE("StateBase", classGUID)%

Package
{
 name=%className%
 stereotype="PC"
 Class
 {
   name="%className%Executer"
 }
 Class
 {
   name="%className%State"
   $baseclass
 }
$states=%list="Class__State" @separator="\n\n" @indent="  "%
%REPLACE($states, "#PARENT_GUID#", classGUID)%
}
%endIf%


[Bokkie]

This leads to another question. Assume you have a transformation from the source model - Model A to Model B. You start working on Model A, transform it to Model B and continue working with Model B. Then you realize (this never happens to you offcourse   ) that there is something missing in Model A - you make the addition in Model A. Is it possible to make the transformation again from A to B without loosing your work in B - i.e. a Merge or Update Transformation.

Thanks

[Eve]

Looks like I replaced the wrong classGUID with "#PARENT_GUID#"  It was the description of the solution that was the important thing though.

Well, the transform keeps track of any attributes/operations that were created in a transformation, and only removes those that were created in a previous transform but not in the current one.  This doesn't help you if you've modified an attribute, but it does if you've added a new one.