
Do real developers use UML and other CASE tools? - niyazpk
http://programmers.stackexchange.com/questions/54666/do-real-developers-use-uml-and-other-case-tools
======
edw519
These tools serve 3 purposes:

1\. To make theory more closely match practice that already works. This gives
teachers something to teach.

2\. To make someone who doesn't know what he's doing appear as if he did. This
gives consulting firms profitability.

3\. To help organize the System Development Life Cycle (waterfall process) of
very large projects. This gives someone who knows what they're doing a few
more tools in their toolbox.

My take? If you've really found good use for tools like these, then your
project is probably too big. Break it down into smaller pieces, build a
prototype for each piece, get feedback, and refine. It's not how quickly you
appear to get started; it's how soon you deliver something of value.

~~~
shushan
I wonder if you would dare say the same on other engineering blueprints.

~~~
fleitz
Good things are not designed in this fashion. I'm sure everyone else in the
aviation industry used the uml equivalent, I'm pretty sure the skunkworks
teams do not.

~~~
shushan
It was hard for the skunk works teams to use UML for a long time since it was
only published in the late 90's, but what makes you so sure they are not using
it now? or do you have a survey of which "good things" are not designed in
this fashion?

And besides what is the relative share of skunk works type teams from the
overall software development market?

------
DanielBMarkham
Ok.

UML does NOT equal CASE. Yes, you can use MDA and other techniques to somehow
convert UML and OCL into a quasi-CASE tool, and there are lots of folks
excited about UML as part of a code-generation tier, but UML is a
specification for drawing technical diagrams. That's it.

UML is also not a methodology. Yes, there are methodologies that rely on bits
of UML but that's a one-way association. You can use UML all the time and
never do a bit of any kind of methodology.

UML is also not for large projects. Yes, it helps to diagram things instead of
writing them out, especially if you have 100 developers or more. But drawing
things can help teams as small as two people. Heck, drawing things can help a
sole developer.

You need to be clear about the question if you would like to get a meaningful
answer. UML is for drawing pictures in a consistent way. So is the question
"Do real developers draw pictures consistently?" Because in my teams, we use
UML when we need to sketch out things so that everybody has some baseline to
understand what's being drawn. It has nothing to do with generating code,
completing a process, or being part of some huge team.

I liked this comment: _If a diagram takes more than 5 minutes to sketch on the
back of an envelope it is generally too complex_

I might extend it to 15-20 minutes, but the gist here is correct, at least for
small teams. Different story entirely with large teams, though. With a large
team, having a visual roadmap of where things are and where things go is hell
of a lot better than trying to type it up in a Word document or teach people
by random story-telling. (It should still be pretty simple, though. The
purpose is communication, not documentation or showing people how detailed you
can make something)

------
mahmud
I prefer to use UML as an _output_ language, never input. It's good to come to
foreign codebase and generate visual presentations of its hierarchy and flow
graphs.

As an _input_ language, created by hand? No, not really. It's mostly something
for java/.net architecture astronauts: often used only once, to generate the
cruft that will be the project directory hierarchy, but it's brittle and grows
quickly out of touch with code & documentation.

------
spinlock
As a fake developer (i.e. PhD student in Computer Science who did very little
programming) I used UML, MOFF, and other such tools extensively. I've worked
on the GME from ISIS at Vanderbilt and Ptolemy from CHESS at Berkeley. The one
point that my thesis advisor - Janos Stipanovitz - made brutally clear
whenever we were discussing Model Integrated Computing was that the value is
not in building a better IDE that makes programmers more efficient. The value
is in building analyzable frameworks that you can use in safety critical
systems to show that your system adheres to the safety specification that you
have to meet. So, I don't think there are any programmers who would benefit
from these tools, but they absolutely do benefit system engineers building
fly-by-wire airplanes, nuclear reactors, Mars rovers, etc...

Now, I am starting to work on a web-ap with a designer and I find that State-
Charts are a great way for us to spec out the application. We're not trying to
generate code from these but my partner is such a visual thinker and learner
that State-Charts are a much more appropriate way for us to communicate than a
spec written in English.

~~~
ssn
Would love to see an example on how you use state charts to document web
applications. Thks!

------
bane
These tools serve two, very useful, purposes that aren't often readily
apparent unless you have to use them.

1) Organize complexity. UML, for example, is extremely useful as a _language_
capable of describing complex information systems -- just like the periodic
table organizes chemical elements or the biological classification taxonomy
organizes life -- or perhaps a better analogy are skeletal formulas in
chemistry and life sciences.

You can probably get away with not using this language on small projects,
maybe less than 10 people and under a quarter million lines of code. But on
larger projects, 300 developers on one project spread over a continent and
tens of millions of lines of code, some kind of formal organizational method
becomes a necessity. Ad hoc diagrams just don't really cut it. You'll be glad
to know that UML is not just stick figures anymore, some of the other diagrams
do a much better job at modeling and organizing deeper into the design than
others.

But like I said, the utility doesn't really become apparent until you deal
with this kind of scale.

