 |
For years I've written that the
UML isn't complete, at least
from the point of view of business application
development, and that we therefore need to
extend it. In fact, I believe that I was
the first one in the IT industry to argue this:
I can't remember which was physically published
first, but both the first edition of
Building Object Applications That Work
and an article I wrote reviewing the initial
release of the UML published in Object Magazine
(the first such UML article they published) came
out within a few months of each other.
Both the book and the article pointed out the
need to include fairly obvious things such as
user interface,
business process/workflow,
and
data modeling to the UML so
that we could actually model a business
application. Since then I've expanded on
this idea in several publications, but what I've
never really done is written, at least in one
place, about why extending the UML beyond object
and component technology is so important to the
IT industry. Until now. |
|
By extending the
UML, we would:
- Support the full
range of business
application development.
There's more to business
application development than
object/component technology.
There are user interfaces on
the front end and databases
on the back end. We're
now taking a
service-oriented
architecture (SOA) approach
with web services,
transaction processing (TP)
technologies (e.g. CICS),
and even stored procedures
that are used to wrap
database access. Call
me old fashioned, but I
think it's a good idea to
model the UI, the database,
and services (not to mention
a myriad of other aspects)
when it makes sense to do
so.
- Make it a truly
unified language.
The word "unified" is
wonderful marketing rhetoric
describing the consolidation
of major object-oriented (OO)
modeling languages in the
mid-1990s. This is a
great start, but to have a
truly unified modeling
language I believe that it
should address the other
important aspects of
development too.
- Break down
communication barriers.
A common language, with a
common notation and
semantics, promotes
communication between
people. We've seen
this work within the object
community, now it's time to
do so within the IT
community as a whole.
- Break down cultural
barriers. By
having a common,
comprehensive modeling
language IT professionals
will come to understand the
issues that other
specialists have to deal
with. More
importantly, they may even
realize that being a
specialist reduces their
overall effectiveness and
that they should instead
strive to become a
generalizing specialist.
- Provide direction to
developers. Many
developers, if they choose
to take a formal approach to
modeling at all, will focus
on UML-based techniques
(often
class diagrams,
sequence diagrams, and
use case diagrams from
what an
informal poll has shown)
but not other techniques.
I suspect that this is in
part due to the effective
marketing of the UML tool
vendors, in part due to OO
books which only cover
UML-based techniques, and in
part due to over
specialization within
organizations (e.g. you
don't need to learn how to
model data because the data
folks do that work).
By including
non-object/component
modeling techniques in the
UML they're at least put on
the radar scope of these
developers, increasing the
chance that they'd pick up
the requisite skills to
apply them effectively.
- Provide guidance to
tool vendors. I often
see developers struggle to
use UML modeling tools
effectively. Sometimes
their management has forced
them to use the modeling
tool but they haven't been
given adequate training to
use it. Unfortunately
there's not much I can do
about that problem other
than to advise against it.
Other times, however, the
developers have the UML
skills, they have a good UML
tool, yet they still
struggle because the tool
doesn't fully reflect what
they need to do.
Often, the tool is either
limited to just the UML or
has includes a
less-than-stellar
implementation of non-UML
models (more on this in a
minute). For example,
if the UML included a
physical data modeling
profile then
O/R mapping tool vendors
(see my list of existing
O/R mapping tools) might
be motivated to build
something that maps between
a standard class diagram and
a standard data model.
Right now, although there
are a lot of great O/R
mapping tools out there,
they're all pretty much
limited to a subset of
platforms.
There are several
significant challenges to
this approach:
- The UML is
arguably too big already.
Although the breadth of
the UML is still a bit
challenged, the depth
proves to be quite
impressive. The
UML exhibits such detail
due to the needs of the
MDA tool vendors,
which is great for them,
but most UML
practitioners neither
need nor want this
detail. Most
people are happy with
the 20% of the UML
notation that they
already use, struggle to
see the point of the
other 80%, and really
aren't all that
concerned about adding
to the UML.
- Object purists
don't like the idea.
The original goal of the
UML was to define a
common approach to
modeling OO software.
That scope was later
expanded for
component-based
software. Some
purists feel that the
scope of the UML is fine
the way that it is.
- Non-object
purists don't like the
idea. This
seems to be a problem
withing the data
community in particular,
although to be fair it's
really a problem with a
very small minority
within the data
community. They
see modern technologies
and techniques, such as
agile software
development approaches
or object technology
itself, as a threat. And
you know what, they're
absolutely right: the
changes that have been
underway within the
application development
community since the
early 1990s are very
different that the
traditional data
management approaches
which some people within
the data community still
prefer. This is
one aspect of the
unfortunate
cultural impedance
mismatch between the
object and data
communities, a mismatch
that we've been trying
to address with the
Agile Data method
and its surrounding
techniques.
Why I think we will
see the UML extended:
- The tool
vendors are
extending the UML on
their own.
You'd be
hard-pressed to find
a "UML modeling
tool" that simply
restricted itself to
"pure UML", and
that's perfectly
fine. The tool
vendors need to meet
the actual needs of
their clients, and
their clients are
trying to use their
tools to build
actual software.
This is why you see
companies such as
IBM, Oracle, and
Sybase selling CASE
tools which support
their own version of
"UML data modeling"
(respectively, these
tools are
Rational Software
Architect,
JDeveloper, and
PowerDesigner).
Similarly, some UML
modeling tools
support UI modeling,
business process
modeling, and web
service modeling
using their own UML
profiles.
- The
methodologists are
extending the UML on
their own.
Many UML book
authors describe
their techniques for
UI, process, and
data modeling using
the UML. I
cover all three in
The Object Primer
3rd Edition (I
started writing
about all three in
Building Object Applications That Work and
continued to do so
in
Process Patterns
and
The Object Primer
2nd Edition).
Craig Larman covers
similar ground in
Applying UML and
Patterns.
More specifically,
for UI modeling via
the UML, Mark
Harmelen's
Object Modeling and
User Interface
Design is a good
read. For UML
process modeling,
there's Penker and
Eriksson's and
Business Modeling
with UML.
For UML data
modeling, we have
Robert Muller's
Database Design for
Smarties,
Naiberg and
Maksimchuk's
UML for Database
Design, and my
own
Agile Database
Techniques.
- The OMG is
finally starting to
extend the UML.
They've brought the
Business Process
Modeling Notation
(BPMN) into
their fold,
indicating movement
towards a
standardized
approach to process
modeling via the
UML. They've
also issued an
RFP for a data
modeling notation
in December 2005,
which is the first
step to developing
an industry
standard.
Unfortunately, the
data community has
never gone to the
effort of defining
an industry standard
notation (not that
you can blame them,
it's a truly
thankless task) so there
isn't an existing
standards body to
work with, unlike
with BPMN.
In short, it's
already happening.
|
|
|
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. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
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
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
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. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
