Round-trip engineering


Round-trip engineering is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, and even documentation. The need for round-trip engineering arises when the same information is present in multiple artifacts and therefore an inconsistency may occur if not all artifacts are consistently updated to reflect a given change. For example, some piece of information was added to/changed in only one artifact and, as a result, it became missing in/inconsistent with the other artifacts.
Round-trip engineering is closely related to traditional software engineering disciplines: forward engineering, reverse engineering, and reengineering. Round-trip engineering is often wrongly defined as simply supporting both forward and reverse engineering. In fact, the key characteristic of round-trip engineering that distinguishes it from forward and reverse engineering is the ability to synchronize existing artifacts that evolved concurrently by incrementally updating each artifact to reflect changes made to the other artifacts. Furthermore, forward engineering can be seen as a special instance of RTE in which only the specification is present and reverse engineering can be seen as a special instance of RTE in which only the software is present. Many reengineering activities can also be understood as RTE when the software is updated to reflect changes made to the previously reverse engineered specification.
Another characteristic of round-trip engineering is automatic update of the artifacts in response to automatically detected inconsistencies. In that sense, it is different from forward- and reverse engineering which can be both manual and automatic. The automatic update can be either instantaneous or on-demand. In instantaneous RTE, all related artifacts are immediately updated after each change made to one of them. In on-demand RTE, authors of the artifacts may concurrently evolve the artifacts and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts.
Round trip engineering supports an iterative development process. After you have synchronized your model with revised code, you are still free to choose the best way to work – make further modifications to the code or make changes to your model. You can synchronize in either direction at any time and you can repeat the cycle as many times as necessary.

Examples of round-trip engineering

Perhaps the most common form of round-trip engineering is synchronization between UML models and the corresponding source code. Many commercial tools and research prototypes support this form of RTE; a 2007 book lists Rational Rose, Borland Together, ESS-Model, BlueJ, and Fujaba among those capable, with Fujaba said to be capable to also identify design patterns. Usually, UML class diagrams are supported to some degree; however, certain UML concepts, such as associations and containment do not have straightforward representations in many programming languages which limits the usability of the created code and accuracy of code analysis. A 2005 book on Visual Studio notes for instance that a common problem in RTE tools is that the model reversed is not the same as the original one, unless the tools are helped by laborious annotations. The behavioral parts of UML impose even more challenges for RTE.
A more tractable form of round-trip engineering is implemented in the context of framework application programming interfaces, whereby a model describing the usage of a framework API by an application is synchronized with that application's code. In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. Two prominent RTE implementations in this category are framework-specific modeling languages and Spring Roo.
Round-trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's Model-driven architecture. OMG proposed the QVT standard to handle model transformations required for MDA. To date, a few implementations of the standard have been created..

Examples in software engineering

Round-trip engineering based on Unified Modeling Language needs three basic components for software development:
An example of basic round-trip engineering is accessible as a web-based Open Source tool is: