Unified Modeling Language (UML) defines the industry
standard notation and semantics for properly applying
that notation for software built using object-oriented
(OO) or component-based technology.
In fact it is difficult to find modeling books or
tools that do not use the UML these days.
The UML provides a common and consistent notation
with which to describe OO and component software
systems, decreasing the learning curve for developers
because they only need to learn the one modeling
language (in theory at least).
The UML is clearly a step in the right direction,
we are no longer fighting the “notation wars” of the
mid-1990s, it isn’t perfect.
In this article I argue that the UML as it stands
today is not sufficient for the development of business
software and that the vision of Executable UML
a little (okay, a lot) ahead of its time.
principle tells you that you need to have many modeling
techniques in your intellectual toolkit if you want to
be effective as a developer.
The article Artifacts
for AM presents an overview of many common modeling
artifacts, including but not limited to those of the
Unified Modeling Language (UML), and as you can see
there is a wide selection of models available to you.
Each model has its strengths and weaknesses,
therefore no single model is sufficient for all of your
software development needs.
Although the UML is in fact quite robust, the
reality is that it isn’t sufficient for your modeling
example, when I design the user interface of an
application I generally like to create a user interface
flow diagram, an example of which is shown in Figure
diagram enables my team to explore how users will
interact with the system from a birds-eye view, and thus
ask very important usability questions long before
we’ve built the user interface.
Unfortunately the UML currently doesn’t include
such a diagram yet, and it may never include one, so if
you limit your modeling repertoire to the artifacts
defined by the UML you forgo the potential productivity
enhancements of this technique.
Similarly it is quite common for business
application developers to create data models
representing the physical design of their database yet
the UML does not yet have this sort of model either – I
have shown how to include data modeling into object
development efforts. A new UML
Profile for Physical Data Modeling is published at www.agiledata.org
(the good news is that in December 2005 the OMG
for data-oriented models).
A diagram representing navigational flow within a
Although the UML defines an
important collection of models, I highly suggest
adopting them in accordance with the practice
Modeling Standards, the reality is that the UML has
narrowed the range of discussion within the modeling
sometimes it is possible to use
UML diagrams in
situations for which they really weren’t intended, for
example it is quite common to use
UML Activity diagrams
to model business processes as you see in Figure
2, this often proves less than ideal. Although there is a very good effort for business rule modeling, the
very earliest we'll see this is in UML 2.1 IMHO (In
February 2006 the OMG officially adopted the
BPMN, which I suspect
is the first step to inclusion in the UML).
A business process depicted with a UML Activity
Similarly, the UML does not yet
provide a standard way of modeling web service "wiring
diagrams" nor does it say anything about security threat
my opinion the UML is not sufficient for the needs of
business application development, although it is an
important part of the overall picture.
Even the RUP,
which comes from the same organization that first
proposed the UML, explicitly includes non-UML artifacts
such as business rules, data models, and user interface
My suggestion is to use the UML as a base
collection of modeling techniques which you then
supplement with other techniques to meet your
project’s unique needs.
Furthermore, I wouldn’t replace the UML with
other artifacts, although I am convinced that my own
class modeling notation (The Object Primer 1st Edition,
1995) is superior to
that of the UML’s the reality is that my notation
isn’t in common use and therefore by using it I would
make my diagrams difficult for others to understand and
thus reduce communication on my project team.
Ever wish you could draw a few
diagrams, press a button, and have a working software
system that meets your needs? Sound like magic? Perhaps,
but that’s a major part of the Executable UML vision. The
basic idea is that you will use a CASE tool to develop
detailed UML diagrams and then supplement them by
specifications written in a formal language, presumably
the OMG’s Object Constraint Language (OCL).
The basic idea behind Executable UML is that systems can be
modeled at a
higher level of abstraction than source code, simulated
to support validation of your efforts, and then
translated into efficient code.
This higher-level of abstraction should help to
avoid premature design, enable you to change your system
as your requirements evolve, and to delay implementation
decisions until the last minute. In my opinion this sounds great in theory, but unfortunately
there are several problems to making this work in
UML isn’t sufficient.
The UML is clearly not sufficient for
business application development, as I argue above,
so trying to generate a system only from UML models
at the present moment simply won’t suffice. The
implication is that tool vendors will need to add
their own proprietary extensions to the UML to make
this work, which is exactly what existing tool
vendors are doing. This is no longer
executable UML anymore, it's executable models, and
more appropriately we should be talking about
executable modeling (xModeling) instead.
Integrating a collection of
tools to support Executable UML is currently difficult.
Let’s assume that one or more tool vendors
decide to implement the Executable UML vision and fill in the
gaping holes inherent in the UML.
How would they make it work?
Ideally, some companies would focus strictly
on building a good modeling tool and others focus on
taking the output from those tools to produce a
working executable on a given platform.
Some vendors would produce plug-ins for J2EE
environments, others for .NET environments, and
others yet for mainframe environments.
To support this we would need a common
standard for sharing information between tools, the
OMG’s XML Metadata Interchange (XMI) standard
comes to mind, although because XMI is based on the
OMG’s UML and Common Warehouse Metamodel (CWM) on
its own it isn’t yet sufficient for fully
specifying software from end-to-end.
Although the CWM provides insight for
specifying persistence-related information we still
need to specify other aspects of a system, such as
its user interface. Because there isn’t a complete standard in place the
various vendors will to add their own unique
extensions making multi-vendor tool integration
A single vendor approach
will likely prove too narrow.
Another approach would be for a tool vendor
to support both modeling and code generation
features in their tool, something perfectly
reasonable in theory.
But, because of the wide range of platforms,
and range of design options within those platforms,
the tool vendors will need to focus on a single
one vendor will specialize in generating J2EE
development supporting Java Server Pages (JSPs),
servlets, Enterprise JavaBeans (EJBs), and
Perhaps another will specialize in generating
Java-based fat-client applications whereas another
generates a Win32 fat client application.
The implication is that organizations that
develop for several platforms will need several
major development tools, tools that must be
purchased and supported often at great expense.
Furthermore, the wide range of required
functionality of such a tool makes it difficult for
vendors to specialize and focus on a single aspect
of the Executable UML vision, likely resulting in slower
improvement in the overall development environment.
I have no doubt that we will begin
to see some interesting tools emerge over the next few
years based on the Executable UML vision. In
fact, several CASE tool vendors do this now in specific
niches and are doing quite well., But I suspect that this
vision will fall just as short as other similar visions
have done in the past – we will always need
such a tool be agile?
If it is possible to build a tool that is easy to
use, that generates software that is sufficient for your
environment, and that provides better value for your
investment (in accordance to the principle
maximize stakeholder ROI) than does other approaches
to development then I would have to say yes.
Do I expect to see any tool that meets these
requirements anytime soon?
my experiences in the 1980s when CASE tool vendors
bombarded the IT industry with similar promises has made
me a little jaded, but my expectation is that the
complexity of software development and the pace of
technological change will outstrip the ability of tool
vendors to generate reasonably efficient source code to
meet my current needs.
In other words, I fully expect the cobbler’s
children to go without shoes, or in this case for
developers to go without “ultimate tools”, for quite
You might find my
MDA page to be of interest.
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
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.