
UML in Practice - lsinger
http://www.neverworkintheory.org/?p=542
======
GlennS
Is the formalism of UML actually useful?

I don't think I've ever done a collaborative software project without
scribbling some boxes representing system components on a piece of paper.
Sequence diagrams are also quite useful (instead of showing who has a
reference to whom, you're showing flow of control).

But, once the understanding has been passed on, the documents get scrunched up
and chucked in the bin. No-one worries about representing the minutae of
inheritance on them. I certainly don't see the point of showing them to a
customer.

~~~
wpietri
I'm with you on the proper lifetime of diagrams. They should be preserved only
until someone else needs the whiteboard.

Even so, I happily took a little time years ago to learn UML basics, because I
needed _some_ notation for my whiteboard sketching, and having a common one
seemed better than just everybody making up their own. (Even given that the
one that _I_ made up would of course be superior.)

I've never regretted it. It's sort of like blueprint symbols. I never do more
than sketch out a couple of rooms. But I'd still rather use the standard
symbol for a door or a window or a toilet then to screw around coming up with
my own, and then hope others can figure it out.

If anybody wants a quick UML intro, I strongly recommend Martin Fowler's book:
<[http://martinfowler.com/books/uml.html>](http://martinfowler.com/books/uml.html>).

------
bane
In practice, and I mean at mega-corps with government contracts that require
UML diagrams for everything I've seen this as a common pattern:

1) An EA is hired who gins up a stack of UML diagrams which are sent for
review and acceptance by the customer.

2) The system is then actually designed and built regardless of (and often
despite) the accepted UML diagrams.

3) The built system is then documented in a new stack of UML diagrams by the
EA which are then delivered to the customer as if the first stack didn't
exist.

The problem in the industry with UML is not #3, UML can be a great way of
describing a complex system, the problem is #1, UML is a terrible way at
blueprinting how a working system will look like in the end.

~~~
marcosdumay
UML is just a notation. It is great for blueprinting software (except that
graphics create problems, and UML is graphical), it makes no difference if
they exist or not.

The problem is that people are terrible for blueprinting sotfware that does
not yet exist. Whatever notation you choose, the problem will still be there.

~~~
bane
> The problem is that people are terrible for blueprinting sotfware that does
> not yet exist.

I agree, in addition the people who usually are doing the blueprinting usually
don't really know much about the nuts and bolts of actually building software
(or haven't built any in a very long time).

------
aggronn
In school, UML seemed like a great idea. It wasn't very fun, but it was
useful, and if you had a simple class project, UMLs certainly made things
simpler if you were even okay at them.

When I got my first job, however, there were no UML diagrams. I was saddened
to see this. I don't remember if I was surprised, but I was so sure that I
would been useful to have a detailed UMI diagram available for studying the
codebase.

So, as I got acclimated to the codebase, I took it upon myself to start
putting together a UML for our existing product, so that training new people
would be easier. After spending several days doing this, my opinion or UML
changed dramatically for a couple of reasons:

1) Pretty much all of the UML tools out there are not a pleasure to use.
Drawing UML diagrams was still infinitely better than using the various
programs I tried. But drawing them on anything but a whiteboard wasn't
scalable to the size of the project.

2) Once I had the basic classes drawn out, and realized how diverse the kinds
of classes we had were, it became apparent that this just wasn't going to
happen. A basic flowchart of the application would be equally valuable. The
specificity of UML wasn't worthwhile, having a class with 10+ subclasses was a
mess.

3) What I did have was hard to see. This goes back to the first point--the
tools are not good. When you labored over all the clicking and dragging, you
pulled together this monster of a graph that you can only see a small portion
of at a time in a given screen. It was easy to get lost. Printing wasn't
useful.

Ultimately, I only ended up using UMLs when we were thinking about how we were
going to build out new features, or redesign stuff. It was a .NET shop
building a Silverlight app, so serialization and strict static typing was
critical. A decent JSON api would have made life easy, but since the back end
and the front end were essentially all the same thing, class diagrams were
very useful. So for the 2 or 3 times that we had to develop or redo class
serialization while I was there, it came in handy only for working on small
2-5 class models.

That brings us to the next point: do class diagrams have a place in an
increasingly dynamically typed world? Functional programming in javascript.
Frameworks that have their own detailed class system, or which aren't even
class oriented.

UML has essentially become analogous to cursive. You learn about it early on,
and its important to have a notion of how to read it. But ultimately, since we
don't use it every day, we basically never use it.

