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