Slashdot Mirror
Is UML Really Dead, Or Only Cataleptic?
danielstoner writes "Recently UML was pronounced dead as a tool for all programming needs by an article posted on Little Tutorials: 13 reasons for UML's descent into darkness. The author suggests UML was killed by, among other causes, greed, heavy process, and design-by-committee. Is UML really a fading technology? Is it useful beyond a whiteboard notation for designers? Is there any value in code generation?"
Uh yeah, I hated it too, I couldn't express things I wanted well in this strict language, and then there were the people who'd make ridiculous things consisting out of 4 different diagrams with blocks with words in them that contain no info (just repeating the title), and 1 stick figure and 1 arrow, for the most simple things, that made no sense at all except for laughing at. I can express things much better and make people understand it much better in free-to-do-what-you-want diagrams, than in UML.
We just don't let the executive team know we're using it, lest they read all the hype about it on the internet and get the idea we can draw the pictures and code just writes itself.
We often find the "loopholes" in our methodology by drawing it out first. We plug those glaring holes. Then start coding. At that point, the UML becomes historical.
My ZooLoo
Until 2005, the core programming curriculum at the community college I attended was COBOL. I was actually the first programming major to graduate with no COBOL training, as I persuaded the dean to allow me to go the C/C++ route instead.
And no, COBOL is not entirely dead, but it is moribund on the market in general, and used only in very specialized environments with low employee turnover in this area.
The reason COBOL was still used at that school had nothing to do with the needs of our area industry, and everything to do with academic inertia. Fortunately, the year I graduated, the three "COBOL holdouts" all retired, and the department was able to implement other language tracks and areas of specialization.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
Don't worry, there'll be jobs for people like you. I just spent time working on a two-year project where some cockfag consultants said they could spend 10 months creating the various UML diagrams, convert the diagrams to code in 1.5 months, test for two weeks, and deliver to the client.
So what actually happened? They spent 18 months putting together various diagrams. They tried to automatically convert their diagrams to C++, and found that the closed-source code generation tool they were using crashed on the diagrams they had come up with. So they panicked and tried to write a conversion program themselves. After another three months of that bullshit, the managers canned those sorry assholes.
My team was brought in, and we got their app finished in three months. We used Ruby, and didn't bother with C++ and especially not with UML. UML is shit, through and through. Any idea it can express can be expressed just as easily with a rough sketch on a napkin. And it should never be used for real application development of any sort. It always fails in this respect.
As one who had UML as a required course when working on my degree, I can personally say that I hated the whole idea of it (I did fine in the case - got an A, just hated UML).
To me, a diagram of that nature should simply provide an overview. When you start introducing rules on diagram format and such, it really starts to grate me.
My professor in that class even stressed how cool this UML utility was (I can't rememeber the name but it was some Java app the university had site licensed) because it could convert your diagram into basic code (just function names and such - you had to write the real meat'n'taters part). Sad thing was that by the time most people could get the perfect UML diagram of their program created for it to create that skeleton program, most people could have written a freeform diagram, hand coded the skeleton program, and written 20-30% of the actual code.
I'm not saying that people shoudl just dive in and start coding with no planning, but UML was just beyond tedious.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
did you use just Ruby or Rails? Rails attempts to solve similar problems that UML does. Frankly Rails does have a neat way of allowing more organic development, forcing you to build structures with tracking of each change along the way. I think more languages should start similar ides of tests and promotions... without the up-front paperwork.
You would believe it was dead. There are only 2 engineers, myself and another fellow in a different office, that use UML for design. The opposite in the company is no design at all, or very loosely worded documents.
If I get hit by a bus... at least someone will be able to understand what the hell I was working on.
this is my sig, there are many like it, but this one is mine.
And there's the issue. The only time I ever found UML useful in the context of an entire system was when I had a 20' long whiteboard at my disposal. The team and I were trying to figure out just exactly how the hell the system we were designing was going to work. What classes / associations / attributes did we need? We each grabbed a different color marker, and drew what we thought worked. Then we took a step back, talked about it (pointing out and circling as needed)-- then wiped out what didn't work and kept going.
After that we sketched out a pen-based copy that had the pertinents, and went on to coding. I think we referred to the pen stuff once or twice.
As a designing tool, it was fine. As a documentation or coding tool, it would have sucked. It would have taken hours, if not days, to create that diagram in Rose, and we'd never have been able to collaborate on it, nor see the entire system laid out before us.
UTF-8: There and Back Again
The thing about UML is that it's supposed to be a step on the path to designing software automatically. Unfortunately, it very slanted towards translation into C++ (and maybe Java). This bleeds into the problems you mention with strictly defined semantics of visual cues developers treat loosely at best. Moreover, OOP is itself slowly dying for all the right reasons, though not as quickly as you might think.
I've seen an interesting theory floating around in multiple places that dataflow languages, visually represented as DAGs, might be a suitable replacement for OO/UML. The trouble is they've all bought into web centric software and AJAX, which runs like ass in the best cases, and looks like ass in the worst. I've been pondering recently how I might formalize the computing technique and generalize it to effectively define a dataflow middle language that could be implemented in whatever language and platform you like, unlike the heavy C++ slant of UML.
I Browse at +4 Flamebait
Open Source Sysadmin