Fog Creek Software
Discussion Board




UML

UML is one of the current "silver bullets" - Every application manager (not the people actually developing, but the people looking to herd the developers) talks about "looking to start using UML". I have talked to at least 6 of them making this observation. Worse still, it is the most inane diagrams that seem to get attention, like the worse than nothing "use case" diagrams (these things are such spectacular wastes of space that it boggles the mind).

Yet we all pull an anoop and nod our head in agreement.

This industry is such a fraud.

.
Friday, August 27, 2004

I like UML, at least as we use it.  We don't use use case diagrams - we write use case outlines.

However, the environment you're in...  That's why I left my former company.  Except we had herds of PMs "managing" a handful of developers.

hoser
Friday, August 27, 2004

I also like UML. It is a good way to model the real world and to design a system.  It isalso of great utility when maintaining other programmers code... you know it's not always to make your code more efficient but to make it fit the specifications and the client's needs.
I may go for other methodologies/modeling languages though. But I will always encourage developers to use any to model the system (real world) and then the software.

Cecilia Loureiro
Friday, August 27, 2004

UML is very useful, especially in mid-big projects involving many people. But be sure you will finish with production, not diagrams :)

Evgeny Gesin /Javadesk/
Friday, August 27, 2004

UML is one of the key object modelling formal methods you'll learn at university (in Portugal at least), you won't get by without knowing at least the basic principles, and i think no one should be doing commercial grade programming without knowing it, IMHO.

cheers

Platini do Valado
Friday, August 27, 2004

Many people forget the L in UML stands for language. I personally find English a better language to communicate design. Unfortunately some people around here are happier when they can't understand the design documents.

Devil's Advocate
Friday, August 27, 2004

I tend to agree with the OP. I've had to use UML in projects where it seemed like a big waste of time. Hardly found any design problems with it. I think used selectively, it may be useful for communicating functionality (sequence diagrams for complicated interactions, for example). But going the whole UML way is probably unnecessary overhead.

Also, I think using agile programming languages <plug> like Python </plug> greatly eliminates the need for UML because redesigning and maintaining code is easy. Perhaps Java benifits more since you'd better design those thousands of classes before or you'll have spend thousands of hours doing little tweaks.

Shalabh Chaturvedi
Friday, August 27, 2004

"UML is one of the key object modelling formal methods you'll learn at university"

Yeah, the same everywhere. My point wasn't that I don't understand UML, but rather that it is an absolutely classic "cargo cult" technology - someone, somewhere used UML to great effect, so every anoop parrots how great and important it is.

.
Friday, August 27, 2004

"I also like UML. It is a good way to model the real world and to design a system....blah blah blah"

Fuck dude, we're not interviewing you for a job here so you can can the bullshit. Clearly you've never designed a real system, or dealt with the disparity between the useless paper trail and the real system. I have. I've seen some elements of UML of some value, albeit as marginal elements of a much more complex methodology (if I had to choose a core element it most certainly wouldn't be the mythical UML), but I've also seen countless Anoops yapping endlessly about how important UML was, and how every team should use it, blah blah blah.

I am absolutely certain that 99% of the people advocating UML have never used it outside of a classroom setting, and know just enough to bullshit their way through an interview, convincing a cargo cult manager that they'll bring UML skillz to the table and set everything right.

.
Friday, August 27, 2004

I have to agree with "Devil's Advocate", above.

That said, at a previous job, we had a seminar on UML and Rational Rose from Doug Rosenberg, who gave us some of his VB macros for generating Word documents from Rose.  If you actually wrote sentences in your use cases, class diagrams, etc, you'd get a decent start at a written spec when you were done.  Reasonably nice Word templates to pad it out and make it look like a formal report you'd spent some real time on, too.

I ended up scaring my next boss at that company with Rose and Iconix's macros by spending an hour or two diagramming up a real loose spec we'd discussed.  I was able to drop a 15-page spec on his desk that afternoon...  not that there was much there but formatting, but it's not like he sat down and read through it, either.  (and it could have been fleshed out)

Brent
Friday, August 27, 2004

The best thing I have read on why UML is the following

http://www-106.ibm.com/developerworks/rational/library/3760.html

Here is a snippet:

"But before 1996 there was no common notation for software. Before the UML became an international standard, two software engineers, even if they spoke the same language, had no way to talk about their software. There were no conventions that were universally accepted around the world for describing software. No wonder progress was slow!"

I sympathise with the cargo cult cries, but at least if you go by uml you are close to an objective standard. Where I currently work each BAA has their own standards (or lack of). It's crazy.  You talk about agile ... it goes from a don't you know to how come this thing I whispered about is not working right as opposed to we need to make these changes for the next iteration for this thing which we can't identify cus we don't know what it is yet. Most of these so-called agile/xp systems remind me of a kid when I would just doodle and something would come to mind or worse I'd read a design into my doodling.

me
Friday, August 27, 2004

Have  a look at the UML section in the new Crystal Clear book:

http://alistair.cockburn.us/crystal/books/alistairsbooks.html

Regarding the idea that UML is an essential common language for software engineers: while it is useful, good software engineers are quite capable of communicating effectively with, or without, UML.  (Are our communication skills so bad that we cannot communicate without a standard diagramming convention? I don't think so.  In fact, at least 90% of the diagrams I've seen on whiteboards are not 100% UML compliant.  They combine bits of UML with whatever gets the idea across most effectively.) 

John Rusk
Friday, August 27, 2004

And of course, the number-one used diagram, the classic flow chart, is not UML.

