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 the user 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 zones (with the aid of an external editor or an IDE).

Unlike the model driven mode, the round trip mode 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 128, the String type attribute appears in the model.

Figure 128. Principles of round trip engineering

Advantages of the round trip engineering mode

The principal 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 fundamental disadvantage is:

· 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 the two previously described disadvantages

Frequently encountered problems: N-ary associations

Figure 129. 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 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, Objecteering Java Developer will find the correct association again.

Frequently encountered problems: Renaming a class

Figure 130. 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. It differs from the code.

Frequently encountered problems: Divergence in generation

Figure 131. 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 Java 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 the generator recognizes the type, all is well.

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

To avoid this problem, try to choose a type known to Objecteering Java Developer (for details on the list of types known to the Objecteering Java generator, please see "Tagged value types").