Jump to content

Round-trip engineering

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Alexander Davronov (talk | contribs) at 18:46, 5 November 2023 (style). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Round-trip engineering (RTE) in the context of model-driven architecture is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, documentation, etc. between each other.[1] The need for round-trip engineering arises when the same information is present in multiple artifacts and when an inconsistency may arise in case some artifacts are updated. For example, some piece of information was added to/changed in only one artifact (source code) and, as a result, it became missing in/inconsistent with the other artifacts (in models).

Overview

Round-trip engineering is closely related to traditional software engineering disciplines: forward engineering (creating software from specifications), reverse engineering (creating specifications from existing software), and reengineering (understanding existing software and modifying it). 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.

Types

Various books describe two types of RTE:[2]: 459 

  • partial or uni-directional RTE: changes made to a higher level representation of a code and model are reflected in lower level, but not otherwise; the latter might be allowed, but with limitations that may not affect higher-level abstractions
  • full or bi-directional RTE: regardless of changes, both higher and lower-level code and model representations are synchronized if any of them altered

Auto synchronization

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 (traditionally) and automatic (via automatic generation or analysis of the artifacts). 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 update the artifacts (even in a distributed setting) and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts.

Iterative approach

Round trip engineering may involve 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.

Software

Many commercial tools and research prototypes support this form of RTE; a 2007 book lists Rational Rose, Micro Focus Together, ESS-Model, BlueJ, and Fujaba among those capable, with Fujaba said to be capable to also identify design patterns.[3]

Limitations

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 aided by leaving laborious annotations in the source code.[4] The behavioral parts of UML impose even more challenges for RTE.

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/reverse engineering (e.g., containment is hard to recognize in the code).

A more tractable form of round-trip engineering is implemented in the context of framework application programming interfaces (APIs), 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 (Java).

Round-trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's (OMG) Model-driven architecture. OMG proposed the QVT (query/view/transformation) standard to handle model transformations required for MDA. To date[when?], a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE).

Controversies

Code generation controversy

Code generation (forward-engineering) from models means that the user abstractly models solutions, which are connoted by some model data, and then an automated tool derives from the models parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process.

UML (if used for MDA) diagrams specification was criticized for lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code is the design".[5][6]

Disadvantages

There is a serious risk that the generated code will rapidly differ from the model or that the reverse-engineered model will lose its reflection on the code or a mix of these two problems as result of cycled reengineering efforts.[7]

Regarding behavioral/dynamic part of UML for featues like statechart diagram there is no equivalents in programming languages. Their translation during code-generation will result in common programming statement (.e.g if,switch,enum) being either missing or misinterpreted. If edited and imported back may result in different or incomplete model.[8][9] The same goes for code snippets used for code generation stage for the pattern-implementation and user-specific logic: intermixed they may not be easily reverse-engineered back.[8][9]

There is also general lack of advanced tooling for modelling that are comparable to that of modern IDEs (for testing, debugging, navigation, etc.) for general-purpose programming languages and domain-specific languages.[9]

Examples in software engineering

Perhaps the most common form of round-trip engineering is synchronization between UML (Unified Modeling Language) models and the corresponding source code and entity–relationship diagrams in data modelling and database modelling.

Round-trip engineering based on Unified Modeling Language (UML) needs three basic tools for software development:[citation needed]

  • Source Code Editor;
  • UML Editor for the Attributes and Methods;
  • Visualisation of UML structure

References

  1. ^ Gentle, Anne (2012). Conversation and Community: The Social Web for Documentation (2nd ed.). XML Press. ISBN 978-1937434106.
  2. ^ Sobh, Tarek M. (2008). Advances in computer and information sciences and engineering. International Conference on Systems, Computing Sciences and Software Engineering. New York?: Springer. ISBN 978-1-4020-8741-7.
  3. ^ Stephan Diehl (2007). Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software. Springer Science & Business Media. p. 63. ISBN 978-3-540-46505-8.
  4. ^ Andrew Filev; Tony Loton; Kevin McNeish; Ben Schoellmann; John Slater; Chaur G. Wu (2005). Professional UML Using Visual Studio .Net. John Wiley & Sons. p. 181. ISBN 978-0-7645-5875-7.
  5. ^ http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves
  6. ^ Reeves, Jack W. (1992). "What is software engineering". www.bleading-edge.com. C++ Journal. Retrieved 2023-07-25.
  7. ^ "Help -". www.modeliosoft.com. Retrieved 2023-07-25.
  8. ^ a b Siegl, Daniel. "Why Round-Trip Engineering does not work | LieberLieber Modelling Expert". Retrieved 2023-07-25.
  9. ^ a b c "8 Reasons Why Model-Driven Approaches (will) Fail". InfoQ. Retrieved 2023-07-29.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Round-trip_engineering&oldid=1183658106"