
How relevant is UML modeling today? - blazzerbg
http://codebetter.com/blogs/jeremy.miller/archive/2009/09/12/how-relevant-is-uml-modeling-today.aspx
======
makecheck
I've been writing software for 20 years, and aside from my employer paying for
a course on UML a few years ago when it was all the rage, I have never, ever
seen UML seriously used.

Not that I've ever worked at Microsoft or any massive "pure software" groups;
I've basically worked in "get stuff done" smaller software groups. However, I
suspect these small groups are far more common. When push comes to shove, code
_is_ the design documentation.

Beyond that, I've always had practical issues with UML's need to specify
everything. How often is that valuable? Any given box-and-stick-diagram-with-
labels is bound to be pretty clear, whether or not it does things the UML way.
I would be annoyed if someone wasted extra time (and, likely, money) on a UML-
aware tool, when it would have been faster and as useful to just sketch
something.

I've also tended to rely on automatically-generated-and-therefore-always-
correct diagrams (e.g. Doxygen, through GraphViz). This is especially true
given that the majority of my documentation, even outside the code, leans
toward plain text formats (e.g. man pages, simple text files,
reStructuredText, or HTML). My reliance on those formats forces documents to
be on the short side, which also helps avoid the risk of inconsistency with
the code.

~~~
DanielBMarkham
I think you've never learned UML.

UML is a tool, a language. It's not a process, nor does it require that you
specify anything. It's just a way of talking at a technical level.

I've been in the software field for 25 years delivering production code in a
lot of venues. I _always_ use UML as a way of doodling and talking about the
way we're going to attack a problem.

Remember the four Cs of modeling: communication, coordination, collaboration,
and consensus. There is a 5th C, Control, but it's bad medicine. Once you
think that UML controls stuff, you run off in to architect astronaut land
drawing lots of complicated diagrams with lots of little details.

That's what people think of when they think of UML, and it's about the
furthest thing from the truth as you can imagine.

Just to rant a little bit more, a couple of years ago I wrote an agile project
management tracking tool. As part of that, my customers and I had a 30-minutes
requirements meeting. From that I created an analysis model. From that I
created a database and a DAL. The whole process took about 2 hours. When
people wanted changes, I could change the model and have the database and code
change in 5 minutes. It left me to work on the UI and Business Logic and not
be wiring stuff up everywhere.

UML can be nothing more than a bunch of boxes with arrows between them. In
fact, 95% of UML is never or very rarely used by effective projects.

Tools can be very useful or they can cut your arms off. Doesn't make the tool
bad or good. It's just a tool.

~~~
makecheck
It is good to hear that UML has some uses, even if I had always assumed this
was most applicable to larger teams or companies. Can you comment more on the
specific parts of UML that your models used?

I do tend to think of your 4 Cs as all the same, though. In my experience, a
team is either working together effectively or it isn't, and either achieves
all of those "Cs" or none of them. I would even add that, often, a team lead
must forego the "consensus" and simply make a decision. (This can even be true
when dealing with customer requirements; occasionally, a software architect's
design decision ultimately delivers a better thing than what the customer
technically specified.)

~~~
DanielBMarkham
So just look at UML as a formal way of talking and you'll be fine. The secret
here is that pictures can convey bandwidth much higher than words. If you
understand that, then UML is just a way to draw pictures without ambiguity.

For communication, a lot of times I'll be describing something to another
programmer on the phone -- or he'll be describing it to me. As they talk, I
jot down what I think he's saying in lighweight UML. Then I show it to him by
email or webcam or something. It identifies a lot of discrepancies very
quickly.

For collaboration, many times in a group we'll tag-team a problem by drawing
up our idea of what we think it looks like. Either we trade-off, or everybody
draws separately, or one person leads until the group replaces him.

For consensus-building, a lot of times you'll have a subcontractor or person
who's remote who is proposing some kind of work for the team. They can do a
stand-up, or a presentation, or whatever, but the key thing is usually when
they communicate their technical solution in terms of a diagram. This is very
useful when talking about how a screen should flow, for instance, or about how
a third-party tool acts.

For coordination, a lot of times external groups want to be "in the loop" but
don't have time to attend meetings and don't want a lot of paperwork. A lot of
times an email with a couple of pictures attached can give them the gist of
what's going on technically without a 50-page doc being there.

To differentiate between the Cs, ask yourself: is the communication two-way?
One-way? Formal? Informal?

Modeling is just a high-bandwidth version of talking, that's it. I can say
more in a model in 10 minutes than I could in 4 hours of explaining.

But, like every freaking thing else in software engineering, people become too
attached to it and it has developed all these features that nobody needs. And
so it gets abused.

To specifically answer your question, class or domain models seem to work for
a LOT of stuff. Sequencing is good at showing things in layers, and Activity
Diagrams is just flowcharting on steriods. To give a concrete example of using
them, many times when the team is estimating a story and isn't comfortable
with the details, we'll take 15 minutes or so and sketch out an activity
diagram of how it's supposed to work. That usually either fixes the problem or
gives us more questions to go answer :)