2) Communication. Similar to the above, but distinct. UML also provides a
lingua franca for communications between business people and tech people. It
forces business users to apply a rigid logic to their requirements (which can
often become contradictory if not controlled by some kind of formal framework)
which aids in communicating with engineering staff and forces engineers to
stop talking about code and to talk about higher level abstracts that are more
easily relatable to business people. The ability to actually communicate
between these two parties has been extremely powerful.

In smaller organizations, the business people are quite often the tech folks
as well so this isn't as necessary to have. But in most traditional companies,
business folks have almost no way of communicating with the engineers in any
constructive way without something like this.

------
herdcall
On first look UML looks like the "proper" way of building software, but it
really isn't because software changes way too much while it's built. It's like
planning out a road-trip to the minute - it won't hold up. Some compare UML to
how architects use blueprints to build brick-and-mortar stuff, but concrete
walls and ceilings don't move midway like software does (figuratively
speaking).

IMO software process is all about controlling complexity. When the problem is
small, our human mind can come up with ingenious solutions no computer can
match. So it's better to break down the project into small, modular, and
testable components rather than try to overcome the complexity with fancy
plans that will start breaking down the moment you start implementing.

UML could be useful for documentation purposes though, giving a bit more info
than say Javadoc. But that will come after you write the software, not before.
There are some tools that claim round-tripping (i.e., you write your UML, the
tool magically generates code, you edit the code, and the tool magically
updates the UML to stay in sync). I tried a few and found them too painful to
use.

------
mullr
I'm distrustful of people who make lots of diagrams; it indicates to me that
they may not actually know how to create the thing they're drawing, and thus
lack the capacity to make truly sound decisions about it.

I've found UML-y diagrams to be useful it a few cases:

1\. When sketching out an object model in a statically typed language, it
helps to see the whole thing at once. The class diagram tool in later versions
of visual studio is a nice compromise between functionality and usability for
this case; it's easy enough to generates the code, but it's easy to ignore the
diagram and do real work when you're ready.

2\. When talking about system interactions with people via email, sequence
diagrams can be useful. <http://www.websequencediagrams.com/> is by far the
fastest and easiest way I know to make them; trying to use a GUI tool is an
exercise in frustration.

3\. If my system has some internal structure I want to draw for people, I
output graphViz data and let it draw the picture for me. Pictures generated in
this way are always up to date.

I don't know that I've EVER kept a diagram around as a piece of documentation;
they're invariably wrong after a short amount of time. In fact one of my
favorite things about the visual studio diagrams is that they break if you
change the code out from under them.

------
vilya
UML and case tools were all the rage 5-10 years ago, but have fallen out of
favour with the rise of Agile methodologies. I have a feeling* that the
teaching of software engineering at university lags about that same distance
behind current industrial practice. So in another 5 years time I'd expect
universities to have largely abandoned teaching UML except for in certain
niche classes.

* I don't have any facts to back this up, it's really just a guess.

~~~
philwelch
Keep in mind that many parts of industry itself lag 5-10 years from the
leading edge of industry. And the parts of industry many universities track--
i.e. the large firms that employ graduates by the dozens--are not the
companies on the leading edge. This is probably more the case for your middle
tier state universities than for Stanford or something, though.

------
nivertech
I used a lot of diagramming tools (just out of my head):

    
    
      Flow Charts (later criticized for encouraging GOTO)
      Syntax Diagrams (similar to BNF/EBNF grammars)
      ERD - mainly database stuff
      UML - complex C++ systems and recently for Erlang gen_servers 
      MSD - message sequence diagrams
      StateCharts(and FSM diagrams in general)
    

They are all useful for documentation or for meetings as a communication tool.

When working on huge waterfall projects in C++ I just wrote the code stub
first and then run reverse engineering tool for UML class diagram generation -
it's easier than drawing the diagrams yourself.

The problem with UML class diagrams may arise in large organizations, when
Architects can be tempted to put many small rectangles on UML class diagram,
frequently forgetting, that each such rectangle can be days or weeks of work
for a programmer to fully implement, debug and test.

FSM and MSD are especially useful, even for non-OOP languages like Erlang/OTP.

If you learning new grammar or writing parsers - Syntax Diagrams can be useful
too.

In recent years I just switched to using web-based and offline tools to
generate diagrams from text (GraphViz/dot/msd/ditaa/etc.)

------
wglb
You could think of a hierarchy of programming approaches:

1\. Waterfall 2\. UML/OOA&D/RUP/Iterative 3\. Agile 4\. JSC

These are listed in decreasing order of ceremony. You can find "real"
developers, somewhere, using all four of these.

A better question might be, at least in this community "will UML be useful for
my startup". My answer to that question is "check out state diagrams and
sequence diagrams and leave the rest behind" and use some form of Data Flow
Diagrams.

In a very young project, it is likely that you will need to throw out the code
you have written and start over. The less ceremony (translating to time) you
put into the stuff that you throw out, the better off you are. If you are
working in a category 5 CMM outfit, then that is a whole other story entirely.

By the way, methodology #4 (JSC) is Just Start Coding.

