
All the UML you need to know - CaRDiaK
http://www.cs.bsu.edu/homepages/pvg/misc/uml/
======
m_fayer
My first real-world job in the industry was in a large-ish shop that worked as
follows:

Create a full-detail schematic of the system in version-controlled UML.

At some point, "deploy" the UML by printing it into a 4 cm-thick binder of
paper, then distribute these binders to the head architects.

Iterate on the UML until the architects are happy. (The architects spent many
years trying to auto-generate code from the UML diagrams and have the results
"fleshed out" by lowest-bidder consultants, though this never really worked.
Their stated goal was to no longer have to write any code in house, but rather
nothing but UML.)

Begin implementing the system in house with auto-generated code from the
binder-of-UML as a baseline, after the lowest-bidder consultants had failed.

Quickly get into big fights between the coders-on-the-ground and management
when it was found that the UML diagrams contained major architectural flaws
and the UML-phase would not, actually, account for 80% of the project's
duration and budget. Needless to say, more than half of the projects failed
entirely.

This experience nearly made me leave the industry, before I discovered that
there was plenty of software being written in a saner way. This was more than
a decade ago, but to this day, just seeing UML diagrams turns my stomach.

~~~
smoyer
"Their stated goal was to no longer have to write any code in house, but
rather nothing but UML"

This goal was promoted heavily in the late '90s and early '00s. Some tools
could supposedly "round-trip" between UML and code, but I never saw that
actually work. As originally conceived, UML was supposed to foster
communication and there are times when a UML diagram is the perfect means to
communicate the intent. I tend to use sequence diagrams and ER diagrams the
most (yes - I know ER diagrams aren't UML but they're roughly analogous to
class diagrams and what we're usually trying to flesh out is the relationship
between models).

As an aside, there were/are graphical programming languages. I wrote a couple
of Windows and Mac utilities in ProGraph [1] during the '90s. The ProGraph
environment lives on as Marten [2] which I recently played with on Linux. It's
not nearly as clean as I remember it being.

