“When you’re designing and developing new software systems, it is often hard to see how all the pieces are suppose to fit together. Unified Modeling Language is one tool that allow developers and architects to ease the process and create a big picture before committing to a particular technology.”
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
I find that Use Cases are good for communicating the functional requirements during the analysis stage. The value for me is how they are modeled and written, not Use Case diagrams themselves. IMHO, UML doesn’t do Use Cases any justice and Use Case diagrams offer little value most of the time. Alistair Cockburn’s Writing Effective Use Cases is excellent book to read on this subject.
I agree with you completely. Use Cases seem to be often misunderstood. They are not drawings! Use Cases are good, structural and unambigious texts, although on a high level. They are especially useful in the initial phases, although I still have to say that they’re somewhat “disconnected” from the rest of the UML diagrams. Used together with a sensible method, however, they can fit in.
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 is useful for any large project no matter what development process you use.
In Agile environments you just keep the UML agile. Don’t do everything up front, fill in as you go, etc.. UML can still be very useful even when used this way.
Your comment about UML not being useful to developers is total nonsense.
Edited 2007-05-04 16:40
Using UML for design is one thing. And I agree that UML isn’t the best tool in the world to do software.
But I have come to appreciate the use of it for analysis. It’s a very nice tool to flesh out your view of the problem domain.
This is also the most common problem with UML software. Most of them seems to be design with the assumption that the diagram is to be translated into a software design. In practice this means that model elemants that’s very useful for analysis gets left out because they have no sensible representation in most OOP languages. Which kind of makes the tool useless.
UML is not a methodology
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.
Why does UML have to be associated to a big design upfront??? I think there are many misconceptions on here to what UML is what purpose it serves.
” Given a GUI application it’s a lot better to simply design the gui and show that to the customer. ”
What about when you are designing systems that don’t involve a GUI?
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.
Activity diagrams are probably the nearest to flowchats, but as for cumbersome i think not. I would suggest decomposition in fear of making a program/system(s) larger than one can safely understand.
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.
Can you explain what you mean by that?
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.