> From: Wojtek Narczynski <[log in to unmask]>

> Yes. My impression is that UML is less about "design" than about rough
> "scrathing" of ideas.
>
> At some level you have to drop those scratchings, because there is no way
> back from code back to diagrams.
>
> But I'd love to be proven wrong. I would love to see an UML design of, for
> example, smtp or http server, or rdbms, or UML modeling tool - caputred in
> UML diagrams. Unfortunately I only see trivial examples everywhere
> (included with tool distros, uni lessons, etc.).

My project is using my open-source code generator ColdFrame (at the
moment you need Rational Rose at the front end, in principle I could
interface to eg UML Studio but there are project deadlines!) at
http://www.pushface.org/coldframe/

The idea is that the UML model is a set of formal domain (subject
matter) analysis models. There's little need to model framework
concepts (such as where all the current instances of a particular
class are kept) because the generated code will do that. Your Ada code
appears in separate subprograms and task bodies.

You are not allowed to modify generated specs or package bodies! (and
people don't). If you are a really good Ada person you get to work on
the framework (aka software architecture); but most of us are
modelling, writing code to complete the models, testing it (and
engaged in lots and lots of reviews). If you need to change the
structure of the code (because you need an additional operation on a
class, say) you change the model, regenerate the framework, and carry
on. A major reason for this is that it's very hard to relate random
changes in code to what they might have meant in the model -- that's
easier if your generated code is 1..1 with the model, of course.

We find that in application domains we have about 20% hand-written
code (ie, separate bodies), whereas in i/o domains it's the other way
round.