|Re: [ATL] Why UML2 driver? What's the difference to the EMF driver? [message #69404 is a reply to message #69201]
||Thu, 13 December 2007 06:31
| Frédéric Jouault
Registered: July 2009
Please, remember to use the [ATL] prefix :-).
> after some months, I came back to use ATL and got the latest sources
> from CVS. I noticed that there is now a special UML2 driver. When I look
> at the code I see that it is almost identical to the EMF driver except
> for some lines of code concerning "delayed invocations" (whatever that
> So my questions today:
> * In the past, I used the EMF driver with UML2 models, and it worked.
> What is the advantage when I use the UML2 driver, instead?
> * The UML2 driver contains quite a lot of duplicate code from the EMF
> driver. The EMF driver contains code to make it thread-safe - code that
> is not present in the UML2 driver. What is the maintenance strategy to
> avoid fixing bugs twice? Could anybody refactor these drivers so that
> the code is present only once?
The problem with the UML2 plugin is that it does not implement an EMF
metamodel. It leverages EMF, but extends/changes its semantics with Java
code. These extensions make some general assumptions about EMF models
not true anymore for UML2 "models".
For instance, there is no ordering constraint when creating an EMF
model, but there are some ordering constraints with respect to profile &
stereotype application in the UML2 plugin.
The UML2 driver abstracts these differences to make it possible to use
UML2 transparently in ATL.
You can also find this information on the wiki:
I would certainly prefer that the UML2 plugin did not need a specific
driver :-/. As you noticed, this creates some maintenance issues. Some
of these issues may be removed by doing some refactoring as you suggested.
Powered by FUDForum
. Page generated in 0.01462 seconds