|
One of the most commonly asked questions asked by developers
is “What tool(s) should we use?”
Although there are as many answers to this question as people asking it,
I would like to provide a few words of advice to help guide you: “Use the
simplest tools possible.” Why simple
tools? Simple tools are easy to learn,
easy to use, and very often easy to share with others. Yes, complex tools have their place,
assuming they provide the best value for your investment in them, but never
underestimate the effectiveness of simple tools either.
Some simple tools for modeling:
- Index cards. The eXtreme Programming (XP) community
swears by the use of standard index cards for a wide variety of modeling
techniques, and in particular
Class Responsibility Collaborator (CRC)
modeling.
- Post-It notes. Post-It notes are also an
option for you, for example you can develop an
abstract/essential user interface
prototype using Post-Its on large sheets of paper. This is part of a technique called essential user interface
modeling, described in
Software
For Use by Larry Constantine and Lucy Lockwood or my own
The Object Primer
3/e.
- Paper. Pieces of paper, or index cards, tacked
onto a whiteboard and connected by strings can be used for a wide variety of
models. For example the individual
sheets of paper can represent database tables and the lines relationships
between tables on a physical data model, or the sheets can represent screens
and the strings navigation flows between screens on a user interface flow
diagram, or the sheets can represent use cases and actors and the strings
represent associations between them on a UML use case diagram.
- Plain old whiteboards (POWs). A
whiteboard for sketching on
is likely the most common modeling tool in use.
A digital camera
can easily make copies of sketches that you want to keep.
Why simple tools for modeling? I always advise that you should ask yourself why you are
modeling, my philosophy being that you should develop something with an exact
purpose in mind otherwise you shouldn’t develop.
If you are modeling to understand something then the value isn’t
in the model that you create but in the modeling itself. Therefore, you don’t need to invest
significant effort using a CASE tool to make your model look pretty, or to add
comprehensive documentation to it.
Instead you’re better off using a simple tool, such as index cards or a
whiteboard, to enable you to get your modeling done quickly so you can get back
to developing software. More importantly, when you also
adopt simple techniques you discover that your
models are inclusive for your stakeholders, enabling
active stakeholder participation.
When should you use simple tools? My rule of thumb is that the greater the amount of uncertainty
surrounding the issue that you are modeling the greater the flexibility you
will want in your tools, therefore the simpler your tools need to be. As you gain a greater understanding of an
issue you can migrate to more complicated tools as required, assuming that the
tools provide the best value possible for your investment in their usage,
typically starting with manual tools such as index cards or white boards and
eventually moving to a design CASE tool or programming IDE.
For example, when I am first exploring how I intend to build
a screen I will often use Post-It notes, sticking them to the nearest flat
surface (a desktop, a whiteboard, …) that I can find. Post-Its are easy to work with, you can write brief descriptions
on them or little sketches, and easy to move around. Furthermore they stay where you put them because of the glue on
their backside. Post-Its are great at
the beginning of screen design because you can get a feel for the layout very
quickly, adding and removing widgets quickly.
Once I’m happy with the layout I’ll either move straight to
coding the screen or to the whiteboard.
I base this decision on my initial purpose for developing the screen
layout model in the first place. If my
goal was to simply get a strategy for organizing the major widgets that will
make up the screen then I’ve very likely satisfied that purpose and can
therefore move on. If my goal is to
determine how I will organize the screen and to identify the widgets that I
intend to use then I will very likely move to a whiteboard first. With a whiteboard I can draw the widgets with
greater accuracy, drawing them to their relative size as reasonable facsimiles
of the actual type of widget (check box, single-line entry field, multiple-line
entry field, …). However, whiteboards
aren’t as flexible as Post-Its – if I discover that I need to move several
widgets then I may have a lot of erasing and redrawing with a whiteboard,
whereas with Post-Its I simply move them around. The observation is that I the gain in fidelity by moving to a
whiteboard was counter-acted by a loss in agility.
Once I’m happy with the whiteboard drawing the purpose for
developing the model would once again determine my next step. If I was simply modeling to understand the
design of the screen then I would go straight to code. However, if I was modeling to communicate,
perhaps my organization’s process insists on the development of detailed screen
specifications before any coding can begin (clearly not a very agile process)
then that would be my next step.
Actually my next step would very like to be to fight this tooth and
nail, but fighting the bureaucrats within your organization is another issue
entirely. If I am forced to create
comprehensive documentation I’ll likely use a CASE tool that specializes in the
type of documentation that I’m trying to create, in this case a screen
specification. As an aside, an
important lesson to take away from this discussion is that models are not
necessarily documents – I would consider both the Post-It notes and the
whiteboard sketches to be models, likely ones I will discard.
Why not jump straight to code? First, code isn’t as flexible as either Post-Its or whiteboard
sketches, I can’t move things around as easily as I can with Post-It notes and
I very likely can’t change widget types as easily as I can sketch. In short, I suspect that a few minutes
working with Post-It notes and possible drawing some sketches will very likely
pay for itself several times over in saved coding time. Second, Post-Its and sketches are more
inclusive than code, non-developers such as my direct users can become actively
involved with the effort which makes a lot of sense to me because we’re working
on something they can directly relate to (the user interface).
On
the surface it is easy to assume that if you're an agile modeler that you
aren't going to use a CASE tool. Poppycock! An agile modeler uses a
tool, any tool, when that tool makes the most sense for that situation.
Just like a carpenter will use a manual screwdriver sometimes and other
times a electric screwdriver, sometimes an agile modeler will use an index card
and other times a complex software design tool.
Any tool, including Computer Aided System Engineering (CASE)
tools, should be used only when it is the option that provides the maximal value
for your investment in it. This is
basic investment theory – if you can invest your money one way and get a 10%
overall return, or you can invest your money another way and get a 15% overall
return, everything else being equal you’re better off with the second
investment. With respect to modeling
tools, you always have several choices: use simple tools such as index cards
and white boards, use a diagramming tool such as Microsoft Visio, or a more
complicated tool such as Compuware's OptimalJ, Borland’s Together, Rational
System Architect, or Computer
Associate’s ERWin.
So how do you calculate the expected value for your
investment in a tool? I suggest that
you don’t, at least not from in strict accounting sense of the idea. Yes, you could prepare a complex spreadsheet
listing all the costs, both quantitative costs that have a clear dollar value
and qualitative costs that need to be fudged into a dollar value, and then
compare them with the expected benefits, both quantitative and
qualitative. You’d naturally have to
calculate the net present value (NPV) of all of those figures to ensure that
you’re comparing apples to apples. I’ve
got a pretty good write-up of how to do all this in my book Process Patterns if
you’re really interested, but I highly suggest against this sort of lengthy
analysis. Why? Because it’s a lot of work that is more
often than not a façade used to justify a political decision anyway. |
 |
