About TRANSFORM_REFERENCE

[SF_lt]

I need more clear TRANSFORM_REFERENCE description:

•
Finding the transformed class to synchronise with.

what if class is created in transformation (there was no such class before transformation? about what synchronisation is taking about (code generation; MDA transformation)?

•
Creating connectors between transformed classes.

there 3 this macro calls while creating connectors - it should be enough 2 (for source & target); why there is a need for the connector?

•
Determining where to transform to for future transformations.

[/quote]
where means inside which entity?

what does this macro?

Code: [Select]


Dependency
{
 %TRANSFORM_REFERENCE("EJBRealizeHome",classGUID)%
 stereotype="EJBRealizeHome"
 Source
 {
   %TRANSFORM_REFERENCE("EJBEntityBean",classGUID)%
 }
 Target
 {
 %TRANSFORM_REFERENCE("EJBHomeInterface",classGUID)%
 }
}


what is the purpose of macro in this example? it makes reference to EJBRealizeHome named template - so what next - after this reference we can access EJBRealizeHome properties? current dependency properties?
I don't get, what is such reference influence (is it calling pointed template?)

Where:
•
If <name> is not specified it gets the name of the current template.
•
If <sourceGUID> is not specified it gets the GUID of the current class.
•
If <namespace> is not specified it gets the name of the current transformation.

if name is specified, it points to the template - name can be template type (for build-in as "Class", "Operation", "Connector") or template type + "__" + template name (for custom templates as "Class__MyTemplate", "Connector__Warning")?

still many questions about TRANSFORM_REFERENCE macro, but none of clear answers or examples :-/

[SF_lt]

also, for those, who want to create custom transformations for new languages:
- there should be at least one new language data type specified (configuration->language datatypes - this isn't stated in creating custom MDA transformations help topic;
- at least File transformation template should be defined for language - transformation starts from this template and it should exist, otherwise .... :-D

[Eve]

The TRANSFORM_REFERENCE macro is used to get a unique reference.

All elements and connectors created with a transform should have one to identify itself in the template.  This is because without one, EA can't know what to synchronise with when doing the transform consecutive times.

Additionally, when creating a connector you need to include a transform reference to identify what element each of the ends should be attached to.  The EJBReadlizeHome reference there is to uniquely identify that connector.

That last quote from the help is describing what the default parameters are.

Hope that helps some.

[SF_lt]

Am I right, that it's necessary to use TRANSFORM_REFERENCE() when creating new elements - connectors, classes & etc?

in the above example of dependency, why not TRANSFORM_REFERENCE() without parameters used? why to specify name & GUID? in this case (with parameters), what difference is from case without parameters (name would get template name)?
Also, is namespace in this macro equivalent to the package? it not, how and from what namespace is got?

%TRANSFORM_REFERENCE("EJBRealizeHome",classGUID)%

If transforming existing element, is it enough to use TRANSFORM_CURRENT() to use/create unique reference?
Saw some transformations with both macros aside..

For example:

Code: [Select]


 %TRANSFORM_REFERENCE("Class")%
 %TRANSFORM_CURRENT("language","stereotype")%
 language="C#"
%if classStereotype != "table"%
 stereotype=%qt%%classStereotype%%qt%
%endIf%


If this code is set to Class type template, can "Class" be left over?

[SF_lt]

it seems, that when adding new class, TRANSFORM_REFERENCE() can be left over - class is created, but maybe this can cause troubles later?

[Eve]

As you noticed, if you don't use the transform reference macro, a class will still be created, but EA won't then record where that class came from.  As a result you won't be able to synchronise with it and EA won't remember the package you performed that transformation to.

While the parameters can often be omitted and the same result achieved, it helps for clarity sake to show the name and the guid that the reference is being created from.

The namespace is not a package, and doesn't correspond to a package at all.  It is the name of the current transform.  This is more frequently left out because in most cases it would actually take away from clarity.  The only reason you would want to use it, is if you were creating a connector between two classes created in different transforms.

An example of this would be a dependency from an EJB class to a DDL table.

Code: [Select]

Dependency
{
 %TRANSFORM_REFERENCE("UsingTable",classGUID,"EJB-DDL")%
 stereotype="UsingTable"
 Source
 {
   %TRANSFORM_REFERENCE("EJBEntityBean",classGUID,"EJB Entity")%
 }
 Target
 {
 %TRANSFORM_REFERENCE("Table",classGUID,"DDL")%
 }
}


This bit of code could be placed in both the EJB Entity Bean template and the DDL Class template.  In this case the Namespace of the actual connector doesn't actually correspond to a transform.  But it could be anything, including either of the transformations involved.

[SF_lt]

An example of this would be a dependency from an EJB class to a DDL table.

Code: [Select]

Dependency
{
  %TRANSFORM_REFERENCE("UsingTable",classGUID,"EJB-DDL")%
  stereotype="UsingTable"
  Source
  {
    %TRANSFORM_REFERENCE("EJBEntityBean",classGUID,"EJB Entity")%
  }
  Target
  {
  %TRANSFORM_REFERENCE("Table",classGUID,"DDL")%
  }
}

This bit of code could be placed in both the EJB Entity Bean template and the DDL Class template.  In this case the Namespace of the actual connector doesn't actually correspond to a transform.  But it could be anything, including either of the transformations involved.

ok, got about first TRANSFORM_REFERENCE - needed for sync   - "UsingTable" is the dependency literal ID (this dependency could be also pointed by "UsingTable" name?), but why using classGUID, not connectorGUID? which class GUID dependency will have - the last class before this dependency? or it will have it's own unique GUID?
Sometimes witness EA (772 build ) crash when using connectorGUID instead of classGUID
Other 2 macros left :-D

Code: [Select]


%TRANSFORM_REFERENCE("EJBEntityBean",classGUID,"EJB Entity")%

source will be class, named "EJBEntityBean"? what about case, if there are several same name classes (there is no enforcement to use unique class names in the package)

Code: [Select]


%TRANSFORM_REFERENCE("Table",classGUID,"DDL")%  

target - class, named "Table"?

[Eve]

The classGUID is used because this connector is being created from that class.  Or in other words, the current class in the templates is the source class for this connector and the two classes.

There is no current connector, so connectorGUID is undefined.

The names "UsingTable", "EJBEntityBean" and "Table", are not the names of the classes (or connector) being created.  They are part of a unique key for all classes (and connectors) created through a transformation.

[SF_lt]

The names "UsingTable", "EJBEntityBean" and "Table", are not the names of the classes (or connector) being created.  They are part of a unique key for all classes (and connectors) created through a transformation.

In many transformations, names for classes are "Class" - so all these classes will have the same part on theirs unique keys. How then to identify exactly needed class? how to differenciate exact entity from all collection? For example from the EJB transformation: there could (and would) be several EJBEntityBean classes - how to know, which one is the right one...
If I'm creating connector not from the class, but from namespace, then I should use namespace's GUID? or namespace GUID is the as class GUID in such case?

[SF_lt]

have made simple transformation test: put 2 classes - ClassA & ClassB, created new language Test
Transformation must transform existing classes without change & to put dependence from the ClassA to ClassB

File template:
Package
{
name="test model"
namespaceroot="true"
%list="Class" @separator="\n\n" @indent="  "%
%Class__Dependency%
}

Class template:
%elemType%
{
%TRANSFORM_REFERENCE( className )%
%TRANSFORM_CURRENT()%
}

Class_Dependency template:
Dependency
{
%TRANSFORM_REFERENCE( "MyDependency" , packageGUID )%
Source
{
%TRANSFORM_REFERENCE( "ClassA" , packageGUID )%
}
Target
{
%TRANSFORM_REFERENCE( "ClassB" , packageGUID )%
}
}

Transformation log (some parts are left):
Package
{
name="test model"
namespaceroot="true"

Class
 {
 XRef{namespace="Test" name="ClassA" source="{F23AACC7-868C-46a1-973D-52ED6D14A75E}"}
   name="ClassA"
 }

 Class
 {
 XRef{namespace="Test" name="ClassB" source="{F49E97C9-7FBB-45fd-A5F0-1501210EAA80}"}
   name="ClassB"
 }
Dependency
{
XRef{namespace="Test" name="MyDependency" source="{84DC9D5F-DDF7-4c95-9959-03589ED194FC}"}
Source
{
XRef{namespace="Test" name="ClassA" source="{84DC9D5F-DDF7-4c95-9959-03589ED194FC}"}
}
Target
{
XRef{namespace="Test" name="ClassB" source="{84DC9D5F-DDF7-4c95-9959-03589ED194FC}"}
}
}
}

dependency template uses packageGUID as it is called from it - is that right?
no dependency is shown between ClassA & ClassB - perhaps I don't know something important about transformation/code generation framework?

[Eve]

Think for a minute about what you're doing.

You've created two classes with unique references as follows.

XRef{namespace="Test" name="ClassA" source="{F23AACC7-868C-46a1-973D-52ED6D14A75E}"}

XRef{namespace="Test" name="ClassB" source="{F49E97C9-7FBB-45fd-A5F0-1501210EAA80}"}

And then you're trying to refer to them with

XRef{namespace="Test" name="ClassA" source="{84DC9D5F-DDF7-4c95-9959-03589ED194FC}"}

and

XRef{namespace="Test" name="ClassB" source="{84DC9D5F-DDF7-4c95-9959-03589ED194FC}"}

Your references don't match the classes that you're trying to refer to.  That's why it's not creating the dependency.

You need to know the source guid for the classes on either side of the dependency when creating it.  So it's only really possible to create a connector in a PSM when either the two classes were from the same PIM class (in which case the name will be different), or you are currently on a connector in the PIM, in which case you have the guids for both ends as well as the original connector.

In the first case the connector is created from the class (so use the classGUID), in the second it is created from the connector, so use the connectorGUID.

[SF_lt]

Other questions:

You need to know the source guid for the classes on either side of the dependency when creating it.

Ok, so I need to store somewhere those GUID for further use in dependency creation. Conclusion - classes must exist before creating dependency (2 variables to store GUID's).
wouldn't it better to reference using names - easier to remember, don't change as GUID?

So it's only really possible to create a connector in a PSM when either the two classes were from the same PIM class (in which case the name will be different),

Am I understand right, that in this case classes in PSM (classA & classB) must be transformed from the same PIM class (let's say - Father)? no way if classes came from different original classes?
if I want to transform not from the same class, then there is no way to make connector between them?

(interesting decision and implementation I must admit (if I understood correctly))

or you are currently on a connector in the PIM, in which case you have the guids for both ends as well as the original connector.

in this case connector must exist in PIM - if it isn't (like in my case) - not an option

Conclude:
there is no dependency in the original model;
classes in PSM come from the 2 classes, not the same as required;
= no way to make dependency

Left option - to remember each class GUID's and to use them to point to required classes (suppose, if there is a need for more classes :-D ) If TRANSFORM_REFERENCE() is used without GUID's, then the current class GUID will be taken - bad again

yeah...

[Eve]

I think these problems come down to what a transformation should be doing.  All transformations are taking information in one form, and creating an alternative representation of that information in another form.  Specifically a PIM to PSM transform is all about adding detail that has been abstracted out of the PIM.

I suggest that your simple transformation above is not trying to do that.  Instead it is trying to add new information.  Where did that information come from?  How does EA (or your transformation) know that ClassA and ClassB are related?

In this case it can only be coming from knowing exactly what the input to your transformation will be, and it knows how to handle that specific input.  What happens if someone uses your transformation on ClassC, ClassD and ClassE?

Conclusion - classes must exist before creating dependency (2 variables to store GUID's).
wouldn't it better to reference using names - easier to remember, don't change as GUID?

No, the classes don't need to exist before the transformation.  But the classes they are created from do need to be.  The catch is that you could execute 4 transformations, each of which create 5 classes.  That's why there are three parameters to TRANSFORM_REFERENCE.  The guid of the source class (constant for any of the class created above, but will change for every class that is transformed), the name of the transformed class (transform name that is, has to be unique in any given namespace) and finally the transform each was created in.

This gives the full power for any element being transformed to create a link between any of the class that make up the representation of it.  This is true across all transformations.  Additionally, a connector between different classes in the PIM could be transformed into a connector between any of the representations of each class.

Names wouldn't work at all.  What happens if someone changes the name of a PIM class.  Then the link is broken.  GUIDs never change. ¹

Am I understand right, that in this case classes in PSM (classA & classB) must be transformed from the same PIM class (let's say - Father)? no way if classes came from different original classes?
if I want to transform not from the same class, then there is no way to make connector between them?

(interesting decision and implementation I must admit (if I understood correctly))

This comes from the above that we don't add information that comes from nowhere.

in this case connector must exist in PIM - if it isn't (like in my case) - not an option

Conclude:
there is no dependency in the original model;
classes in PSM come from the 2 classes, not the same as required;
= no way to make dependency

If there isn't a relation between the classes in the PIM, then there shouldn't be a relation in the PSM.  If there needs to be a relation between the PSM classes, there needs to be a relation between the PIM classes. <sup>2

1</sup> Actually, there is a command in EA to reset the guids in a project, but I've never needed to use it

² Unless someone out there can give a concrete example of a relation in a PSM that doesn't exist in a PSM.  I've thought of the actual implementation relying on the other class, but then all implementations need to get the information.

[SF_lt]

I think these problems come down to what a transformation should be doing.  All transformations are taking information in one form, and creating an alternative representation of that information in another form.

keyword is representation - another form is based on metamodel. And transformations should represent one metamodel entities into anothers.

Specifically a PIM to PSM transform is all about adding detail that has been abstracted out of the PIM.

I suggest that your simple transformation above is not trying to do that.  Instead it is trying to add new information.  Where did that information come from?  How does EA (or your transformation) know that ClassA and ClassB are related?

New information adding also can be part of transformation, as it represents new details (before transformation this new information wasn't necessary). New information comes from metamodel and transformation knows that (as I know). Abstraction doesn't mean, that all information should be already in PIM - that wouldn't be PIM, there I pay attention to things, which are important at the PIM level.
PIM can't know, that ClassA and ClassB are related - it's a transformation duty to know such details. And my transformation knows, that ClassA and ClassB are related.

In this case it can only be coming from knowing exactly what the input to your transformation will be, and it knows how to handle that specific input.  What happens if someone uses your transformation on ClassC, ClassD and ClassE?

that's why package template calls dependency template; whole models are transformed in MDA - of course, there could be models of single class - transformations will know how to deal with it following metamodel and transformation rules

No, the classes don't need to exist before the transformation.  But the classes they are created from do need to be.

... but if PIM doesn't need such classes, then I'm forced to create them (even they don't belong to abstraction level) in order to use EA transformation capability. Transformation drives PIM...

Names wouldn't work at all.  What happens if someone changes the name of a PIM class.  Then the link is broken.  GUIDs never change. ¹

I have created references to classes with names, which match UML class name and I'm responsible to endure UML class names uniqueness. It's easier to remember reference not by GUID, but by reference's name (match UML class name in my case)

Something like this:

Code: [Select]


%TRANSFORM_REFERENCE_EX(className)%


Transformation language (declarative-imperative) must be flexible and support all kind transformations  ;-)

This comes from the above that we don't add information that comes from nowhere.

it comes from mind inspirations ;-)  or metamodels  ;-)

If there isn't a relation between the classes in the PIM, then there shouldn't be a relation in the PSM.  If there needs to be a relation between the PSM classes, there needs to be a relation between the PIM classes. ²

This is the quote of truth (in EA context). But what, if relation between PIM classes is redundant in PIM (but not in PSM) abstraction level.

Small example of PIM-to-PIM refinement:
source PIM: 2 classes - man, dog; association between man and dog
target PIM: man and dog are related with place, so there should be 3 classes: man, dog, place; association between man and dog and man-place, dog-place dependencies.

Similar example:

PIM:


PSM:


And if a source model is large and complicated, then current state of the transformation language can't help at all

[SF_lt]

and suggestion for Sparx: extend transformation capabilities by leting to add new information during transformation.
Currently only new information, which depend only on existing source elements could be add

What other soft could be used for transformations? except EA  and MapForce?