Round Trip Engineering is nice in theory, but it fails miserably in practice because working in code is impossibly constrained by where and how you can and cannot make changes so as not to confuse the code parsers that are responsible for importing code back into the model.
This is all quite aside from the fact that the modeling tools themselves are incapable of representing certain types of structures, notably those commonly found in contemporary Java.
This term has been around since the early 80's at least, back when CASE tools were supposed to revolutionize the world of software engineering. We're still waiting.
Due to the fact that models are abstractions of an implementation it is virtually impossible to reverse engineer these abstractions. Any attempt to do so usually results in a model that accurately represents the implementation, but not the higher level abstractions being implemented. This raises the question of whether round trip engineering is a worthy goal at all. Instead of trying to propagate changes back into the model, is it better to propagate changes to the model into the implementation? -- jMM
Here's a typical scenario that would be hard to take round trip: Imagine you have an abstract form class. You also have a subclass of it that's actually implemented. The subclass also has a couple of buttons. However, the design might show, that the abstract form may have 0 or more buttons. So really and truely, the aggregation should show up with the abstract form and not with the subclass. For scenarios like this, the FoxPro Modeling Wizards do not handle any aggregation issues. They are meant to be designed once, and they are potentially different from the implementation. -- MarkusEgger
More to the point, possibly, and supporting jMM's point about models being abstractions, is TheSourceCodeIsTheDesign, one of my all time favorite classic Wiki Wiki Web topics. In summary (for now it's a very long, rambling multi-page topic):
Ergo, Round Trip Engineering is snake oil. It's bullshit.
- When the original phases of software development were laid down, they were just plain wrong. Requirements, Design, Implementation, and Test are not what we think they are. Design is not something that you do only before you code. Implementation is not the act of coding.
- Engineers who build bridges and toasters produce documents, plans to be faithfully executed by trained workers.
- Software engineers produce code, plans to be faithfully executed (built) by the compiler.
- When you are programming, you are doing detailed design. The manufacturing team for software is your compiler or interpreter. The source is the only complete specification of what the software will do. The cute boxes in class diagrams are not the design, they are a high level view of the design.
- There isn't a tool in the world that can take your code and translate it back to cute boxes in class diagrams unless you severely constrain how you code and what you code.
Round Trip Engineering is, at best, a collection of batch utilities that help you keep design models and code in some sort of sync. It never really works very well, nevermind perfectly. It's a bit like Napoleon who leaves France for Waterloo with a gaggle of guys and sure, he returns, but not with much, and what does is ragged and beat-up.
-- Steven Black
Although I agree with most of your statements, Steve, I think they are a little generic. Rick and I have been working on a Web based data replication and code distribution system for Eagle USA. We spent a good amount of time on the system design. We ended up using a large number of patterns (well, we implemented a small number of different patterns in many different places) to build a very flexible design. And - believe it or not - I can take the whole thing round trip without any problems whatsoever. Now granted, this may not work for other projects (or may be hard with most projects even), but I don't think we should generally classify it as BS. -- MarkusEgger
Okay, then mostly BS. :-)-- Steven Black
Contributors: Steven Black jMM MarkusEgger
( Topic last updated: 1999.11.02 02:26:55 PM )