Home » Archived » M2M (model-to-model transformation) » [QVTO] transforming profile-based models
| [QVTO] transforming profile-based models [message #78970] |
Sun, 13 April 2008 15:23  |
Eclipse User |
|
|
|
Originally posted by: comouraf-lixo.yahoo.fr
Hi,
I'd like to make transformations involving profiles and stereotypes.
However, even simple examples seem complicated. For the moment, all I wanted
is to transform elements conforming to a given stereotype (from the source
profile) into its namesake in the target metamodel. It's therefore a mostly
one-to-one transformation, so it should not be difficult. But it is not that
simple in practice. For example, I have an UML element of type "Port" to
which I apply the stereotype "MyProfile::FlowPort" and wanted to obtain the
FlowPort element from my metamodel. However, the following mapping does not
work (i.e., qvto does not recognize "extension_FlowPort" as a valid
property
mapping UML::Port::port2flowPort(): GCM::FlowPort
when{not self.extension_FlowPort.oclIsUndefined()}
{
isAtomic:=self.extension_FlowPort.isAtomic;
}
Just for fun, I tried to think of the stereotyped model element as a kind of
stereotype and made up the following mapping, to see what happens (did not
work either):
mapping UML::Stereotype::port2flowPort(): GCM::FlowPort
when{not self.base_Port.oclIsUndefined()}
{
isAtomic:=self.base_Port.isAtomic;
}
Of course, I could also have used the EMF-based calls, like in the example
below (but, if possible, I would prefer to stick to "pure" UML):
mapping UML::Port::port2flowPort(): GCM::FlowPort
when{not self.getAppliedStereotype('MyProfile::FlowPort').oclIsUndefi ned()}
{
isAtomic:=self.getValue(self.getAppliedStereotype('MyProfile ::FlowPort'),'isAtomic').oclAsType(Boolean);}Even if this time I had no syntax errors, it does not work either because ofanother -unrelated- thing: I just don't know how to publish the profile'sURI (to use it with modeltype). So, I seize this opportunity to ask what arethe available methods of defining a profile, so I can use its URI in amodeltype clause (not programmatically). I know of at least two ways: firstthe "static" one, which generates classes from a profile, just like it doesto a regular ecore metamodels. But I don't think it's a good idea since qvtois not going to make use of the (hundreds of) generated classes anyway(neither wanted I use blackboxes for this simple case). As for the dynamicway, using the 'define' action -which creates a ecore file and append it tothe the uml file - I don't know how to publish the the URI. Are there otherways?Sorry for the long post. But, once all these question are answered, maybeI'll be ready to publish a paper on the "best pratices" to transformingprofiles ;-)Thanks,César
|
|
|
| Re: [QVTO] transforming profile-based models [message #79098 is a reply to message #78970] |
Mon, 14 April 2008 16:11  |
| Eclipse User |
|
|
|
Hi César,
Actually, thanks for the long post ;-)
At the moment, QVTo does not have such out-of-the box support for UML
profiles
as you have outlined.
However, the dynamic way with a defined profile and publishing the URI
sounds feasible,
I will look into that and let you know.
Regards,
/Radek
On Sun, 13 Apr 2008 21:23:07 +0200, kaiserlautern <comouraf-lixo@yahoo.fr>
wrote:
> Hi,
>
> I'd like to make transformations involving profiles and stereotypes.
> However, even simple examples seem complicated. For the moment, all I
> wanted is to transform elements conforming to a given stereotype (from
> the source profile) into its namesake in the target metamodel. It's
> therefore a mostly one-to-one transformation, so it should not be
> difficult. But it is not that simple in practice. For example, I have an
> UML element of type "Port" to which I apply the stereotype
> "MyProfile::FlowPort" and wanted to obtain the FlowPort element from my
> metamodel. However, the following mapping does not work (i.e., qvto
> does not recognize "extension_FlowPort" as a valid property
>
> mapping UML::Port::port2flowPort(): GCM::FlowPort
> when{not self.extension_FlowPort.oclIsUndefined()}
> {
> isAtomic:=self.extension_FlowPort.isAtomic;
> }
>
> Just for fun, I tried to think of the stereotyped model element as a
> kind of stereotype and made up the following mapping, to see what
> happens (did not work either):
>
> mapping UML::Stereotype::port2flowPort(): GCM::FlowPort
> when{not self.base_Port.oclIsUndefined()}
> {
> isAtomic:=self.base_Port.isAtomic;
> }
>
> Of course, I could also have used the EMF-based calls, like in the
> example below (but, if possible, I would prefer to stick to "pure" UML):
>
> mapping UML::Port::port2flowPort(): GCM::FlowPort
> when{not
> self.getAppliedStereotype('MyProfile::FlowPort').oclIsUndefi ned()}
> {
> isAtomic:=self.getValue(self.getAppliedStereotype('MyProfile ::FlowPort'),'isAtomic').oclAsType(Boolean);}Even
> if this time I had no syntax errors, it does not work either because
> ofanother -unrelated- thing: I just don't know how to publish the
> profile'sURI (to use it with modeltype). So, I seize this opportunity to
> ask what arethe available methods of defining a profile, so I can use
> its URI in amodeltype clause (not programmatically). I know of at least
> two ways: firstthe "static" one, which generates classes from a profile,
> just like it doesto a regular ecore metamodels. But I don't think it's a
> good idea since qvtois not going to make use of the (hundreds of)
> generated classes anyway(neither wanted I use blackboxes for this simple
> case). As for the dynamicway, using the 'define' action -which creates a
> ecore file and append it tothe the uml file - I don't know how to
> publish the the URI. Are there otherways?Sorry for the long post. But,
> once all these question are answered, maybeI'll be ready to publish a
> paper on the "best pratices" to transformingprofiles ;-)Thanks,César
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVTO] transforming profile-based models [message #79114 is a reply to message #79098] |
Mon, 14 April 2008 18:02 |
| Eclipse User |
|
|
|
Originally posted by: comouraf-lixo.yahoo.fr
Hi, Radek,
Since QVTO apparently does not accept UML files as target model URIs in
metamodel mappings, we are left with the only choice of generating the
ecore metamodel corresponding to our profile (even if, contrary to what I
said before, we don't need to generate classes).
However, the problem of converting between metaclasses, sterotypes and
metamodel still persists. I'll give you a simplified example of what I need
and maybe you may suggest me something. As I said before, I want to create
metamodel's FlowPorts from each UML port that has the FlowPort stereotype.
The query provided below would serve to bridge the semantic gap between UML
Ports and Flowports. The problem is that "extension_FlowPort" is not
recognized. Nevertheless, I think that the problem here is OCL's and not
QVT's (unless QVTO provides its own OCL implementation). In fact, with the
MDT-OCL interpreter, I cannot see "extension_FlowPort" either (apparently,
MDT-OCL does not support the navigation of non-navigable association ends -
an optional feature in the OCL spec.). Anyway, I'm just begining with all
this stuff (QVT, OCL, etc) , and I am sure that there must be many
workarounds to this problem.
mapping UML::Class::composite2structuredComponent() :
GCM::StructuredComponent {
name:=self.name;
ownedPorts:=
self.ownedPort.umlport2mmport().oclAsType(InteractionPort)->asBag();
}
query Port::umlport2mmport():MarteProfile::MARTE_Foundations::GCM: :FlowPort{
self.extension_FlowPort->map stereotypeport2mmPort();
}
mapping
MarteProfile::MARTE_Foundations::GCM::FlowPort::stereotypepo rt2mmport():
GCM::FlowPort
when{not self.base_Port.oclIsUndefined()}
{
isAtomic:=self.isAtomic;
}
Thank you again,
César
"Radek Dvorak" <radek.dvorak@borland.com> a écrit dans le message de
news:op.t9mac4aghj1a1g@czprl-rdvorak2.emea.borl.net...
> Hi César,
>
> Actually, thanks for the long post ;-)
> At the moment, QVTo does not have such out-of-the box support for UML
> profiles
> as you have outlined.
> However, the dynamic way with a defined profile and publishing the URI
> sounds feasible,
> I will look into that and let you know.
>
> Regards,
> /Radek
>
> On Sun, 13 Apr 2008 21:23:07 +0200, kaiserlautern <comouraf-lixo@yahoo.fr>
> wrote:
>
>> Hi,
>>
>> I'd like to make transformations involving profiles and stereotypes.
>> However, even simple examples seem complicated. For the moment, all I
>> wanted is to transform elements conforming to a given stereotype (from
>> the source profile) into its namesake in the target metamodel. It's
>> therefore a mostly one-to-one transformation, so it should not be
>> difficult. But it is not that simple in practice. For example, I have an
>> UML element of type "Port" to which I apply the stereotype
>> "MyProfile::FlowPort" and wanted to obtain the FlowPort element from my
>> metamodel. However, the following mapping does not work (i.e., qvto
>> does not recognize "extension_FlowPort" as a valid property
>>
>> mapping UML::Port::port2flowPort(): GCM::FlowPort
>> when{not self.extension_FlowPort.oclIsUndefined()}
>> {
>> isAtomic:=self.extension_FlowPort.isAtomic;
>> }
>>
>> Just for fun, I tried to think of the stereotyped model element as a
>> kind of stereotype and made up the following mapping, to see what
>> happens (did not work either):
>>
>> mapping UML::Stereotype::port2flowPort(): GCM::FlowPort
>> when{not self.base_Port.oclIsUndefined()}
>> {
>> isAtomic:=self.base_Port.isAtomic;
>> }
>>
>> Of course, I could also have used the EMF-based calls, like in the
>> example below (but, if possible, I would prefer to stick to "pure" UML):
>>
>> mapping UML::Port::port2flowPort(): GCM::FlowPort
>> when{not
>> self.getAppliedStereotype('MyProfile::FlowPort').oclIsUndefi ned()}
>> {
>>
>> isAtomic:=self.getValue(self.getAppliedStereotype('MyProfile ::FlowPort'),'isAtomic').oclAsType(Boolean);}Even
>> if this time I had no syntax errors, it does not work either because
>> ofanother -unrelated- thing: I just don't know how to publish the
>> profile'sURI (to use it with modeltype). So, I seize this opportunity to
>> ask what arethe available methods of defining a profile, so I can use
>> its URI in amodeltype clause (not programmatically). I know of at least
>> two ways: firstthe "static" one, which generates classes from a profile,
>> just like it doesto a regular ecore metamodels. But I don't think it's a
>> good idea since qvtois not going to make use of the (hundreds of)
>> generated classes anyway(neither wanted I use blackboxes for this simple
>> case). As for the dynamicway, using the 'define' action -which creates a
>> ecore file and append it tothe the uml file - I don't know how to
>> publish the the URI. Are there otherways?Sorry for the long post. But,
>> once all these question are answered, maybeI'll be ready to publish a
>> paper on the "best pratices" to transformingprofiles ;-)Thanks,César
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVTO] transforming profile-based models [message #79163 is a reply to message #78970] |
Tue, 15 April 2008 04:14 |
| Eclipse User |
|
|
|
Hello kaiserlautern,
Qvto supports UML profiles just as ordinary UML client, i.e. no special
API is introduced. By that means qvto doesn't differ from OCL for example.
Existed profile support provided by UML2 metamodel is enough to access
profile info.
As you mentioned there are two basic opportunities to define profile -
'dynamic' and 'static'.
For dynamic one you have to use stereotype related operations (like
UML::Element::getValue(Stereotype, String) and others).
For example (for input UML model profile named 'UmlInColor' was applied) :
modeltype Uml uses "http://www.eclipse.org/uml2/2.1.0/UML";
modeltype Ecore uses "http://www.eclipse.org/emf/2002/Ecore";
transformation Profiles(in uml : Uml, out ecore : Ecore);
main() {
uml.objectsOfType(Class)->collect(map toEClass());
}
mapping Class::toEClass() : EClass {
init {
var stereotype := self.getAppliedStereotype('UmlInColor::thing');
}
name := self.getValue(stereotype, 'Address').oclAsType(String);
}
In case of statically defined profile (see
http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.u ml2/msg00817.html)
you can declare it's URI and work with stereotyped features.
For example ('UmlInColor' profile this time was statically defined):
modeltype Uml uses "http://www.eclipse.org/uml2/2.1.0/UML";
modeltype Ecore uses "http://www.eclipse.org/emf/2002/Ecore";
modeltype UmlInColor uses "http://UmlInColor";
transformation Profiles(in uml : Uml, out ecore : Ecore);
main() {
uml.objectsOfType(Class)->collect(map toEClass());
}
mapping Class::toEClass() : EClass {
init {
var stereotype := self.getAppliedStereotype('UmlInColor::thing');
var streotypeApp :=
self.getStereotypeApplication(stereotype).oclAsType(UmlInCol or::thing);
}
name := streotypeApp.Address;
}
Examples above tested with M6 builds bundle (EMF, OCL, UML2, QVTO).
Also some comments are inlined below.
Regards,
Sergey.
kaiserlautern wrote:
> Hi,
>
> I'd like to make transformations involving profiles and stereotypes.
> However, even simple examples seem complicated. For the moment, all I
> wanted is to transform elements conforming to a given stereotype (from
> the source profile) into its namesake in the target metamodel. It's
> therefore a mostly one-to-one transformation, so it should not be
> difficult. But it is not that simple in practice. For example, I have an
> UML element of type "Port" to which I apply the stereotype
> "MyProfile::FlowPort" and wanted to obtain the FlowPort element from my
> metamodel. However, the following mapping does not work (i.e., qvto
> does not recognize "extension_FlowPort" as a valid property
>
> mapping UML::Port::port2flowPort(): GCM::FlowPort
> when{not self.extension_FlowPort.oclIsUndefined()}
> {
> isAtomic:=self.extension_FlowPort.isAtomic;
> }
Of course it does not since UML::Port classifier has no
'extension_FlowPort' feature.
>
> Just for fun, I tried to think of the stereotyped model element as a
> kind of stereotype and made up the following mapping, to see what
> happens (did not work either):
>
> mapping UML::Stereotype::port2flowPort(): GCM::FlowPort
> when{not self.base_Port.oclIsUndefined()}
> {
> isAtomic:=self.base_Port.isAtomic;
> }
Just the same - UML::Stereotype classifier has no 'base_Port' feature.
>
> Of course, I could also have used the EMF-based calls, like in the
> example below (but, if possible, I would prefer to stick to "pure" UML):
>
> mapping UML::Port::port2flowPort(): GCM::FlowPort
> when{not self.getAppliedStereotype('MyProfile::FlowPort').oclIsUndefi ned()}
> {
> isAtomic:=self.getValue(self.getAppliedStereotype('MyProfile ::FlowPort'),'isAtomic').oclAsType(Boolean);}Even
> if this time I had no syntax errors, it does not work either because
> ofanother -unrelated- thing: I just don't know how to publish the
> profile'sURI (to use it with modeltype).
For the Element.GetValue() like operations you don't have to publish
profile metamodel URI. It's kind of reflective API for which you only
should provide correctly spelled string names for the element of
interest (profile, stereotype, etc.).
> So, I seize this opportunity to
> ask what arethe available methods of defining a profile, so I can use
> its URI in amodeltype clause (not programmatically). I know of at least
> two ways: firstthe "static" one, which generates classes from a profile,
> just like it doesto a regular ecore metamodels. But I don't think it's a
> good idea since qvtois not going to make use of the (hundreds of)
> generated classes anyway(neither wanted I use blackboxes for this simple
> case).
Qvto uses these "(hundreds of) generated classes" by means of EMF.
For me "static" profile definition is more convenient since that way
Qvto has access to profile metamodel.
> As for the dynamicway, using the 'define' action -which creates a
> ecore file and append it tothe the uml file - I don't know how to
> publish the the URI.
There is no need to obtain profile's URI. Operations that UML metamodel
provides for profile access require string names of elements and features.
> Are there otherways?Sorry for the long post. But,
> once all these question are answered, maybeI'll be ready to publish a
> paper on the "best pratices" to transformingprofiles ;-)Thanks,César
|
|
|
| Re: [QVTO] transforming profile-based models [message #79316 is a reply to message #79163] |
Tue, 15 April 2008 18:31 |
| Eclipse User |
|
|
|
Originally posted by: comouraf-lixo.yahoo.fr
Hi, Sergey and Radek,
Thank you for your guidance. Much of the problems I faced was simply due to
a bad profile. I made the same tests using an error-free profile (i.e.
Ecore's) and everything worked as anticipated. I only have a final
comment/question (until next message, of course ;-) :
> Of course it does not since UML::Port classifier has no
> 'extension_FlowPort' feature.
> ......
> Just the same - UML::Stereotype classifier has no 'base_Port' feature.
How then should I interpret (and especially make use of) the following part
from the UML spec (page 657):
"The MOF construct equivalent to an extension is an aggregation from the
extended metaclass to the extension stereotype, navigable from the extension
stereotype to the extended metaclass. When the extension is required, then
the cardinality on the extension stereotype is "1." The role names are
provided using the following rule: The name of the role of the extended
metaclass is:
'base_' extendedMetaclassName
The name of the role of the extension stereotype is:
'extension$_' stereotypeName
Constraints are frequently added to stereotypes. The role names will be used
for expressing OCL navigations. For example, the following OCL expression
states that a Home interface shall not have attributes:
self.base_Interface.ownedAttributes->size() = 0"
That is, this extension-equivalence is not something we can use in our
transformations (if not now, sometime later) ? (The MDT-OCL interpreter,
for example, offers "base_Metaclass" as a stereotype property in its code
completion feature.)
Thanks once again,
César
|
|
|
| Re: [QVTO] transforming profile-based models [message #79551 is a reply to message #79316] |
Fri, 18 April 2008 07:44 |
| Eclipse User |
|
|
|
Hi kaiserlautern,
Comments are inlined below..
Regards,
Sergey.
kaiserlautern wrote:
> Hi, Sergey and Radek,
>
> Thank you for your guidance. Much of the problems I faced was simply
> due to a bad profile. I made the same tests using an error-free profile
> (i.e. Ecore's) and everything worked as anticipated. I only have a final
> comment/question (until next message, of course ;-) :
>
>
>> Of course it does not since UML::Port classifier has no
>> 'extension_FlowPort' feature.
>> ......
>> Just the same - UML::Stereotype classifier has no 'base_Port' feature.
>
> How then should I interpret (and especially make use of) the following
> part from the UML spec (page 657):
>
> "The MOF construct equivalent to an extension is an aggregation from the
> extended metaclass to the extension stereotype, navigable from the
> extension stereotype to the extended metaclass. When the extension is
> required, then the cardinality on the extension stereotype is "1." The
> role names are provided using the following rule: The name of the role
> of the extended metaclass is:
> 'base_' extendedMetaclassName
> The name of the role of the extension stereotype is:
> 'extension$_' stereotypeName
> Constraints are frequently added to stereotypes. The role names will be
> used for expressing OCL navigations. For example, the following OCL
> expression states that a Home interface shall not have attributes:
> self.base_Interface.ownedAttributes->size() = 0"
>
UML generates profile metamodel according to that. Features 'base_..'
and 'extension_..' exist in generated profile's ecore model (either for
"dymanic" or "static" definition).
Internally UML implementation uses 'base_' and 'extension_' prefixes
(with help of String.startWith() function) to filter profile-oriented
features.
> That is, this extension-equivalence is not something we can use in our
> transformations (if not now, sometime later) ? (The MDT-OCL
> interpreter, for example, offers "base_Metaclass" as a stereotype
> property in its code completion feature.)
Right, MDT-OCL provides support for UML profiles. It's implicitly
considers not only element's metaclass (from UML metamodel in case) but
also checks for profile metamodel in case of applied stereotype. That's
done in UML specialization of OCL (org.eclipse.ocl.uml plugin,
UMLEvaluationEnvironment::getEClassifier()).
Returning to the 'UML::Port' and 'UML::Stereotype' features:
MDT-OCL interpreter can explore profile features since it operates in
context of concrete instance to which stereotype is applied.
In QVT we operates with element's metaclass and no runtime info on
actual instance is available.
Approach like
self.getStereotypeApplications()->select(oclIsKindOf(UmlInColor::thing))
is the only available at development time.
>
> Thanks once again,
>
> César
>
>
|
|
|
Goto Forum:
Current Time: Fri Oct 31 03:31:51 EDT 2025
Powered by FUDForum. Page generated in 0.46851 seconds |
Home