Hi Matthias,
I'm happy to see you have similar goals as I originally set out for my
Ph. D. research.  Indeed, requirements can be set as transformation
parameters to configure transactions etc.  I got some delay in my
research by working on a project concerning UML refactoring and
investigating how graph transformation theory could be applied in the
context of model transformation.  Therefore, I haven't been able to
apply my actual research proposal in AndroMDA yet but as I'm making
good progress on CAViT's implementation, we may be able to produce an
alternative for your ATL approach relatively soon...

Looking forward to compare the results,
-- Pieter.

On 8/23/05, Matthias Bohlen <[EMAIL PROTECTED]> wrote:
> Hello Pieter,
> 
> Tuesday, August 23, 2005, 9:51:12 AM, you wrote:
> 
> PVG> Hi Matthias, please be careful not to keep the semantics of your
> PVG> UML::foundation::core metapackage and Java metamodel at the same level
> PVG> of abstraction.  A UML class shouldn't map directly on a Java class.
> PVG> I mean: you could give both the same semantics but I believe you would
> PVG> use MDA outside its original scope.  Reengineering the EJB cartridge
> PVG> would be a good case study for model transformations since one can
> PVG> introduce several useful abstraction layers.  I'm just mentioning this
> PVG> because most ATL examples involve mappings between languages at the
> PVG> same levels of abstraction...
> 
> PVG> Best regards,
> PVG> Pieter.
> 
> good point, I agree with you completely! I have already seen people write
> transformations too simple and straightforward. :-)
> 
> No, we won't do transformations between identical abstraction layers.
> We will have several levels in between. For example, the Spring
> cartridge could have its own PSM metamodel. A UML <<Service>> could be
> translated into a Service instance in the Spring metamodel and then
> further be transformed into separate Class and Interface instances in
> the 3GL metamodel as well as into text format, i.e. an entry in
> applicationContext.xml. That way, we'll achieve more re-use and less
> code. There could also be all kinds of technical stuff in the Spring
> metamodel, e.g. support for transactions, security, etc. That will
> depend on requirements and feasability.
> 
> I also intend to have higher level constructs in the 3GL metamodel,
> for example pre- and postconditions of methods. That way, concrete
> cartridges like Java and C# could map those conditions to additional
> methods in the generated code.
> 
> Re-engineering the EJB cartridge would be an interesting project.
> However, EJB 2.x will soon go away and be replaced by EJB 3.0, so we
> should at least wait until we decide to invest further resources into
> it for AndroMDA 4.0.
> 
> The possibilities are endless...
> Matthias
> 
> ---
> 
> Matthias Bohlen
> 
> Internet:
>    http://www.mbohlen.de/
>    [EMAIL PROTECTED]
> 
> Post:
>    Luise-Albertz-Str. 25
>    D-53340 Meckenheim
> 
> Tel: 0170 / 772 8545
> Fax: 02225 / 945189
> 
> 
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Reply via email to