One of the most frequently-raised topics in model-based engineering is that of “Round-Trip Engineering“. Well, there is a good reason why there is no workable solution for round-trip engineering on the market. This is because of two reasons.
First – is the difference between the languages. Both tasks – forward engineering (code generation from the model) as well as the reverse engineering (parsing the source code and creating model elements based on the results) are nothing else than translation from one language into another and as we know some things get lost in translation. Whereas, on the one hand the structural UML features like classes or interfaces have comparable features in most of the high level programming languages and can be translated from UML to the programming language and vice versa, the behavioral part of UML is different. Features like state machine have no equivalents in programming languages and will be translated during code generation to standard programming statements (like if, else, switch, function calls etc.). These statements have to follow exact pre-defined schema (or with other words pattern). Once the schema has been broken by accident while editing source code this code can not be reverse engineered any more to the same model as it has been generated from.
Second – since in most cases models contain source code snippets, the generated code consists of two parts: the part that defines pattern implementation, and the part that defines user-specific logic. While these parts are separated in the model by concept, in the generated source code one can impossible hardly be discerned from the other since they are essentially interwoven. So again, this is where mistakes are bound to be made while programming the source code… and once this mistake has been made and both parts have been mixed up, not even the world’s most advanced parser can re-assemble this code into a clean model. All in one that means the round-trip-engineering is restricted to very basic part of UML simply due to conceptual differences between the modeling and programming languages.
Nevertheless, even if model-based engineering provides many advantages, some parts can be developed much more quickly in the source code editor and not using very basic code editor features provided by modeling tools and clicking through hundreds of dialogs. The User Code Sync feature integrated into LieberLieber Embedded Engineer offers a workable alternative to round-trip engineering by clearly marking the areas in the source code that can safely be edited by the developer at any time. Typically, users add some hand-written source code either as the implementation of an operation or an opaque action. The description how it works please find here
Recent Comments