Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Round-trip engineering
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{refimprove|date=December 2009}} '''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, [[Conceptual model (computer science)|models]], configuration files, documentation, etc. between each other.<ref>{{cite book|last1=Gentle|first1=Anne|title=Conversation and Community: The Social Web for Documentation|date=2012|publisher=XML Press|isbn=978-1937434106|edition=2nd}}</ref> 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 (software)|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:<ref>{{Cite book |last=Sobh |first=Tarek M. |title=Advances in computer and information sciences and engineering |date=2008 |publisher=Springer |others=International Conference on Systems, Computing Sciences and Software Engineering |isbn=978-1-4020-8741-7 |location=New York?}}</ref>{{Rp|page=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]], [[Together (software)|Together]], [[ESS-Model]], [[BlueJ]], and [[Fujaba]] among those capable, with Fujaba said to be capable to also identify [[design pattern]]s.<ref name="Diehl2007">{{cite book|author=Stephan Diehl|title=Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software|year=2007|publisher=Springer Science & Business Media|isbn=978-3-540-46505-8|page=63}}</ref> == 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.<ref name="FilevLoton2005">{{cite book|author1=Andrew Filev|author2=Tony Loton|author3=Kevin McNeish |author4=Ben Schoellmann |author5=John Slater |author6=Chaur G. Wu|title=Professional UML Using Visual Studio .Net|year=2005|publisher=John Wiley & Sons|isbn=978-0-7645-5875-7|page=181}}</ref> 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 interface]]s (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 language]]s 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|date=July 2023}}, a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE). == Controversies == === Code generation controversy === [[Automatic programming|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 (programming)|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".<ref>http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves</ref><ref>{{Cite web |last=Reeves |first=Jack W. |date=1992 |title=What is software engineering |url=http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm |access-date=2023-07-25 |website=www.bleading-edge.com |publisher=C++ Journal}}</ref> == 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.<ref>{{Cite web |title=Help - |url=https://www.modeliosoft.com/modelio-help/41/en/index.jsp?topic=/csdesigner-doc/html/Csdesigner_choose_functional_mode_round_trip.html |access-date=2023-07-25 |website=www.modeliosoft.com}}</ref> Regarding behavioral/dynamic part of [[UML]] for features like [[State diagram|statechart diagram]] there is no equivalents in programming languages. Their translation during code-generation will result in common programming statement (.e.g {{Code|if,switch,enum}}) being either missing or misinterpreted. If edited and imported back may result in different or incomplete model.<ref name=":0">{{Cite web |last=Siegl |first=Daniel |title=Why Round-Trip Engineering does not work {{!}} LieberLieber Modelling Expert |url=https://blog.lieberlieber.com/2015/09/05/why-round-trip-engineering-does-not-work/ |access-date=2023-07-25 |language=en-US}}</ref><ref name=":1">{{Cite web |title=8 Reasons Why Model-Driven Approaches (will) Fail |url=https://www.infoq.com/articles/8-reasons-why-MDE-fails/ |access-date=2023-07-29 |website=InfoQ |language=en}}</ref> 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.<ref name=":0" /><ref name=":1" /> 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 language]]s and [[domain-specific language]]s.<ref name=":1" /> ==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 model|entity–relationship diagrams]] in [[Data modeling|data modelling]] and [[database modelling]]. Round-trip engineering based on [[Unified Modeling Language]] (UML) needs three basic tools for software development:{{fact|date=January 2018}} * Source Code Editor; * UML Editor for the Attributes and Methods; * Visualisation of UML structure ==References== {{reflist}} {{DEFAULTSORT:Round-Trip Engineering}} [[Category:Programming tools]] [[Category:Reverse engineering]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Cite book
(
edit
)
Template:Cite web
(
edit
)
Template:Code
(
edit
)
Template:Fact
(
edit
)
Template:Refimprove
(
edit
)
Template:Reflist
(
edit
)
Template:Rp
(
edit
)
Template:When
(
edit
)