From XpFaq

''How much faster will a UML Phase make us?''

pandith@my-deja.com wrote:

 > I have the requirements for a project and have to design the system.
 >
 > Once we got the requirements, we did the use cases and use case
 > diagrams. What is the logical and easiest way to arrive at the low
 > level design?
 >
 > Should we do activity diagram or Component diagram and Sequence diagram
 > to end up with the Class Diagram?

Easy. Take the most important feature, and type in a snip of code that will
test the feature exists. (TestDrivenDesign.)

Then type in the feature. Forget, at this point, any concept of Design, or
of drawing pictures of your design. Forget every feature you know the
program eventually must support except the one single feature you are typing
in. Sounds easy, huh? (YouArentGonnaNeedIt.)

When you go to the next feature, add a test for it, then add the feature.
Repeat. (ContinuousIntegration.)

As you do this, the code will get ... ugly. Detect ugliness by looking for
places where the code violates the "OnceAndOnlyOnce" rule. This means you
don't have the right kinds of abstractions. At this point, change the code
so it fixes the OAOO problem. As you do this you'l probably put in some
structure (AdapterPattern, etc.).

Chart your program's structure, as it emerges from the feature list, using
the UML you are learning. This means your UML is now proofed and known to
work. Easy, huh? (Reversed WaterFall.)

As you refactor code, the test you wrote (before _each_ feature) will
protect that feature. Without this simple safety net, you will eventually
generate code that can't be changed at all, and your project will die. (KentBeck.)

If you "train" your team, code and UnifiedModelingLanguage diagrams to always incrementally make the code better over time, it can live for ever. Easy.

> BTW the project has a tight schedule.

The system I listed preserves each feature as you add it. Therefore you know
the general rate at which the team adds features. This lets you know when
the project will end. (PlanningGame.)

You are trying to do all the UML up front, in a batch. _Nobody_ does it like
that, but the UML books often overlook this point. Big batches like this
will damage your schedule by obscuring the actual rate at which real
features can be added. Lots of UnitTest''''''s to lock down functionality are
more important, and easier. They will eventually support good design, which
then deserves to be drawn up in UML diagrams.

--PhlIp