OSNews

The author seems to have a very clear understanding of UML 2.0, however the introduction is extremely brief---too brief. Also, it's not really an introduction to UML in itself, rather an article about his tool "Ubrello" (I will give it a try for sure).

He also holds the Use Case and Class Diagram as the two most useful diagrams in the UML 2.0. Although being very useful in itself, the biggest drawback with the Use Case diagram is the rather weak link with the rest of the UML Model.

Sequence diagrams are at least as important. They are completely interlinked with the UML Model, and together with Class diagrams they almost make up an entire "mini UML specification"---two powerful ways to express the static and the dynamic behaviours of data.

(edit: typo)

Edited 2007-05-04 15:15

UML is becoming largely unnecessary as Agile practices become more and more mainstream (UML is a prime example of 'Big Design Up Front' which is a no no in Agile methodologies). I've personally never been a big fan of UML as it does not accurately model software (well, maybe for business folks, but to geeks it looks like gibberish).

UML serves little purpose, the customer does not care about your shiny drawings, and that's if he understands it. Given a GUI application it's a lot better to simply design the gui and show that to the customer.

As internal design/documentation it's far to time consuming to make all that UML stuff, and more important too much work to keep it up to date. The only technique that remotely works is the javadoc/doxygen approach.

The big design upfront is no-go because you must know what you're going to build. And if you know what you are going to build, there is little point in writing it down. If you don't know what you're going to build, your design will most likely be flawed.

UML is useful if you design a system with a fellow engineer, both directly understanding what you draw is handy. But any arrow and box drawing will do with some explaining.

Planning ahead with diagrams and models makes perfect sense; I can't help but be suspicious when Design becomes so complicated and formalized that it starts to be an end in itself, though. I'm just waiting for someone to announce a 4 year degree in Modeling.

Once again, I can't criticize the guys who invented UML. Actually, I'm embarrassed that I didn't foresee where the software business was going and invent something, like UML, "modern" C++, or most of the latest buzzword "processes." I could be one of the Gurus, with guaranteed employment or tenure somewhere and a book or two a year on the side.

On a tangent: I don't know about you, but UML reminds me of good old flowcharts: they are both as cumbersome and as beside the point. However, this sentiment does injustice to how UML could be used; my opinion is simply formed by the way I have seen it used and how people have tried to teach me how to use it. I rather preach that one should never make a program larger than one can safely understand in its entirety.

I strongly believe that UML can be handy at two levels instead of the traditional three:

1) conceptual level (before the job)
In which you can draw components of your system in future with standardized pictograms with type of collaboration among them. This can be for communication purposes
- if you like "use cases" then with your customers
- or just with your software engineers/programmers

2) rough documention (after the job):
In order to make your bussiness running not only today
but 2 months after when your programmer who wrote your
most profitable product had left,
you will miss the time
and money you did not spent for documentation.
Even a newer programmer will miss it too!

And you two can slip out of the bussines slowly.
I deeply believe that rough (not full or comprehensive) documentation of the projects you made
can help a lot to stabilize the future of your company.

Finally, I'd like to suggest to you BOUML http://bouml.free.fr instead of umbrello or any expensive java based stuff. Umbrello is so much infancy! other are so expensive and slow. Sparx system is fairly good. I runs smoothly with wine on linux.
I have so good experiences BOUML versus others I mentioned, that I just can recommend it to anyone.

It is fast, stable, small, fully GNU and is in the rocket fast development stage. Can generate C++,java, idl, and reverse engineer from these too.

Already too big.Buggy. Freezes often. Doubles associations.The generated XMI is just full of rabbish (main duplicates). Cannot generate code, cannot reverse engineer code reliably and unfortunately, this situation has not changed for quite a long time, anyhow I was waiting for to get it operating reliably. I really did not expect to have newer features but operate stable.
Give bouml a chance! It is worth. The author is so much responsive to all comments and help requests. It is even plug-able, if you like to certain actions on your design in a way that you like. (sorting by x,v,z aspects...etc.)

I have spent quite a lot of time to test UML stuffs. I am not an expert in UML (however, I hold certificate from this) but I use it very often and this was my very recent conclusion.

I had a small epiphany of sorts on the subject. We were writing large documents almost entirely in UML (many of which I am fairly sure were never read and were so dry that I found it difficult to learn anything from them).

I came to the conclusion that UML should be treated like pseudo-code, just used in places in a document. For me it certainly doesn't replace an insightful bit of prose or a good custom diagram (written by the right people) for big-picture view, and its usually a waste of time if its trying to be too detailed... in my experience.

It is useful if people use the KISS principle and simplify complicate process/steps that cannot be express by words.

But many people do it the other way round and make the diagrams too complicated for others to understand.