The Old Joel on Software Forum: Part 4 (of 5) - How does UML fit into Agile Methodology?

How does UML fit into Agile Methodology?

In some ways UML seems to encourage big upfront design, which is a no-no in most Agile Methodologies and a stance that I agree with.

However, I can't deny that properly maintained UML diagrams can be extremely valuable high level documents for getting new programmers up to speed or reminding yourself how you did something you worked on previously.

How do you guys reconcile two (possibly) diverging approaches to development?

Also are there any tools you prefer? Evaluating UML tools is just plain painful. It takes a long time to see what's out there, fill out evaluation forms, learn how to use the tool, explore, etc. I tend to be thorough with this kind of thing as I hate having the feeling that something somewhere else has a better price/performance ratio than the thing I settled on. However, after a while, I find that I'm willing to settle on the next thing I see that's "good enough".

Crimson
Tuesday, February 17, 2004

I've evaluated a lot of UML toolsets, and I've finally settled on a suite of tools I'm pretty happy with. For my initial, up-front JAD sessions I generally tend towards "Waving Hands In Air." Then when I need to do some serious design, I resort to Pencil And Paper 2.0.
If I need approval on the design, I'll go with a flow chart in Visio.

Other than that, I've found most tools take time and energy away from the actual process of design. :-)

Philo

Philo
Tuesday, February 17, 2004

I'll go with Philo on that, with the addendum that using a whiteboard plus a digital camera to save useful drawings, combined with a software package to cleanup the photo [1] works really well -- just the right level of detail but no maintainability headaches. If it gets too out of date just whack the image from the doc/ directory since it didn't take that long to create anyway. (Stuff tweaked for hours in visio tends to stick around way past its useful life because the people who worked on it can't bear to see their work tossed.)

[1] The aptly named Whiteboard Photo works for me: http://www.websterboards.com/products/wbp.html

Chris Winters
Tuesday, February 17, 2004

In agile UML is generally not used as a design tool but as a documentation tool. Generally you'll want to get a tool that can take you're source and generate a UML diagram from that. This generator whould be run with you're automated build so you can guarantee it is always in perfect sync with the codebase. Nothing is worse than stale UML diagrams.

Oren Miller
Tuesday, February 17, 2004

Check out the agile modeling website maintained by Scott Ambler for a thorough discussion of one theory of how to fit UML and similar tools into an agile process:

http://www.agilemodeling.com/

cricket
Tuesday, February 17, 2004

Way to go, Philo.

I thought I was out of touch. I find those the best tools - I will ad - document the design the best way you can understand - a lot of Vision and Word documents.

Works perfect for us here - saves a lot of time when you are a team of 3 developing enterprise level software

KS
Tuesday, February 17, 2004

Good comments from everyone. I agree, a UML's purpose in "agile" methodologies seems to be clear, unifrom whiteboard markings (or notepad, napkins, etc.). Also agree with the part about having a program generate UML from code. Now, if only there was a *good* free program that did that.

vince
Tuesday, February 17, 2004

My agile methodology for handling UML is to run away
very quickly...

x
Tuesday, February 17, 2004

Agile or not, the run away strategy is the best one, in my opinion.

If drawing pictures was sufficient to convey understanding, we never would have needed to invent spoken and written language. UML is arguably good at capturing the what, but that's not what matters most. What really matters is the why, and no diagram can ever capture that. If people spent their time documenting why, rather than drawing fancy what diagrams, we'd all be far better off.

Sum Dum Gai
Tuesday, February 17, 2004

I've been playing around with an open-source package on my free time, thinking about adding to it.

I tried reverse-engineering with UML. Got a whole lot of pretty pictures.

I am absolutely no closer to understanding "why".

Nigel
Tuesday, February 17, 2004

nigel,

"why?"

while i have not yet worked with large scale OO, i have found that by having a "big-picture" diagram of a system it is easier to maintain. in my experience, it lowers the possiblity that i will change something without knowing what else will be affected.

that's the easiest way i can explain it.

Michael Sica (michaelsica.com)
Wednesday, February 18, 2004

oh, and to answer the OP's question about tools, a friend just suggested the community edition of this:

Poseidon for UML
http://www.gentleware.com/

the community edition is free.

Michael Sica (michaelsica.com)
Wednesday, February 18, 2004

I'm with Philo. Doodles on a whiteboard, then transcribed to paper, and finally Visio so people don't have to deal with my chicken scratch handwriting any more than they absolutely have to.

Computers tend to isolate, and the hand can jump from one side of the whiteboard to start writing much faster than move mouse / click /start typing.

www.MarkTAW.com
Wednesday, February 18, 2004

Some interesting thoughts from one of the Agile guru. See
http://www.martinfowler.com/bliki/UmlMode.html (& al.) for the different possibilities of using UML.
> As a notation to communicate over some specific problem ("UML as Sketch": the Agile Way)
> As a notation for big up front design methodology ("UML as BluePrint": RUP, etc.)
> "UML As a Programming language" (MDA and Co)

R Chevallier
Wednesday, February 18, 2004

Michael, when I said "why", I was referring to a previous post by Sum.

I want to know why a class exists. I want to know why a class has a certain member.

I think these sorts of questions can only be answered with boring ol' written documentation.

Nigel
Wednesday, February 18, 2004

Nigel: i know, right. :)

Michael Sica (michaelsica.com)
Wednesday, February 18, 2004

I would say that one useful thing that UML provides is a standard graphical way of describing software systems. That is, for example, if you need to do a quick sketch to explain to another programmer how the modules of a sub-system work, if you both know UML, you can communicate quickly without having to explain what a squigley line means here or what a double box means there.

Sure, each company can develop their own standard diagrams and symbol sets, but if there is a reasonably functional one already, why bother.

So while I wouldn't advocate doing the whole umpteen diagrams for each project, I do think that all progammers should familiarize themselves with the basics of UML so that we can talk to each other using the same symbology.

Bill Tomlinson
Wednesday, February 18, 2004

I second Bill on the fact that UML is a language and not a methodology (not to be confused with RUP).

That being said, it does not "encourage big design up front", it doesn't really encourage anything, since it's just a language.

More on topic, my use of UML would be to make a series of very broad / general UML charts at the beginning of a project, and then add in details / modify them as the project progresses, adapting to the changes in requirements.

I find that Visio 2000 with a good UML stencil works fine for that purpose.

Renaud Martinon
Thursday, February 19, 2004

Guys,
To me the best way how UML fit into Agile Methodology is to build and test partial model simultaneously. Surf the link to know more about Partial Models. http://www.agilealliance.com/articles/articles/AgileModelingEnvironment.pdf

Thanks
Bhaskar

Bhaskar Kolluru
Tuesday, March 23, 2004