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!