[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [polarsys-iwg] UML Generators Proposal Question
|
Hi
I would like to know if it is possible to add Atos as interested parties ?
-----Message d'origine-----
De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx] De la part de etienne.juliot@xxxxxxx
Envoyé : mardi 28 janvier 2014 10:37
À : polarsys-iwg@xxxxxxxxxxx
Objet : Re: [polarsys-iwg] UML Generators Proposal Question
>
> Originally I wanted just to ask about Xtext/Xpand for code generation
> and maybe the reverse engineering code.
There isn't any XText implementation for Java and C.
So, we plan to use directly CDT and JDT.
> 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.
>
I understand. But, we can manage very large models with EMF itself. I don't see the add-in value of Sphinx if EMF is well used.
For exemple, EMF Compare success to manage 1,5GB of models, and it scales very well.
>>
>>> * 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.
You are right.
And that why I prefer to keep a consistency of the technology used to execute code generators of UML Generators.
And, as initial contributions are all created with Acceleo, as it uses a standard syntax, as this syntax is easy to understand for somebody who already know OCL (which is the case of UML users), as 100% of initial commiters know Acceleo and 0% know Xpand, it is really better to stay on Acceleo.
Your proposition to use XPand going in the wrong way: it would complexified the architecture by adding a new dependance and a new syntax.
For Artop, Eclipse community can't help you as this isn't an OpenSource project, and it isn't in Eclipse Foundation. We can't be responsible of external projects's choices.
>
>
> 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.
That's exactly why I prefer to not add non-required dependencies, and
keep the architecture as simple as possible.
>>> 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.
OK, I understand. It already worked with EAST-ADL, but it was a pure
Ecore metamodels.
If you are engage in this project, perhaps it can make sense to propose
them to be consistant with UML Generators by just proposed extension to
the generic templates.
>>> * 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)
If you want to have an easy-to-use and easy-to-customize tool for
Autosar, just try Sirius : http://www.eclipse.org/sirius
With this Eclispse project, you can rely directly on the XML files of
Artop. And when some concepts are missing (like port, interfaces, like
with others models, ...), you can by yourself add them without the need
to create java code.
We did several years ago a prototype for Artop, and it worked very well
: http://marketplace.obeonetwork.com/module/autosar
>
> Regards, kessel
> _______________________________________________
> polarsys-iwg mailing list
> polarsys-iwg@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
>
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
