Re: UMLish Modellers
Re: UMLish Modellers
- Subject: Re: UMLish Modellers
- From: Simon Stapleton <email@hidden>
- Date: Mon, 10 Sep 2001 11:20:40 +0100 (BST)
>
From: "Erik M. Buck" <email@hidden>
>
To: "developers" <email@hidden>,
>
<email@hidden>
>
Subject: Re: UMLish modellers?
>
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.
Woot!
>
I have used Rational Rose on a few different projects over several
>
years.
Ditto, since approximately 1996. Before that, years of business
analysis and data modelling work.
<snip>
>
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.
This I can agree with (almost) wholeheartedly. If you rely on UML
alone to express a design, you're blown out of the water from day
one. Many of the diagrams produced by Rose are useless, and convey
little or no information to the designer, implementor, or eventual
end-user. I've sat in design reviews where analysts have had to
explain the basics of what the models mean and how one little box (or
fluffy cloud) relates to another in terms the users can understand.
Needless to say, such reviews were usually hopeless cases.
>
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.
The same can be said of many methodologies. For a case in point,
look at IEF - loads of pretty diagrams, and in most cases they are
out of date before the (highly expensive) A0 plotter has finished
churning them out. It's very expensive to keep diagrams current (and
don't even mention round-trip-engineering : Even if reverse-
engineering the code works to produce a model, it takes longer to
reorganise and prune the diagrams to a usable state than it would
have done to completely regenerate them.)
<snip>
>
Back to the real issue: UML and Rose are reasonable tools that may
>
improve one part of the development process.
That is definitely the case, and I think they may well be useful in
several places. Just not as a 'one tool fixes every problem magic
bullet'.
>
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.
Modelling in general _can_ help, both at the design and
implementation stage. But I don't believe in one overall model of
the whole thing. I just don't believe that's possible.
>
>
So what does work in my experience ?
>
>
We use the seminal Design Patterns book. We have named and
>
described many more patterns.
Same here. Everybody should use this book. If you don't own a copy,
but have software engineering as a career, stop reading _now_ and buy
one.
>
Our top level design uses a
>
short hand that names top level sub-systems and suggests likely
>
design patterns.
A high-level model, no?
>
Since I have control, I insist that every module
>
be well documented and the documentation is automatically tracted.
>
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.
This makes enormous amounts of sense. POD type documentation can
help with this.
There is a cost involved, however. When the semantics of a method
change, the developer must always remember to keep the documentation
up to date.
>
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.
Again, good sense. How many times have I seen systems where whole
chunks of code are left well alone because 'it works', even though it
means enormous work-arounds in the rest of the system to keep it
working? Requirements change over time. This means that code
changes over time. It also means that, from time to time, high level
designs change. Deal with it.
>
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.
You're preaching to the converted here. I have personally been
responsible for the cancellation of more than one >#1m projects where
it became obvious that they would never deliver their projected
benefits. In all cases, these were replacement systems, and the
existing systems were sucessfully modified to carry out the
functionality required. One of these systems had been in development
for more than 3 years (>15 man-years of effort), yet the new
functionality was implemented in the previous system in less than 2
man-months.
>
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 :(
This is all too often the case.
So, given that I inadvertantly kicked this little thread off, where
_do_ I think modellers work?
* Requirements capture
For requirements capture, 'depends on' and 'subclass of' type
relationships can be very useful, and a web-type model can be
very useful for identifying redundant or contradictory
requirements.
* Data modelling
In the world of hierarchical databases, ERD diagramming is very
useful. Nuff said.
* High level design.
Although it's often slower to model a high level design on the
machine than on paper / back of a fag packet, it's more
controllable. At a high level, there is no unnecessary detail
and the design can be encapsulated in one or two sheets (no bigger
than A3, please ;-) I've seen 'high level' designs that could be
used to wallpaper the average house. They didn't work.
* Low level (implementation) design.
Totally divorced from the higher level, and used primarily for
sketching out class hierarchies. Also useful (on small projects)
for generating skeleton code. I personally waste far too much time
coding accessors and mutators. If tools understood low-level (i.e.
singleton, class cluster) patterns properly, this could also be
very useful.
Although this is usually slower than using the index-card method,
index cards don't generate accessors and mutators.
I'm currently working (at work) on a project that relies on Rose -
part of our codebase is mechanically generated from a rose based
model - The model has to be kept up to date or the project won't
compile - but the generated code is _never_ touched by human hand,
merely subclassed. This works extremely well, although you have to
implicitly trust the generated code.
<obCocoaDev>
Although I had a bit of a duff weekend, having spent most of it
dialled into the works machines keeping stuff running, I have
progressed my modeller project somewhat. It now scans for plugins,
populates palettes depending on what's supported by the various
plugins, lets you drag & drop stuff from palettes into models, etc
etc. I'll try to have an alpha release out sometime this week.
This tool will deliberately NOT implement full UML. In fact, as it
stands, it doesn't implement anything. It's intended for doing the
mechanical generation bits, although I haven't got any of that coded
yet ;-)
On the other hand, it's totally extensible, so if someone wanted to
clone Rose in a plugin, they could...
I modelled the tool using index cards, a pinboard, and pins. (grin)
</obCocoaDev>
Simon
--
If the answer isn't obvious, the question is a distraction. Go find
an easier question.