[1]
[https://en.wikipedia.org/wiki/Prograph](https://en.wikipedia.org/wiki/Prograph)

[2]
[http://www.andescotia.com/products/marten/](http://www.andescotia.com/products/marten/)

~~~
pjc50

      > UML was supposed to foster communication
    
      > could supposedly "round-trip" between UML and code, but I never saw that actually work
    

This is the root of the problem with UML-as-spec: it's used as a tool for
_one-way_ communication, for open-loop management that doesn't want to have
feedback or dialogue stages in development.

~~~
feider
I think this is the real problem with UML. It first kinda seems to work when
project is managed with waterfall-style, but when actual development is done
iteratively (when is it not?) it just adds confusion or work either by
providing out-of-date spec or introducing more stuff to keep in sync.

~~~
mpdehaan2
UML is a way to talk about things. Just having a standard-ish way to draw on
whiteboards is pretty helpful, even if the diagrams are super temporary.

In practice in most industries, most folks can probably get away with just
knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also
somewhat useful as a concept (but so are regular flowcharts).

There's a whole other ton of UML (see 5/7th of Rational Rose around the early
2000s, which is probably gone all deep and crazy now, etc) that is, IMHO,
pretty skippable.

I've not even seen some of the "stuff you have to know" (ball and socket, etc)
used.

I do think that designs get better when you can draw them, as when they get
hard to draw, it becomes conceptually obvious there may be problems.

UML generation code tools running against 1300+ Java classes and making some
huge diagram covered up in arrows definitely doesn't work too well though :)

------
putzdown
No, all the UML you need to know is this: (1) draw and label a box for each
class; (2) draw an arrow from one class to another to show dependency; (3)
draw a different kind of arrow from one class to another to show inheritance;
(4) [bonus material, for super-geniuses like you] use regex-style symbols * ,
+, 1 and suchlike to mark the ends of dependency arrows in order to indicate
when you have one-to-one or one-to-many relationships and so forth.

There. My 20+ years of experience in software architecture in various fields
from games to networking tells me that you now know enough to work out the
classes and their relationships in a large software system.

Don't fuss around with "aggregation" or "composition" or whatever. Don't spell
out functions (though occasionally I'll jot one below a line to remind myself
what the salient feature of the dependency is). And by no means write the
class properties, their types, or their access specifiers (public,
protected...)—this is way too much detail. A UML diagram is useful in modeling
broad object relationships in a system. If you want to work out what
properties a class should have, write the damn class. Any software developer
worth his salt can figure out the code from a high-level diagram; don't write
the code for him. Or do, but then don't call it an architectural diagram.

I know there's a whole culture of software development where architects design
code but don't dirty their hands with writing it, then hand it off to
underlings who type it up for them, and so on down some kind of techno-
bureaucracy Great Chain of Being. Rubbish. Code architecture _is_ a thing and
some kind of diagramming is helpful, but UML as such is the sort of busywork
and IRS-style hierarchism that marks bloated government jobs, not real
productivity or real teamwork.

Give UML a miss and use something very, very simple.

------
cjg
I've generally found UML to be a complete waste of time.

I'd rather outline the major components of a system by drawing (on real paper)
simple boxes and lines, or write the code that implements the system.

Not sure what code-as-picture achieves - it's generally has worse tooling
(less editable, less versionable, etc.) and tends to be used by 'architects'
who don't write code, only for that UML to be essentially ignored by the
coders on the ground.

~~~
jeremysmyth
As long a the "simple boxes and lines" describe the functionality of your
design at the level you wish to communicate, then you're doing good. You can
stop reading here.

The problem is that complex systems need complex design. As your design get
more sophisticated, you need more sophisticated ways to communicate the
design. Concepts like dependency, multiplicity, inheritance, inclusion,
asynchronous message, exception, timed event are all things you can represent
with boxes and lines, but unless you adorn the diagram with a huge amount of
text you're not going to capture the distinctions between those different
types of relationship.

It's not unlike any other language: I can use the word _thought_ to describe
something in my head that isn't physically manifested, but words like _lie_ ,
_memory_ , _hypothesis_ , _idea_ , _belief_ , _image_ , _nostalgia_ ,
_forecast_ , _imagination_ are all used to distinguish between types of
thoughts. If I used only simple words like "thought" then I wouldn't be able
to express anything more sophisticated while still being concise.

In short, if you want to graphically describe something complex, you can
either use a sophisticated visual language to do it concisely and
unambiguously, or you can use a simple visual language and write tonnes of
documentation to support it, with all the problems of attention, ambiguity,
and rot that go along with it.

~~~
mironathetin
"The problem is that complex systems need complex design. "

No. Complex systems need more thinking and refactoring until they are less
complex.

~~~
jeremysmyth
Really? The device you're reading this on probably contains more complexity
than it's possible for one person to understand in a lifetime, and that's _one
device_.

It's incredibly naive (or at best disingenuous) to assume that complex systems
can be reduced by thinking and refactoring. Perhaps some can, but when you
consider many of the software artefacts we use daily (seeing as that's the
context of this subthread), such as operating systems, virtualization
platforms, or even good ol' clunky enterprise applications, you can't just
wish the complexity away with a bit of hard work.

~~~
crdoconnor
>Really? The device you're reading this on probably contains more complexity
than it's possible for one person to understand in a lifetime, and that's one
device.

It wouldn't have been possible at all if the pieces that make it up weren't
loosely coupled.

>It's incredibly naive (or at best disingenuous) to assume that complex
systems can be reduced by thinking and refactoring.

It's naive to assume that you can't. Loose coupling pretty much only comes as
a result of extensive refactoring.

~~~
jeremysmyth
...and one of the ways you can communicate such coupling is by diagramming the
(complex) system's design.

Google for "linux kernel diagram"[1]. It's quite well designed, displays loose
coupling, high cohesion, and all the other things we like about good complex
systems. If I want to dig in and start working on a module, I'd still have to
understand the relationship between all the bits I work directly with (and
probably some that are further away).

Don't confuse loose coupling with low complexity.

[https://www.google.com/search?q=linux+kernel+diagram](https://www.google.com/search?q=linux+kernel+diagram)

------
jasode
Diagrams/notation I've found useful:

++ _E-R (entity-relationship) diagrams_. I find it easier to look at boxses
for each table follow the lines signifying relationships to other boxes. The
"crows feet" can signify 1-to-many. The diagram is easier than reading a
sequential list of SQL CREATE TABLE statements and making a mental note of
"FOREIGN KEY" strings and mentally backtracking to the parent table.

++ _swim lanes_ to show how the "state" of a system is supposed to change with
"time". This can succinctly show how data "flows" without having to actually
run a program and watch variables in a debugger to manually recreate the "swim
lane" in your head.

++ _truth tables_ to summarize combinations of valid/invalid business rules
and associated side effects. A grid is easier than parsing a long (and often
nested) list of if/then/else/switch statements.

As for UML, the notation never seems to be that succinct or helpful to me. On
the surface level, it seems that UML (for code) should have the same return-
on-investment as E-R (for db tables) but it doesn't in my experience.

I also wonder if there is a cultural component to UML usage. It doesn't seem
like tech companies (such as Microsoft/Google/Amazon/Ubisoft/etc) internally
use UML as a prerequisite step for building systems. On the other hand, I
could see more UML usage at non-tech companies (such as
banks/manufacturing/government) building line-of-business CRUD apps. Grady
Booch (Booch & UML notation) did consulting about software methodology at non-
tech companies so that may have been a factor.

------
DanielBMarkham
I love UML. UML is overused. More people need to know UML. The less UML you
do, the better.

I believe all of these statements to be true.

I had a contract many years ago with a large insurer. Their development
process basically consisted of drawing really complex UML diagrams, then
hitting the Big Red Button and having the modeling tool generate 40,000 lines
of framework code. The chief architect explained to me that really the only
work required was just a tiny bit of business logic in the appropriate places.

Fortunately I was not part of the main dev team, which for some strange reason
(at least in the lead architect's mind) had the damnedest time with this
system. My job was to create an internal permissions system. Given app X, user
Y, and action Z, was the action allowed or not.

I looked at the problem for a while, and no matter how I thought about it, to
me I had three lookup tables and one method. Boom, I'm done.

The lead architect wanted me to still draw a diagram with one class, push the
button, and get the 40,000 lines of code. For some reason, this did not appeal
to me.

Took me about 3 weeks to convince him that really 20 lines or so of code was
all we needed. I still had to draw the diagram, though.

That's the horror story -- one among dozens I have. But on the flip side, I've
been with teams that interviewed the customer while sketching out a domain
model. Since we all understood UML, a quick and lightweight sketch using the
appropriate notation got agreement on a ton of detail just taking 30 minutes
or so. That would have been very difficult using a conversation or word
processor. Sketching without some common lightweight understanding could have
led to rookie errors.

There is nothing in this world better for getting quick technical agreement on
complex problems than group sketching using lightweight UML. The trick is
sticking to the absolute minimum.

~~~
keithb-
I tend to agree. I studied UML and earn certs. At the time, I really liked it
and I had fun drawing diagrams for both new and existing projects. Now, I only
use it for sketching and I think the vocabulary is the key: it is more
important for you and your team to know the important terms than the nuances
of the actual spec. For example, the transitions on activity diagrams have
sophisticated semantics for describing events, functions, etc. that may be
more cumbersome to document and explain than, for example, a label just saying
"convert to binary".

In my career, I have only seen a few things that caused religious fervor on
any significant scale: XML and UML. But I would like to know if the level of
specification around these languages is the off-putting aspect or if it is
something else. Did mathematicians of the Newton-Leibiz time exchange letters
denouncing proofs or trolling with irreducible polynomials?

------
edpichler
Plot twist: this article doesn't have all the UML you need to know, it's just
the class diagram.

Particularly, for my personal projects, I use the Use Cases diagram to map the
requirements and the features my application will have, associated with my
prototypes. Other diagrams, like Class diagram, usually I use just to map the
Domain before develop the persistence. This is how all my projects start, even
if I am working alone. It is good to me and it's part of my creative process.

------
jmartinpetersen
Key quote: "Keep in mind that UML is a communication tool, and you can omit
details that are not necessary for expressing your message."

~~~
k__
Haha, yes.

All the "Software Engineering" classes at university were just UML. Many years
I thought SE was just that, UML.

When I did my first job interview I was rather relieved that the hiring
manager wanted me to draw UML. He was very pleased with my UML skills, but he
always said, I shouldn't draw it with all the details, just the basics are
enough :D

That was 2011... I never had to use UML in an interview again. But I often
used it as a documentation tool for a big PHP codebase, I had to manage.

UML and ER diagrams are often an overkill when designing an app. But they are
nice to visualize what is going on in legacy stuff.

------
skrebbel
The complete overapplication of UML for many years gave UML an undeservedly
bad name. The top comments in this thread are testament to that: many
programmers are simply all too happy to go "haha! UML! that's for enterprise
losers in suits who prefer paper over working code!"

Thing is, the core elements of UML are very useful in communicating a design
or an idea. Class diagrams are a _great_ way to discuss an OO-ish codebase in
front of a whiteboard (or any data model, really). When you do that, it
_really helps_ when everybody knows that an arrow in static UML diagram types
means "dependency" and not "the data flows from here to there".

Similarly, I still haven't seen a better way to visualise state than with a
UML state chart.

It's also very nice if you can draw a UML object diagram that people
understand (looks like a class diagram, except you basically draw a
hypothetical runtime situation of instantiated classes and you underline the
object identifier names). This works best when people understand that the
picture on the left is a class diagram (design time) and the one on the right
is an object diagram (runtime example) of the same classes. This is not
complicated stuff, but it doesn't really work as well when half the team
thinks UML is for losers.

Now, bear with me, I'll be the first to agree, UML is a bloated piece of shit.
Package diagrams, wtf, who needs that? Use case diagrams that show _which use
cases are specified_ , instead of how the use cases go - seriously? Activity
diagrams so you can draw a 5-line method on an entire sheet of paper, big
fucking what the hell were you guys thinking?? Why do I even know what this
stuff is? What a waste of time - even the decent diagram types have 60%
bullshit syntax and only 40% useful stuff. And message sequence charts are
nice enough for protocols but impossible to draw right.

But to dismiss UML just because some enterprise architects went a little
overboard in 2002 is a bit like dismissing all of OOP because 15-level
inheritance hierarchies used to be hip.

I wish we could agree on a tiny subset of UML that actually makes sense, and
all learn that. This post makes a good start for class diagrams, although IMO
even the ball-and-socket notation is overblown nonsense from a time long gone.
Maybe we should do this, and give it a separate name.

On a mildly related note, one thing I like about OOP is that you can draw
pictures of it easily. Does anyone here know of a good way to visualize
functional code structure? You can draw a dependency chart of modules of
functions but that only gets you so far.

~~~
danmaz74
After many many years not touching UML, I recently had to design some state
charts - because it's something really helpful in an app we're working on at
the moment - and found that using an UML tool for that is very useful. So I
agree that it's something good, if taken with a big grain of salt.

------
mark_l_watson
Too bad he skipped sequence diagrams, saying that he had already covered them
in class.

Years ago I co-authored a book on UML, but the only UML diagrams that I still
use are sequence diagrams which I think are great for explaining interactions
between objects or separate services.

------
omellet
This should have linked to a blank page.

------
vortico
Yup, even if you never write OOP code, this is a somewhat common language you
will encounter between colleagues, so it is worth knowing exactly what is on
this page.

~~~
arethuza
Personally, I find that the "closer" you get to code the less use formal
detailed diagrams are - UML as sketch rather than UML as blueprint:

[http://martinfowler.com/bliki/UmlAsSketch.html](http://martinfowler.com/bliki/UmlAsSketch.html)

------
saiki
Personally I use quite a lot sketch like UML and find it very helpful for
clarifying complex environments or ideas that are not clear yet. Most of the
time sketches are just boxes, circles and lines, but those communicates and
clarifies the problem for others very well. I don't use lot of time when
sketching, system can be described graphically very quickly, just to get the
idea out or it usually goes too detailed. We have also built a tool that helps
sketching systems with remote teammates
([https://sketchboard.me](https://sketchboard.me)).

~~~
Pamar
Are you sure you are not actually using dataflow diagrams by another name?

[http://www.visual-paradigm.com/tutorials/data-flow-
diagram-e...](http://www.visual-paradigm.com/tutorials/data-flow-diagram-
example-food-ordering-system.jsp)

------
lisper
Graphical representations are useful for representing _spatial_ relationships
because then you can take advantage of the inverse-GPU in the human visual
cortex to do a lot of computation for you. But software doesn't have spatial
relationships because it doesn't exist in space. So trying to represent
software concepts graphically is generally doomed to fail. There are a few
exceptions, like code indentation, but there's a reason that flowcharts aren't
used much any more.

------
cubano
I've never figured out how to use UML abstractions to fix client and/or user
production bugs, or met anyone else who could, so who the hell has the time?

------
agentgt
I'm just curious and I'm not trying to be snide but is there any spec that OMG
has produced that people actually like and use still? (they are also makers of
CORBA)

I live in the Boston rt128 area and I pass OMG's building all the time and I
just have no idea how they are still in business (they are near Trip Advisors
new complete awesome building).

I wonder how many massive companies continuously donate to OMG and do not
realize it.

------
makecheck
Just think of UML as the C++ of diagrams: it is sometimes the best way to
produce the result that you need but you have to choose a sane subset.

------
crocal
All the UML I need to know? Frankly? Nothing. I am surprised people would
still consider this thing useful.

------
CrLf
The general feeling about UML is that it's overkill for most projects and
actively harmful when used to generate code. On the other hand, most agree
that parts of UML are useful as communication tools.

However, UML was designed as a standard, near-UML is not UML. Ergo, UML is
useless.

I feel better already.

