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?"
Judging by just how many people have bothered to reply to the story so far, mmm, I'd say there's a good chance it's dead.
The World Wide Web is dying. Soon, we shall have only the Internet.
shit, i just payed for a course :(
UML as whole can be cumbersome and difficult to manage. A smart manager and developer will pick and choose the components of UML that best fit their development process, and use those.
When using specific sections/sub-sets of UML, it can be an effective tool in the software development process.
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.
Don't be confused.
You are being MICROattacked, from various angles, in a SOFT manner.
uml as practiced by uml fetishists is a bad idea.
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.
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
[
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.
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) approach tries to treat UML as a programming language, 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.
My business: Farstrider Studios.
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.
...I write the code, and then generate UML with doxygen to figure out what the hell I just did.
I worked on a project that was using "Executable UML". Executable UML by the way is what happens when some numb-nuts looked at UML and said to themselves "Hey! In certain circumstances, this stuff can be used as a high level abstraction prior to writing code." They thought that sounded like a great thing, so they did the only rational thing to follow. They hacked together a programming language that almost could be used to write actual code in UML.
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.
I'll use that next time somebody asks.
You should've enrolled into a spelling course instead. Would have proved more useful.
I'm much more funny, interesting and insightful than the moderators think
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? and my experience on a MDA project.
I suspect frameworks, like Struts and the like, are a much better approach.
---- It won't be as bad as you fear or as good as you hope, but it will take twice as long as you plan.
I would say that UML is useful just to make sure everybody's using roughly the same notation on their napkin diagrams.
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...