[imiric]

> Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway.

I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date?

They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code.

Besides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. Rather start with informal diagrams and sketches, and once the design has mostly settled, switch to something like UML. This would mean it wouldn't require changes every other week.

As for automatically generating, and dynamically arranging diagrams, this is more up to the generating tool than UML. These tools are still stuck using decades old technology at this point AFAIA, but there's no reason that a smarter tool couldn't do the things you mention.