[ Team LiB ]
Documents and Diagrams
Whenever I'm in a meeting discussing a software design, I can hardly
function without drawing on
a whiteboard or sketchpad. A good part of what I draw is UML diagrams, mostly class diagrams or
object-interactions.
Some people are naturally visual, and diagrams help people grasp certain kinds of information.
UML diagrams are pretty good at communicating relationships between objects, and they are fair
at showing interactions. But they do not convey the conceptual definitions of those objects. In a
meeting, I would flesh out those meanings in speech as I sketched the diagram, or they would
emerge in a dialog with other participants.
Simple, informal UML diagrams can anchor a discussion. Sketch a diagram of three to five objects
central
to the issue at hand, and everyone can stay focused. Everyone will share a view of the
relationships between the objects and, significantly, the objects' names. The spoken discussion can
be more effective with this aid. A diagram can be changed as people try different thought
experiments, and the sketch will take on some of the fluidity of spoken words, a true part of the
discussion. After all, UML
stands for Unified Modeling
Language
.
The trouble comes when people feel compelled to convey the whole model or design through UML.
A lot of object model diagrams are too complete and, simultaneously, leave too much out. They
are too complete because people feel they have to put all the objects that they are going to code
into a modeling tool. With all that detail, no one can see the forest for the trees.
Yet in spite of all that detail, the attributes and relationships are only half the story of an object
model. The behavior of those objects and the constraints on them are not so easily illustrated.
Object interaction diagrams can illustrate some tricky hotspots in the design, but the bulk of the
interactions can't be shown that way.
It is just too much work, both to create the diagrams and to
read them. And an interaction diagram can still only imply the purpose behind the model. To
include constraints and assertions, UML falls back on text, placed in little brackets, inserted into
the diagram.
The behavioral responsibilities of an object can be hinted at through operation names, and they
can be implicitly demonstrated with object interaction (or sequence) diagrams, but they cannot be
stated
. So, this task falls to supplemental text or conversation.
In other words, a UML diagram
cannot convey two of the most important aspects of a model: the meaning of the concepts it
represents, and what the objects are meant to do. This needn't trouble us, though, because
careful use of English (or Spanish, or whatever) can fill this role pretty well.
Nor is UML a very satisfying programming language. Every attempt I've seen to use the code-
generation capabilities of the modeling tools has been counterproductive. If you are constrained by
the capabilities of UML, you will often have to leave out the most crucial part of the model because
it is some rule that doesn't fit into a box-and-line diagram. And, of course,
a code generator
cannot make use of those textual annotations. If you do use some technology that allows
executable programs to be written in a UML-like diagramming language, then the UML diagram is
reduced to merely another way to view the program itself, and the very meaning of "model" is
lost. If you use UML as your implementation language, you will still need other means of
communicating the uncluttered model.
Diagrams are a means of communication and explanation, and they facilitate brainstorming. They
serve these ends best if they are minimal. Comprehensive diagrams of the entire object model fail
to
communicate or explain; they overwhelm the reader with detail and they lack meaning. This
leads us away from the all-encompassing object model diagram, or even the all-encompassing
database repository of UML. It leads us toward simplified diagrams of conceptually important parts
of the object model that are essential to understanding the design. The diagrams in this book are
typical of those I use on projects. They simplify, they explain, and they even incorporate a bit of
nonstandard notation when it clarifies their point. They show design constraints, but they are not
design specifications in every detail. They represent the skeletons of ideas.
The vital detail about the design is captured in the code
. A well-written implementation should be
transparent, revealing the model underlying it. (Making sure that this happens is the subject of the
next chapter and much of the rest of this book.) Supplemental diagrams and documents can guide
people's attention to the central points. Natural language discussion can fill in the nuances of
meaning. This is why I prefer to turn things inside out from the way a typical UML diagram handles
them. Rather than a diagram annotated with text, I write a text document illustrated with selective
and simplified diagrams.
Always remember that
the model is not the diagram
. The diagram's purpose is to help
communicate and explain the model. The code can serve as a repository of the details of the
design. Well-written Java is as expressive as UML in its way. Carefully selected and constructed
diagrams can serve to focus attention and aid navigation if they are not obscured by a compulsion
to represent the model or design completely.
Do'stlaringiz bilan baham: 
