Skip to main content
Jump to: navigation, search

Papyrus/Codegen/Cpp description

The C++ code generation is available in the extra plugins of Papyrus. Once Papyrus is installed, the C++ code generation can be installed via the menu entry "Help->Install Papyrus additional components". Pick "C++ code generation" from the list. Alternatively, you install the code generation manually: Go to "Help->Install New Software". Choose the Papyrus update site and make sure to unselect "Group features by category", then search for C++ code generation. C++ code generation is also automatically installed, if you install 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

C++ profile

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 in alphabetical order:

Stereotype Metaclass extension Description
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
External Classifier Indicate that no code should be generated for this classifier. Other classifiers will import this classifier with the include path specified in the "definition" attribute
ExternLibrary Package Mark a package as External Library. If an element of this package is used, the associated CDT project will be configured accordingly (include and library paths)
Friend Operation or Dependency Indicate that the operation is a C++ friend
Include Class, Package or PackageImport An arbitrary string that is added to header and body file. Although primarily intended for manual #include directives, it can be used for arbitrary definitions. The contents of the attribute "preBody" is added to a C++ body file before automatic #include statements, "body" after these.
Inline Operation Indicate that generator produces an inline method inside the header file
NoCodeGen Element Do not generate code for this element
Ptr Parameter or Property Make attribute or parameter declaration a pointer.
Ref Parameter or Property Call call by references semantics to the parameter
Template Class Indicate that the class is a C++ template
Union DataType Generate a union instead of a struct for this data type
Virtual Operation Make operation virtual
Volatile Operation, Parameter or Property Indicate the storage class

Code generator

The C++ code generator focuses on structural elements. It will generate code for classes, datatypes (C++ structs or unions) and primitive types along with their relationships such as inheritance and associations.

The behavior of operations must be supplied in form of an opaque behavior, i.e. a text block that is stored inside the model. The generator will produce a header and body file. Required #include directives are largely handled automatically, for instance if a certain type appears in the signature of one of your operations, the required #include will be added. For types that are only appearing within the opaque behavior, the user has to add an explicit dependency. An associated #include directive will be added to the body file. If additional definitions, e.g. #defines are required, it is possible to do that via the stereotype "Include" (see above).

The code generator places the created files in a folder hierarchy that corresponds to the package hierarchy in the model. By default, the files are generated into a CDT project with the name org.eclipse.papyrus.cppgen.<name of your model>. The prefix can be configured in the preferences. Note: enumerations and primitive type definitions are currently not placed into a separate file, but added to the file generated for the (nearest) package of these types. So don't be surprised, if you do not find a file that has the name of your enumeration or primitive type. This might change in the future.

There is a support for external libraries that might include system libraries or legacy code. These libraries can be represented in your model by means of a stereotyped package. The stereotype "ExternalLibrary" provides information about include directories and library paths that are used to configure the generated CDT project - if there is an explicit or automatic dependency to the external library. For instance, the user can place a class called "pthread" into the external library package of the same name. No code is generated for this class. If the application classes reference a pthread class into their signature, the external library is taken into account.

Statemachine support

A design objective of the code generator is to keep it quite simple and focus on the structural parts. Advanced support for component based modeling (ports and connectors) is done in Qompass designer. Qompass designer executes a model to model transformation for component based models. In the context of Qompass designer, there is also a support for (simple) state-machines.

CDT integration

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.

Back to the top