For most of the last ten years I’ve been suffering with Rational Rose or related UML modelling tool, all of which seemed to miss the point completely “A picture can replace a thousand words”.. but with UML you needed two thousand words to explain the interpretation of UML in the context.

Two tools have changed that for me:

1) Sparx Enterprise Architect is an Excellent UML modelling tool, covering the full life-cycle with very good forward/reverse engineering of code and database schemas. The great thing about EA is that it generates web-documentation with all the appropriate hyperlinks.. but the best thing is that it is priced so you can put it on everybody’s desk.

2) Microsoft Visual Studio Domain Specific Language SDK for very specific models that generate very specific code fragments

The key point to the article (that I agree with) is not to waste time with modelling constructs that are meaningless (containment is largely meaningless & ternary associations have always been). State transition diagrams outside real-time systems or parsers are a common sign of ‘analysis paralysis’, but a DSL state-model for code generation is a RAD tool.

"That's all fine as far as it goes, but how do you know when a particular nuance is inconsequential and when it's an important item to specify?"

If it isn't obviously important when you are drawing the model it probably isn't that important yet. Move on, do the next bit, just be reasonably sure that you can visualise the way the code is going together.

You can always come back and fill in some details later - if you think it is important. It probably isn't though.

If UML is such a great design tool how come the Rational product line is so rubbish?

Forget about UML -- knock up a prototype and get the user community to tell you whats wrong with it. Keep changing it until they say its OK. Than tell your programmers to write the 5000 lines of java that do what your 200 lines of php does.

They are just entity-relationship diagrams disguised with (then) trendy OO terminology. They are of no help in understanding a system composed of dynamic, communicating objects. State charts and sequence diagrams are much more helpful, as is the objects-and-interfaces notation used in the old RM-ODP documentation.

Furthermore, they have no semantics so expecting them to "stamp out ambiguity in specifications and designs" is a pipe dream.

There are still two (or more) camps in this after a generation (or two.) Modeling (UML, whatever) is an easy way to show the business requirements but once it comes to implementation nothing yet (and IMHO not for a long time) beats a common sense. I'm all for modeling a system because you get a solution what is needed but, unfortunately, no modeling can yet (easily) include the performance, security, interoperability, maintainability, etc to that solution. So, we still need good human developers who can interpret the model. I have been doing all kinds of models abut 30 years, even creating modeling systems, but when it comes to execution they are just guidelines.

I'm a second year comp sci undergraduate and cannot stress enough how helpful UML can be for learners. Many times I've used it in group meetings to get across my ideas to peers of varying skill levels.

How is UML useful to show the business requirements?

Firstly, the business should be showing *developers* requirements, not the other way round.

Secondly, business people do not think in terms of abstractions in the same way that computer programmers do. UML does not, in my experience, mesh at all well with how business users/stakeholders think.

Thirdly, UML is far too fine-grained to express how stakeholders think about requirements. Use cases are very solution focused. Business users think at a larger scale, in terms of how many transactions their staff can turn over per month, for example, not about how little stick men interact with system components.