[tlug] Re: several messages

[Curt Sampson <cjs@example.com>]

On Wed, 5 Sep 2007, Zuco Pietro wrote:

> I had try a lot of UML books and tutorial but until know I didn't find
> what I was looking for.

I think it was an earlier edition of this one I used at some point, and
found it to be good:

    http://www.amazon.com/UML-Distilled-Standard-Addison-Wesley-Technology/dp/0321193687/

It's in storage right now, but I could dig it out and bring it to the
tech. meeting tomorrow, if you wanted to look at it. Heck, I might even
sell it to you. :-)

> I need to implement code from a diagram and create a diagram from code.

You might consider just why you want to do this. That's difficult,
expensive, time-consuming, and will harm both your diagram and your
code.

On Thu, 6 Sep 2007, Dimitar Dimitrov wrote:

> *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)

If you truly need a formal specification of part of a system, UML is
useless, and you'll have difficulty proving your spec. with the other
suggestions. I recommend using Z (pronounced "zed") for formal work. In
particular, see:

    http://www.amazon.com/Way-Practical-Programming-Formal-Methods/dp/0521559766/

> *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).
>
> 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...

I completely agree. The purpose of a diagram is to communicate some
aspect of the system to someone else. This has some implications:

    1. Any formalisms that get in the way of that communication need to
    be removed.

    2. Diagrams frequently need additional explanation in the form of
    text or conversation; use this when necessary, rather than trying
    to make the diagram do all the work.

    3. Too much detail will harm a diagram; strip it down to only
    necessary detail.

UML works against all three of these principles.

The one area where I disagree with Dimitar is with using paper: I like
to use a whiteboard. :-)

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com