[tlug] Re: [OT] UML Book

["Dimitar Dimitrov" <dimitar.dimitrov@example.com>]

>  From: "Zuco Pietro" <zucomailinglist@example.com>
>  Date: Wed, 5 Sep 2007 16:36:17 +0900
>  Subject: [tlug] [OT] UML Book
>  
>  I had try a lot of UML books and tutorial but until now I didn't find
>  what I was looking for. All them lack of practical examples.

Perhaps that might be because UML as per spec lacks practical applicability ;-)

>  I need to implement code from a diagram and create a diagram from code.
>  I was looking for examples that show me an UML project, class
>  diagrams, activity,.... 

IMHO, UML is good for illustrating particular aspects of your system and a terribly bad language for writing stuff in. Since UML is used in different way by different people, depending on your case, you'll want to read different books.  See some scenarios bellow:

*1* MDA (Model Driven Architecture [1]) - the assumption is that if your domain is uniform enough and includes a lot of repetitive coding, you can generate the code from a higher level model (translation). The OMG recommends that the higher level model is described in UML and specifies standard translation technologies. An obvious advantage is that in pure MDA project the model IS the code and if you want to add for example runtime OCL constraint checking, the only thing you need to change is your generator. The greatest disadvantage is that the tooling isn't there yet (no model level debuggers, generators are complex and buggy, etc.) also the standards are still in flux. For example of an open source MDA tool, you might want to check the AndroMDA project. 

*2* UML as rigorous formal specification (e.g. hard real-time systems) - never done it, but if you want to prove your programs you can use UML (or Eiffel, or Java JML)

*3* UML as dust in the PHB's eyes (AKA "yes we have documentation"). In this case you usually generate UML from code and set the tool to create one diagram for each package. When, combined with process like RUP, the next step is to copy the same diagrams into the Logical View and then create one diagram in the Use Case View and go wild with bubbles and arrows.

*4* UML as supplement for developer's documentation (never use UML formalism in end user's documents) - this starts  with reversing part of the system and then hand-crafting diagrams to show specific parts of the system. The value comes from the decision which classes to include in the diagrams and the annotations you provide in the form of notes, stereotypes and tagged values. Usually a paragraph of text besides the picture helps a lot.

*5* UML as sketch - start with a blank sheet of paper. Draw boxes and arrows with pencil, use the rubber for Undo. Don't care too much of the formal notation cause you'll throw it away in the end (some people like to take photos first). If you don't like paper, use Umlet[4] or Violet.

I have personally started with 4, been forced to do 3, dabbled in 1, decided that it's not worth it and now going mostly with 5, and ocasionally 4. My favorite UML tool is Umlet and for more formal stuff Magic Draw. My most hated UML tool is Rational Rose, followed closely by Posseidon. 

For "what is uml" type of questions, I've read a couple of tutorials and parts of the UML Infrastructure/Superstructure documents. When doing formal stuff, I usually go through Allen Holub's UML Quick Reference[6]. Agile Modelling[7] is also a great resource if you are after scenario 4 and 5, they have a couple of books as well (I can give away a copy of The Elements of UML 2.0 Style[8] if you are interested). 

Cheers,
Dimitar

[1] http://www.omg.org/mda/
[2] http://www.andromda.org/
[3] http://www.embedded.com/98/9803fe2.htm
[4] http://umlet.com
[5] http://horstmann.com/violet/
[6] http://www.holub.com/goodies/uml/
[7] http://www.agilemodeling.com/ 
[8] http://www.ambysoft.com/books/elementsUMLStyle.html