There’s a trope I’ve noticed with UML discussions and articles, which is that UML and agile are diametrically opposed.
This is not strictly the case. There’s nothing in UML or agile that says you cannot update a diagram in a sprint.
The supposed opposition comes from, not technical reasons, but the manner of thinking that each encourages. The promise of UML is that if you diagram the problem, all things will flow from it (implementation and documentation), this implies a design upfront and lends its self naturally to the waterfall approach, though this need not necessarily be the case.
And most tools were tailored towards that use case!
The (open source) exception that I remember from back in the day was Green UML.
Their sourceforge is still live and saying "green is a LIVE round-tripping editor, meaning that it supports both software engineering and reverse engineering."
Renaming a method in a reverse engineered UML diagram and seeing that reflected in code was pretty neat.
I never got why this isn't a standard feature until now. Hearing about the relationship between UML and broken project management I get it (I wasn't into that at that time, except that I never bought into the waterfall promise).
Let's hope someone will revive UML as a code navigation and round trip refactoring tool. That would help a lot and nicely fit an agile approach.
This is not strictly the case. There’s nothing in UML or agile that says you cannot update a diagram in a sprint.
The supposed opposition comes from, not technical reasons, but the manner of thinking that each encourages. The promise of UML is that if you diagram the problem, all things will flow from it (implementation and documentation), this implies a design upfront and lends its self naturally to the waterfall approach, though this need not necessarily be the case.