Automatic decoration of structural features

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.

Objecteering C++ Developer 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 (Figure 11).

Figure 11. A more detailed model of our application prototype

The "Management" association links a "Person" with 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, Objecteering C++ Developer 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 Objecteering C++ Developer automatically creates the respective declarations.

Figure 12. The model deduced by Objecteering C++ Developer

In our example, an STL-type library is chosen by default. Consequently, Objecteering C++ Developer produces the following definition of the "Person" class.

class Person

{

//...

public:

std::string FirstName;

std::string LastName;

std::string Email;

//associations

private:

std::hash_map<std::string,SimpleProject> drivenProject;

//operations

public:

Person();

Person(const Person& value);

Person& operator =(const Person& value);

~Person();

//non-modeled members

};

As another example, let's consider the "Task" class. The "Task WBS" (work breakdown structure) association links a "Task" with its sub-tasks. A task can have several sub-tasks, with each sub-task belonging to only one task, meaning that multiplicity is set to "1" and "*". A task can have another task as a sub-task only once, and the sequence of sub-tasks forms the work breakdown structure of a task, so uniqueness and ordering is set for the "subTask" association end.

Figure 13. The "Task" class and the "Task WBS" association

By analyzing those properties, Objecteering C++ Developer deduces that the "owner" association end is represented by simple pointer, and that the "subtask" association end is represented by "OrderedSet" (due to uniqueness). Ordered sets are naturally represented by set collections, so Objecteering C++ Developer automatically creates the respective decorations.

The "Resources" association links a "Task" with a "HumanResource", such as "programmer", "tester" or "architect". A task can have several resources assigned, and one kind of resource can be assigned to a task many times (for example, several programmers can be assigned to a task). Consequently, multiplicity is set to "*", and no uniqueness and no ordering is defined for the "resource" association end. No properties are set for the task, since access from types of resource to tasks is not important.

By analyzing these properties, Objecteering C++ Developer deduces that the "resource" association end is represented by "UnorderedCollection". Unordered collections are naturally represented by list collections.

Objecteering C++ Developer consequently produces the following definition of the "Task" class.

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

//non-modeled members

};