Re: [atl_discussion] How to target a UML profile in ATL? (bis)

From: Pieter Van Gorp <pieter_at_example.com>
Date: Wed Sep 07 2005 - 11:04:50 CEST

Hi Frédéric,

> But anyway, the constraints are expressed as a model.
> As we said in our paper, embedding the constraints in a transformation
> program is only a matter of currying.
> For instance: one could write a transformation from (UML-XMI) to ATL
> that would extract the constraints and automatically generate the
> surrounding ATL code.
>
> To summarize: one can develop a UML-specific tool using a
> transformation engine such as ATL. A UML user would never need to
> write ATL code, but would rather simply write his constraints within a
> UML editor and then evaluate them using the tool.
Seems indeed like a correct application of the MDE approach. Have you
already released the complete transformation from profile WFR models
to ATL programs? I think we could use it.

> What do you mean by "expressive"?
> My personal definition is that language A is more expressive than
> language B when you can address more problems with A than with B.
>
> I do not know Story Diagrams precisely, but I agree declarative ATL
> may be less expressive, especially as it is implemented now.
>
> However, with its imperative part (i.e. turing-complete, although not
> implemented yet), ATL is in theory able to address any problem. But
> maybe not more elegantly than e.g. Java in some cases.
I was referring to the turing-completeness of SDM and the limitations
of declarative ATL. I like SDM because it can be considered as a
rewriting language on top of traditional object-graphs. MoTMoT
compiles SDM rules to Java methods and allows one to use Java within
SDM and vice versa. We don't want to offer yet another syntax for the
imperative constructs already present in Java but not present in graph
rewriting. What's the relationship between imperative ATL and Java?

> Ok, I see that our approaches have several similarities. This seems
> quite interesting.
> Maybe we should consider working together on this.
I'll let you know when I've completed my implementation of CAViT and
the related case study (
http://www.dagstuhl.de/files/Proceedings/05/05161/05161.VanGorpPieter.Paper!.pdf
). I'm also looking forward to use both ATL and SDM within AndroMDA 4
(see http://www.mail-archive.com/andromda-devel@lists.sourceforge.net/msg06298.html
). Then we can work out a common case stuy.

Best regards,
Pieter.

On 9/6/05, Frédéric Jouault <f.jouault@gmail.com> wrote:
> Hi,
>
> > Regarding my statement about UML profiles, I meant that a generic MOF
> > transformation engine does not know about UML profile constraints
> > whereas a UML-specific tool does know about them. The reason for this
> > is that UML Profile WFRs are not specified in a metamodel definition
> > (MOF-XMI) but in a UML model definition (UML-XMI).
>
> Ok, I better understand your statement now.
>
> But anyway, the constraints are expressed as a model.
> As we said in our paper, embedding the constraints in a transformation
> program is only a matter of currying.
> For instance: one could write a transformation from (UML-XMI) to ATL
> that would extract the constraints and automatically generate the
> surrounding ATL code.
>
> To summarize: one can develop a UML-specific tool using a
> transformation engine such as ATL. A UML user would never need to
> write ATL code, but would rather simply write his constraints within a
> UML editor and then evaluate them using the tool.
>
> > You just illustrated that one can express profile WFRs with ATL's OCL
> > engine. In that scenario, you specificy the WFRs explicitly and
> > associate transformations with them. Your approach of creating a
> > "diagnostics model" is quite intuitive. Note that in my profile
> > tutorial (http://www.fots.ua.ac.be/motmot/docs/profileTutorial-p5.php)
> > I'm also checking for the presence of stereotypes to trigger MOF
> > transformations. The main difference is that I use a graphical syntax
> > based on graph rewriting. In the upcoming year a student will extend
> > MoTMoT such that OCL can be used to specify textual constraints and
> > path expressions inside Story Diagrams. Once finished, one will be
> > able to combine the advantages of visual and model queries and
> > associated transformations.
>
> Ok, I see that our approaches have several similarities. This seems
> quite interesting.
> Maybe we should consider working together on this.
>
> > Still I encourage you to continue your more general approach. Please
> > let me know if you succeed to implement the composition of
> > refactorings discussed in our UML'03 paper. Perhaps somebody can work
> > out our example of automatically composing the "extract method"
> > refactoring before the "pull up method" refactoring?
>
> That would be interesting indeed.
>
> > Of course I'm not underestimating the impact of using a particular
> > formalism... Since Story Diagrams (or "controlled graph rewriting") is
> > much more expressive than ATL we should continue to conduct more
> > complex transformation case studies to see which formalism is most
> > suitable in what circumstances.
>
> What do you mean by "expressive"?
> My personal definition is that language A is more expressive than
> language B when you can address more problems with A than with B.
>
> I do not know Story Diagrams precisely, but I agree declarative ATL
> may be less expressive, especially as it is implemented now.
>
> However, with its imperative part (i.e. turing-complete, although not
> implemented yet), ATL is in theory able to address any problem. But
> maybe not more elegantly than e.g. Java in some cases.
>
>
> Regards,
>
> Frédéric Jouault
>

           
Received on Wed Sep 07 02:04:52 2005

This archive was generated by hypermail 2.1.8 : Thu Jan 18 2007 - 15:04:54 CET