Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


A generic controller for Active Objects

This model library provides some facilities which allow to stimulate active objects and observe their reactions. It's based on the Moka framework and available in the Eclipse's Debug perspective. The controller UI looks as follows:


Content of the library

The library contains two classes: ActiveObjectController and ConrollerUI. ActiveObjectController is an active class which enables particular objects (instantiated during the execution of a model) to register with the controller. ControllerUI represents the UI of the controller.

In order to enable registration of objects with the controller, the library introduces signal “Register”, which has an untyped property called object. The argument corresponding to this property can be any active object that needs to be observed.

Library structure.png

Please note that the controller must be explicitly started by the application model. This can be done using the StartActiveObjectController activity, availlable in the Utils package. This activity creates an instance of the controller and starts the UI.

Model explorer behavior.png

Once an instance of ActiveObjectController is created, its classifier behavior is started. The behavior is depicted in the activity diagram below. It waits for the reception of Register signals. When a signal is received, operation Register is called on the ControllerUI, using the object received with the signal as an argument for the operation call. The effect of this call is that the argument object is added to the Objects list of the UI. User can then select an object from the UI, and stimulate it with signals.


Model example

Let us illustrate the usage of this library with a simple model example. The corresponding Papyrus model is available here Download it, define a project in your workspace, and then import the model in this project. It consists in two active classes, with classifier behavior.


In this example, there are two active classes. The active class Launcher has a property typed by the other active class (A). Its classifier behavior starts the ActiveObjectController and registers an object of type A.

As illustrated in the model explorer screenshot bellow, the behaviors associated with those classes are specified by activities.


Importing the library

First of all, to use the library you need to import it (the import is already done in the model example). To do so, right click on the root object called model, then go to Import / Import Registered Package / Select ActiveObjectControllerModelLibrary.

Import Library.png

There are a lot of libraries in this window, so you can filter by name to get it easily.


Registering active objects

To observe the reaction of an active object, you need to register it in the controller. This action is illustrated in the figure bellow which represents the classifier behavior of the Launcher. To do so, call the StartActiveObjectController activity (available in the model library under package Utils). This activity returns an instance of the controller, which can be used as the target of a SendSignalAction for signal Register. Then, use the object you want to register as an argument for the SendSignalAction.

How to register classifierBehavior.png

Controlling an object

To start the execution, define a launch configuration for the Launcher_Factory activity, as explained here [[1]]. Please note that this library works only with the PSCS - multithread execution engine. Make sure that this engine is selected in the Papyrus/Moka preferences before launching the configuration (cf. [[2]] for explanations on the selection of an execution engine).

When the execution is started, the controller view is awaken. As depicted in the figure below, the objects list shows the registered active objects. When you select one of them, the list of ports is updated (to show ports available on the selected object) as well as the list of signals it can receive.


The list of signals only displays signals for which a reception is explicitly defined (either receptions on the object, or receptions on provided interfaces of the selected port). If you don't want to restrict the list (i.e., display all the signals availble in the scope of this model), just disable the checkbox “Hide signals without explicit receptions”. If the selected signal has no attribute, just press the Send button to send the selected signal to the selected object.

Hiding signals.png

If a signal has attributes, arguments have to be specified. This can be done using the arguments table (only for primitive types). The editor will check if specified arguments are valid.


If everything is ok, the controller allows you to send the signal.


If the target object was not waiting for this signal, a message like the following one will be displayed in the console:

FUMLConsoleWarning losting signals.png

Back to the top