It feels like an artifacts of an earlier days, but UML sure does have its use. However, agile processes like Extreme Programming advocates "embracing changes", does that also means I should make less documents and UML models as well? Since they gives the impression of setting something in stone.
Where does UML belongs in an Agile development practice? Other than the preliminary spec documents, should I use it at all?
EDIT: Found this: Potential artifacts for agile modeling
For throw away diagrams, yes. I'd generally only use it as a tool for communicating ideas, issues etc. Sequence diagrams, use cases and class diagrams.
For true agility you should express your design once and only once -- in code.
So while UML diagrams might well be useful as a shorthand notation for communication while preparing a task, and can usefully summarize a design while discussing designs with colleagues, they shouldn't be a delivered artifact.
In particular, they shouldn't be maintained, as this is needless duplication.
I've not formed my own solid conclusions about UML within Agile development practices, but I find it very useful as a simple communications medium between programmers.
Imagine you have started working on a story that you've taken on and you find that you have to swap your partner. You could find UML useful to sketch out your current position to your new pair to bring them up to speed.
I also find it useful in helping to explain design patterns and design principles when I give presentations.
Use what you find helpful. If a UML diagram helps you visualize what you need to do, use it. If a whiteboard does the same thing, use that.
Just don't make UML diagrams for the sake of making UML diagrams. Our time is too expensive to spend doing useless things.
Breeze through Robert Martin's Agile Principles, Patterns and Practices
So says UncleBob... I concur.
In my experience, what has been more useful is doing initial UML design (per feature, module or project basis,depending on the project itself), and then do initial code generation, and then in every iteration just doing simple reverse engineering to the models keeps them updated and reliable, in order to use them on refactoring meetings and such. This works for static diagrams.
But dynamic diagrams should be made and updated as needed only, they consume too much time and they change too often in agile projects for they to be part of the documentation. But then, if you find yourself updating a dynamic diagram too often, it's kindda a project smell, in my opinion, because, as it's said before, they should be used only for communication among the team.
For a very well thought out and expressed view on this topic read Martin Fowler's "Is Design Dead?" and if that convinces you, buy/borrow and read Scott Ambler's Agile Modelling.
In a nutshell, UML is a useful tool but don't over use it/abuse it; it's for thinking, as well as documenting but the code is the ultimate (though not only) expression of the design - the executable design. To this end, the team should do the architecture and design. Finally, use whatever tools to do it that helps (i.e. whiteboards and pens and digital cameras are great - you don't need a CASE tool)
We use UML when you need to explain to other programmers how the user story works. You can just sketch out the interaction diagram and show which objects talk to which other ones.
Very much like what Martin Fowler describes here: http://martinfowler.com/bliki/UmlAsSketch.html