MDT/Papyrus/Juno Work Description

This page lists the main current tasks in the Papyrus development, with links to the associated Bugzilla tasks.

Profile Management and lifecycle

This work is developed by CEA LIST and sponsored by Ericsson in the context of Polarsys [1]
Planed release date : 2012

Modeling OCL constraints

Bugzilla : 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 : 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 : 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 : 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 : 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 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 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 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 CEA LIST and sponsored by Ericsson in the context of Plarsys [2]
Planed release date : Unknown
Bugzilla : 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 CEA LIST and sponsored by Ericsson in the context of Polarsys [3]
Planed release date : Eclipse Juno (June 2012)
Bugzilla : 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. :

Class { /* All GMF views representing a Class */
   bold:true; /* This is a GMF property */
}
 
ClassDiagram Class { /* All classes in a ClassDiagram */
   bold:false;
}

The selectors should also be able to test semantic properties:

Class[isAbstract=true] {
   italic:true;
}

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.

Class[hasStereotype("SysML::Blocks::Block")] {
   fillColor:#C3D1D5;
   gradient:white vertical;
}

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 CEA LIST and sponsored by Ericsson in the context of Polarsys [4]
Planed release date : 2012
Bugzilla : 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