View source for MDT/Papyrus/Juno Work Description

This page lists the main current tasks in the Papyrus development, with links to the associated [http://bugs.eclipse.org/bugs Bugzilla tasks].

= Profile Management and lifecycle =

This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Polarsys [http://wiki.eclipse.org/Polarsys]<br> Planed release date&nbsp;: 2012<br> 

== Modeling OCL constraints ==

Bugzilla&nbsp;: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370815 Bug 370815] 

It should be possible to model OCL constraints for a profile, with a specific OCL editor. It should be possible to generate an EMF Validation plug-in from these constraints. The constraints should be validated either in real-time or in batch-mode, according to a user preference. It should be possible to define this preference either globally or constraint by constraint. 

Concretely, this will be realized in three steps: 

*Embedding the OCL X-Text editor in the property view, and associating it to UML Opaque expressions using the OCL language 
*Creating a generator, which inputs a Profile and outputs an EMF Validation plug-in 
*If necessary, adapt the Papyrus validation framework

== Profile evolution ==

Bugzilla&nbsp;: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370816 Bug 370816] 

Profiles defined in the workspace typically evolve quickly. They should be automatically re-applied when the users open a diagram for the first time after the profile has evolved. The user should be asked whether the modification is ok or not. 

== Model/Profile packaging ==

Bugzilla&nbsp;: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370817 Bug 370817] 

When packaging a Model on which a local profile is applied, the Profile should also be packaged, either in the same plug-in or in another plug-in. 

== Import by copy ==

Bugzilla&nbsp;: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370818 Bug 370818] 

Currently, the only import option available in Papyrus is an external reference to another model. It should also possible to import an external model (Or subset of a model) by copying it.

=Model Based Tracing of UML models in Papyrus=

==Tracing support==
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=380921 Bug 380921]

The model-based tracing framework shall allow adding, deleting and displaying static tracepoints on UML model elements.

Tracepoints will be used by the generator/compiler to instrument the generated code with tracing information containing the model element on which the tracepoint has been set.

Tracepoints shall be allowed on the following diagrams:
*Class diagram: class (may mean that tracepoints should be added to all owned properties and operations), Open: select each property/operation individually or whole class? Open: howto trace access to properties given that code within an opaque behavior can access the property natively.
*Composite structure diagram: class (may mean that tracepoints will be added to all properties and ports)
*State machine diagram: statemachine(may mean that tracepoints will be added/deleted to/from all states and transitions of the statemachine), states (for composite states tracepoints will be added to substates and contained transitions), transitions, entry, exit and doActivities.
*Activity diagram: activity (may mean that tracepoints will be added to all owned actions and control flows), actions, control flows.
*Sequence diagram: lifeline, Message.

