Re: Request for input
- Sure Boris, but if your customer wants you to architect/design the
entire app upfront I cannot be of any help.
What I mean is that we never sit down and design entire applications
upfront. Nor do we design entire iterations worth of features in one
sitting. Instead, when a pair needs to do some design they might use
UML to sketch out some ideas on a whiteboard, and as Jeff said they
can make decisions about those design ideas in real time and in light
of the true state of the code base. But designing is often closely
coupled to coding, so those diagrams almost never make it into some
"design document" because they are implemented and modified almost
immediately. The next day might bring some entirely new design ideas.
I do think the UML "back generation" tools are consistent with agile
though. We are often asked to deliver UML and "design docs" with our
work, so right before we have to deliver we take a "snapshot" of the
design using UML back generation (try a cheap(er) tool like Enterprise
Architect), and perhaps we add some notes to clarify things. But the
neat thing is that the empirical reality of the code is what drives
back generated diagrams, it wasn't some upfront diagrams that drove us
to code a certain way. Of course, as soon as we start working on the
code again the diagrams we delivered get stale, but at least the
delivered code was fairly well documented.
Hopefully this makes sense.
-- Victor Szalvay
Danube Technologies, Inc.
--- In email@example.com, Boris Gloger <boris@g...> wrote:
> Hi Victor, can you explain a bit more in which way you use the UML
> diagrams in flux way? I will be faced with the fact that I will need to
> architect a whole new application and I want to work as iterative as
> possible AND using UML diagrams. And I do not want to use FDD.
> On 04.08.2004, at 02:02, Victor Szalvay wrote:
> > Fascinating ideas Jeff. This is essentially the context in which we
> > use UML diagrams. UML is used to temporarily describe design ideas in
> > flux systems that are too dynamic to "document" in a final sense. The
> > empirical nature of (agile) software development drives the documents,
> > not the other way around.