[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.modeling.m2m] Re: [ATL] Re-usable modules with metamodels as formal parameters?
Matthias Bohlen schreef:
On 2007-03-19 11:39:51 +0100, Dennis Wagelaar <dennis.wagelaar@xxxxxxxxx> said:

Superimposition cannot do *exactly* what you want. It can work for you, if it's possible to use the same meta-model and model names (IN, OUT, MB, MA, etc.). In this case, you can define a general transformation module with the common transformation rules already in there. Then, you define another transformation module with some specific rules (and perhaps additional models/meta-models), which you can "superimpose" on top of the general transformation module. 

Hi Dennis,

thanks for the update.

Superimposition is not exactly what I need because my metamodels are really different. They contain different metaclasses, only some of which are common across several metamodels. This is why I really need formal parameter substitution at ATL compile time, not superimposition at load time.

Your meta-models can be different, as long as you use the same symbolic name for your models/meta-models in the ATL transformations. For example: 'UML' can refer to different meta-models, as long as they are compatible for your purposes. More on this below...

You mention compile-time: the ATL compiler does not include a linker. That means that helper calls and meta-model types are not checked at compile time. The compiler just includes their symbolic references (e.g. "UML" or "toString()"), such that the virtual machine can look up the helpers and meta-classes. These helpers and meta-classes are looked up in the libraries and (meta-)models you provide in your launch configuration. If you provide your own meta-model and call it "UML" for the purpose of the launch configuration, that's where the ATL VM will look up any meta-classes starting with "UML!".

So ATL does its linking at run-time, except for rule inheritance. Rule inheritance is implemented by inlining, not linking. This means all inherited code is inserted in the child rule.


To give you an example:

AndroMDA generates code for enterprise applications in Java or C#.

AndroMDA has one metamodel (EnterpriseApp) for enterprise applications, it contains a Service and an Entity metaclass. Services and Entities can have methods with parameters and their types, so this metamodel also contains the metaclasses Method, Parameter and Type.

AndroMDA contains a second metamodel (Spring) for Spring-enabled beans. This metamodel contains the metaclass SpringBean. Because SpringBeans can have methods with parameters and their types, the Spring metamodel also contains the same metaclasses Method, Parameter and Type.

Now, AndroMDA even contains a third metamodel called OOP (for object oriented programming). This metamodel contains Class, Interface, Property, Method, Parameter, Type and Comment. So, you see, Method, Parameter and Type again.

(By the way: I create these metamodels in UML 2 and let them include the same sub-model for the OOP metaclasses so that I do not have to repeat myself).

Hey, there we are! You even have a portion of the meta-model that is guaranteed identical for all your meta-models. That means you can, more-or-less, safely define a model transformation for that portion of the meta-model. I say "more-or-less", since ATL is in effect a dynamically typed language and does not provide type safety at compile-time.

(According to model-driven tradition: if you do want compile-time type safety, you can add this by defining a type checking transformation ;-).)


Now, I have three got ATL transformations:

* UML2EnterpriseApp
* EnterpriseApp2Spring
* Spring2OOP

Each one of these transformations has to copy methods with parameters and types from the source to the target model - always the same code except that the metamodels are different although they contain some common metaclasses.

What can we do so that I can write this "copy" code only once? It's really essential for proper operation in AndroMDA.

You can refer to your meta-models with a common symbolic name, e.g. 'MM'. Ever since ATL had support for MOF packages, it's easy to distinguish between the different parts of your metamodel, e.g.:

rule Method {
  from s : MM!common::Method
  to t : MM!common::Method (
    ...)
}

As soon as you use something specific from your "other" meta-models (it's really just one big meta-network), you use a different MOF package:

rule SpringBean {
  from s : MM!spring::SpringBean
  to t : MM!spring::SpringBean (
    ...)
}


Some months ago, Frédéric proposed this kind of "formal metamodel parameter substitution". Would it be difficult to implement? Who has got the necessary knowledge about the compiler?

Cheers,
Matthias


It would be more difficult than the above solution of just using 'MM' whenever you refer to one of your meta-models.

The ATL compiler is in effect an ATL model transformation, for which the source is unfortunately not available in the Eclipse CVS (/org/atl/eclipse/engine/resources/ATLToASMCompiler.asm). The ATL engine does provide an extension point such that you can include your own compiler. I believe Frédéric has access to and knows everything about the standard compiler setup.

--
Regards,
Dennis