Automatic decoration of operation parameters

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.

Objecteering C++ Developer 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.

Objecteering C++ Developer 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. Objecteering C++ Developer 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.

Figure 14. The new "addSubTask" operation you have just created

Before generation, Objecteering C++ Developer 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.

Figure 15. The "SubTask" parameter on the "addSubTask" operation

Objecteering C++ Developer produces the following declaration of the "addSubTask" operation.

class Task

{

//...

public:

std::string name;

std::string wbsCode;

//associations

protected:

SimpleProject* project;

std::set<Task> subTask;

Task* owner;

std::list<HumanResource> resource;

//operations

public:

Task();

Task(const Task& value);

Task& operator =(const Task& value);

~Task();

bool addSubTask(int wbsNum, Task& SubTask);

//non-modeled members

};