The C++ code generation is available in the extra plugins of Papyrus. Make sure to unselect "Group features by category" and install "Papyrus C++ profile, view and code generation (Incubation)". C++ code generation is also automatically installed with [Papyrus_Qompass Qompass].
The C++ code generation comes with the following elements
- A C++ specific profile and a view simplifying the edition
- The code generator itself (enriched with the C++ profile)
- A CDT editor integration, allowing you to edit the code of a class in a CDT editor
The C++ profile defines a set of stereotypes that add C++ specific information to a UML model. For instance, a parameter of an operation might be passed by value, reference or as a pointer. The latter can be specified via the stereotypes C_Cpp::Ref and C_Cpp::Ptr respectively.
In the sequence, we shortly describe all stereotypes:
|Array||Parameter or Property||Indicate array with a given multiplicity. Unlike the multiplicities in UML, the array size can be an arbitrary expression, it must not be directly an integer.|
|Const||Operation, Property or Parameter||Declare that an operation, property or parameter is constant. Refer to the C++ semantics|
|Friend||Operation or Dependency||Indicate that the operation is a C++ friend|
|Inline||Operation||Indicate that generator produces an inline method inside the header file|
|Ptr||Parameter or Property||Make attribute or parameter declaration a pointer.|
|Ref||Parameter or Property||Call call by references semantics to the parameter|
|Volatile||Operation, Parameter or Property||Indicate the storage class|
More information will be added soon.
After installation, you can import the plugin org.eclipse.papyrus.cpp.test into your workspace. Within, you can find a sample model called "TestCDTintegration". Once opened, you should see the following screen.
The CDT editor appears within a tab of Papyrus. This enables a side-by-side view of model and code. The editor can be invoked via the context menu of a class, operation or transition (within a statechart). Synchronisation is done, when the CDT editor looses focus. When model elements change, e.g. is you rename an operation, the code is regenerated and an update is done. It should not be possible to get conflicting changes, since a change in the model implies that the focus is no longer on the textual editor, i.e. changes in the texteditor should be already in the model.