For years I have discussed the idea that modeling
doesn't occur in nice, neat phases. Instead of
spending time in the "Requirements Phase", then the
"Analysis Phase", then the "Design Phase" it is far more
common to iterate back and forth between these so-called
modeling activities. When you think about it,
these different phases are more a reflection of the
Tayloristic thinking of the early 1900s than it is
of effective software development.
Many people, particularly
generalizing specialists with a wide understanding
of development will hear a requirement, ask a few
questions to analyze what is actually needed, and then
proceed to designing it in their heads. This
typically occurs within a matter of minutes if not
seconds. Clearly the concept of modeling phases is
questionable, but I'm also beginning to wonder if the
idea of focusing on requirements, analysis, and even
design makes much sense these days. Perhaps we
should just talk about modeling in general, or perhaps
we should focus on other types of modeling instead.
Assume that we decide to focus on modeling, or better
yet agile modeling, in general. I think that it is
still valuable to consider requirements, which to me
should identify what our stakeholders want; analysis,
which investigates the details pertaining to the
requirements; and design, which focuses on identifying
how we intend to fulfill those requirements. Very
useful concepts, but not very useful phases.
Now let's take a different tack and try to identify
what concepts should replace the activities of
requirements, analysis, and design. One way that
we could do this is to take a bottom up approach by
potential modeling artifacts and identifying
categories which they belong to. Or we could take
a top-down approach and consider existing categories of
modeling prevalent within software development. Or
we could combine the two approaches, which is what I've
done, to identify the following categories of modeling
- Usage modeling. The focus of usage
modeling is to identify how people work with your
system. Potential artifacts include
essential use cases,
system use cases,
2 use case diagrams and
user stories. Usage modeling crosses the
boundary of traditional requirements and analysis, and
arguably even design, because when you model usage you
explore what users will do with the system as well as
how the system will support that usage (e.g. by
considering user interface and deployment decisions).
scenarios should also be considered.
- Process modeling. The goal of process
modeling is very similar to usage modeling in that it
is to explore how people work with the system, taking
into account the flow of the activities being
performed. The main difference is that usage modeling
techniques don't fully address the flow of artifacts,
including but not limited to information, within a
system whereas process models do. Potential
process models include
data flow diagrams (DFDs),
flow charts, and
2 activity diagrams.
- User interface (UI) modeling. UI
modeling can include UI requirement identification via
essential UI prototypes,
traditional prototyping, and/or
user interface flow modeling (storyboarding).
Usability issues are clearly an important concern
when developing the UI.
- Supplementary requirements modeling.
There is more to identifying what stakeholders need
than usage or UI modeling, hence the need for
supplementary artifacts which address these critical
details. For example many systems have complex
technical requirements and sometimes a requirement
is best identified via a simple
- Conceptual domain modeling. The goal
of conceptual domain modeling, sometimes simply called
either conceptual modeling or domain modeling, is to
identify the entities, their responsibilities, and
their relationships within your problem domain.
Potential models which you may want to consider
class responsibility collaborator (CRC) models,
logical data models (LDMs),
object role model (ORM) diagrams,
robustness diagrams, or
UML 2 class models.
- Architectural modeling. Architectural
modeling should focus on the high-level design of a
system or that of an enterprise as the case may be.
Although virtually any model can be used for
architectural modeling, I prefer models which can be
used to explore the general landscape of your efforts.
network diagrams. A supporting model are
change cases, a form of architectural requirement
which enables you to explore potential requirements.
- Dynamic design modeling. The goal of
dynamic design modeling is to explore the behavioral
aspects of an object system. UML interaction
diagrams -- including
composite structure diagrams,
interaction overview diagrams, and
sequence diagrams -- can be used as can
state machine diagrams and
UML 2 timing diagrams.
- Structural design modeling. Structural
design modeling, using
2 class diagrams,
object diagrams, and/or
physical data models (PDMs).
My experience is that it is better
to consider modeling categories instead of modeling
phases/disciplines. Figure 1
depicts this idea, showing the eight different modeling
categories described above and listing potential models
within each category.
Figure 1. Iterative
It's interesting to observe that this is very similar
conceptually to Phillipe Kruchten's 4+1 View of
Modeling, albeit one with eight views instead of five.
These categories are also similar to the six columns of
Zachman Framework (ZF), arguably a different take on
the same basic idea. Although I would like to say
that you should simply pick one model per category it's
not that simple. Here's my advice:
- You need one or more models from the usage and
process modeling categories. This choice
will often be driven by your chosen software process,
following either the Rational Unified Process (RUP) or
Enterprise Unified Process (EUP) you will need use
case artifacts, with Extreme Programming (XP) user
stories, and with a structured analysis and design
approach data flow diagrams (DFDs). It is also
quite common to use process models to analyze the
information contained in usage models.
- Create user interface models as needed.
Some systems are UI intense whereas others are not,
some developers prefer to start with essential
models whereas others prefer to go straight to
prototyping or even development of the actual source
code itself. As always,
Apply The Right Artifact(s).
- Model supplementary requirements as appropriate.
I'm a firm believer in using each type of model for
what it's good at and for recording information in one
place only. Supplemental requirements such as
business rules and technical requirements can and
should be referred to within other development
artifacts such as use cases, class models, and source
- Create one type of conceptual domain model.
You need to understand the business domain, and
conceptual domain models are very good at that. Pick
one model that best meets your needs.
- Create architectural, dynamic design, and
structural design models as needed. You
often need several views of your architecture, so
create the model(s) that reflect your situation.
Similarly you are likely to discover that you need one
or more dynamic design models from time to time,
sequence diagrams are a popular choice as are state
machine diagrams. Structural design diagrams are
often the mainstay of modeling as they are very close
to object code as well as data schemas.
|So how do these categories change the development
landscape? First, I believe that they make the
complexity of modern software development more explicit.
These categories focus on the high-level issues that you
should consider modeling, instead of modeling phases,
and as a result provide better guidance to developers.
Second, they provide insight into the types of models
that you should create.
Figure 2 maps the modeling categories to individual
modeling techniques, indicating which techniques are
inclusive and which are complex. Inclusive
techniques use simple tools (paper, whiteboards,...) and
are simple in and of themselves (and are therefore easy
to learn). I call these techniques inclusive
because they are simple enough that stakeholders can use
them, thus enabling the practice
Active Stakeholder Participation.
Figure 2. Inclusive to complex
during "Iteration 0"
envisioning is to understand at a high level what
is. The other activities -
The Agile Model Driven
Development (AMDD) lifecycle for
It's fair to ask what impediments exist to
implementing this vision. The first impediment is
the prevailing culture within the IT industry. For
years we've been told that the modeling phases reflect
how development occurs but it never really seemed to
ring true with many developers, people who often threw
out the "modeling baby" with the "phases bath water"
when they abandoned the idea of serial development.
The second impediment is existing IT specialists.
There are many people who identify themselves as
requirements analysts, architects, object designers, or
database designers, all jobs which reflect "phasist
thinking". It would be far more effective if
people could identify themselves as the more general
concept of modelers or better yet simply as developers
who happen to have solid modeling skills.
One person's design element is another person's requirement.
In short, I'm simply not convinced that the modeling
phases of requirements, analysis, and design make sense
any more. Nor, in the case of the various flavors
of the Unified Process, do they make sense as
disciplines. We need to rethink our approach to
modeling within the IT industry, and my experience is
that the categories which I have described above are far
more realistic of an approach. Think about it.
Parts of this article have been excerpted from
The Object Primer 3rd Edition: Agile Modeling Driven
Development with UML 2.