Slashdot Log In
Is UML Really Dead, Or Only Cataleptic?
Posted by
kdawson
on Sat May 31, 2008 01:56 PM
from the pining-for-the-fjords dept.
from the pining-for-the-fjords dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
"Is UML Really Dead, Or...." (Score:2, Funny)
Sorry
Judging by the bevy of replies... (Score:5, Insightful)
Re:Judging by the bevy of replies... (Score:5, Funny)
It feels happy! It feels happy!
Parent
Re: (Score:3, Insightful)
pieces can be usefull (Score:5, Insightful)
When using specific sections/sub-sets of UML, it can be an effective tool in the software development process.
Re:pieces can be usefull (Score:5, Funny)
stop there -- finishing the sentence won't add any information
Parent
Get into government contracting (Score:2)
Re:pieces can be usefull (Score:4, Informative)
Parent
Re: (Score:3, Interesting)
I've seen an interesting theory floating around in multiple places that dataflow languages, visually r
Annoying (Score:3, Interesting)
Re:Annoying (Score:5, Insightful)
Parent
Re: (Score:2)
Not that I like UML for designing my application, but that's another matter. Having a class design be generated automatically after implementation can be a huge win (if the design is not to complicated I will do it inside my head instead of using an overcomplicated squ
User Mode Linux is not dead (Score:5, Funny)
in summary: (Score:5, Insightful)
congratulations. this was obvious back before 1998 and certainly a long time before then. unfortunately, the "article" was written by someone who doesn't really grok uml. specious claims include: "No solution for multi-tasking and communication between tasks" which is false as of UML 1.4 (active v. passive classes, message diagrams)" and "No dependency between use cases" which is also false --- add an association with the > stereotype.
there are some legitimate gripes (i think they could have chosen more distinct shapes), but most of that list is a laundry list of bitching and moaning by a person who hasn't actually developed the requisite level of proficiency with uml to actually understand how to use it well.
Re:in summary: (Score:5, Insightful)
Sure UML can be/has been extended to handle other things like that, but it's also the reason the spec is so huge that few people can really make use of it all. In the end a lot of times people spend more time on the UML than they would have doing simpler diagrams and iterating through a project a few times, willing to discard diagrams as scaffolding instead of dictating it as a rigid structure to which a project must conform forever.
Parent
Re: (Score:3, Insightful)
the short answer to your question is: both. developers should keep up with their tools, the same way i expect doctors to keep up with new treatments and diseases, lawyers to keep up with recent decisions and new
Re:in summary: (Score:5, Insightful)
Of course, UML used for communication like design and documentation, especially at a high level, is a good thing. Just don't go UML crazy and think that every little detail of the system has to be documented in UML. You'll probably end up spending more time doing UML than you will making the actual system.
Parent
Re:in summary: (Score:4, Insightful)
As the other poster noted UML is a means of communication, not a tool in and of itself.
Can you get a brain scan without an MRI? No. Can you work through issues without a circuit simulator? Yes but it will add a lot more time.
In each of the cases you present there is a clear benefit to use, either in terms of knowledge you could not otherwise attain, or in clean and easy to understand time savings.
To a point UML produces time savings in that thinking about things ahead of time can save trouble later. But when UML comes into a company, UML use goes beyond that point to where it's pretty obvious to developers that more effort is going into UML work or maintenance than is going into actual development, with decreasing returns in quality and certainly a loss of time to delivery.
So then good knowledge of the simply aspects of UML is pretty much mandatory for a good software developer, because it aids in communication. But knowing all the edges of UML, training every person on a team to do so - that is an utter waste of time and effort. Thus some of the more advanced things UML is adding on later simply do not matter and in fact should be avoided so as not to create confusion in your documentation.
Parent
Re: (Score:2)
specious claims include: "No solution for multi-tasking and communication between tasks" which is false as of UML 1.4 (active v. passive classes, message diagrams)" and "No dependency between use cases" which is also false --- add an association with the > stereotype.
Wow, you really nailed that one criticism there! I bet the other 12 are just as specious as this one!
Oh wait, no I really don't. In fact, the other 12 ring very, very true. Please, let UML die already! The world doesn't need silly box-diagrams that are hard to draw (even with a "proper" tool like Rational Rose), hard to understand, hard to maintain, and convey little to no information.
Re: (Score:2)
1, 3, and 5 are redundant ("oh noes! it's big!"). they're also pretty weak. IEEE1394 is a pretty big standard (especially by the time you factor in all the standards it's built on). ditto USB, various flavors of PCI, XML, IEEE 802.3*, IEEE 802.11*, etc. does that mean we shouldn't use those standards? or does it mean that the specifications are as complex as the processes / protocols / etc. that they define?
4, 6, 7, 13 are also redundant and a misunderstanding of what uml is meant to do, which is
UML great for design (Score:5, Interesting)
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.
Re:UML great for design (Score:4, Informative)
Parent
Re: (Score:2)
We use it... (Score:2, Informative)
Good In The Beginning, and At The End (Score:3, Insightful)
Its great to focus your thoughts early. Its great to document those abstractions at the end, but trying to have the model keep up with the code as it is being developed for real is a complete waste of everyone's time.
UML as a sketch versus UML for MDA (Score:5, Insightful)
I find UML very useful when I'm thinking about some classes I'm about to write. I can draw out a few rough boxes to represent classes, and get a view of how my various classes can interact. The way I do this is a very quick processes, but it helps get a view of the way that some software components can fit together before I jump into coding. The sketches can often help initiate design discussions. In this way, I'm a using UML as a sketching tool [martinfowler.com].
At the opposite end of the spectrum, you can buy some very expensive tools that let you try to capture every single nuance of the software in the UML diagram itself, and the code is generated directory from the UML model. This Model Driven Architecture (MDA) [wikipedia.org] approach tries to treat UML as a programming language [martinfowler.com], and I think it fails horribly. I think writing code by manipulating boxes and arrows in an MDA tool is a terribly inefficient way to develop software, though there are many vendors who will try and tell you otherwise.
In summary, I think using UML as a rough way to sketch out software design is still a good way to go. Using UML as a programming language has never been a good idea, and probably should die.
I use it backwards... (Score:5, Funny)
Sounds good (Score:5, Funny)
Parent
UML is a cripple trying to climb to the moon (Score:4, Insightful)
Of course, it had some limitations...like even though it compiled to C++, it ran slower than the Ruby running in an interpreter written in Python, which is itself running on an interpreter written in Smalltalk, which is running in another interpreter written in Smalltalk (since Smalltalk always runs on itself).
It also had the limitation of not being able to actually do anything at all. People complain when Java can't produce "native looking graphics", or if any interpreted language doesn't have direct access to ports when they need them. Imagine instead, a language with no direct access to anything. Want to connect to a socket, you'll need to link to C++ code for that. Want a GUI, you'll need C++ code. Want to write to a file, write some C++ code. Want to write to the console (seriously), then write some freaking C++ code. If 80% of your real code is still in C++, and the rest runs at sloth speed, it's not hard to call the Executable UML solution a solution at all.
So far, the issue has been with the pseudo code language they used to tie the pieces together, but in my experience UML is not suitable for fully designing a project either. If you fill out each of your classes completely, how many can you look at at a time? In my experience, you can only put about four classes on the screen at a time. Anything more and you've got to overlap the diagrams to a degree that it becomes unreadable. Until I get a 75' monitor, this is going to be a problem. Yes, if I could see everything all at once I might be able to visualize a complex problem more fully in UML, but since I can't, it doesn't do any good. This is the real reason UML has little future. It is excellent for diagramming simple constructs. If you read Gang of Four, their ideas are all concise and easily written in UML. But if you want to build a full system, UML is too bulky. A text based synopsis of each class would probably be more valuable, and could probably be mostly generated automatically.
So in summary. UML is a cripple trying to climb a ladder to the moon.
Re: (Score:2)
Dude, you just buried a joke under avalanche of words.
Re: (Score:3, Interesting)
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,
13 reasons that X, Y, Z (Score:2)
Booch notation... (Score:2)
It's a bunch of shapes connected by lines (Score:2)
- It's a bunch of shapes connected by lines.
Re: (Score:2)
Hated it (Score:3, Interesting)
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.
Re: (Score:3, Funny)
Re:Just le (Score:5, Funny)
Parent
Re: (Score:3, Informative)
Re: (Score:2)
Re:Just le - Remember Jackson & Ward/Mellor &a (Score:5, Informative)
This was all part of the set of diagraming methodologies for structured programming. They are all gone now, which is unfortunate, and they have lessons for today's object oriented world. Which is to say that we're now re-living the same evolution for object oriented systems. The results will probably be the same. System generation from diagrams (now called MDA) probably isn't worth it.
For the uninitiated, Jackson (structure charts) and Ward & Mellow (real-time system modelling) were diagramming methodologies to help design systems written in structured languages (assembly, COBOL, FORTRAN, C, etc.). There were lots of others, but I can't remember all the names.
It all culminated in CASE (Computer Aided Software Engineering). Which, in it's extreme form, called 'strong case', was trying to be a CAD system for replacing programming. Like today's UML the intent was to generate code directly from the diagrams. It didn't work too well on real projects and gradually faded away.
There was also a 'weak case' faction, that wanted to use the diagrams merely to do early design and document the resulting system. The intent was to have a lingua-franca in which you could quickly express design concepts using a simple standardized notation. This is where ULM started. It not a bad idea, as long as you keep the diagramming system fairly simple, which means it won't be rich enough to generate code from.
The 'strong case' equivalent in the object world is MDA (Model Driven Architecture), which from what I've seen and read about is doomed to failure. I believe that the diagram to code gap is just too large and the programming detail required to actually implement a system is too difficult to capture in simple diagrams (which is what you want in the design stage).
Have a look at Pros and Cons of MDA Code Generators? [slashdot.org] and my experience on a MDA project [slashdot.org].
I suspect frameworks, like Struts and the like, are a much better approach.
Parent
Re: (Score:3, Interesting)
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 th
Re: (Score:3, Interesting)
Re:Just le (Score:5, Insightful)
Oh, and there's already a bunch of software out there that makes it easier for you to draw UML when you store your docs on a Wiki or something, rather than a large napkin server...
Parent
Re: (Score:3, Interesting)
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 re
Re:Universities teach this stuff (Score:4, Insightful)
Parent
Re: (Score:2)
You must be new...never mind.
Re: (Score:3, Informative)
Of course there's a difference. If the moderators agree with you, the post is informative. If they disagree, its a troll.
Re: (Score:2)
Re: (Score:2)