Round trip mode

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 Modelio, 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 the figure below, the String type attribute appears in the model.

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.

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

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 Modelio automatically generate accessors, the reverse engineering tool will find the correct association again.

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.

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 Modelio C# Designer recognizes the type, all is well.

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

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