| Papyrus SysMl metamodel weakness for M2M/M2T [message #857512] |
Thu, 26 April 2012 15:57 |
|
Hello,
I guess this should probably go into a fix/bug request, but I wanted to socialize it first.
I work in a project that uses SysML as base models for a model transformation chain. Previously we worked with TopCased but since they moved to Papyrus we had to move to. This, sadly, required us to revise all of our transformations because the TopCased SysML metamodel is different form the Papyrus SysML metamodel (go wonder).
After various ours of transformation modification I came to realize that the Papyrus approach to the definition of a metamodel for a UML profile is not "navigation" friendly. I have been having the most problems when trying to navigate through FlowPorts and specifically when they implement a FlowSpecification.
From a SysML perspective a FlowSpecfication has a set of FlowProperties. However in the Papyrus metamodel this is not so. In Papyrus a FlowSpecification has a base_Interface and a FlowPorperty has a base_Property. So although my reason would tell me that his should work (EOL snippets):
for(property in FlowSpecification.ownedProperty){
-- do something
}
it turns out that I actually have to do something like:
for(property in SysML!FlowSpecification.all().selectOne(fs |
fs.base_Interface = self) {
-- do something
}
The above can become more much complicated when doing actual M2M transformations and you want, for example, to know the owner FlowSpecification of a FlowProperty, or when you want to know if the FlowPort that has the FlowSpecification as type is conjugated whilst accessing the FlowProperty elements. The real nightmare begins when you want to know if a connector end is a FlowSpecification.... 8o
In Topcased the SysML concepts inherited from the UML concepts they stereotyped, for example the FlowPort would be a specialization of Port. Hence, a FlowPort inherited all the attributes from the UML Port in UML which provides a more "friendly" navigation set of relations/associations.
I guess the definition of the Papyrus SysML metamodel had a great deal of conversation and debate ate the heart of the Papyrus group, and I should also guess that it responds to the "better" solution for supporting the Papyrus project per-se (editors, java/c generation, etc.). However IMHO its design makes it harder to use Papyrus models in a M2M/M2T environment.
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
Powered by
FUDForum. Page generated in 0.03520 seconds
] 
Search
Help
Register
Login
Home
