The Papyrus Trace Framework allows annotating UML model elements with a trace annotation. Different kind of model elements can be annotated, such as operations or ports. These annotations are shown by means of a decoration icon. When the code of the application is generated, the trace declaration must lead to an instrumentation of the generated code for a specific trace implementation, in our case primarily LTTng.
Several model elements can be annotated with trace information. The context menu shown below (shared with the possibility to handle breakpoints) allows the user to set a trace point on a given model element. A trace point can be enabled or disabled. The sub-menu trace properties enables the user to specify two aspects. The first aspect refines which events should be traced, e.g. whether the entry, the exit or both of a state should be traced. The second aspect refines the data associated with a trace event, notably whether parameter data should be included.
In the sequel, we list these and outline the different trace options, depending on the model element.
When a class is annotated, by default its creation and destruction is traced. Please note that this implies the creation of a default constructor and default destructor, if these do not exist. In addition, a class has several features (such as operations and attributes, in addition states and transitions). These can be traced without having to place a trace-point on the feature itself. The user can choose whether he wants to trace in addition all attributes, all operations, all ports or all states. This choice is available in the tracing context menu, after the trace-point has been applied.
If a port of a component is traced, the trace instrumentation is placed on the method that handles incoming request. The trace instrumentation is thus only available for ports that provide an interface. The trace instrumentation can optionally include parameter information in the trace data.
A trace-point may be placed on an operation of a class. This means that an interceptor (on class level) will create a trace event before and/or after the operation has been called. In addition, there is the option to add the operation name and the model reference into the trace point, or ' in addition ' all of the operations parameters. If the trace event is produced before the application invocation, out parameters and return values are not part of the trace event.
If a class defines a state-machine, the states can be annotated with a trace marker. A trace event is produced, if the state is entered and/or left (configurable via the option).
A transition can be annotated. A trace event is produced, when the transition is fired.
When a trace point is added, its trace properties are initialized with a choice customizable in the preferences. The screenshot below shows this preference dialog. Please note that the preferences are copied into the properties of a specific trace-point during addition, changing the properties afterwards to not influence the properties of an existing trace-point.
The figure below shows the dedicated trace-point view. This view can be opened via the Window->Show view->Other dialog (search for Trace in the Papyrus category).
The trace-view gives an overview over trace points currently existing in a workspace. It is possible to delete all or selected tracepoints ("xx" and "x" buttons, respectively). For each trace-point, it is possible to specify the trace actions, either via the button shown in the screenshot below or via the context menu.
The trace-view also enables the serialization of trace-points, i.e. the export or import to a file. This is useful, if developers want to share a trace configuration in different Eclipse environments. The import and export file selection dialog opens by default the folder of the of the current Papyrus model (if any). The figure below shows the tool-tip of the export action in the trace view
