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?"

Comments

Judging by the bevy of replies...

[FooAtWFU]

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.

Re:Judging by the bevy of replies...

[Unoti]

It's dead. The effort for reward ratio isn't there, just like EJB. Some things are great ideas, like sequence diagrams, but generally it's just a big pain in the ass way to annoy your coworkers and mystify your bosses.

pieces can be usefull

[gbr]

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.

Re:Annoying

[Yetihehe]

Yeah, I tried to use UML for modelling, but it looks like EVERY time I need to do my code and then make adjustments in model. UML should be just used for high abstraction stuff, but then it is really better to just do it with custom blocks instead of strict.

in summary:

[blackcoot]

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.

Re:in summary:

[SuperKendall]

The thing is, if a feature of UML requires a certain level of training or tools to understand and/or use, it's essentially the same as that feature not existing. Should developers spend time keeping up with UML, or technologies more closely related to actual development?

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.

Re:in summary:

[blackcoot]

your argument is pretty weak. because MRI's require a certain level of training and tools to understand and / or use, it's essentially the same as an MRI not existing? does the same apply to FEM, CFD, circuit simulator, or any other package that requires more training than office to use effectively?

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 legislation, accountants to stay abreast of IRS audit requirements, etc. continuing education is a pretty standard part of any profession.

Re:in summary:

[theCoder]

UML is not a tool. UML is a notation used for communicating software design ideas between developers. If a portion of UML is not widely known, to the point that only one or two people on a software team readily understand it, then it is essentially not worth it and it might as well not exist. Remember that UML should be used to help developers talk to other developers about the software they are developing. UML for the sake of UML (i.e., not using it for effective communication) is pretty worthless.

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.

Re:in summary:

[SuperKendall]

your argument is pretty weak. because MRI's require a certain level of training and tools to understand and / or use, it's essentially the same as an MRI not existing? does the same apply to FEM, CFD, circuit simulator, or any other package that requires more training than office to use effectively?

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.

Re:Universities teach this stuff

[Speare]

I personally cannot comment on how good UML is industry, I'm just a 1st year student at uni. But it seems to be a bit daft to be teaching a dying tool/language to fresh university students. By the time we get out at industry, nobody might use it any more. Erm, wake up, young pupil. A University is not a trade school. Don't expect to learn tools, expect to learn how to structure your thought to solve problems.

Good In The Beginning, and At The End

[quakeaddict]

...but not in the middle.

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

[Tumbarumba]

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.

UML is a cripple trying to climb to the moon

[benhattman]

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.

Re:Universities teach this stuff

[Anonymous Coward]

Then again, if those .net apps are in C#, the experience you got with java, C and C++ is directly useful, because the languages themselves are quite close. If you had been taught the same concepts in, say, lisp, the practical aspects of implementing it would have been harder.

I agree that the hard part is the underlying ideas, but you do have a certain competitive advantage because your university chose a mainstream family of languages. ;)

Re:Just le

[EnglishTim]

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...