~~~
styluss
Have you tried Umlet [http://www.umlet.com/](http://www.umlet.com/) ?

~~~
aggronn
Thats actually what I had settled on using, and I think its a fine tool. But
even umlet doesn't make writing and viewing large UML diagrams...pleasurable?
In the sense that we have tools like vim, word, excel, and chrome that are
very polished and allow you to get to work quickly and accurately. Even with
umlet, i find myself worrying about the interface too much.

I suspect its more of a problem with the fundamental design of UML though. I
think if there was like, a UML-lite spec or something. To me, i feel like UML
is to what I want to use as XML is to JSON (or csv for that matter), if that
makes any sense.

------
QEDturtles
I've never found UML useful for diagraming an entire application. However, I
don't know if this is a fault in UML or a problem with the application
architecture. Applications tend to get large and disjointed. They solve
multiple problem sets and consist of several different layers. When we try to
take a complex system and put it into a UML diagram things get really hairy
fast.

UML is more useful when it is used for diagramming the components of systems.
This practice also promotes the practice of identifying and decoupling system
components. When complex problems or unfamiliar patterns emerge, UML is
indispensable.

Still the biggest issues I've observed with UML adoption are: 1) A lack of
tools developers want to use. 2) As developers become familiar with the
codebase (you know, by writing it...) they begin to think it's self
explanatory tedious documentation efforts like UML are unnecessary.

------
Yhippa
Ten years ago I spent a semester essentially learning UML and it's components.
We got a lot of practice designing classes and using the CASE tools to
generate code from them.

Since I graduated I've only ever run into a shop that uses UML once. They paid
for Enterprise Architect and I was impressed at how useful the idea of UML is
for documenting and architecting software.

I feel the big trend has moved towards spending effort around requirements
definition and clarification thanks to Agile. By the time that's done it feels
to me that creating UML artifacts is doing double-work when you could be
coding instead. There's also inconsistent tooling and its associated monetary
expenses.

------
RogerL
UML slices code oddly.

You can't fit a big system on a piece of paper. So, let's say you have a big
graphics system. One of your base classes is Widget. It is almost certainly
worthless to show every class that derives from Widget on one page, even if
you could. What you are really interested in is how subsystem interact when in
various states. For example, you might have a map window that uses a small
collection of items derived from Widget, some strategy pattern type things (to
project to Mercator or whatever), and so on. The only useful graphic is a
sheet that shows how all of these components interact. But, maps are complex,
so you are probably pulling in and using 100+ classes. Most of which are not
relevant. So it takes a human, and a lot of thought, to figure out how to
slice through the code to produce a useful UML diagram for the area of
interest.

And then the diagrams are static. You have a bunch of other stacks of paper to
try to show how things happen in time. Typically there are several scenerios -
each scenerio is going to involve a different subset of classes.

