[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [polarsys-iwg] UML Generators Proposal Question
|
Am 27.01.2014 18:36, schrieb etienne.juliot@xxxxxxx:
Hi,
I just wanted to ask, if you actually plan for:
* the UML Generators to also look into Xtext/Xpand/Xtend?
The existing generators which are parts of the initial contribution
are based on Acceleo.
So, it doesn't make sense to translate these existing template (based
on MTL, an OMG specification) to another technology.
* Sphinx. http://www.eclipse.org/sphinx/
used in ARTOP and EATOP already
Model repository and database persistance support based on CDO
and MFT, which should help to scale for very big models
I don't see how Sphinx can help us to manage big models for code
generation.
As I just wrote to Sebastians answer, originally I wanted to ask just
for the Xtext/Xpand as code generators. Then I was thinking about that
other projects.
Regarding Sphinx and CDO as backend, it is a planning for Artop/EATOP
afaik, and AUTOSAR models can really grow.
Then I thought, that UML Models could also grow and it was rather a
question for performance reason if Papyrus wouldn't benefit from this too.
The thing is, that I read somewhere that Sphinx will use CDO only at
runtime, loading the XML files into it, and saving it back to it,
instead of only reading/writing to XML files.
UML Generators will just use EMF models. If these models are stored
with a specific backend, it will be transparent of the generator. So,
you will be allow to use CDO for free. But we don't need for our
project to create a specific dependency to CDO.
So, if Sphinx consumes EMF models, integration should be transparent.
If you do the test, I will be interest by the result.
* ReqIF/ProR - http://www.eclipse.org/rmf/
What is your question?
I know ReqIF, but I don't know what do you want.
* Regarding "Scripting" EASE - http://wiki.eclipse.org/E4/Scripting
What is your question?
Well, that was also just one of the additonal questions popping up after
the one about Xtext/Xpand for code generators.
It was rather again about another contribution to Eclipse, or
using/contributing to already existing Eclipse projects.
How many different Eclipse Plugins does one have to install and learn to
work with to see them die after 1 or 2 years, learning then a new
Eclipse contribution?
We have some AUTOSAR configuration and generation tools based on
Eclipse+Artop, some use JET to get some code out,
others use Java Plugins for generation, here comes Acceleo, then some
use Xtext/Xpand.
My job is not to develop model transformers, I'm an embedded SW
developer. Java, JET, Acceleo, Xtext/Xpand are not really what I need to
get my ECU running.
They are just tools that should help me, not keeping me from working.
I currently have here an Eclipse installation, which idles with some
open editors at 800MB RAM usage.
At work I have additonal tools, that each want between 300 .. 700MB RAM,
one tool (CANoe also requires after 2..3 hours simulation time at 2..4
GB RAM.
The reason I ask (at least for Xtext/Xpand and Sphinx)?
* Several other projects like EATOP and ARTOP are going there
EATOP and ARTOP doesn't rely on UML. So, I don't really understand
your need to integrate them with UML Generators.
Well, EATOP is about EAST-ADL, and there is an UML Profile for it in
Papyrus.
* AFAIK, Papyrus is already using it for their editors.
* I wonder, if Xtext DSLs can be written for each language and maybe
also easier extended, e.g. different compiler addons for embedded
compilers.
I just wanted to remind you for reverse engineering to the
different dialects/extension regarding
void _interrupt MyISR(void) vs. interrupt void MyISR() vs.
void MyIsr(void) _interrupt
int @far / @near myVar;
int myVar = 0 _at(0x0100);
_inline vs. _inline_ vs. inline
AUTOSAR like Compiler/Memory Abstractions
Thanks to template overriding feature of Acceleo, it's very easy to
manage these different generation strategies with a simple property.
Creating an XText DSL just for this is an heavy solution for a simple
problem. And I prefer to use simple solution until possible.
http://wiki.eclipse.org/Acceleo/Views_Perspective#Overrides_View
Ok, I'll take a look on it. Even though, I currently don't know, where
to start to choose from Generation Tools.
But perhaps you have some complex use cases and this approach can make
sense. I propose to wait to use the future official newsgroup for
technical discussion.
* And last but not least, maybe there is one times a less spread
amount of projects doing the same over and over.
A lot of subprojects exist now on Eclipse-Foundation, and several
have gone with the wind, but other pop up again.
I'm personally overwhelmed by all the different kinds of
subprojects and solutions.
I agree.
And that exactly why we are launching this project.
Any contribution is welcomed!
If you want to be list as an interested party, you can ask (I just
need to know if it's personal, of professional (in this case, I need
the name of your company)).
Well, at the moment, I personally just try to follow/track/evaluate the
current projects and development about UML and SysML, Code Generators
and their
applicability to the Automotive Field I'm working in. We are currently
using Rhapsody at work, which is a bit tedious to use in a C environment.
Also, sometimes I miss a tool/feature to express my ideas, like Rhasody
missing the timing diagram, or when using just UML, the missing
difference between
Ports and Flow Ports of SysML, e.g. when specifing Client-Server
Interfaces vs. Sender-Receiver Interfaces.
The AUTOSAR tools we currently use are, well, somehow hard to use. I'm
not a fan of editing an AUTOSAR configuration or define SW-Component
Interfaces
just in tree-based editors.
So, in my current projects we have about 5..8 different tools to change
between and exchange data between.
And given the different projects and versions, comparing different
versions of the file types is getting harder and harder.
Like merging Rhapsody versions with their DiffMerge tool, or AUTOSAR xml
files on XML level, this isn't much fun.
Maybe this also explains my questions about the different Eclipse
Plugins above. :o)
Regards, kessel