Difference between revisions of "Papyrus/Oxygen Work Description/NewFeature/Papyrus4Toolsmiths"

Revision as of 08:59, 17 October 2016

3 major layers for One Papyrus

Papyrus is a modeling environment, standards based, with specific Domain specific extension with many enablers [1].

Papyrus could be split into 3 major layers:

• Papyrus is composed upon Eclipse with several features embedded plugins, i.e. Papyrus-CORE
• In order to develop Papyrus-CORE, a set of plugins have been created to assist Papyrus developers. These plugins will be grouped and released as Papyrus-DEV.
• Finally in order to allow Domain specific extension, a set of plugins have been specificly developed to speed-up Papyrus customization. These plugins belong to the Papyrus-TOOLSMITHS

In parralle of these 3 layers [Papyrus-CORE, Papyrus-DEV, Papyrus-TOOLSMITHS), Papyrus have several extensions. We introduce here the "Component" concept (Component word will be changed). In this category we have for instance SysML, Marte, Designer, RobotML, Moka. All components shared a common infrastruture for release engineering. Those elements are gather inside the Papyrus-Components plugins. These plugins are managed inside the papyrus-tools repository [3].

[1]: https://www.eclipse.org/papyrus/ [2]: https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.tools.git/tree/components

Problematic

Badly, these different plugins belonging the Papyrus-TOOLSMITH are sparsed accross the whole Papyrus repository. Even if identified, a short analysis shows also they do not have exactly the same Technology Readiness Level based on their code quality, documentation, included tests, specific editors not only based on String, extension point provided.

To produce a usefull TOOLSMITHS, work will be splitted into 3 phases:

• Phase 1: Identify the Soldier
  • list the plugins that could belong to the Papyrus-TOOLSMITHS
  • write a minimal documentation and a Standard Operating Procedure to integrate a new plugin into these TOOLSMITHS
  • create an initial product that integrate some of them
  • create a set of HIPP jobs to manage the TOOLSMITH continuous integration
• Phase 2: Manage them, from soldiers to army
  • merge, enhance the documentation
  • enhance the plugins with specific editors
• Phase 3: Develop a strategy for your army: from plugins to methodologies and sop implementation
  • Goal will to be able to propose specific methodology on top of those plugins, ensuring fast development of DSL products.
  • Full industrialization of the process

The TOOLSMITH project will require a good feedback from the developers of DSL,DSML like SysML.

Team

• Francois Le Fevre
• Florian Noyrit
• Patrick Tessier