General structure and interpretation rules

An ACT type definition consists of the <type> XML element, which has a number of attributes containing important meta-information about the type, and which contains a <declaration> element defining the type declaration.

An ACT type definition may also contain one or more <include> elements, containing information about #include directives that may be required in order to use this type in generated code.

When Modelio Cxx Designer generates code for a UML attribute, parameter or association end,  it considers the type definitions available in the current library path and matches them against the name of the UML element designated as being the type of the attribute/parameter/association end being generated, as well as other decorations (for example containers).

You can generate the type of your choice by creating a new type definitions file in a variant.

Defining a simple type

The following is an example of basic type definition, used when generating a "string" type (used for example by an attribute).

    <type name="string">
        <include path="string" />
        <declaration>std::string</declaration>
        <decoration>
            <parameter-passing>REF</parameter-passing>
            <return-passing>REF</return-passing>
        </decoration>
    </type>

With this definition, the generated type will be std::string, and its include also is generated at the beginning of the generated file.

The <decoration> XML element indicates additional Cxx decorations that will be added if the type is used in a parameter or a return parameter. Here, a reference is added.

Defining a container

The following is an example of basic type definition, used when generating a "set" container (used for example by an attribute).

    <type name="set">
         <include path="set" />
         <declaration>$containerTypeName&lt;$valueTypeName&gt;</declaration>
         <container name="std::set" unique="true" ordered="true"/>
         <decoration>
              <class-storage>PTR</class-storage>
         </decoration>
    </type>

Here, the declaration contains some macros. $containerTypeName corresponds to the container name, defined in the next line, and $valueTypeName is the basic type of the element chosen from your model. Let’s assume this is a "string" attribute.

The <decoration> XML element indicates that an additional Cxx decoration will be added to the type stored in the container.

With this definition, the generated type will be std::set<* std::string>, and its include is also generated at the beginning of the generated file.

The <container> XML element also contains two attributes, indicating whether or not the container is unique or order. There properties are used in the container mapping.

Container mapping

When choosing a container in automatic decoration mode, several properties of your UML model are used to choose the best matching container.

The container mapping part of a type definition file indicated how this corresponding container is chosen.

Container kind Has Key Ordered Unique

OrderedMap

X

X

X

UnorderedMap

X

X

OrderedMultiMap

X

X

UnorderedMultiMap

X

OrderedSet

X

X

UnorederedSet

X

OrderedCollection

X

UnorderedCollection

Here is an extract of the container mapping part of the STL type library file:

    <container-mapping>
        <OrderedMap>
            <containerref name="map" />
        </OrderedMap>
        <UnorderedMap>
            <containerref name="hash_map" />
            <containerref name="map" />
        </UnorderedMap>
        <OrderedMultiMap>
            <containerref name="multimap" />
        </OrderedMultiMap>
        <UnorderedMultiMap>
            <containerref name="hash_multimap" />
        </UnorderedMultiMap>
        <OrderedSet>
            <containerref name="set" />
        </OrderedSet>
        <UnorderedSet>
            <containerref name="hash_set" />
        </UnorderedSet>
        <OrderedCollection>
            <!-- No ordered collection defined -->
            <degradedKind>UnorderedCollection</degradedKind>
        </OrderedCollection>
        <UnorderedCollection>
            <containerref name="vector" />
        </UnorderedCollection>
    </container-mapping>

The <containerref> XML element indicates directly which container should be used.

A <degradedKind> XML element indicates that no defined container respects all the properties, but that another one will be used instead.

In the example given above, when looking for an ordered container, it will correspond to the OrderedCollection kind. No direct match is found, but the UnorderedCollection kind is then chosen, leading to the usage of a "vector" container.