Paul posits:

Logically speaking, I can’t see why, if any tool were *really* good at forward-engineering, one would ever want to reverse-engineer. The “round-trip” tools I know are there because they do a good job of organising and re-organising the gross structure of the code as models, but can’t do anything with the fine detail of the code.

Scott Ambler tossed out the case where folks that are visually oriented would appreciate reverse engineering the code [into models].

I added: one might want to use reverse engineering of

machine-generated source to:

• see what the code looks like in a different view(s).
• see code added manually outside of generator
• check for compliance with intentions of the fwd engineering tool

Paul’s reply tends to lead me to think that Paul is making his points based on an assumption that the “(near) perfect” tool to go from some higher form (modeling+?) to source code is in existence. That this tool automagically forward engineers perfect code — hence why would you need to reverse engineer the code? An analogous situation to source code being forward engineered into assembly code.

I’m no computer scientist, but someone help me out here. I would surmise the leap from source code to assembly code being one of nearly a mathematical proportionality. That is, the source code — being of a higher order language — is merely a more compact form of an equivalent expression in assembly. Sort of like multiplication is a shorthand notation for lots of addition statements.

The breakdown occurs as the model-to-source code paradigm is considered. Paul’s view may be one of the “Holy Grail” of modeling tools that can capture any type of application and all of its complexity at some level higher than simple source code, yet be able to generate the requisite code to have the application run.

I think we have a long way to go before this tool crosses our computers!

And I don’t mean with LSD… In a post, Juha-Pekka postulates the following:

• “My personal opinion is that roundtripping is a recipe for trouble. “
• “Still I need to ask what is the value of having a rectangle symbol in a digram and an equivalent class in a file.”

When I first laid eyes on an ad for Together/C++ in 1994 that promised code and diagram were always in sync, I spent $1200 of my own money and bought it sight unseen.

Not having accurate diagrams that represented the code was a problem… Though I had powerpoint templates for Object Modeling and excel spreadsheet templates for sequence diagrams, these always seemed to get out of sync with the code after a while. This is quite likely worse than having no diagrams at all! (Kind of like a map with an error might be worse than no map at all… depending if the road now goes through a man-made lake.)

Think of round-tripping a class diagram as follows:

• edit the code, the diagram automatically reflects the change.
• edit the diagram and the code is immediately updated.

Sounds like a visual editor to me… always in-sync diagram and code.

Much like we represent bytecode and assembly with higher-order languages (i.e., things like source code), another level up of representation of the same thing can be useful.

At least I found in-sync round-tripping useful for the past dozen years. Others’ experience may vary.

A given software problem can be solved in more than one way.

Suffice to say, Developer A might require 5 times as much effort as Developer B. To add to that statistic, the design and code from Developer A might be 5 times the LOC, and much worse quality (maybe 5 times the complexity) — basically more expensive to maintain. Might as well add one more problem: the code from Developer A exhibited brittleness when attempting to extend the functionality.

However, both A and B products provide the desired functionality.

A project team or a company likely has both A and B type developers, but rarely has the opportunity to compare parallel solutions to the same problem.

How do you go about trying to get the best solution for your money at your company?