Hi everyone,
Today I delivered a 2-hour long Papyrus training workshop to 15-20
engineers from UK industry and I thought I'd summarise some of their
questions/remarks about Papyrus (before I forget), in case any of
these can feed into future discussions/actions:
- They liked the idea of being able to simplify the UI through a
configuration model as demonstrated in [1]. One question was whether
one can switch between the simplified/full UI at runtime (i.e. to
“break-out" of the simplified UI when needed).
The full UML is always available through configuration.
- There was a question about who are the main contributors to the
development of Papyrus
Seb can had to it regarding Papyrus contributors/committers, but here is the list of main contributors to the aspects Ericsson is involved in. In terms of projects, this includes Papyrus, Papyrus-RT, EMF Compare and EGit integration. This list includes
different types of contributors: committers, product and project managers (managing the open source projects), and people defining requirements/use cases and performing testing/validation of the delivered functionality
- All4Tec: Celine Janssens, Mickael Adam
- CEA: Sebastien Gérard, Remi Schnekenburger, Florian Noyrit, Benoit Maggi, Asma Smaoui, Ansgar Radermacher, Patrick Tessier -- CEA leads the work on Papyrus
- EclipseSource: Maximilian Koegel, Philip Langer, Alexandra Buzila, Martin Fleck, Stefan Dirix -- EclipseSource leads the work on EMF Compare and its integration in Papyrus
- Ericsson: Simon Delisle, Patrik Nandorf
- Tieto: Peter Cigehn
- Zeligsoft: Simon Redding, Charles Rivet, Ernesto Posse, Young-Soo Rho — Zeligsoft lead the work on Papyrus-RT
- Independant: Christin Damus, Bran Selic
You can find the list of Committers to the different projects
- Another question was whether Papyrus supports any import interfaces
from other tools? (Developing such "import" facilities is an
unrewarding task for researchers so we may want to pool resources
here)
In the context of the Ericsson work, we have funded the development of model import for RSA (RSA to Papyrus), which is currently used to migrate from RSA to Papyrus at Ericsson, and RSA-RTE (RSA-RTE to Papyrus-RT) which is currently developed together
with Papyrus-RT (Papyrus-RT is planned to be released at the end of January/beginning of February together with C++ Code Generator and Run-Time).
CEA is also working on a Rhapsody import, which includes a sub-set of the Rhapsody diagrams. Seb can provide more info on this.
- They liked the idea of being able to split models across multiple
projects/files as many of them are struggling with large monolithic
models stored in proprietary tool-specific repositories
This was one of the key priorities for Ericsson from the very beginning in all our development contexts and we worked closely with CEA (who did the development work) to implement the required support. This aspect is extensively used in the project (over
120 users) where are using Papyrus as a replacement for RSA.
- They also liked the idea of being able to use Git to version control
models - especially after I demonstrated EMFCompare. They didn't seem
to be too bothered that there's no built-in support for "live"
collaboration (I was prepared to talk to them about the Papyrus-CDO
integration but I saw little demand for a model repository)
This was another key Ericsson priority from the very beginning as Git is now the main technology used in Ericsson. EclipseSource and Obeo have led the development of this part.
- There was a question about if/how Papyrus can interface to Simulink
(I had to take this one offline as I have no idea)
I am not aware of any real implementation for the integration of MathWorks Simulink and Papyrus, but I know that Zeligsoft has worked on this type of integrations in the past. Here are links to two videos (one with MathWorks Simulink and one with Agilent
SystemVue) that were developed in the context of Software Defined Radio (SDR) projects. The integration was done with Zeligsoft CX, which is a component-based modeling DSL built on top of IBM RSA. Similar integrations could be developed for Papyrus/Papyrus-RT.
There is in fact quite much interest on this specific topic in the context of Automotive, Mechatronic, and CPS. We can potentially look at developing such an integration if industrial members/partners are interested in financially committing to it. You can
contact Simon Redding (Zeligsoft) if you want additional details.
- One of the attendees asked if/how UML model elements in Papyrus can
be linked to elements from domain-specific (EMF) models (also had to
take this offline)
I will let more other people comment on this one to provide appropriate level of details.
- There was a question about model execution capabilities to which I
responded by pointing the person that asked towards Moka
Mona is the only project that I am aware of.
- All in all, there was overwhelming support for continuing to
evaluate Papyrus and we’ll run a second Q&A workshop after Christmas
That is a great news. It implies that you did a good job!
Thanks,
Dimitris
[1]
https://wiki.eclipse.org/Papyrus_for_Information_Modeling/Customization_Guide
--
Dr Dimitris Kolovos
Senior Lecturer in Enterprise Systems
Director of the Large-Scale Complex IT Systems Engineering Doctorate
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
_______________________________________________
papyrus-ic mailing list
papyrus-ic@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-ic