UML is not an exact science

[Peter Sanders]

Hi

Apologies if this is off topic but I think it is relevant to Part 2...

I'm not saying UML isn't useful, but I don't think its as amazing as a lot of the industry seems to want to make out (there seem to be a lot of things like this in the IT industry). Anyway I don't think its worth getting The UML user guide by MFowler etc (although UML distilled is quite good).

Anyway I don't think its an exact science. I'm tempted to say its like the Emperors new clothes but I suppose that would be a bit harsh...

Anyone else got any views on this?

Cheers

Peter

[Theodore Casser]

Well, I think that it's really a matter of taste, honestly. UML doesn't have to be perfect - heaven knows we don't use too much of it in my office in a formal sense - to be useful. I think that we all take it for what it is, a tool to demonstrate what we're picturing in terms of design for a project and to have a common language for expressing that design. (Or at the very least, I haven't seen many folks expressing that UML is 'amazing' to use your words for it... it is what it is.)

And that's really, I think, what this exam's project is about - demonstrating both that you can come up with a coherent strategy for implementing a solution to the client's project and that you can explain what your solution is.

[Stan James]

This Blog comments on Fowler's notion of modes of use for UML. For sketching you don't need much precision. For blueprinting you need enough precision and completeness for the reader to use the blueprint to build something. For MDA code generation you need enough precision for a computer to generate code. Sketch users are probably the most common, and can get by quite happily with a few boxes & arrows. Day to day I see whiteboards or PowerPoint used for this much more than any UML tools.

[I Roberts]

Hi,

I've been using UML for about six or so years now, alongside other design and architectural notations. However, by far the most useful is UML. However, UML is not something that you can learn overnight and suddenly become great at, like any specification, the more you know and understand it the more useful it becomes. Back in the early days I had my doubts, basically because I didn't understand it well enough or how it should be applied but now it is used quite extensively in most of my day to day role as a software architect. The level of abstraction used depends upon what I am trying to achieve, the view I am trying to present and its intended audience.

I am a great fan of the UML Distilled book, however, it does have its limitations and should be used in conjunction with other reference books. I hate to say it but UML is only a notation, how it is applied depends upon your knowledge of the development methodology being used.

Why is it better than boxes and arrows? Well, depending upon the audience it might not be but it depends on what you are trying to achieve from the diagram. My path regular comes into contact with off-shore and on-shore developers and UML is a great language bridge in that regardless of where you are born or educated, UML remains the same. The surrounding text may be substantially different - but a picture does paint a thousand words!

Before UML I used SSADM, DFDs, ERDs, flowcharts etc., everyone did them different and each organisation had their own understanding. As a specification, UML (when used by someone who actually knows it) is consistent and cross-organisational.

Regards,