Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MDT/Papyrus/Model-Based-Tracing-of-UML-models-in-Papyrus"

< MDT‎ | Papyrus
(Tracing support)
(Trace data visualization)
Line 32: Line 32:
 
==Trace data visualization==
 
==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.
 
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
+
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 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.

Revision as of 10:30, 29 May 2012

Model Based Tracing of UML models in Papyrus

Tracing support

Bugzilla : Bug 370815

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.

Bugzilla : Bug 370816

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.

Back to the top