And I'm afraid you're still not telling me what UML is, only what it's for, which is subtly different. You're keen to tell me what it's intended to make better about my life, but you haven't really described what it is, and how it achieves what it aims to achieve. There can be a world of difference between things which have the same aim: for example, a vacuum cleaner, a carpet shampoo and a mop all share the aim of making floors cleaner, but they are totally different things which go about the job in different ways.

Oh, sorry, I thought that "what is it for" was actually what you wanted to know, rather than "what is it".

How about this, then:

It's a modelling language that defines syntaxes for different types of diagrams relating to system design (eg FSMs, message sequence charts, user interactions, object hierarchies) and a framework for fitting them together to provide a coherent (hopefully :-)) system architecture that can (again, hopefully :-)) be understood by techies and non-techies alike.

It has a string of other claims associated with it, including things like self-documenting systems (if you've written the UML model and developed the code from it, there's no need for further documentation) and making development faster and more reliable with less need for skilled programmers (if your system architect has designed the model, she doesn't need to know the intricacies of C or C++ or Java syntax to implement it - just press a button and bing, there it is).

As I tried to imply above, I'm not really sure that it does actually achieve any of these otherwise laudable aims.

OK. So, notably:

• the types of diagram and their visual syntaxes and symbol sets actually are pretty much the whole of UML, and there's no textual component that goes with them
• the sole purpose of a UML model is to communicate information about systems' structure between people (i.e. it isn't a "modelling" language in the sense of "simulation", and doesn't give you ways to predict how the system will behave other than thinking very hard about it in the conventional non-UML-based way).

Are those accurate? Because neither one was something I was entirely sure about before this conversation, so I'm learning new facts here which I suspect most UML people would have seen as so basic that they'd have forgotten to tell them to me.

First bullet: yes, although you can apply labels to states, transitions, messages etc. But they are attributes of that diagram component rather than being useful in and of themselves.

Second bullet: yes, although there are some tools that can help you iron out some of the issues (like warning you that you've got a use case that isn't covered by any of your state transitions, or a message sequence that can never get triggered).

There is also a "real time extension" for UML that claims to allow you to add clocks and timers and whatnot to your diagrams, and I bet that would also then allow you to simulate stuff happening (again, with the right tools). However, I have never met anybody who had a good word to say about that, other than the people who sell the tools :-)

I suspect some UML proponents would make far greater claims for it than I am making here - my knowledge is based on a years-ago training course which I have used very infrequently since.

UML is for describing system architecture and behaviour, in a way that allows non-technical people to understand how it all works

eg FSMs, message sequence charts, user interactions, object hierarchies

I'm having a hard time imagining these two things as remotely compatible. (Also the first reminds me of COBOL.)