Models
are
useful as tools of discovery. The process of creating a model is just
as important as the model itself, often more. When you are unsure about
how to proceed you can model to get your direction. When
confronted with code that defies understanding modeling can
help. Models include flowcharts, class diagrams, interaction diagrams,
UI
mock ups, etc. There are many different model types well suited to
learning new things about your project.
Models
can become very anti-agile if you let them. Don't think of
models like a photograph, instead consider them like a painting. Above
is a photograph of the night sky. It correctly notes the position and
size of all the stars. Above right is a Van Gogh painting of the night
sky. The artist is communicating something important about the
sky. Van Gogh is telling us his impression of what a night sky means.
This is exactly how you want to approach modeling.
"If
you understand
your painting beforehand, you might as
well not paint it." Salvador
Dali could just as easily have been talking about Agile models.
Create them to understand. Printing huge models generated by a
tool from code is another way to view your code but it isn't
an Agile model. A painting of your code that highlights important
objects and interactions for a specific operation or process step is an
Agile model.
The
best modeling tools are an old fashioned fountain pen and an artist's
blank sketch book with pages that pull out. These simple tools let each
model be unique with a language of its own. Some things will be
exaggerated, others omitted. A model should express the modeler's
|
thoughts and subjective point
of view. So be creative, use a drop
shadow to indicate more important objects, put a shinning star
on newly created objects, try drawing little stacks to
show collections. UML was created to document complexity, not
expose it. Instead of the typical
class hierarchy diagram try an instance diagram to find complexity.
Don't let conventions stop
you from communicating your thoughts rather than details.
Don't
spend time getting everything just right. You certainly don't want to
spend time getting all the lines straight. When modeling ask yourself a
simple question: How much effort should I put into this model if it
will be thrown away tomorrow? That is how you know when you are done
modeling.
CRC
cards can be used two different ways. Originally a card would have
class name, responsibilities, and collaborations. The second way is
more Agile. Get your team together and use cards as instances instead
of classes. Move the cards around with your hands to show messages and
interactions. Stack them to show collections. Overlap them to show
collaborations.
Designing this way uses the artistic right side of your brain, the side
that understands relationships and
movement. You will find that you don't need to label more than a few
cards to tell them apart.
Sometimes
the
activity of modeling can be more important than the
model. Agile
CRC cards are an expression of that. You model together as a team. At
the
end the model disappears but the understanding, insight, and team
collaboration remains. Designing this way is more
dynamic and object oriented than static versions.
|
Create
a model to answer specific questions, keep the answer short and
concise. If you think others could learn from your model you can keep
the document, but make it Agile. Saving a document
is an implicit agreement to keep it up to date or destroy it. Restrict
documents to one page and post them on a wall. Then you can
easily update them by finding all the old versions and replacing them
with the new edition.
If you decide to destroy it, just pull down all the obsolete
pages and
throw them out.
Depending
on your project you may also need some larger documents for
validation or standards compliance. Those are not Agile documents but
need to be
created and archived anyway. Don't use your Agile process as an
argument to avoid creating them. Create them just-in-time and as
efficiently as possible.
Having
a model printed out with straight lines and square corners in a
specially labeled binder does not mean you have a good design, it just
means you have a well documented one. I have found that a huge
UML document is an excellent way to hide a complex design. Agile modeling can help discover
areas of complexity and eliminate them. You can use tools that create
diagrams as an alternative to browsing source code, but not as an
alternative to Agile modeling.
|