Login | Register
My pages Projects Community openCollabNet

Appendix D.  The C++ Module

The ArgoUML C++ Module (C++ module) provides C++ code generation functionalities and C++ notation within ArgoUML. It works the same way as the other languages' modules.

D.1.  Modeling for C++

The C++ programming language has constructs that aren't contained by default in UML. Examples are pointers, global functions and variables, references and operator overloading. To enable us to apply these constructs in our models and be capable of taking advantage of it for code generation and C++ notation in UML diagrams, the C++ module uses conventions in the use of the extension features of UML, such as tagged values, stereotypes and data types.

Since UML and C++ are object oriented, there is an obvious correspondence between the UML model elements and C++ structural constructs, e.g, the UML Class is related to the C++ class. These obvious relations will not be described here, since it is assumed that an ArgoUML user that wants to model for C++ has basic knowledge of both C++ and UML.

The C++ module comes with a UML profile for C++, which defines Stereotypes and Tagged Definitions which enable the modeling of C++ specific constructs, such as pointers and references. It also includes Data Types that model the C++ built-in types, such as unsigned long int.

To have these constructs available in our model, we need to configure the UML profile for C++ in the model explicitly via the Project Properties dialog, in the Profiles tab (see Section 10.3.14, “ Project Properties ).

Tagged values are one of the main means by which we can define code generation behavior. They have a name - the tag - and a value, and are applied to model elements. For each of the possible Tagged values, the C++ profile contains a tag definition, which is contained in a stereotype, applicable to the models elements to which we can define a tagged value's value to specify specific behaviour. So, for instance, to define that the parameter x is a reference, you apply the stereotype cppParameter to it, them you add the tagged value reference with the value true.

The tagged values in use for the C++ module have two categories:

  • free format values - any String is valid, except the empty String

  • formated values - the value must obey some restrictions, e.g., be one of true or false (abbreviated to true || false)

For Boolean tagged values, only the values "true" or " false" are applicable. If a Boolean tagged value does not exist or is invalid for one model element, a default value is assumed by the code generator. In the bellow documentation the default value is marked.

Free format tagged values are only significant if present and if the value isn't an empty String. When the value must follow some sort of format, that is explicitly stated. In this case, there is the chance that the value is invalid. If the value is invalid, no assumptions are made; the generator will trace the problem and ignore the tagged value.

D.1.1.  Class tagged values

To make the tag definitions applicable to a C++ class available we apply the cppClass stereotype to it.


true - generates a default constructor for the class.

false (default) - no default constructor is generated, unless it is explicitly modeled with the «create» stereotype.


Name of the file to include in the header.


If we desire to have multiple headers included this way, just use multiple tagged values with header_incl as the tag.

Other tagged values used for C++ modeling may also be used this way. This note won't be repeated in those cases.


Name of the file to include in the source ( .cpp file).


<source type> <type_name> - creates typedef line in the public area of the class with typedef <source type> <type name>.


Same as typedef_public, but, in protected area.


Same as typedef_public, but, in the private area.


Same as typedef_public, but, in the global area of the header.


Same as typedef_global_source, but, in the source file.


Directory - will search in the specified directory for the template files "header_template" and "cpp_template" which are placed in top of the corresponding file. The following tags in the template file are replaced by model values: |FILENAME|, |DATE|, |YEAR|, |AUTHOR|, |EMAIL|. If no such tag is specified, the templates are searched in the subdirectory of the root directory for the code generation.


name@domain.country - replaces the tag |EMAIL| of the template file.


name - replaces the tag |AUTHOR| of the template file.


You may simply use the Author property in the documentation property panel.

D.1.2.  Attribute tagged values

UML Attributes are mapped to class member variables. To make the tag definitions applicable to a C++ member variable available we apply the cppAttribute stereotype to it.


true - the type of the member variable will be a pointer to the attribute type.

For example, if you have the UML Attribute: name: std::string, with the pointer tagged value set to true, the generated member variable would be: std::string* name;

false (default) - no pointer modifier is applied.


true - the type of the member variable will be a reference to the attribute type.

false (default) - no reference modifier is applied.


header - will lead for class types to a pre-declaration in the header, and the include of the remote class header in the header of the generated class.


list || slist || vector || map || stack || stringmap - will define a multiplicity as the corresponding STL container, if the Multiplicity range of the attribute is variable (for fixed size ranges this setting is ignored).


private || protected || public - creates a simple function to set the attribute by a function (call by reference is used for class-types, else call by value); place the function in the given visibility area.


private || protected || public - as for set.

D.1.3.  Parameters

To make the tag definitions applicable to a C++ argument available we apply the cppParameter stereotype to it.

D.1.3.1.  Variable passing semantics

If a Parameter for an Operation is marked as out or inout the variable will be passed by reference (default) or pointer (needs tagged value pointer - see above), otherwise by value.

Return values in UML are simply Parameters marked as return, therefore everything here applies to them, except where explicitly noted.


Note that UML allows multiple return values. This is possible to support in C++ as out parameters, but, currently the generator doesn't supports it.

This problem is being handled in issue #3553 - handle multiple return parameters.

D.1.3.2.  Parameter tagged values


true || false (default) - same as for Attributes.



D.1.4.  Generalization

To make the tag definitions applicable to a C++ generalization available we apply the cppGeneralization stereotype to it.

D.1.4.1.  Generalization tagged values


true || false (default) - used to specify virtual inheritance.


public (default) || private || protected - use this to specify the inheritance visibility of the generalization.

D.1.5.  Realization

To make the tag definitions applicable to a C++ realization available we apply the cppRealization stereotype to it.

D.1.5.1.  Realization tagged values


public (default) || private || protected - use this to specify the inheritance visibility of the generalization.

D.1.6.  Preserved sections

With each code generation, special comments around the member function definitions will be generated like this:

  function Testclass::Testclass()
  // section -64--88-0-40-76f2e8:ec37965ae0:-7fff begin
  // section -64--88-0-40-76f2e8:ec37965ae0:-7fff end

All code you put within the "begin" and "end" lines will be preserved when you generate the code again. Please do not change anything within these lines because the sections are recognized by this comment syntax. As the curly braces are placed within the preserved area, attribute initializers are preserved on constructors.

This also works if you change Method Names after the generation.

  void newOperation(std::string test = "fddsaffa")
  // section 603522:ec4c7ff768:-7ffc begin
  // section 603522:ec4c7ff768:-7ffc end

If you delete an Operation in the model. The next time the class is generated, the lost code - i.e., the whole member function definition - will be added as comment to the end of the file.