Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » Transform to SysML Blocks(I'm trying to transform a model from a custom meta-model to SysML, but I'm stuck on creating SysML Blocks.)
Transform to SysML Blocks [message #872514] Wed, 16 May 2012 09:02 Go to next message
Matteo M. is currently offline Matteo M.Friend
Messages: 40
Registered: May 2012
Member
Dear all,

I'm trying to transform a model from a (extremely simple) custom meta-model to SysML, but I'm stuck on creating SysML Blocks.

By opening a simple Papyrus diagram containing a Block (the *.uml file), I noticed that, in its simpler form, a SysML Block is described by the two following entries:

1) a <packagedElement xmi:type="uml:Class" xmi:id="_pNiGwJnwEeG8hYBgdInPzQ" name="Block0">, inside

<uml:Model xmi:id="_tSXsoJnZEeG_XYf4QGS6LA" name="SysMLmodel"> ... </uml:Model>

2) a <Blocks:Block xmi:id="_pQ_qcJnwEeG8hYBgdInPzQ" base_Class="_pNiGwJnwEeG8hYBgdInPzQ"/>, outside of <uml:Model xmi:id="_tSXsoJnZEeG_XYf4QGS6LA" name="SysMLmodel"> ... </uml:Model> and inside <xmi:XMI xmi:version="2.1" ....> ... </xmi:XMI>

