Round trip mode

Principles of round trip engineering

Round trip engineering is a functioning mode that combines code generation and reverse engineering. Code is generated in exactly the same way as with model-driven engineering. Markers, which are used during the reverse engineering phase to differentiate between code written by you and code generated by Objecteering, are also generated.

Application code (virtually reduced to programming operations if the model is complete) is written in these marked zone (using an external editor or an IDE).

Unlike model-driven mode, the round trip model allows the model to be directly modified at code level. The code is then fully reversed, in order to update the model.

In the example shown in Figure 61, the String type attribute appears in the model.

Figure 61. Principles of round trip engineering

Advantages of the round trip engineering mode

The main advantage of the round trip mode is that modifications can be carried out within the code itself, with the model only being updated periodically.

Drawbacks of the round trip engineering mode

The main disadvantages are:

· either that the code will very rapidly differ from the model

· or that the model returned will be physical and will lose its "overview"

· or a mix of these two disadvantages

Frequently encountered problems: n-ary associations

Figure 62. The problem of n-ary associations

Starting with a 0..* association called "theBars" from the "Foo" class to the "Bar" class, after the round trip we have a 1..1 association, still called "theBars" but this time going from the "Foo" class to the "Vector" class. The semantics of this association have therefore been lost. The model has regressed from its logical level to its physical level.

Certain mechanisms exist to get round these problems. Thus, if the "theBars" association has a "public Bar getTheBars (int idx);" form accessor, which is normally the case where you have requested that Objecteering automatically generate accessors, the reverse engineering tool will find the correct association again.

Frequently encountered problems: Renaming a class

Figure 63. The problem of renaming a class

We start with a 1..1 association called "theBar" going from the "Foo" class to the "Bar" class. After carrying out a round trip operation and renaming the "Foo" class "Foo2", we have a 1..1 association going from the "Foo2" class to the "Vector" class, but at the same time the "Foo" class with its association has been retained. In this case, the model is no longer valid, and differs from the code.

Frequently encountered problems: Divergence in generation

Figure 64. The problem of generation divergence

Starting with a 1..1 association called "theBar" from the "Foo" class to the "Bar" class, default generation creates a Vector. If this Vector is changed into another collection type in the C# code, two case scenarios are possible:

· Reverse engineering recognizes the new type and transfers it in the form of the {type=…} tagged value. During the next generation, if Objecteering C# Developer recognizes the type, all is well.

· Reverse engineering does not recognize the new typr (as illustrated in Figure 64). Generation is stopped and the round trip cycle is interrupted.

To avoid this problem, try to choose a type known to Objecteering C# Developer (for details on known types, please see "Tagged value types").