What is a value of reverse and round-trip engineering in UML tools?

For some reason, reverse engineering and round-trip engineering is considered important feature for UML tools. UML tool developers sometimes postpone other features in order to make it running. I always wondered why so. It looks it is not only me.

In theory, the feature could display a messy body of source code as messy diagrams.

The problem with reverse-engineering is that diagrams have the same level of abstraction as original code. If we add into mix the fact that diagrams are more cumbersome than source code, we receive less efficient representation of what we already have in the code. Why we need that?

I have seen two roles of UML where UML might be useful in the projects:

1. UML can be used to document important parts of the application.
2. UML could be use as substrate for domain specific language.

Reverse-engineering offers a little for the both of uses.

As documenting usually comes before implementing, there is a little to reverse-engineer when we creating the docs.

When the code is generated from UML-based DSL, mapping is usually one-to-many and mapping functions are not easily reversible. Therefore changing one element in UML model affects many places in source code. And even the code structure could change depending on the changes (consider changing multiplicity of the attribute in OR-mapping). This complicates creation of reverse engineering tools greatly. So there are usually no reverse-engineering for DSLs.

One of few cases where it was at least marginally useful was JBuilder’s UML view of the currently selected class. This view were somewhat convenient when get an idea of what is used by the class. However there was no significant advantage over outline view and Ctrl-LEFT_CLICK in Eclipse.