In defining my own QVTo transform I used the following target meta-models (I'm not allowed to post links, thus I changed them a little; I hope they are still clear):

modeltype UMLMM uses "http_://www.eclipse.org/uml2/3.0.0/UML";
modeltype BlocksMM uses "http_://www.eclipse.org/papyrus/0.7.0/SysML/Blocks";

and the following (simple) mapping (Component is defined in the source meta-model):

mapping Component::toBlock() : Class {
name := self.name;
}

Now, I'm able to transform components to UML Classes, but I can't stereotype them to SysML Blocks. I'm moving my first steps with QVTo and M2M transformations in general, so I'd really need to be pointed out to the right direction at this point. Any hints?

Thank you in advance,

--
Matteo
Re: Transform to SysML Blocks [message #872518 is a reply to message #872514] Wed, 16 May 2012 09:04 Go to previous messageGo to next message
Matteo M. is currently offline Matteo M.Friend
Messages: 40
Registered: May 2012
Member
Ok, I only changed "http" to "http_" and it worked. Links are perfectly readable.

--
Matteo
Re: Transform to SysML Blocks [message #873205 is a reply to message #872514] Thu, 17 May 2012 17:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Look at the various MDT/UML2 apply stereotype helper functions in the
UML meta-model. I think that these can be invoked from QVTo.

Regards

Ed Willink

On 16/05/2012 10:02, Matteo M. wrote:
> Dear all,
>
> I'm trying to transform a model from a (extremely simple) custom
> meta-model to SysML, but I'm stuck on creating SysML Blocks.
>
> By opening a simple Papyrus diagram containing a Block (the *.uml
> file), I noticed that, in its simpler form, a SysML Block is described
> by the two following entries:
>
> 1) a <packagedElement xmi:type="uml:Class"
> xmi:id="_pNiGwJnwEeG8hYBgdInPzQ" name="Block0">, inside
>
> <uml:Model xmi:id="_tSXsoJnZEeG_XYf4QGS6LA" name="SysMLmodel"> ...
> </uml:Model>
>
> 2) a <Blocks:Block xmi:id="_pQ_qcJnwEeG8hYBgdInPzQ"
> base_Class="_pNiGwJnwEeG8hYBgdInPzQ"/>, outside of <uml:Model
> xmi:id="_tSXsoJnZEeG_XYf4QGS6LA" name="SysMLmodel"> ... </uml:Model>
> and inside <xmi:XMI xmi:version="2.1" ....> ... </xmi:XMI>
>
> In defining my own QVTo transform I used the following target
> meta-models (I'm not allowed to post links, thus I changed them a
> little; I hope they are still clear):
>
> modeltype UMLMM uses "http_://www.eclipse.org/uml2/3.0.0/UML";
> modeltype BlocksMM uses
> "http_://www.eclipse.org/papyrus/0.7.0/SysML/Blocks";
>
> and the following (simple) mapping (Component is defined in the source
> meta-model):
>
> mapping Component::toBlock() : Class {
> name := self.name;
> }
>
> Now, I'm able to transform components to UML Classes, but I can't
> stereotype them to SysML Blocks. I'm moving my first steps with QVTo
> and M2M transformations in general, so I'd really need to be pointed
> out to the right direction at this point. Any hints?
>
> Thank you in advance,
>
> --
> Matteo
Re: Transform to SysML Blocks [message #874636 is a reply to message #873205] Mon, 21 May 2012 09:46 Go to previous messageGo to next message
Matteo M. is currently offline Matteo M.Friend
Messages: 40
Registered: May 2012
Member
Dear Ed,

thanks for the time you took to answer.

I'm investigating the use of applyStereotype(); as the very first step, I tried to check which stereotypes I can apply to Class(es) in my Component::toBlock() map.

In order to get this information, I modified the map as follows:

mapping Component::toBlock() : Class {
	name := self.name;
	var ster := result.getApplicableStereotypes();
	if (ster->isEmpty()) then
		log("ARGH! isEmpty....?!")
	else
		ster->forEach(st) {
			log(st.name);
		}
	endif;
}


But in fact, the ster variable always results to be empty. How can this be? Am I not allowed to apply stereotypes to UML Class(es)?

I thank you in advance for any suggestion you can give me.

Regards,

--
Matteo
Re: Transform to SysML Blocks [message #874645 is a reply to message #874636] Mon, 21 May 2012 10:01 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Sorry I don't use stereotypes and am not a QVTo author so I have no
idea. Use the Java debugger.

I can only suggest that getApplicableStereotypes probably considers only
referenced stereotypes and you haven't referenced any. Try practicising
by applying some propfiles and stereotypes from scratch in the UML editor.

Regards

Ed Willink


On 21/05/2012 10:46, Matteo M. wrote:
> Dear Ed,
>
> thanks for the time you took to answer.
>
> I'm investigating the use of applyStereotype(); as the very first
> step, I tried to check which stereotypes I can apply to Class(es) in
> my Component::toBlock() map.
>
> In order to get this information, I modified the map as follows:
>
>
> mapping Component::toBlock() : Class {
> name := self.name;
> var ster := result.getApplicableStereotypes();
> if (ster->isEmpty()) then
> log("ARGH! isEmpty....?!")
> else
> ster->forEach(st) {
> log(st.name);
> }
> endif;
> }
>
>
> But in fact, the ster variable always results to be empty. How can
> this be? Am I not allowed to apply stereotypes to UML Class(es)?
>
> I thank you in advance for any suggestion you can give me.
>
> Regards,
>
> --
> Matteo
Re: Transform to SysML Blocks [message #874747 is a reply to message #874645] Mon, 21 May 2012 13:32 Go to previous messageGo to next message
Matteo M. is currently offline Matteo M.Friend
Messages: 40
Registered: May 2012
Member
Dear Ed,

I investigated a little more and I think I made some steps forward... Without bothering you with details, I'm now facing the following problem.

I defined a mapping between the root node (Bundle) in MMA and a SysML Package:

mapping Bundle::toPackage() : Package {
    ...
}


Now I want to transform each Component in MMA to a SysML Block in the Package; thus I added the following instruction in the population section of the mapping above:

packagedElement := self.component->map toBlock();


where

mapping Component::toBlock() : Block { ... }


transforms each Component in a UML Class and then applies the SysML Block stereotype. However, the following error is raised up by Eclipse:
" The type 'sysml::blocks::Block' does not conform to the base type 'uml::PackageableElement' of the multi-valued property 'packagedElement' "

I don't know what this means: I may guess that (at the very least) an explicit casting operation is needed to resolve the type mismatch, but I have no idea on how this can be performed. I tried to google for the error message, but I didn't find anything.

Since this is only marginally related to "stereotypization", I was wondering if you can provide some hints that help me to fix this issue...

Again, thank you in advance.

--
Matteo
Re: Transform to SysML Blocks [message #874773 is a reply to message #874747] Mon, 21 May 2012 14:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Casting is done with oclAsType, but only for valid casts.

The message says that Block is not derived from PackageableElement,
which is either true, or only true because your sysml does not correctly
extend uml, and so you have multiple distinct PackageableElement classes.

Regards

Ed Willink

On 21/05/2012 14:32, Matteo M. wrote:
> Dear Ed,
>
> I investigated a little more and I think I made some steps forward...
> Without bothering you with details, I'm now facing the following problem.
>
> I defined a mapping between the root node (Bundle) in MMA and a SysML
> Package:
>
>
> mapping Bundle::toPackage() : Package {
> ...
> }
>
>
> Now I want to transform each Component in MMA to a SysML Block in the
> Package; thus I added the following instruction in the population
> section of the mapping above:
>
>
> packagedElement := self.component->map toBlock();
>
>
> where
>
>
> mapping Component::toBlock() : Block { ... }
>
>
> transforms each Component in a UML Class and then applies the SysML
> Block stereotype. However, the following error is raised up by Eclipse:
> " The type 'sysml::blocks::Block' does not conform to the base type
> 'uml::PackageableElement' of the multi-valued property
> 'packagedElement' "
>
> I don't know what this means: I may guess that (at the very least) an
> explicit casting operation is needed to resolve the type mismatch, but
> I have no idea on how this can be performed. I tried to google for the
> error message, but I didn't find anything.
>
> Since this is only marginally related to "stereotypization", I was
> wondering if you can provide some hints that help me to fix this issue...
>
> Again, thank you in advance.
>
> --
> Matteo
Re: Transform to SysML Blocks [message #881869 is a reply to message #874773] Tue, 05 June 2012 12:03 Go to previous messageGo to next message
Matteo M. is currently offline Matteo M.Friend
Messages: 40
Registered: May 2012
Member
Dear Ed, dear all,

I finally managed it to work. For those of you having similar issues, the following post has helped a lot:
www.eclipse.org/forums/index.php/mv/msg/32162/104316/#msg_104316

Essentially, it says that you cannot apply stereotypes before you applied profiles to your model. This is somewhat of obvious, but there are cases in which is not (at least for me). For example, assuming that model has SysML profiles applied (i.e. Blocks, PortAndFlows, ...), the following code does not work:

  var cls := object Class {name := "foo"};
  cls.applyStereotype(blk_st); // line 2
  model.ownedType += cls;      // line 3


This is ok, since cls has no profiles applied at all. On the other hand, it *does* work if you exchange lines 2 and 3 above, like this

  var cls := object Class {name := "foo"};
  model.ownedType += cls;      // moved up
  cls.applyStereotype(blk_st); // moved down


I was wondering why does this happen. My guess is we first have to add the class to the model so that it "inherits" the applied profiles (profiles are initially applied to model, not to cls), and only after we can apply the stereotype on cls with success. Is this right?

But even if it's right, I still have some questions. How does this "profile inheritance" work? I mean, what is the internal implementation of

model.ownedType += cls;


supposed to do. Does it deep copy the cls's properties in a new Class instance inside model or does it add a "pointer" to cls (like in C lang) to model? And in this latter case how model's profiles are applied back to cls? To put it more easily, where can I find details on the semantics of this command?

Finally, I was trying to change the direction of a SysML FlowPort. The port is correctly added to the model and stereotypes are successfully applied. I was expecting that the following code would work:

// prt is a UML::Port
cls.ownedPort += prt;
prt.applyStereotype(fwpt_st);
prt.aggregation := AggregationKind::composite;              // this works
prt.oclAsType(FlowPort).direction := FlowDirection::_'out'; // this does not work


But it does not work. More specifically, I succesfully change aggregation from "none" to "composite", but direction always remains "inout". Can you explain why? Does

prt.oclAsType(FlowPort)


operate on a temporary instance of FlowPort?

Thank you in advance for your time!

Regards,

--
Matteo
Re: Transform to SysML Blocks [message #881995 is a reply to message #881869] Tue, 05 June 2012 15:47 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Matteo

Thanks for sharing your solutions.

I don't understand much of this, so the following comments are slightly
instinctive.

Profile inheritance: it is recognised that many aspects of profiles lack
clarity in the specification, so you may be going beyond the safe
operating region. There is an ongoing initiative at the OMG called MEF
(Metamodel Extension Facility) to do a bit better.

"inout". My own experiences of trying to understand the QVT
specification on QVTo invocation context are not good, and the QVTo
project does not provide clarifying documentation. So you are into an
area where empirical discovery may be necessary. I hope to see progress
on the OMG specification and Eclipse tooling in the next couple of years.

Regards

Ed Willink

On 05/06/2012 13:03, Matteo M. wrote:
> Dear Ed, dear all,
>
> I finally managed it to work. For those of you having similar issues,
> the following post has helped a lot:
> www.eclipse.org/forums/index.php/mv/msg/32162/104316/#msg_104316
>
> Essentially, it says that you cannot apply stereotypes before you
> applied profiles to your model. This is somewhat of obvious, but there
> are cases in which is not (at least for me). For example, assuming
> that model has SysML profiles applied (i.e. Blocks, PortAndFlows,
> ...), the following code does not work:
>
>
> var cls := object Class {name := "foo"};
> cls.applyStereotype(blk_st); // line 2
> model.ownedType += cls; // line 3
>
>
> This is ok, since cls has no profiles applied at all. On the other
> hand, it *does* work if you exchange lines 2 and 3 above, like this
>
>
> var cls := object Class {name := "foo"};
> model.ownedType += cls; // moved up
> cls.applyStereotype(blk_st); // moved down
>
>
> I was wondering why does this happen. My guess is we first have to add
> the class to the model so that it "inherits" the applied profiles
> (profiles are initially applied to model, not to cls), and only after
> we can apply the stereotype on cls with success. Is this right?
>
> But even if it's right, I still have some questions. How does this
> "profile inheritance" work? I mean, what is the internal
> implementation of
>
> model.ownedType += cls;
>
>
> supposed to do. Does it deep copy the cls's properties in a new Class
> instance inside model or does it add a "pointer" to cls (like in C
> lang) to model? And in this latter case how model's profiles are
> applied back to cls? To put it more easily, where can I find details
> on the semantics of this command?
>
> Finally, I was trying to change the direction of a SysML FlowPort. The
> port is correctly added to the model and stereotypes are successfully
> applied. I was expecting that the following code would work:
>
>
> // prt is a UML::Port
> cls.ownedPort += prt;
> prt.applyStereotype(fwpt_st);
> prt.aggregation := AggregationKind::composite; // this works
> prt.oclAsType(FlowPort).direction := FlowDirection::_'out'; // this
> does not work
>
>
> But it does not work. More specifically, I succesfully change
> aggregation from "none" to "composite", but direction always remains
> "inout". Can you explain why? Does
>
>
> prt.oclAsType(FlowPort)
>
>
> operate on a temporary instance of FlowPort?
>
> Thank you in advance for your time!
>
> Regards,
>
> --
> Matteo
Previous Topic:Transformation diagrams (QVTo) UML
Next Topic:exemple
Goto Forum:
  


Current Time: Fri Apr 19 16:07:46 GMT 2024

Powered by FUDForum. Page generated in 0.02456 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top