For the ergonomics concerns, we may be inspired the [http://wiki.eclipse.org/CDT/designs/Tracepoints tracepoint] feature of the CDT framework.

===Tracepoint view===

The model-based tracing framework shall provide a tabular view displaying specified tracepoints for a model. All traced elements, with their UML type and name, should appear in this view.
Within this view, it should be possible to enable/disable or remove a tracepoint or a set of tracepoints.
Within this view, it will be possible to navigate between the tracepoints and the traced model elements.


==Instrumentation of code generation==
C++ code generation instrumentation for tracing: We will upgrade the CEA LIST C++ code generator in order to be able to instrument the generated C++ code according to [http://wiki.eclipse.org/Linux_Tools_Project/LTTng LTTNG] specification. An alternative implementation strategy for instrumentation might be a model transformation (container).
For the demonstrator we will use LTTNG under linux.

==Trace data visualization==
Each tracepoint has an associated data depending of its context which is defined according to the nature of the model element on which the tracepoint is specified.
At this stage, we will reuse as much as possible the tools provided by [http://wiki.eclipse.org/Linux_Tools_Project/LTTng#Tracing_and_Monitoring_Framework_.28TMF.29 TMF]

* Trace data view: A trace data view shall be added for each diagram on which tracepoints are allowed to be specified. The data view is linked with the tracepoint view. When a tracepoint is selected in the tracepoint view, the trace data view corresponding to the selected tracepoint is displayed.

* Trace data visualization for class diagram: For class properties, the trace data corresponds to their current value. This value shall be displayed in the trace data view along with the property name and type. For a class operation, the trace data corresponds to the value of its parameters.

* Trace data visualization for composite structure diagram: For properties, the trace data corresponds to their current value. This value shall be displayed in the trace data view along with the property name and type. For ports, the trace data corresponds to the value, instance or operation called (with its parameters values).

* Trace data visualization for state machine diagram: For states, the trace data may be a boolean value or an enumeration literal indicating if the state is entered or leaved. For transitions, the trace data may be…

* Trace data visualization for activity diagram: For actions, the trace data depends on the type of action; More generally the trace data may include values of it input pins (for an action entry tracepoint) and the value of its output pin (for an action exit tracepoint).

==User documentation==
The documentation shall describe the usage of the UML tracing framework in Papyrus. It shall cover the specification of tracepoints on supported diagrams and also cover the visualization of traces in the model.

=Flexible Drag & Drop framework=

This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Plarsys [http://wiki.eclipse.org/Polarsys]<br />
Planed release date : Unknown<br/>
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370819 Bug 370819]

Papyrus should provide a customizable Drag & Drop (D&D) framework, unifying the different kinds of D&D:

* Drag & Drop between views
* Drag & Drop between a view and a Diagram
* Drag & Drop between a Diagram and a View
* Drag & Drop inside a Diagram

This will require a global reflection on the different mechanisms involved, especially for the Diagram to Diagram D&D, which are currently handled by GMF generated code.

Basically, the tool should propose a few D&D policies, and the user or tool provider should be able to choose one.

Like other Papyrus customization tools, it should be possible to customize the D&D locally, in the workspace (user customization), or to deploy the customization in a plug-in (Tool provider)

=Themes and preferences=

This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Polarsys [http://wiki.eclipse.org/Polarsys]<br />
Planed release date : Eclipse Juno (June 2012)<br/>
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370797 Bug 370797]

==CSS Support==

Papyrus should provide a CSS Engine for its diagrams. The stylesheets should be defined at three levels:

* Workspace stylesheets: Applied on every elements
* Model stylesheets: Applied on each element of the Model
* Diagram Stylesheets: Applied on each element of the Diagram

The CSS Engine should handle three kinds of properties:

* GMF "Style" properties
* Papyrus style properties (From Annotated Notation model)
* User defined properties

Regarding the CSS Selectors, they should be based on the Semantic model, plus the diagram type, i.e. :

<source lang="css">
Class { /* All GMF views representing a Class */
   bold:true; /* This is a GMF property */
}

ClassDiagram Class { /* All classes in a ClassDiagram */
   bold:false;
}
</source>

The selectors should also be able to test semantic properties:

<source lang="css">
Class[isAbstract=true] {
   italic:true;
}
</source>

The CSS Engine should be generic enough to handle any kind of Semantic Model (i.e. it should not depend on UML).

It should be possible to define local Style, CSS Classes and CSS ID on specific GMF Elements.

==Extended CSS Support==

Papyrus should provide an Extended CSS Syntax, allowing the user to define its own CSS Selectors through custom queries (OCL, EMF Facet, Java...)

This extended CSS syntax is not compatible with the standard CSS parsers. Thus, we will need to define a custom parser for CSSX files. The CSSX parser should be able to handle standard CSS files, as well as custom queries.

<source lang="css">
Class[hasStereotype("SysML::Blocks::Block")] {
   fillColor:#C3D1D5;
   gradient:white vertical;
}
</source>

==Editor & Preferences==

The user should be able to edit the CSS/CSSX files either textually or graphically. The graphical editor should look like the current Papyrus preferences page, which it will replace.

=Documentation=

This work is developed by [http://www-list.cea.fr CEA LIST] and sponsored by [http://www.ericsson.com Ericsson] in the context of Polarsys [http://wiki.eclipse.org/Polarsys]<br />
Planed release date : 2012<br/>
Bugzilla : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=370820 Bug 370820]

The documentation for the end-user should be improved and updated. The following points will be improved in priority:

* How to create a Model and edit Model properties
* Model management (Model split using fragments, profile application lifecycle)
* Model validation
* Profile definition