Les C
Friday, August 27, 2004

UML or any other language  is useless if not used correclty to document an architecture.

I found a lot of insight in Paul Clement's Documenting Software Architectures.

It shows that it is not the diagraming languaje, but the completeness of the graphical representation of combined views the thing that works.

.NET Developer
Friday, August 27, 2004

"I sympathise with the cargo cult cries, but at least if you go by uml you are close to an objective standard."

Yes, this is a common business model in the IT industry.  Consultants (in this case Martin Fowler and his cronies) sell the boondoggles of the day as "standards," and oh-by-the-way buy my book as a reference, too.

My point being:  that UML is a standard, or is becoming one, is a self-fulfilling prophecy, and has nothing to do with the merits of UML itself.

In my experience, working for a company that worships UML on all fours, the notation is rather flaccid.  It "standardizes" a few simplistic views of software, and then leaves it to the user to figure out a reasonable means to tie them together.  That's harder than it sounds, especially when UML is being presented to management.

And despite the simplicity of UML models themselves, they're still a pain to actually create and share.  The WYSIWYG nature of most UML modeling tools ensures that you spend a lot of time moving boxes around on a screen, rather than actually thinking about your system's design (and no, most auto-format features I've used don't work worth a damn).

indeed
Saturday, August 28, 2004

UML is a communication tool.
When you want explain something about your code, without going into low level details, then the best way to start is a class diagram/sequence diagram.

Same goes for design patterns; good for communicating ideas; nothing more nothing less.

Michael Moser
Saturday, August 28, 2004

UML's a nice way to write down descriptions of systems, and I think a lot of companies could do a lot worse than throw out their ad-hoc Word based "documentation" and shift to something which is firstly formal and secondly portable.

Where it fails is in the sales pitch that you write UML and working code falls out of the back end of the process. It's the thing that fails with ALL these methodologies; the assumption that you can turn software creation into a purely mechanical process executed by (cheap to hire) morons. The reason XP is working so well is that currently it's being done by the best people around who are picking it up and playing with it.

Give it to the morons, and they'll write shite with it., just like they do with UML and, in fact, waterfall.

Companies aren't going to switch to using formal notations for their "specifications" anytime soon for two reasons. The  first is that because the moment they do that, the holes in the specs will start showing up. They'll blame the methodology for not allowing them to not spec things properly and we'll all go back to waterfall where the input is a Word document saying things like "verify the username is valid by verifying it correctly". The second reason is that every company will find some (stupid and invalid) reason for believing that UML is "too general" to describe their own special class of problems and they'll half-implement a broken non portable version of UML internally at great expense but lots of opportunities for nice job titles and reserved parking spaces.

Yes. It's been a rough week.

Katie Lucas
Saturday, August 28, 2004

The fact that anyone can describe UML as "formal" and keep a straight face is indicative of the utterly dismal state of the industry. UML is a horrendously complex set of informal descriptive mechanisms - "industrial-strength hand-waving" is the most accurate description I've seen. And even with all that vile bloat, they still had to create OCL in a vain attempt to add a bit of precision.

And as for the idea that before 1996 software engineers had no way to talk about their code! Young people!! You crack me up!!! (Cue rant from muppet)

Grumpy old fart, and getting grumpier by the second
Sunday, August 29, 2004

I think the author made common mistake:
he confuses UML with Unified Process.
UML is language intended to describe design of system.
It is good - because it gives you are COMMON language to describe design between number of people without saying - this box is class -and box inside box is sub system and e.t.c.
Unified Process (Rational Unified Process - RUP) is methodology of designing software. It needs a lot of training to get used to it. Sometimes it successful but sometimes not…

Leonid
Monday, August 30, 2004

Turn your diagrams into code, make the code work and then get your code back into diagrams. See what's changed and more importantly why it's changed.

Then you'll have pertinent comments on UML diagrams. Including on the limitations of the UML.

This industry is not a fraud; it's just incomplete or inconsistent :-)

PS Joel would describe it as a leaky abstraction.

Dino
Monday, August 30, 2004

When code needs to be written, someone has to carry out the analysis and design.  I do not find use case diagrams particularly useful because I have to type in the description anyway, it is easier to write a well formatted documet with my uses cases numbered.  When documenting classes and the relationships between them, it is easier to use UML.  Class , sequence and collaboration diagrams are far easier to write and understand than textual description.

One caution though,  you do not have to use each and every one of the diagrams available from the UML standard.  I have had very few uses of State diagrams in my work.  I only use what I need.

Amon
Tuesday, August 31, 2004

IMHO Managers are interested in UML because they are more concerned with the problem that the software solves than with the software itself.  If you see the problem from their point of view, you have:

Problem/Real World ---> Model of RW --- > Specifications of the System -- > Software/Code

UML helps to standardise the language between all the stages.  So managers, coders and clients can be sure they are talking about the same thing.  If one focuses only on the last stage (coding) the benefit of UML cannot be appreciated on its totality.

Cecilia Loureiro
Thursday, September 02, 2004

"This industry is not a fraud; it's just incomplete or inconsistent”

Dino, I completely agree.

Cecilia I think your diagram would look better if you add an extra stage:

Problem/Real World ---> Model of RW --- > Analysis of Requirements -->
Specifications of the System -- > Software/Code

I don’t think UML is the silver bullet, but yet there is nothing better than can cope with the above.

TheFBIgaveMeANewIdentity
Thursday, September 02, 2004

*  Recent Topics

*  Fog Creek Home