Model level accessors

The methods used to access the attributes of application classes constitute an important part of model semantics. However, these accessors are traditionally produced only at code level, with the result that the model differs from the code.

Objecteering C++ Developer is the first solution to support the automatic creation of model-level accessors for structural features.

To create accessor operations for an attribute or association end, simply select the element in question and run the "Create accessors" command from the Objecteering C++ Developer context menu.

Figure 17. Creating accessors

Objecteering C++ Developer implements accessors through design patterns. The current accessor pattern creates the "get" accessor operation if the feature has a "read" access flag (which corresponds to get access), and the "set" accessor operation if the feature has a "write" access flag (which corresponds to set access).

For a single cardinality primitive-type attribute, the get operation returns the attribute and the set operation sets its value. For an association end with single cardinality or a complex-type attribute, the get operation returns the reference to the target class and the set operation sets the feature value from a given const reference. For implemented collections with multiple cardinality features, get and set accessors are implemented by a single operation that returns the reference to the collection instance, which is a const if the "write" (set) access mode is not specified.

For example, let's run the "Create accessors" command on the "subtask" association end in the "Task" class, which has "*" multiplicity and read-only access semantics expressed by only the "read" (get) access mode. Objecteering C++ Developer will then create the UML operation "getSubTask" in the "Task" class (Figure 18).

Figure 18. The result of running the "Create accessors" command on the "subtask" association end in the "Task" class

Objecteering C++ Developer copies the C++ decorations (that were automatically deduced for the "subtask" association end from its uniqueness and ordering properties) to the return type of the created accessor, additionally decorating it with the const specifier to represent read-only semantics. Objecteering C++ Developer also creates the C++ code note, which implements default accessor implementation.

Figure 19. Copied C++ decorations

Objecteering C++ Developer produces the following code for the "Task" class, which implements get access to the "subTask" member.

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

const std::set<Task>& getSubTask() const;

//non-modeled members

};

const std::set<Task>& Task::getSubTask() const

{

//modifiable zone @12953@30671900:493@T

return subTask;

//modifiable zone @12953@30671900:493@E

}

Note: Users can create their own model-level accessor patterns with the help of Objecteering C++ Developer platform development capabilities, by editing open ACT pattern libraries.

Model-level accessor patterns are dynamic, meaning that when an attribute is updated, its accessors are automatically updated too.

If you rename an element, its accessors are automatically renamed. For example, let's rename the "subTask" association end "subTasks" (with an extra "s" on the end). The name of its accessor is changed accordingly to "getSubTasks" (Figure 20).

Figure 20. Accessor names have been automatically updated following changes to the names of their parent elements

If you change an element's access mode, the respective accessors are automatically created or deleted, and the const specifiers of collection accessors are automatically created or removed. For example, let's change the read-only semantics of the "subTasks" association end to read-write access by adding the set access mode. The const specifier of its accessor is automatically removed.

Figure 21. Accessors have been automatically updated following changes made to an element's access mode

If the C++ decorations of an element are updated, either as a result of automatic deduction from updated high-level properties or as a result of user changes, the decorations of accessor parameters are automatically updated. For example, let's reset the uniqueness property of the "subTask" association end. This element is automatically re-decorated: ordering and non-uniqueness induce the "OrderedCollection", which is represented by the vector collection type. The return parameter of the get accessor is updated accordingly (Figure 22).

Figure 22. Accessors decorations have been automatically updated following changes made to the C++ decorations of an element

Generation of accessors directly at UML model level and their automatic synchronization with accessed elements is used to conveniently express access semantics at a high level, thereby creating a closer link between the application model and the code, starting from the prototyping stage.

In addition to creating accessors for particular elements, Objecteering C++ Developer lets you create accessors for all the members of a chosen class. For this, you simply select a class and run the "Create accessors" command from the Objecteering C++ Developer context menu (Figure 23).

Figure 23. Creating accessors for all the members of a selected class

As a result, Objecteering C++ Developer creates accessors to all the attributes and association ends that are defined in the class and that have at least get access mode (Figure 24).

Figure 24. Accessors have been created for all the attributes and associations belonging to the selected class