Home » Archived » M2M (model-to-model transformation) » superimposition in UML2
| superimposition in UML2 [message #57583] |
Sat, 11 August 2007 16:14  |
 Ivano
Messages: 35
Registered: July 2009 |
Member |
|
|
Hi, I have a problem superimposing two ATL modules.
I have the following module:
-- @atlcompiler atl2006
-- $Id$
module mod;
create OUT : UML2 from IN : UML2;
uses UML2;
rule Component {
from s : UML2!Component
to t : UML2!Component mapsTo s (
name <- 'ASD',
visibility <- s.visibility,
isLeaf <- s.isLeaf,
isAbstract <- s.isAbstract,
isActive <- s.isActive,
isIndirectlyInstantiated <- s.isIndirectlyInstantiated,
eAnnotations <- s.eAnnotations,
ownedComment <- s.ownedComment,
clientDependency <- s.clientDependency,
nameExpression <- s.nameExpression,
elementImport <- s.elementImport,
packageImport <- s.packageImport,
ownedRule <- s.ownedRule,
templateParameter <- s.templateParameter,
templateBinding <- s.templateBinding,
ownedTemplateSignature <- s.ownedTemplateSignature,
generalization <- s.generalization,
powertypeExtent <- s.powertypeExtent,
redefinedClassifier <- s.redefinedClassifier,
substitution <- s.substitution,
representation <- s.representation,
collaborationUse <- s.collaborationUse,
ownedUseCase <- s.ownedUseCase,
useCase <- s.useCase,
ownedAttribute <- s.ownedAttribute,
ownedConnector <- s.ownedConnector,
ownedBehavior <- s.ownedBehavior,
classifierBehavior <- s.classifierBehavior,
interfaceRealization <- s.interfaceRealization,
ownedTrigger <- s.ownedTrigger,
nestedClassifier <- s.nestedClassifier,
ownedOperation <- s.ownedOperation,
ownedReception <- s.ownedReception,
packagedElement <- s.packagedElement,
realization <- s.realization)
}
It is superimposed on Dennis Wagelaar's UML2Copy.atl
My idea is to copy an entire UML model and to simply rename each component
to ASD. It is only an experiment....
The problems are two:
(1)
the components of the resulting model have the same name of the initial
model; so I think that the rule 'Component' has not been overrided, does
anyone know why?
(2)
the stereotypes and profiles applied to the initial model are not copied
into the resulting model. Does anyone know why?
Regards, Ivano
|
|
|
| Re: superimposition in UML2 [message #57607 is a reply to message #57583] |
Mon, 13 August 2007 15:06  |
Dennis Wagelaar
Messages: 147
Registered: July 2009 |
Senior Member |
|
|
Ivano schreef:
> Hi, I have a problem superimposing two ATL modules.
>
> I have the following module:
>
> -- @atlcompiler atl2006
> -- $Id$
>
> module mod; create OUT : UML2 from IN : UML2;
>
> uses UML2;
>
> rule Component {
> from s : UML2!Component
> to t : UML2!Component mapsTo s (
> name <- 'ASD',
*snip*
> }
>
> It is superimposed on Dennis Wagelaar's UML2Copy.atl
>
> My idea is to copy an entire UML model and to simply rename each
> component to ASD. It is only an experiment....
>
> The problems are two:
> (1)
> the components of the resulting model have the same name of the initial
> model; so I think that the rule 'Component' has not been overrided, does
> anyone know why?
Can you verify the order in which you superimposed? You need to specify
UML2Copy.atl as your main transformation and add your own module to the
superimposed modules list.
>
> (2)
> the stereotypes and profiles applied to the initial model are not copied
> into the resulting model. Does anyone know why?
Stereotype *applications* are not expressed in terms of UML. They have
their own Ecore meta-classes. UML profiles include an Ecore
representation of themselves, where each stereotype is mapped to an EClass.
One way to "copy" stereotype applications is to re-apply them using the
UML2 plugin native API methods. That creates some fall-out, since the
UML2 plugin developers have put ordering constraints on the native API:
stereotypes can only be applied *after* the corresponding profile has
been applied. That conflicts with ATL's execution strategy. The UML24ATL
plugin aims to address this issue.
Another way to copy stereotype applications, is to create special
copying rules for each stereotype (using its EClass representation).
This has the following advantages/drawbacks:
+ no special UML2 driver needed.
+ less regressions caused by new restrictions in the UML2 plugin.
+ transparent w.r.t. underlying technology.
- You need to create extra copying rules for each profile you use.
- You need to create a "wrapper" meta-model, that imports UML as well as
your profiles.
I chose to use the last method, since it leaves me in control :-). The
following page shows some usage scenarios:
http://ssel.vub.ac.be/ssel/research:mdd:casestudies
The UML2Profiles.ecore meta-model is a wrapper meta-model that imports
UML as well as the profiles that I use (UML profiles can be loaded as
meta-models). The "wrapping" is done by creating a dummy (abstract)
meta-class that inherits from (at least) one meta-class from each
meta-model you want to import. The EMF4ATL driver then transitively
loads all referenced meta-models.
The UML2ProfileCopy.atl transformation is the result of applying
EModelCopyGenerator.atl on all desired profiles and putting the
generated rules together.
N.B. UML2 still seems to know when I want to apply stereotypes before
applying a profile, so rule execution order problems still exist. This
is currently solved by making sure that the rule that copies stereotype
applications comes after the rule that copies profiles applications.
(Superimposed rules that do not exist in the base module are added at
the end.)
Regards,
Dennis
>
> Regards, Ivano
>
>
>
|
|
| |
| Re: superimposition in UML2 [message #57891 is a reply to message #57655] |
Tue, 14 August 2007 15:57 |
Dennis Wagelaar
Messages: 147
Registered: July 2009 |
Senior Member |
|
|
Ivano schreef:
> Thank you very much, I understand more your use cases know :)
>
> Last doubt: if I import the transformation of your use case as is, it
> does not compile, but if I delete the "uml::" part of each metamodel
> reference it works, do you know why?
>
>
This is a problem with the new ANTLR3 based parser: it doesn't deal well
with "::" strings. You can work around it by putting double quotes
around the fully qualified names, e.g.:
from s : UML2!"uml::Class"
instead of:
from s : UML2!uml::Class
You may also remove the "uml::" part, but you risk name clashes with
stereotypes, such as those from the Standard profile. I may update
EModelCopyGenerator.atl and UML2Copy.atl from my case studies in the
future, so they already use the quotes.
Regards,
Dennis
|
|
|
Goto Forum:
Current Time: Fri Apr 19 03:51:14 GMT 2024
Powered by FUDForum. Page generated in 0.01407 seconds |
] 
Search
Help
Register
Login
Home