Its combinatorial explosion. No one can do this. Its far more work than
writing and debugging the code itself. The code IS the documentation, for
better and worse (and yes, sometimes it's worse).

So, like most people, I do whiteboard sketches of high level design. If I am
particularly pressed, I'll sit down with pen and paper, sketch 2-4 competing
UML diagrams, then hand write in different transactions/events - showing how
data flows, and so on.

But capturing an entire source tree? Impossible, unless you just want the
spaghetti diagrams that are not displayable on any monitor, and that are
completely useless at telling a story.

~~~
a3n
I agree, the whole picture obscures the whole picture.

But having the whole picture without looking at it is useful. In doxygen, for
example, you can capture an entire source tree, but then only zoom in to areas
that you're interested in. You get the flexibility of seeing any portion of
the whole that helps you understand.

Generating something like that before code, though, is a waste of time. Unless
it's a government contract, and then it's profit.

------
Pamar
I work on corporate level custom webapps. The main two areas where you have to
be careful to design things correctly and to be able to convey your ideas to
end users (in clear, unambiguous terms) are - in my experience, at least:

\- Database design

\- (Web) Interface design

Oddly enough, UML provides zero support for either. So it's always DBA stuff
on one side and mockups/wireframing/prototype on the other. Especially to
discuss user-front things (i.e. how the application will look and how you will
work with it) UML is completely useless.

These are our primary concerns, and UML does not help at all. Use cases are
too abstract, and the rest is of little value for the users.

So despite my attempts at learning it, I was never able to get any real value
out of it.

~~~
Pamar
Also, have a look at this to better explain my problems in using UML for
practical purposes:
[https://files.ifi.uzh.ch/rerg/amadeus/publications/papers/IW...](https://files.ifi.uzh.ch/rerg/amadeus/publications/papers/IWSSD-10.pdf)

------
contingencies
I spoke at Code Generation 2010 in Cambridge about 'roll your own' code
generation solutions and some examples of how I'd used them to reform an
existing software development process.

While most people there were UML junkies, and the UML designing 'Object Group'
were also in attendance, I still used the phrase _UML hell_ during my talk
which garnered significant cheers from the audience.

My conclusion was that there are often all sorts of useful, formal models just
lying around and UML isn't necessarily the best thing to rely upon. Three
useful and IMHO often overlooked examples of 'free' formal models are:
software dependency trees in package managers, directory structures, and
database definitions.

------
jrobbins
Trends come and go. Even the strongest software engineering trends seem to
last about 10 years.

More than 10 years ago, I worked on a tool called ArgoUML. Years later, check
out what I was surprised to find on YouTube:
[http://www.youtube.com/results?search_query=argouml](http://www.youtube.com/results?search_query=argouml)

Tons of fairly recent videos of how to use ArgoUML. Mostly in Spanish,
Portuguese, or Vietnamese.

------
biofox
Graphical modelling is an incredibly powerful tool, and it saddens me that UML
is not valued more by hackers. I suspect one of the reasons it's not used, is
that people simply don't need it most of the time. When I started in software
I was apathetic about UML, in fact I thought the whole thing was a bit silly.
I used the occasional class diagram to communicate an idea, but I could never
see the point of modelling. Most of the time I know what needs coding and have
a good intuition for how to implement it; but with experience, that has
changed.

Only twice in my life have I had anything close to a religious epiphany: 1)
the first time I tried psychedelics, and 2) the time I finally 'got' UML: I
was faced with an enormously complex software project that was far beyond my
level of experience and skill set, and I didn't have the faintest clue where
to start... it was the sort of project that makes you feel slightly terrified
and incompetent. After several false starts, I realised I needed to try a
different approach, so out of desperation I dug up an old college textbook on
systems analysis and tried to design the entire system on paper away from the
computer. I started with a use case diagram, then numerous class diagrams,
then sequence diagrams, then activity diagrams. In a matter of hours, I'd
nailed the ENTIRE project, without straining my brain the slightest. I was
ecstatic! It felt like I'd just acquired a superhuman power or a secret black
art -- I'd transcended the capabilities of mere mortals, into the realm of
gods! In that moment, I saw the essence of UML, and it was power! As nerdy as
it sounds, it was certainly one of the most profound and memorable experience
I've had -- taking something I knew moderately well (UML), and seeing an
aspect of it that I could never have anticipated, and using it to solve a
problem that was completely beyond me.

Saying all that, I should qualify that I'm not a UML fundamentalist, nor do I
think everything should be modelled. People often criticise over-abstraction
and "architecture astronauts", and rightfully so. There is an inherent danger
to modelling, but if you're an experienced coder (and more importantly the
person who's going to be implementing the designs, so as to stay grounded and
realistic) then there's immense power in abstracting away the code and the
limitations that come with "thinking in code". Under the right conditions,
modelling enables you to see the essence of the problem and derive a well-
structured solution. That, at least, is my opinion.

...and on the topic of Agile doing away with the need for modelling: the whole
point of modelling is to enable fast iterations. It's amazing how fast ideas
can develop with just a whiteboard and some thinking space. Why waste time
coding?

~~~
biofox
I should also add that I think a lot of the criticisms of UML itself are fair.

I'm talking exclusively about using it as a problem solving tool before the
implementation stage. I do wish there were better alternatives for graphically
tracking and documenting large code-bases... or even generating UML diagrams
for that matter.

~~~
bane
One of the problems is that there's an awful lot in the way of "Architecture
Astronauts" who sit down for a few days and build (in UML) a brilliant and
complex system design that has no grounding in reality.

I remember vaguely one argument with an EA who had built a very nice looking
system blueprint in UML, who didn't understand that several of the ways
various components needed to interact either required very large amounts of
computing power or an algorithm that didn't exist. "But I carefully looked at
that in the sequence diagrams here and here!"

In the usual best case, when the implementation starts to diverge away from
the UML (as it usually does), it becomes nightmarish to keep the UML synched
to the codebase. It's usually just easier to wait for the code to freeze, then
go in and document what's there...which of course is not really the point of
UML.

------
eliben
The idea of UML makes sense - why not have a common graphical language for the
things programmers want to describe to each other all the time?

Sometimes I think the implementation is just wrong - because programmers are
obviously voting with their fit.

A modern replacement for UML, anyone ;-) ?

~~~
bobm_kite9
Someone in the thread above suggested the same. This needs doing.

------
abawany
I use the hosted version of websequencediagrams.com for sequence diagrams and
that works out very well. I know that sequence diagrams are a very small part
of UML but I find that they have an extraordinary effect on clarifying a
system's design without too much effort.

------
dykesa
Actually, I really like UML; I especially like swimlanes. Of course it doesn't
make sense for every design but I find that 12 months later, a map to what I
was thinking during the original design is invaluable.

------
jacob019
was hoping for an article on user mode linux

~~~
duskwuff
That UML is used about as often these days as UML notation, given the
availability of virtualization solutions like KVM. Its time has come and gone.

------
ssn
How do you document a web application?

