Re: UMLish modellers?
Re: UMLish modellers?
- Subject: Re: UMLish modellers?
- From: "Erik M. Buck" <email@hidden>
- Date: Sun, 9 Sep 2001 16:08:08 -0500
I have used Rational Rose with Ada, C++, and even an Objective-C mode
created for the MCI research labs.
I have used Rational Rose on a few different projects over several years.
In one project, I lead a team of 11 people who were responsible for one part
of a large project that included 40-50 people at three sites. My team was
the "architecture team" which meant that we more or less controlled the
entire design as well as the implementation of core bits used by the other
teams.
We eventually stopped using Rose but continued to use UML. We thought that
it was just Rose/Apex/ClearCase that did not work well for us. It turned
out that the essential problem was premature design coupled with lack of
expressiveness in UML. UML is often harder to understand that the eventual
source code! The density of information is too low. If a programmer can
not discover the essential design features of a subsystem from a one-page
diagram, he is likely to just ask the designers and spend hours of his own
time as well as the designer's time. Rose produced 200-1000 page books of
useless diagrams.
UML encourages too much inappropriate detail at the expense of the big
picture. UML also encourages premature implementation decisions. For
example, even specifying one-to-many relationships in a design can be a
mistake. The implementers might discover that many one-to-one relationships
work better. The nature of the relationship can be a design decision or an
implementation decision, but UML/Rose demands that these decisions are made
in the design. UML and Rose also discourage iterative design since they
both almost require the water-fall model. It is so painful to revise and
existing UML design in a non-trivial way that people just let the UML get
out of date.
I should not have been surprised. I used to listen to Booch and Rumbach
lecture together and separately. They are both kooks IMHO.
Back to the real issue: UML and Rose are reasonable tools that may improve
one part of the development process. Unfortunately, the part that UML can
help is not the hard part. I doubt that it is possible to design a large
software system with UML if there is no complete rational specification for
the software system. In all of Computer Science history, there may have
been one or two software projects that had complete rational specifications
up front. To use UML for design, you must first live in the fantasy world
of complete rational specifications.
So what does work in my experience ?
We use the seminal Design Patterns book. We have named and described many
more patterns. Our top level design uses a short hand that names top level
sub-systems and suggests likely design patterns. Since I have control, I
insist that every module be well documented and the documentation is
automatically extracted. We gradually build a book of design and
implementation documentation. We do NOT keep documentation separate from
the code. If the documentation is separate, it will eventually not reflect
reality.
We iterate! We do not bite off more than we can design and explain in 5
pages or less during each iteration. We go through an iterative cycle that
can turn over once a day or once a year depending on the point in the
project life cycle. When new features are suggested/required, we write a
design that keeps nothing sacred. Any previous design decision can be
reconsidered. We sometimes throw out working code.
I also let programmers "show me". I often doubt the benefits of design and
implementation suggestions/decisions that other programmers make. Even when
I doubt, I will permit a programmer to spend several days of possibly wasted
effort. Sometimes the effort convinces the other programmer that I am
right. Sometimes I am convinced that I was wrong. In either case, the
several days of hacking is thrown out so that a proper designed and
documented version can be written. I think we must be willing to throw out
code.
Without a complete specification, we are forced to experiment to discover a
satisfactory product. The nature of experimentation is that sometimes the
experiments fail.
P.S. Even in the two or three historic instances of complete specifications
up front, not all requirements were known up front so the software built
according to the specifications was not acceptable in the end :(
----- Original Message -----