UML - The Unified Modeling Language
The What and the Why
As the Object Management Group's website explains:
The Unified Modeling Language (UML) is a language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as
for business modeling and other non-software systems. The UML represents
a collection of best engineering practices that have proven successful in the
modeling of large and complex systems.
What does all that mean? Mainly, that there is now a standard method of illustrating
(modeling) the components and processes that comprise software systems. It's really more
flexible than that: you can use it to model just about anything. Once upon a time
various notational and diagramming methods abounded; now you should simply
I won't attempt to teach the UML and will only address it in general terms beyond this document,
but I cannot stress its importance to you enough. For one thing, using the UML means
that you can describe projects to anyone. Following the processes that create those
diagrams assists you in the critical thinking that is required to manage successful
projects. And your knowledge of the UML gives you credibility when you're working
with established contractors. I strongly urge you to get a good book on UML and perhaps
from the .
I will say this: the UML is far more flexible than many references
let on: and, there is no tool specifically designed for UML modeling that takes
full advantage of its flexibility (that includes Rational Rose). If you want to use
UML mechanically, as part of a process that includes the automatic creation of
software classes, use the tools and be prepared to live with their limitation.
I'll provide you with a list of good ones. However, If you want to use the UML
expressively, you're better off with a drawing tool like Visio, or Dia, or
SmartDraw, or Kivio.
The minimum: At a minimum you need to learn the following types of
- Use Cases: These are instrumental in defining your requirements.
Learn Use Cases inside out.
- Class Diagrams: These are essential. Most people think of
class diagrams as defining your software components, and that's exactly how
products like Rational Rose treat them. You can be a lot more imaginative
- Activity Diagrams
describe how the components of your system will work together. There are a
number of different ways do this, and they all have different strengths. Activity
diagrams and swimlanes are fairly close to what you might be used to if you've
- Sequence Diagrams
are most useful show complex interactions between a limited number of classes.
I use these all the time. The trick is not to have too many classes on the
diagram. If you need to diagram complex interactions between a large number of
classes, break the problem down and represent parts of it as packages.
- Collaboration Diagrams
are useful to show limited interactions between a large number of classes. These
are nice because in many cases you can simply modify existing class diagrams to
But Wait! There's More! In addition to the minimum diagrams
listed above you should know a few more:
- State Diagrams
I despise these, but they can actually be useful. For a component, a State
diagram shows the various states that the component can be in, and the transitions
that get it from one state to another. If it sounds confusing it can be.
I don't ever recommend showing one of these to a user; for one thing, they're
usually used when you're deep in the details of technical design. Limit your users
to Use Cases, Sequences, and maybe Collaboration Diagrams.
- Package Diagrams
are similar to a class diagrams. A package is a number of classes
grouped together by some common criteria (usually dependencies) and treated as a
single component (components and packages are often interchangeable).
In addition to pure package diagrams, the nice thing about packages is that once
you've identified their interfaces you can substitute them for a bunch of classes
in any other UML diagram that needs to be simplified.
- Component Diagrams
illustrate the physical interconnectedness of the components that make up your
system. They're often used in conjunction with deployment diagrams.
- Deployment Diagrams
show which components are physically located on which boxen. Say you want to show
that when this system is deployed, component A resides on an AIX box called Jumper,
while components B and C are on an NT web server called Thumper. The physical
locations and physical interfaces are shown on a deployment diagram.
- The following tools are useful for integrating the UML into
advanced system development.
- Rational Rose.
This is the market leader, and a major black hole in your
pocketbook as well. It also creates some of the most aesthetically
disappointing diagrams of any tool. Can you tell I'm not impressed?
Try Rhapsody or Describe.
- Embarcadero Describe.
Formerly GDPro, this product has high interoperability with
whatever Java IDE you might use, as well as the ability to produce
nice, presentable diagrams. However, they don't list prices on the
website. According to common wisdom, if you have to ask, you can't
- ILogix Rhapsody.
You can't beat the price on this one. It's a nice, professional
product. It's free for personal use, and I highly recommend it.
This product is specifically geared toward creating embedded
systems, but it's more flexible than their sales staff will admit.
- The following drawing tools are useful for expressively diagramming
difficult concepts. Since they don't have the restrictions of the
programming tools you can get very creative and even mix and match
elements of different types of diagrams (useful and encouraged if
it helps to get a point across).
This is a solid general-purpose drawing tool that provides UML
templates. Hope you don't mind spending money: Visio Professional
runs $499. You can get a cheap version for about $199, but then you'd
have to create your own UML diagram components. I use it when
someone throws at it me, but if I had to buy a tool it would
If you use Windows, use this product. It's cheap (it starts at
$49) it's as solid as Visio, and I think it's easier and faster.
is exceptional for two reasons, even though its diagrams
look a bit clunky and unprofessional to me. First it runs under
Linux and is free. Second, it handles its drawing objects far more
intelligently that the Windows drawing tools. For instance, when you
right-click on a class it doesn't just give you properties of the
diagram component; it allows you to enter properties for the class
itself. Fantastic! Third, it stores its information in XML, which
makes it possible to extend the tool with code generators and all of
the bells and whistles that exist in tools like Rational. Those tools
don't exist yet, but the open design makes it inevitable.
is a part of the KDE project. This program is as close to Visio as you
can get on Linux, and it generates beautiful diagrams. It's a component
of KOffice 2.2. Even though Kivio is free, TheKompany generates a buck or
two selling the templates (I mean that literally: the UML template is only
Before We Begin
The informational content of this website is copyright 1997-2002 by David F. Leigh
unless otherwise stated. Permission to distribute is granted under the terms of the
GNU Free Documentation License.