Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is UML Really Dead, Or Only Cataleptic?

kdawson posted more than 6 years ago | from the pining-for-the-fjords dept.

Programming 156

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

cancel ×

156 comments

Sorry! There are no comments related to the filter you selected.

Just le (1, Funny)

Anonymous Coward | more than 6 years ago | (#23611507)

Shit, i just learned UML :(

Re:Just le (3, Funny)

MR LOLALOT (1286276) | more than 6 years ago | (#23611587)

shit, i just payed for a course :(

Re:Just le (5, Funny)

wannabgeek (323414) | more than 6 years ago | (#23613767)

You should've enrolled into a spelling course instead. Would have proved more useful.

Re:Just le (2, Informative)

antek9 (305362) | more than 6 years ago | (#23611837)

Dang, I just bought a book on UML 2. I should have read the writing on the wall, though: it was heavily discounted...

Re:Just le (1)

Z00L00K (682162) | more than 6 years ago | (#23612047)

Anyone remember Jackson Structured Programming?

Michael Jackson Structured Programming Re:Just le (0)

Anonymous Coward | more than 6 years ago | (#23612335)

Is that the one that came with the glittering glove and free candy? It had syntax like

useBoi();
while (line != in.Boi) {
        line = in.Boi;
}

Re:Just le (3, Interesting)

Anonymous Coward | more than 6 years ago | (#23612223)

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.

Re:Just le (2, Interesting)

mabhatter654 (561290) | more than 6 years ago | (#23613661)

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.

Re:Just le (-1, Flamebait)

jo42 (227475) | more than 6 years ago | (#23612453)

One can only hope that XML is next to die...

Re:Just le (0)

Anonymous Coward | more than 6 years ago | (#23613549)

Ha ha!

"Is UML Really Dead, Or...." (2, Funny)

Anonymous Coward | more than 6 years ago | (#23611559)

...is it just pining for the fjords?

Sorry :(

Yes, UML is really dead. (1, Funny)

Anonymous Coward | more than 6 years ago | (#23611569)

Netcraft confirms it.

Judging by the bevy of replies... (5, Insightful)

FooAtWFU (699187) | more than 6 years ago | (#23611577)

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... (4, Funny)

Yvan256 (722131) | more than 6 years ago | (#23611781)

It's not dead, and it wants to go for a walk!

It feels happy! It feels happy!

Re:Judging by the bevy of replies... (0, Redundant)

mobby_6kl (668092) | more than 6 years ago | (#23612141)

It feels happy! It feels happy!

I'm not so sure. Looks like it's pining for the fjords.

pieces can be usefull (5, Insightful)

gbr (31010) | more than 6 years ago | (#23611589)

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:pieces can be usefull (4, Funny)

legirons (809082) | more than 6 years ago | (#23611687)

UML as whole can be cumbersome and difficult to manage. A smart manager will...

stop there -- finishing the sentence won't add any information

Get into government contracting (1)

smitty_one_each (243267) | more than 6 years ago | (#23612069)

UML can be a fantastic way to manage a problem, so long as you hold before yourself the ultimate truth that a "government solution" is like a "smart manager".

Re:pieces can be usefull (3, Informative)

CastrTroy (595695) | more than 6 years ago | (#23613435)

UML is a nice concept. You draw little pictures to make it easier to understand the architecture and behaviour of your system. In university, we had a term for professors who were really pendantic about UML. UML Nazis. Really UML should just be a set of loose rules and semi conventions so that people can get the gist of what your program does. The UML Nazis try to turn it into more of a programming language, where everything is ultra specific, and where using a filled in arrowhead instead of an empty one is punishable by death. Which is the real reason UML died. Too many symbols that look almost, but not quite exactly the same which are supposed to represent different concepts.

Re:pieces can be usefull (1)

Evil Pete (73279) | more than 6 years ago | (#23613613)

Yeah. And UML is "unified", it was supposed to unify several approaches to the problem to simplify the process. More and more I notice it just getting overburdened. UML is very valuable as long as you don't try and swallow the whole lot. Just use what is necessary, and ignore the nazis (I hope this doesn't generate a Godwin Exception).

My 2 cents.

Re:pieces can be usefull (1)

theshowmecanuck (703852) | more than 6 years ago | (#23614475)

The Godwin Principle is bullshit. Sometimes comparing someone to a Nazi is apt.

Re:pieces can be usefull (0)

Anonymous Coward | more than 6 years ago | (#23614413)

Kind of like GNU Nazis. It must all be free free free. Ubuntu is bad because it allows proprietary code in it.... blah blah blah... religious nuts of a different stripe.

Re:pieces can be usefull (1)

SQLGuru (980662) | more than 6 years ago | (#23613595)

I was making pretty understandable drawings before UML that developers could use to create an application based on my design. I've looked at UML and most of the notation seems counter-intuitive based on my style. I've never really used it and won't unless someone upstairs puts it in my performance plan (and guess what, those are usually more about RESULTS than METHODS)......that being said, they have sometimes put some moronic things in my plan that I put personal comments around indicating just how moronic they are.

Layne

Annoying (3, Interesting)

Lord Lode (1290856) | more than 6 years ago | (#23611603)

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.

Re:Annoying (0)

Anonymous Coward | more than 6 years ago | (#23611649)

So, you're saying the "medium is the message"?

Re:Annoying (5, Insightful)

Yetihehe (971185) | more than 6 years ago | (#23611769)

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.

Re:Annoying (1)

EWIPlayer (881908) | more than 6 years ago | (#23611867)

Software design and development is refactoring. You learn and learn every day, improving the code and improving the model. Making a model in UML does not mean that it is that way for the rest of its life. It will change... sometimes daily.

Re:Annoying (1)

owlstead (636356) | more than 6 years ago | (#23612699)

That's why you need a toolkit that directly connects to the language and knows how to convert from one to the other (keeping in line with the code conventions for that language). For Java there are a few Eclipse plugins that manage to do this.

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 square/circle drawing program, thank you).

But seriously, if your tool chain cannot handle re-factoring, you've got yourself a big problem.

Re:Annoying (1)

hey! (33014) | more than 6 years ago | (#23614421)

Well, I've been at this long enough to see a number of methodologies come down the pike and then go down the pike. Most of them had some merit, few of them close to the kind of merit claimed for them.

The problem is inflated expectations, and UML was probably the worst case of inflated expectations ever. Having a shared notation is a good thing. Expecting a notation to think for you is foolish. Worrying about flaws in the notation more than flaws in the thinking represented (as often happened) is madness.

Re:Annoying (0)

Anonymous Coward | more than 6 years ago | (#23614175)

Y'know, I feel much better about the last Java and Data Structures classes I took (and failed). They were both taught by the same professor, who'd never had a job outside professorship since graduating from State College (Not even a University). He was extraordinarily pedantic about this, and also wasted a huge amount of time half-discussing internal cpu layout rather than details that actually mattered to the class in question (he did it in both the java and data structures classes, not just one or the other!)

Between him and a similiar professor at my current college, I STILL haven't finished those classes (which only have one option for who to take. And migraines do not improve my memory.)

User Mode Linux is not dead (5, Funny)

SpaceLifeForm (228190) | more than 6 years ago | (#23611679)

Don't be confused.

Universities teach this stuff (0)

Anonymous Coward | more than 6 years ago | (#23611731)

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.

Re:Universities teach this stuff (0, Flamebait)

Papabravo (1278230) | more than 6 years ago | (#23611821)

Do you think that professors could actually learn and teach something useful? That'll be the day...

Re:Universities teach this stuff (2, Interesting)

jeiler (1106393) | more than 6 years ago | (#23611933)

But it seems to be a bit daft to be teaching a dying tool/language to fresh university students.

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.

Re:Universities teach this stuff (3, Insightful)

Speare (84249) | more than 6 years ago | (#23612031)

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.

Re:Universities teach this stuff (1)

CastrTroy (595695) | more than 6 years ago | (#23613585)

A little harsh but I share the same views. In university, I did a lot of console/gui Java apps and C/C++ code. Now for work I'm doing .Net web applications. The programming field is so large that you will be unlikely to be using anything you learned in university in your day-to-day work. What you do learn in university is how to think about software and design, and how other things were designed, so that you can hopefully design a good system yourself (or with a team) one day. Most of the tools themselves won't be directly applicable, but the concepts learned will be directly applicable no matter how much the tools change.

Re:Universities teach this stuff (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23614141)

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:Universities teach this stuff (1)

Lije Baley (88936) | more than 6 years ago | (#23612077)

You're new at this University thing, aren't you?

Re:Universities teach this stuff (1)

doombringerltx (1109389) | more than 6 years ago | (#23612419)

And they also still teach assembly

Re:Universities teach this stuff (1)

kshade (914666) | more than 6 years ago | (#23613597)

And they also still teach assembly
And that's great! Assembler code is very close to the hardware you heard about in other courses and generally gives you deeper insight into the guts of a computer. Way better than these theory courses. And it can be used for fun projects with cheap microcontrollers.

in summary: (4, Insightful)

blackcoot (124938) | more than 6 years ago | (#23611775)

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: (4, Insightful)

SuperKendall (25149) | more than 6 years ago | (#23611949)

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: (2, Insightful)

blackcoot (124938) | more than 6 years ago | (#23612439)

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: (4, Insightful)

theCoder (23772) | more than 6 years ago | (#23612953)

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: (1)

bigsteve@dstc (140392) | more than 6 years ago | (#23614151)

Don't dismiss MDA as being expensive and useless. There are MDA-based tools out there that are free and do a pretty good job, once you figure out how best to use them. The best example is Eclipse Modelling Framework (EMF) which takes models specified as ECore models, an XML (XMI) syntax plus a stack of Java library code including, in-memory representation, instance editors, validators and persistence via XML serialization or SDO.

Actually, ECore is not UML. It really based on MOF which is the meta-model for UML. You can think of MOF as being a subset of UML object notation, with some of the more sophisticated UML object modelling features (e.g. N-ary associations, association classes, stereotypes, etc) left out. EMF augments the ECore model with a "GenModel" which allow the developer to tune various aspects of the code, etc generation. This is a concrete example of MDA's PIM/PSM view of the world.

EMF works, at least for some problem domains. I've used it successfully for two significant projects which involved representing, editing and using relatively complex metadata. The secret to using EMF successfully is to understand their limitations, and to not try to be too ambitious in what you do. For example, I would NOT try to use EMF to generate code for a fine-grained transactional system, or one that required browser-based editing.

Re:in summary: (3, Insightful)

SuperKendall (25149) | more than 6 years ago | (#23613707)

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:in summary: (1)

pla (258480) | more than 6 years ago | (#23614325)

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?

Yes. Languages (graphical or otherwise) exist for the purpose of communication. If your target audience doesn't know the "words" you use, you may as well babble incoherently to yourself.


continuing education is a pretty standard part of any profession.

My doctor can't optimally treat me without knowing the latest and greatest drugs. My accountant can't get me the most on my tax refund without learning the new IRS rules. But I can code just as well without even having heard of UML, as I could knowing it.


the short answer to your question is: both.

I have a finite amount of time. You can study dead languages if you want; I'll spend the time learning/improving "real" skills, thankyouverymuch.

Re:in summary: (0)

Anonymous Coward | more than 6 years ago | (#23613229)

The thing is, if a feature of a programming language requires a certain level of training or tools to understand and/or use, it's essentially the same as that feature not existing.

Re:in summary: (1)

johannesg (664142) | more than 6 years ago | (#23612415)

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:in summary: (1)

blackcoot (124938) | more than 6 years ago | (#23612759)

12? really?

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 *model* (see, right there in the middle of its name), as opposed to what the people writing the marketing blurbs for the tools are pedalling. this is a gripe with tool vendors' marketing departments and not uml.

an experienced uml user would know that 11 is pretty much total crap --- uml tools have supported round trip engineering (i.e. model a bit, regen code, mess with code, update model and the changes in the code magically appear) for quite a while now.

12 really irks me. if you are a software engineering professional, your job is to apply a process that starts with requirements, refines them, then converts them into detailed design specifications, implements that design specification, and finally validates and verifies that the implementation is correct. if you bemoan the use of process, you have no business working in software or anything even vaguely related to engineering.

8 i find particularly disingenuous. matlab costs just sy of $3k per license, and additional toolkits run $1-5k per license as well, for a "typical" per seat license cost between $7 and 15k. cad packages also cost thousands of dollars per seat. all that means is that the tool needs to make most people marginally more productive to break even.

2 is ridiculous. oh no! people want to make money!

in case you're keeping score, 5 of 13 claims are utter crap, with 7 of the 8 remaining claims being highly redundant. half of those claims relate to complexity, and half those claims relate to marketing hype. that leaves one gripe (#9) that i tend to mildly agree with. so really 4 claims, and a whole lot of ignorance and inexperience.

Re:in summary: (1)

tomhudson (43916) | more than 6 years ago | (#23613481)

if you are a software engineering professional, your job is to apply a process that starts with requirements, refines them, then converts them into detailed design specifications, implements that design specification, and finally validates and verifies that the implementation is correct. if you bemoan the use of process, you have no business working in software or anything even vaguely related to engineering.

... as opposed to how it's mostly done today, unfortunately.

BTW, my UML toolkit is a stack of 4x6 index cards and a pen, you ignorant clod!

Wow! (0)

Anonymous Coward | more than 6 years ago | (#23611777)

Five adwords ad boxes! If this isn't a blatant Slashdotting profiting attempt, I don't know what is.

And worst of all, all of the boxes are pushing UML tools. So obviously this critical article didn't help the advertisers either.

is this blog just trying to up their pagerank? (0)

Anonymous Coward | more than 6 years ago | (#23611795)

By submitting the same article with a slightly different wording to slashdot 50 times littletutorials is wasting our time.

UML great for design (4, Interesting)

fragmentate (908035) | more than 6 years ago | (#23611807)

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 (3, Informative)

GileadGreene (539584) | more than 6 years ago | (#23612049)

We often find the "loopholes" in our methodology by drawing it out first. We plug those glaring holes. Then start coding.
Pretty much anything you do to think through your design before committing to code will help to uncover inconsistencies and holes. It's just a question of what medium you use as your motivating tool to spur the "design analysis". Diagramming in UML is one approach. For the TDD fetishists, writing a bunch of tests tends to help uncover facets of the design that hadn't previously considered (subtle aspects of particular use cases, corner cases that the design needs to handle, etc.). A large part of the value to be found in modeling the design in a precise language like Z, Alloy, or CSP is the thought about the design that's required in order to construct a model (the other part of the value being the model-checking or other automated analysis that helps you to find holes that aren't quite so "glaring"). Almost any kind of "design analysis" (read "thinking about how the design operates and whether it will work as intended") will help. The more interesting question is "which approaches to analysis give me the most bang for the buck?"

Re:UML great for design (1)

Yetihehe (971185) | more than 6 years ago | (#23612573)

We often find the "loopholes" in our methodology by drawing it out first. We plug those glaring holes. Then start coding.
Pretty much anything you do to think through your design before committing to code will help to uncover inconsistencies and holes.
Funny thing, it is typically the other way for me, eg. I make model and close loopholes in it during coding

Re:UML great for design (1)

GileadGreene (539584) | more than 6 years ago | (#23613305)

Funny thing, it is typically the other way for me, eg. I make model and close loopholes in it during coding

Hardly surprising. I didn't say that you wouldn't find holes while you're coding. Each step of the design and development process inevitably involves resolving new issues as you learn more about the problem you're trying to solve. That's part of what makes development such a fun activity :-)

But how many more holes would you find in coding if your "model" was just a vague idea in your head, rather than something more explicit? And how many of the those holes would be structural problems with the basic design that require complex changes to the code? The act of making your design ideas explicit as a model of some sort (be it UML, test suites, or Z schemas) helps to elaborate and clarify them. Paraphrasing Richard Guindon's comment about writing: "[Modeling] is Nature's way of showing us how sloppy our thinking is."

Re:UML great for design (1)

SQLGuru (980662) | more than 6 years ago | (#23613627)

I don't find any holes because (like most developers), once it compiles, it's "perfect".....any bugs are PEBCAK issues.

Layne

YES (0)

Anonymous Coward | more than 6 years ago | (#23611811)

If it isn't dead yet, it needs to die. Horribly.

We use it... (2, Informative)

fitten (521191) | more than 6 years ago | (#23612065)

We use it fairly often to express things such as cardinalities in problems and the like, but we pretty much limit it to diagramming so we can better understand how some things interact. I've never used it to automagically generate code.

Good In The Beginning, and At The End (2, Insightful)

quakeaddict (94195) | more than 6 years ago | (#23612075)

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

Whatever happened to pure, unadulterated... (0)

Anonymous Coward | more than 6 years ago | (#23612095)

I had no idea things had gotten so bad. This is all PHP's fault. She's been polluting developers minds with notions of simplicity and ugly syntax. Whatever happened to formal specification? Whatever happened to big committees, arduous debates, and communication with management? Whatever happened to pure, unadultered documentation?

I won't preside over the demise of software engineering! If this industry can't have UML, I'll quit! The line has to be drawn here! This far, and no further!

UML as a sketch versus UML for MDA (4, Insightful)

Tumbarumba (74816) | more than 6 years ago | (#23612101)

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.

Re:UML as a sketch versus UML for MDA (1)

MichaelSmith (789609) | more than 6 years ago | (#23613227)

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.
Yes where I work a couple of million dollars of developer resources were burned up doing this. The pure OO code it generated just wasn't appropriate to our application.

damn TLA (0, Troll)

frovingslosh (582462) | more than 6 years ago | (#23612171)

Will /. ever start defining tla's that it uses? Seems unlikely, given this is far from the first time one has been used with no explanation. The article doesn't bother to ever use the full name of UML either. For what it's worth, after a Google search, I think that this it talking about Unified Modeling Language, but of course I could be wrong. They might even be talking about University of Massachusetts Lowell or User-mode Linux for all I know.

Re:damn TLA (1)

u38cg (607297) | more than 6 years ago | (#23612987)

I think anyone with a user number lower than mine who is still posting ought to know what UML is.

Is UML Really Dead? (-1, Redundant)

Simon (S2) (600188) | more than 6 years ago | (#23612203)

By the count of comments on this post, and thus the interest of the Slashdot comunity on the topic, I would say yes.

Re:Is UML Really Dead? (1)

pembo13 (770295) | more than 6 years ago | (#23612303)

I was going to comment, when it was just posted, but I was like "blaa".

Re:Is UML Really Dead? (1)

larry bagina (561269) | more than 6 years ago | (#23612481)

according to the slashdot community, it's been the year of the linux desktop since 1999. And nobody wants an ipod since it doesn't support ogg vorbis.

Please people, please- it's *The* UML (1)

tillerman35 (763054) | more than 6 years ago | (#23612225)

(title is sarcastic, obviously). There's nothing I hate more than one of those UML fetishists (thanks, blackcoot for that spot-on description) who insists on correcting you when you call it "UML." Yes, we know the authors intended it to be called "The UML," but frankly only about .05% of us give a shit. Unfortunately, it's the most annoying sanctimonious .05%. I don't care when they call it "The UML," so why should it be put their panties all in a wad when someone leaves off the article?

/rant mode off.
//not a troll, just a person with a pet peeve
///hopefully there's a difference.

Re:Please people, please- it's *The* UML (1)

Hankapobe (1290722) | more than 6 years ago | (#23612263)

Unfortunately, it's the most annoying sanctimonious .05%. I don't care when they call it "The UML," so why should it be put their panties all in a wad when someone leaves off the article?

You must be new...never mind.

Re:Please people, please- it's *The* UML (0)

Anonymous Coward | more than 6 years ago | (#23612325)

I think you have The Gay.

Re:Please people, please- it's *The* UML (2, Informative)

julesh (229690) | more than 6 years ago | (#23613327)

//not a troll, just a person with a pet peeve ///hopefully there's a difference.

Of course there's a difference. If the moderators agree with you, the post is informative. If they disagree, its a troll.

I use it backwards... (4, Funny)

AmazingRuss (555076) | more than 6 years ago | (#23612235)

...I write the code, and then generate UML with doxygen to figure out what the hell I just did.

Re:I use it backwards... (1)

magical_mystery_meat (1042950) | more than 6 years ago | (#23612729)

Isn't that what they call "emergent design"

Sounds good (4, Funny)

AmazingRuss (555076) | more than 6 years ago | (#23612961)

I'll use that next time somebody asks.

Re:I use it backwards... (1)

julesh (229690) | more than 6 years ago | (#23613277)

Dunno why this is modded 'funny'. It's a valid method of using UML, and is favored by most "agile" processes at least.

You can also get tools that will allow you to modify the generated UML diagram and then apply the changes to the code (I've played with an eclipse plugin that does this, although I didn't find it particularly helpful for me).

Re:I use it backwards... (1)

azgard (461476) | more than 6 years ago | (#23613551)

(I've played with an eclipse plugin that does this, although I didn't find it particularly helpful for me).
That's probably why it was modded as funny. Seriously, imagine writing a program in one language and then debugging it in another. You would have to understand all the parts twice. If anything, this approach is a hindrance.

Re:I use it backwards... (1)

hey! (33014) | more than 6 years ago | (#23614395)

But you don't use it for debugging.

I've never tried what the GGP suggests, but I imagine it's a lot like the "grammar checker" in Word, which was nearly useless as a guide to grammar. However, it did tend to offer a lot of advice, albeit bad, useless or confusing, in places that needed work. So, I found it quite helpful as way of detecting grammatical problems, less so as a means of solving them.

So I imagine if you ran your code through UML-izer, and you (the author) couldn't make head or tail of it, it'd probably be a quicker way of detecting sloppiness than going through the code reference by reference.

Re:I use it backwards... (1)

darjus (1299529) | more than 6 years ago | (#23613913)

I do some High Level UML for the design phase and Doxygen and alike to "see" what I'm coding.

UML is a cripple trying to climb to the moon (4, Insightful)

benhattman (1258918) | more than 6 years ago | (#23612247)

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:UML is a cripple trying to climb to the moon (1)

mapkinase (958129) | more than 6 years ago | (#23612459)

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

Dude, you just buried a joke under avalanche of words.

Re:UML is a cripple trying to climb to the moon (1)

Profane MuthaFucka (574406) | more than 6 years ago | (#23613477)

Sometimes the jokes just bury themselves.

Re:UML is a cripple trying to climb to the moon (1)

dsanfte (443781) | more than 6 years ago | (#23613439)

Or, to ignore the marketdrone cliche definition and take a step back into chemistry, Executable UML sounds like a solution of suck and fail.

UML? It never was useful (0)

Anonymous Coward | more than 6 years ago | (#23612345)

UML is a popular amongst corporations but I've not found any use for it in my hobbyist programming axis. Why?

UML's job is to describe behavior, to describe interface, and to describe the structure of a program. This is, if applied in the end to document the program, otherwise it is defining those things.

Defining the structure of a program beforehand the program is doing anything is quite stupid. I know since I've been done this error a couple of times. You are directly declaring with it, that you can't invent anything new while you are writing the program, therefore you can't solve the problem with the program in a satistifying manner.

This language actually can trouble the general view from the program, because it is not the thing that will be compiled and doesn't necessarily give off any more information than what a properly structured code written in a decent language would give off.

Code I write is expressing exactly the same things what a good UML-document is doing, without the one extra language for it. Documentation is more important than the code, and UML fails to notice that in imitating common concepts from object oriented languages.

Your understanding from the code grows increasingly if you treat it in a similar manner to a poem. Like poem, it is short compared to what it stands for. Like poem, only when you study it then you can extract it's full meaning.

Well-written documentation gives the needed deep understanding into the code-poem. UML does not do much in helping you to do that. You'll go better along with documentation by understanding the concepts behind your code, and understanding what kind of details are meaningful. Well-written documentation describes that behavior and interfaces in words and even then, if they were important in the design in the first hand.

they all moved on to the next thing (0)

Anonymous Coward | more than 6 years ago | (#23612421)

You know, the little cottage industry of tech. book authors, publishers, cert trainers, and seminar speakers.

XML, J2EE, and .Net come to mind. But the most direct successor of the UML mantle is perhaps "agile programming" and its cousins (extreme programming, scrum, etc.), since like UML it's not clear whether they deliver measurable value to anyone other than the gentlefolks listed above.

13 reasons that X, Y, Z (1)

Zarf (5735) | more than 6 years ago | (#23612503)

Is it me or is this a new meme. I see a lot of "13 reasons blah-diddy-blah this-and-that" lately. I think it's a virus.

Re:13 reasons that X, Y, Z (1)

whitehatlurker (867714) | more than 6 years ago | (#23613223)

I blame digg - every third posting there is a list of [some number, usually less than 20] [reasons for/reasons against/top/bottom/sexiest/...] something. I didn't read TFA - is there a PROFIT! on the list?

Booch notation... (1)

gatkinso (15975) | more than 6 years ago | (#23612787)

...poised for a comeback!

Re:Booch notation... (1)

isj (453011) | more than 6 years ago | (#23613753)

Actually, Booch notation isn't half bad. I does not have all the details and precision of UML, but it is sufficient. And classes and objects are fluffy clouds - not boxes. Grady Booch's rationale for that shape was that the drawings were approximations anyway. the story goes that when UML was designed the others wanted nice rectangular boxes for classes and Booch had to give in, but commented "but they are really just rectangular floffy clouds"

It's a bunch of shapes connected by lines (1)

hritcu (871613) | more than 6 years ago | (#23612809)

- I'd like to start with a diagram.
- It's a bunch of shapes connected by lines.

Re:It's a bunch of shapes connected by lines (1)

hritcu (871613) | more than 6 years ago | (#23612867)

Re:It's a bunch of shapes connected by lines (1)

scotsghost (1125495) | more than 6 years ago | (#23613433)

What the hell is wrong with the Dilbert site?? The only way I can read the comic is in short glimpses before the Flashcrap loads -- then hit reload to read the next panel. Did Scott Adams let his pointy-haired-boss design the flashcrap??

Documentation will be next? (0)

Anonymous Coward | more than 6 years ago | (#23612923)

This article is silly and I also wonder if the author actually grasps the whole concept of UML's. IMO the article basically boils down to "UML will die because programmers hate it". But isn't this something which has been going on for the last 30 years or so? When looking at the things a programmer dislikes (generalizing:) you can be sure that documentation will score high on the list. Heck; from what I understand its even one of the key reasons why Java invented javadoc. A means to produce the maximum amount of (usefull) documentation with a minimum amount of effort on the programmer.

But even despite the disdain the need for documentation hasn't gone away... Next thing I wonder about is the fact that UML can be used by more people than merely the programmers. When looking at use case diagrams one of its basic requirements is that it will only describe the functionality of the program from a - users - point of view. It shouldn't reflect anything which has something to do with programming or programming techniques. Its solely aimed at design, not technical implementation.

But the main reason why I simply chose to disregard this article as fud is the fact that the author mentions "expensive tools" and "java" in the same article. Guess what? One of the main Java IDE's called NetBeans [netbeans.org] offers native support for UML modeling [netbeans.org] . And yes; NetBeans is free.

And well, to finish up; when looking at the bottom of the article you'll see that this story falls right into the same category of the article we had a couple of days back stating that Java was to die very soon now thanks to the likes of Ruby and Python. I sure hope /. will ignore silly articles like these for a while now. Its boring.

It didn't solve many problems (1)

webview (49052) | more than 6 years ago | (#23612957)

I think the reason why it died was because it really didn't solve any problems.

Don't get me wrong, I was trained in UML and think it is great for communicating high-level processes, but it's pointless to expect the typical developer (even users outside your organization which you have no control over) to understand all the details of cardinality, the difference between a dashed-line with an outline arrow and solid-line with an outline arrow, or how about a half-arrow and dash-lined?

I love it for 10,000ft view illustrations, but to go any further is pointless. We were always promised a rich (round-trip) set of tools, but it never happened. Whenever I would get into to details of the code, I quickly learned that my models had become out of date and it ended up being an exercise in redoing the diagrams just so they would match the code (i.e. the code became the authoritative source).

I firmly believe that the actual coding process is 75% of the design phase and UML assumed that the models comprised 99% of the design phase. I still think models are useful, and I use UML to-this-day, but I don't think it will be as prominant as some people had hoped.

Hated it (2, Interesting)

MBGMorden (803437) | more than 6 years ago | (#23613157)

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.

Cataleptic (1)

rwa2 (4391) | more than 6 years ago | (#23613233)

The military-industrial complex seems to be using it a lot... Lockheed was supposedly planning on using IBM Rational Rose to do all of the JSF software development, and Boeing's been playing around with the Ilogix Rhapsody tools to do various simulation things.

A complete working toolchain is of course prohibitively expensive to use in any other setting (with ClearCase to do version control, and all of the full time admins needed to keep the system organized enough to keep from falling flat on its face).

But as long as the PHBs and other management types think it gives them simple enough pictures to have at least a glimmer of hope of appearing to know how any of the SW projects they manage work, then I have a feeling they will mandate that developers use UML-to-code tools regardless of the cost.

I worked on a decent-sized development effort using the Rhapsody thing, and I have to admit I was surprised that it actually worked pretty well. Most of the "real" code was embedded in traditional blocks of text attached as properties to the UML elements, but the additional structure enforced by the software kinda helped organize everything. And it was pretty neat to be able to visually navigate the code tree.

You still needed pretty skilled developers to make the thing worse, and of course they could do their job better without having management trying to interject things they half-learned from a design pattern seminar. And ultimately, management will point to how easy development now looks, and will use that to justify hiring cheaper, less qualified developers.

Bottom line, I think UML-to-code development styles have shown that they can work, and will persevere, even if only as a learning tool. I think it just depends on how fast the open-source tools like Umbrello reach the level of capability of the expensive commercial tools.

For what it's worth (1)

wellingj (1030460) | more than 6 years ago | (#23614049)

I found this little thing: http://dia2code.sourceforge.net/examples.html [sourceforge.net] I thought it was interesting that they actually do code generation of 'virtual' functions in C.

If you looked at my company... (2, Interesting)

shadoelord (163710) | more than 6 years ago | (#23614377)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>