Login | Register
My pages Projects Community openCollabNet
Appendix D. The C++ Module
Prev   Next

Appendix D. The C++ Module

Table of Contents

D.1. Modeling for C++
D.1.1. Class tagged values
D.1.2. Attribute tagged values
D.1.3. Parameters
D.1.4. Preserved sections

The ArgoUML C++ Module (C++ Mod.) 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, tagged values and stereotypes.

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.

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.

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

constructor

true - generates a default constructor for the class.

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

header_incl

Name of the file to include in the header.

[Note]Note

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.

source_incl

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

typedef_public

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

typedef_protected

Same as typedef_public, but, in protected area.

typedef_private

Same as typedef_public, but, in the private area.

typedef_global_header

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

typedef_global_source

Same as typedef_global_source, but, in the source file.

TemplatePath

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.

email

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

author

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

[Note]Note

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.

pointer

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.

reference

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

false (default) - no reference modifier is applied.

usage

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.

MultiplicityType

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).

set

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.

get

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

D.1.3. Parameters

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.

[Warning]Warning

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

pointer

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

reference

ditto

D.1.4. 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.

Prev   Next
C.2. Commercial Tools (To be written) Home Appendix E. Limits and Shortcomings