|
Contrary to what the computer aided system
engineering (CASE) proponents may tell you,
there is a wide range of modeling approaches
which you can take on a software development
project, some of which involves software-based
modeling tools but other which involve simpler
tools such as paper or
whiteboards.
Agile modelers
use the simplest tools for the job, and
sometimes that's a whiteboard, sometimes that's
a unit regression testing tool, and sometimes
that's a complex modeling tool. This
article, overviewed in Figure
1, compares the
various approaches
to modeling, mapping the four common
modeling paradigms
(MDA, Software Factories, AMDD, and Agile MDA)
to these approaches, and estimates the
rate of adoption for
each modeling approach.
Figure 1.
Comparing the various approaches
to modeling.

| |
|
Throughout
this article I
use the term
CASE (computer
aided
system/software
engineering)
tool to indicate
software-based
modeling tools.
CASE as a term
has gone out of
favor in recent
years because
the CASE tool
vendors have
realized that
the term has far
too many
negative
connotations for
those of us who
were around for
the integrated
CASE (I-CASE)
debacle of the
late 1980s.
Many vendors
prefer the term
"modeling tool"
over the term
CASE because it
doesn't have the
negative
connotation and
because it has
the side effect
that many
developers have
been brainwashed
to think that in
order to
"officially
model" you need
a software-based
modeling tool.
The fact, as I
will show in
this article, is
that the vast
majority of
developers do in
fact model but
that they use
simple/inclusive
tools such as
whiteboards
and paper to do
so. |
|
|
Figure
1 compares the following approaches to
modeling software-based systems:
- No modeling.
Basically, you're not doing
any of the other things in
this list. A serious
problem in the IT industry
is that too many people
think that just because they
aren't using a CASE tool
that they're not modeling.
- Discussion.
When you are discussing a
problem, either in the
problem domain or the
solution domain, you're
effectively modeling it in
your head as you talk about
it. The important
thing is that you are
thinking the issue through
before you code the
solution, therefore you're
still modeling albeit in a
very low fidelity manner.
- Sketching/Paper.
I believe that the vast
majority of visual modeling
is done by hand using
simple/inclusive
tools such as
whiteboards
or paper (see
Figure 1
for some survey findings).
Furthermore, I also believe
that the real thinking is
often done in such modeling
sessions, and that drawing
and CASE tools are simply
used for documentation and
detailing purposes.
The
sketching approach to
modeling should be taken
just as seriously as the
blueprint form of
modeling, yet it always
seems to get short shrift in
the literature (it's fairly
hard to find modeling books
with hand-drawn sketches in
them, even though the
authors are usually willing
to admit that they do a lot
of sketching in their
modeling practices).
- Test Driven Design
(TDD). With a
TDD approach you create
a test then write enough
production code to fulfill
that test. In other
words, the tests form your
detailed design model (as
executable specifications),
arguably making TDD a
modeling approach.
- Drawing Tools.
Many people use drawing
tools such as Visio, or
perhaps even PowerPoint, to
draw technical diagrams.
For the most part these
tools are used to draw
pretty pictures, which can
be important, for
documentation and/or
presentation purposes.
- Documentation CASE.
CASE tools that can only be
used for documentation
purposes. These tools
are often called front end
CASE, logical CASE, platform
independent CASE, or
enterprise CASE.
Although you can draw and
capture information with
documentation CASE tools,
you cannot generate working
software (or source code
from which you could then
create working software)
from them.
- Generative CASE.
CASE tools that are "close
to the metal" and can both
engineer and reverse
engineer source code and/or
working software.
- Integrated CASE.
Simply put: documentation
CASE + generative CASE.
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).
Figure 2.
Primary approaches to modeling.

The right hand side of
Figure 1
presents the following
modeling paradigms:
- Model Driven
Architecture (MDA).
The
MDA is based on the
idea that a system or
component can be modeled
via two categories of
models: Platform
Independent Models (PIMs)
and Platform Specific
Models (PSMs). PIMs are
further divided into
Computation Independent
Business Models (CIBMs)
and Platform Independent
Component Models (PICMs).
As the name implies PIMs
do not take
technology-specific
considerations into
account, a concept that
is equivalent to logical
models in the structured
methodologies and to
essential models within
usage-centered
techniques. The CIBMs
represent the business
requirements and
processes that the
system or component
supports and the PICMs
are used to model the
logical business
components, also called
domain components. PSMs
bring technology issues
into account and are
effectively
transformations of PIMs
to reflect
platform-specific
considerations.
- Software
Factories.
Software factories
is a paradigm for
automating software
development that
integrates these
advances to increase
agility, productivity,
and predictability
across the software life
cycle. A software
factory schema is a
graph of viewpoints used
to separate concerns,
relating work done at
one level of
abstraction, in one part
of a system, or in one
phase of the life cycle,
to work done at other
levels, or in other
parts and phases, and
about how the schema can
be used to deliver
guidance and to support
its enactment through
model transformation,
constraint checking and
other techniques.
- Agile Model
Driven Development
(AMDD). As the name
implies,
AMDD is the agile
version of Model Driven
Development (MDD). MDD
is an approach to
software development
where extensive models
are created before
source code is
written. The difference
with AMDD is that
instead of creating
extensive models before
writing source code you
instead create agile
models which are
just barely good enough.
With AMDD there is an
initial envisioning/modeling
activity during
iteration 0 where you do
initial requirements
modeling and
initial
architecture modeling.
Then, during development
cycles/iterations, you
model storm on a
just-in-time (JIT)
basis.
- Agile MDA.
With
an agile approach to MDA
you still have the PIM
and PSM modeling
efforts, but you also
have
inclusive modeling
using simple tools to
enable effective
interaction with your
project stakeholders.
Furthermore, an agile
approach enhances the
MDA with a
comprehensive testing
effort.
It's interesting to
see how well each
modeling paradigm does
when compared to the
various modeling
techniques.
Traditional MDA and
Software Factories are
the most narrowly
focused, requiring
sophisticated tooling
for them to work.
From a modeling point of
view they are very
similar: first, the MDA
is
UML-based whereas
the software factories
approach employs smaller
domain specific models (DSMs);
second, the software
factories approach seems
closer to the metal than
does the UML, likely a
reflection of the
practical nature of
Microsoft compared to
the far more theoretical
nature of the OMG.
AMDD is the most
expressive of the four
modeling paradigms,
being applicable to
every modeling approach
except TDD (TDD was
purposefully left out of
scope for AMDD).
Agile MDA also fairs
well, which makes sense
because it adopts the
best of breed from the
MDA, AMDD, and TDD.
|
|