- Initial
training and education
- Evaluation
costs
- Maintenance
of the model over time (it’s even worse when the model has outlasted its
usefulness but you’re still maintaining it for posterity)
- Upgrade
costs of the tool
- Ongoing
usage/maintenance fees
- Time
lost waiting for the tool to do its job
- Time
lost over-using the tool (e.g. making your diagrams look pretty,
extraneous information, and so on)
- Migration
costs to port models to another tool
- Increased
effort to synchronize models with other artifacts, such as source code
- CASE
tools often promote syntax over communication between developers (in other
words, your model looks good but doesn’t necessarily work)
- Generated
code often too simplistic, or cluttered with extraneous information
required by the tool
- Poor
user interfaces often hamper the modeling effort
- Inadequate
integration with other tools reduces productivity and/or requires
integration work
- Complex
tools are often prevent the inclusion of non-developers in your modeling
efforts
- Forward
engineering (code generation)
- Reverse
engineering of existing code
- Support
for changing levels of abstraction (e.g. from requirements to analysis to
design to code)
- Testing
of the consistency and validity of your models
- Synchronization
of models with delivered code
- Support
for different views and/or potential solutions to a problem
- Generation
of documentation
The principle
Model With
a Purpose tells you that you should know why you are creating an
artifact. Knowing the purpose for an
artifact indicates the extent of the work that you need to perform to complete
your model, you stop as soon as your model fulfills its purpose, and this in
turn provides insight into what you require of your tools. By knowing your actual requirements you can
then determine whether a given tool will actually provide the most value for
your situation. My experience is that a
gut-feel approach to choosing your tools is often the most effective approach,
albeit one that senior management may not trust you to take.
Furthermore, you should know the features of the tools that you are using, and the
practice
Use the Simplest Tools tells you to select the most simple tool (even if
it’s a CASE tool) that will do the job.
Consider some examples:
- You
are modeling simply to explore the potential structure of several Java
classes. You clearly need a tool
that supports class diagramming and perhaps supports generation of Java
code. My two best options would
likely be a whiteboard, I would sketch the classes and then proceed to
write code, or Together/J, I would use the tool to diagram the classes and
then generate the code from the diagram.
My deciding factor would be how well I know Together/J and how
likely is it that I would need to work with the tool in the future – If I
know the tool well or it was likely that I would be doing enough Java
development in the future to warrant my learning the tool, then Together/J
would be a good choice for me because one of its primary strength is its
support for Java developers.
- You
are developing the table structure for a database. Yes, you could choose to sketch the
schema on a whiteboard and then start coding the data definition language
(DDL) code to create those tables, and the procedural code for any
triggers, but that’s a lot of work.
Several CASE tools exist, Computer Associate’s ERWin is one, that
supports the ability to generate the DDL and triggers automatically from a
data model. Once again, the
deciding factors are skill with the tool and whether it is worth the
investment to learn the tool.
- Your
organization has won a bid to identify and document the requirements for a
system, with the hope that you will win the next stage of the project (the
actual development itself).
Ignoring the dysfunctional aspects of the serial nature of this
project, the reality is that many projects, particularly those for the
U.S. Federal Government, work this way.
In this situation I would be tempted to use a variety of tools – a
Word Processor for textual information, a tool that supports creation of
use case diagrams (Visio, PowerPoint, Rational Rose), and perhaps even a
tool to manage the requirements (Requisite Pro or DOORS).
4. What Modeling Tools
Are
Agilists
Using In
Practice?
In my
Agile Adoption Rate survey
in March 2007 I asked about the
effectiveness of various
approaches to modeling was on
agile teams. The results
is summarized in the histogram
of Figure 1.
As you can see, Agilists do in
fact model in practice, and that
inclusive tools such as
whiteboards and paper seem very
popular. It's interesting
to note that CASE tools are also
in use, although only 68% of the
teams doing so find them useful
in practice. Furthermore,
I suspect that drawing tools
such as Visio are being lumped
into the CASE tool category.
Figure 1.
Adoption Rates of Modeling on
Agile Teams.
The
DDJ 2008
Modeling
and
Documentation
survey
explored
how
people
approach
modeling
and
documentation.
Figure 2
summarizes
the
results
of the
question
that
looked
into the
primary
approach
to
modeling,
and
regardless
of
development
paradigm
sketching
was the
most
common
approach
to
modeling
(SBMT =
Software
Based
Modeling
Tool, my
term for
CASE).
Figure 2.
Primary
approaches
to
modeling.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
