The “Automatic Decoration” tickbox in the “C++” property view for a parameter
By default, Modelio C++ Designer automatically deduces C++ decorations for parameters, attributes and association ends. However, in certain cases, deduced decorations may not correspond to what you actually intended. For example, you may want to override an externally defined virtual function, whose prototype does not correspond to that deduced by Modelio C++ Designer.
Modelio C++ Designer lets you mark the model elements to be avoided by the automatic deduction procedure. For this, the “C++” property view contains the “Automatic Decoration” tickbox.
The “Automatic Decoration” tickbox in the “C++” property view for a parameter
By default, the automatic decoration flag is always on.
By switching off the flag, you indicate that the selected element should not be taken into account in the automatic deduction process. In this case, Modelio C++ Designer only takes in account your decorations, and does not extrapolate new ones. To help you, deduced decorations are saved into the model, so that you can use them as a basis.
By switching on the flag, you indicate that the selected element is to be taken into account during the automatic deduction process. In this case, any decorations you have previously created are removed, and Modelio C++ Designer deduces new decorations at generation according to the rules defined.
Note: The automatic decoration strategy is also called automatic guessing.
See the corresponding section in the advanced part of this guide for more information.
Note 2: Editing C++ properties in the corresponding edition box sets the automatic decoration to off.
Structural features are attributes and associations between UML classes. Many existing C++ generators translate these as C pointers. However, C pointers are a poor choice to represent the semantics of relationships between model elements. Consequently, you have to implement this at code level and the model then diverges from code, or else you are distracted by low-level details, such as collection types for multiple attributes, storage by pointer or by value, and so on.
Modelio C++ Designer lets you focus on the high-level properties of application entity relationships and attributes. It automatically deduces C++ decorations, which specify collection and storage type, by analyzing the high- level properties of structural features (multiplicity, uniqueness, ordering, and qualifying attributes). These properties are often used to represent semantics on UML models.
We are now going to continue by creating a more detailed model of our
application prototype.
A more detailed model of our application prototype
The “Management” association links a “Person” to a “SimpleProject”. One manager can drive several projects, and there is only one manager for each project, so multiplicity is set to “1” and “*”. A manager can drive a project only once, and THE order of projects is not important, and we therefore specify uniqueness and no ordering for the “drivenProject” association end. For rapid access to a driven project, we qualify projects by project names, which are used as project keys.
By analyzing these properties, Modelio C++ Designer deduces that the “manager” association end is represented by simple pointer, and that the “drivenProject” association end is represented by “UnorderedMap”. Unordered maps are naturally represented by hash map collections, so Modelio C++ Designer automatically creates the respective declarations.
The model deduced by Modelio C++ Designer
In our example, an STL-type library is chosen by default. Consequently, Modelio C++ Designer produces the following definition of the “Person” class.
1 class Person
2 {
3 //...
4 public:
5 std::string FirstName;
6 std::string LastName;
7 std::string Email;
8 //associations
9
10 private:
11 std::hash_map<std::string,SimpleProject> drivenProject;
12
13 //operations
14
15 public:
16 Person();
17 Person(const Person& value);
18 Person& operator =(const Person& value);
19 ~Person();
20
21 //non-modeled members
22 };
Since C++ does not provide automatic memory management capabilities, you as a C++ user have to pay particular attention to the method you use to pass operation parameters, in order to avoid producing inefficient or incorrect code. For example, if a class parameter is passed by value, a copy constructor will be called, and the operation code will modify the copy, not the object itself, and so on.
Modelio C++ Designer lets you focus on high-level UML model properties without being distracted by low-level details, such as passing operation parameters by reference or by value or const qualifiers for “in” parameters.
Modelio C++ Designer analyzes a parameter’s type and sets the “by reference” passing modes for class or datatype parameters, as well as for parameters of non-primitive types defined in type libraries. In C++, this mode is implemented by adding a reference specifier to the parameter type. Modelio C++ Designer adds const specifiers to “in” parameters in order to explicitly express the fact that these parameters cannot be changed by the operation body, and const specifiers to “in” operations in order to explicitly express the fact that these operations do not change object state.
Consider our application prototype model. Continue by creating the “addSubTask” operation in the “Task” class operation, which takes a subtask to add and its number in the task work breakdown structure.
Before generation, Modelio C++ Designer automatically creates C++ decorations for its parameters. It adds a reference specifier to the type of the “SubTask” parameter, since this type is a class. It does not add a const specifier to this parameter, because it has “inout” semantics and can therefore be changed by the operation. It does not create a const specifier for the “wbsNum” parameter, because it is of primitive type. The integer type is translated to the C++ int type, which is passed by value, so there is no point in qualifying the “wbsNum” parameter as a const.
The “SubTask” parameter on the “addSubTask” operation
Modelio C++ Designer produces the following declaration of the “addSubTask” operation.
1 class Task
2 {
3 //...
4 public:
5 std::string name;
6 std::string wbsCode;
7
8 //associations
9
10 protected:
11 SimpleProject* project;
12 std::set<Task> subTask;
13 Task* owner;
14 std::list<HumanResource> resource;
15
16 //operations
17
18 public:
19 Task();
20 Task(const Task& value);
21 Task& operator =(const Task& value);
22 ~Task();
23 bool addSubTask(int wbsNum, Task& SubTask);
24
25 //non-modeled members
26
27 };