------
zenocon
I used to use these tools much more extensively when working in more formal,
water-fall-ish, slow, more arcane development environments; nowadays I use UML
only for documentation after the fact. Specifically, the only place I use UML
is after feature X has been implemented and tested, and if it is reasonably
complex where just reading the code and tests can get you there, but a couple
of high level visuals with some text that describe design rationale would get
you there much quicker...well then, I try to be a good netizen and jot that
info down. Can't tell you how many times people have thanked me for that. That
said, UML is a lot easier to do this with vs. any other visual tool. It is
standardized, and most people can read it fairly easily. On a side note, I've
found Sparx Enterprise Architect to be the best tool out there for UML.

------
baddox
I wonder where the asker's degree is from. With the exception of entity-
relation diagrams in my Database course, my CS degree didn't touch any of the
things he mentioned (I haven't even heard of some of them). Even my DB course
didn't focus much on ER diagrams; a significant chunk was over relational
algebra.

~~~
epochwolf
There was one professor I had to deal with that required a UML for every
assignment, sometimes the UML was to be turned in before you got assigned the
code. In either case points would be docked if your UML didn't match your
code.

Solution? I coded all my projects before the UML deadline and turned in a
screenshot from XCode's UML generator.

(I had him for 4 classes using Java and C++)

~~~
JonnieCache
That's how I got through all my uni assignments that required UML. I just
hacked it together in the agile style and then generated UML diagrams in svg
after the fact.

------
known
Business consultants need UML to communicate with Tech guys.

------
TorKlingberg
I think it is difficult to get fair answers to this kind of question, because
mostly people who use UML will answer. All those developers who never use UML
probably do not know enough about it to feel confident criticizing. Or they
just find other discussions more interesting.

------
tristanperry
I'm currently doing a computer science (& maths) degree and within the CS
department there's two main degree schemes: information systems, and computer
science.

The latter is programming, i.e. the more technical side of things. The former
is more about the IT/business consultancy side of things.

The former group hate programming, but there's a large emphasis on UML and
other such 'design' 'tools' within their course.

We (the computer scientists) never tend to use UML or CASE tools though.

So yeah, I have no real World development experience yet (other than helping
out in a couple of relatively big online projects), but it does seem to me
that programmers ('real developers', as the title puts it) don't use UML and
other such 'tools', whereas the IT consultancy side of things tend to use
them.

------
petervandijck
Web developers, not really.

~~~
ssn
What do they use?

------
motters
Personally I don't. I started off with data flow diagrams and similar top down
design methodologies which I'd been formally taught, but it's very difficult
to keep your software and your diagrams in line and over time the diagrams
become more and more spaghetti-like, to the point where they're no longer
useful.

The best methodology seems to be the unix-like approach of dividing the
problem into small self-contained programs for dedicated tasks which are then
strung together as needed. This allows development to proceed in a flexible
way, without having to waste a lot of time re-drawing impossibly complicated
diagrams. Instead of a hierarchy of programs you can think of this as being an
ecosystem of programs.

------
gte910h
Not really. Generally speaking, some projects use a few of them for some
communication, but generally speaking, they're not used anywhere to the degree
they're portrayed they are in classes.

That said, I've seen them on white boards (and drawn them myself) or tossed
some in documentation occasionally, but they're relatively rare.

------
damoncali
Heck, I've never heard of them, let alone used them.

------
kersny
Real developers use the best tool for the job.

~~~
statictype
Except for all the times when Real Developers have to use tools which may not
be the best due to various constraints but they go ahead and do it anyway
because they're Real Developers and not Magpies looking for shiny objects.

~~~
kersny
Wouldn't that then be the best tool? Maybe not the best tool from an outside
standpoint, but given the circumstances.

~~~
statictype
True. Agreed.

------
astral303
The answer is NO.

------
myusuf3
I would say yes; alot in places where security is key. These types of model
are also generated when doing different types of analysis as well. Day to day
use not alot but when you getting familiar with something its priceless.

~~~
spinlock
This is a great point. We always focused on safety critical applications when
I was in school but security is another area where having a clear and
consistent architecture is a hard requirement. This is a great example of an
area that would benefit from having an analyzable framework in place.

------
bkaid
Getting my masters in computer science was the only time I ever used those
tools (thankfully). It was somewhat helpful to learn a few of the UML diagrams
as they are referenced in design pattern books, etc. - but I've never had a
desire to create my own diagrams, let alone use a tool to create them for me.

~~~
smhinsey
To me, being familiar enough with UML to sketch efficient and consistent
diagrams on a whiteboard or whatever has justified the time spent learning it.
I don't care about absolute correctness, but just having the reserve of ideas
to draw from when you are trying to communicate a complex idea to a group of
people has proven valuable to me throughout my professional career.

------
HelloBeautiful
This is a funny topic. The best developers generally solve a problem by using
high level abstractions. They would usually (in my humble experience) make
some drawings on a piece of paper or a white board, before writing any code.
UML&Co tried to teach average developers this method, but lost focus, bloated
and are hated by real developers nowadays.

BTW this is the best book on UML and software design I've read:
[http://www.amazon.com/gp/product/020169946X?ie=UTF8&tag=...](http://www.amazon.com/gp/product/020169946X?ie=UTF8&tag=arbeidsgivere-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=020169946X)

