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?"
Shit, i just learned UML :(
...is it just pining for the fjords?
:(
Sorry
Netcraft confirms it.
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.
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.
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.
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.
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.
By submitting the same article with a slightly different wording to slashdot 50 times littletutorials is wasting our time.
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
If it isn't dead yet, it needs to die. Horribly.
http://user-mode-linux.sourceforge.net/
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
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".
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
...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.
I'm still working on a clever footer.
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!
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.
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.
I'm an American. I love this country and the freedoms that we used to have.
(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.
...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 was going to comment, when it was just posted, but I was like "blaa".
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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;
}
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.
You know, the little cottage industry of tech. book authors, publishers, cert trainers, and seminar speakers.
.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.
XML, J2EE, and
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.
Do you even lift?
These aren't the 'roids you're looking for.
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.
[signature]
...poised for a comeback!
I am very small, utmostly microscopic.
- I'd like to start with a diagram.
- It's a bunch of shapes connected by lines.
If you don't fail at least 90 percent of the time, you're not aiming high enough. (Alan Kay)
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.
/. will ignore silly articles like these for a while now. Its boring.
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 offers native support for UML modeling. 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
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.
I'll use that next time somebody asks.
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
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.
I found this little thing: http://dia2code.sourceforge.net/examples.html I thought it was interesting that they actually do code generation of 'virtual' functions in C.
Money is the root of all evil?
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.
Dead??? What're you talking about??? Most modern software engineering tools are being based on use cases, classes diagrams, and scenarios... you can't say uml is dead without a strong replacement for it... As far as I concern, UML has helped me to understand lot of things, it helps a lot with customer-developers relation, and it's really useful for size and effort estimations.
There's one thing that I think is being misunderstood, UML isn't a tool for developers, it's a tool for the entire software process...
So, I don't think UML is dead, it's just being deprecated by those who doesn't understand its pros and are most likely to develop using a code-and-fix life cycle.
After doing development professionally for a number of years, I've found a special hate for UML used beyond simple class overviews. The amount of time that gets wasted by UML is onerous. Generally, if you've got a solid design doc (you do have one, right????) then UML is just a halfway point between your DD and the code you'd write. But, if you've written a solid DD then doing UML is just making you repeat 75% of your DD in a different format, and 25-50% of you coding in a different format. Cutting out the DD leaves a project with far more time to actually reach completion on time.
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.
UML is mostly used in a informal fashion as a way to illustrate text outlining/documenting a design. As such it can be useful since it gives engineers a concise vocabulary to discuss things on a whiteboard or piece of paper. As such it has somewhat displaced older notations and I actually like it. One of my favorite tools is an obscure one called umlet that does exactly what I need it to do: generate diagrams from very concise pseudo code.
What is dead, or rather was never alive, is UML tooling as a silver bullet to fix bad design, incompetent consultants, magic please generate my application tools, etc. Rational Rose is one of the most successful scams in our industry. They sell lots of tools, licenses, certification and consultancy to companies that think their architecture and design problems can be bought off. I heard a talk by Ivar Jacobson once where he joked that he was happy that people were buying his books (on e.g. Rational Unified Process) but regretted that they didn't bother reading them.
I've been in a number of companies and I've never seen any effective use of UML related tooling beyond the annotate boring word documents and power point slides with pointless diagrams stage. We all know the diagrams where trivial classes with a bunch of setters and getters get nice sequence diagrams and use case diagrams and the state diagram or sequence diagram for the poorly designed 3000 lines long very complex class is conveniently omitted.
My best example here is very simple: try find UML diagrams of eclipse EMF and related infrastructure for many UML tools. Hint, you won't find much to write home about. This is extremely complicated software and UML just isn't good enough for it. The experts on this matter are voting with their feet. UML tool designers don't eat their own dog food when it comes to their own software. So why should you? Come to think of it, I don't know of any open source projects where UML is used extensively. I know of a few with bullshit design wikis sporting a few useless class diagrams though. I also know of quite many that produce UML tooling. But I know of exactly 0 projects that use UML tooling as intended.
Jilles
UML was just an idea to communicate ideas.
Then came in the PHBs and thought that they could get rid of the programming part by converting the diagrams into code.
FAIL.
----
I am currently a CIS student at Appalachian State University. In fact, we take a Systems Analysis class and use UML some in Database Design. It is all very interesting. However, particularly in Systems Analysis, Diagramming and System modeling are practically treated as Sacred and Holy. Personally, for Database Design at least it would see that UML is useful. However, for programming in general I am not so sure. It was interesting to read the article and the responses though.
I sometimes turn to UML when something is too complicated for me to figure out in my head... In those cases, I need some sort of diagram to sort out the confusion. Since I hate to reinvent the wheel, I use UML... a bunch of smart people spent a long time developing this system. It's good enough for me when I need it.
However, I only use the UML described in Fowler's "UML Distilled". It's just the right amout for me.
Heh. The lecturer for my second-year Software Engineering module told us about "the future"; a lot of very clever people were designing systems that would eliminate the need for coding by hand by automatically generating code from UML. I couldn't quite believe what I was hearing.
"No code? Just UML diagrams?"
"Yes."
The most WTF-worthy aspect of this was that he said this was why you couldn't be a software engineer without knowing UML,because every employer would be using it.
Please please please, let it die. And to be sure, shoot it with a silver bullet, put a stake through its heart, cut off its head and stuff the mouth with garlic, and bury it upside-down at the crossroads.
Can we please learn from this and just immediately pummel with clue-by-fours the next bunch who think that cryptic diagrams are the best way to communicate about computer programs?
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
i don't really believe that, at least not in the general case.
Why not? It's not like he said coding without any kind of diagramming, which is a different thing - remember that there were many diagram notations well before UML, that people used - and even if people did not know that almost everyone has done ad-hoc diagrams with boxes and lines to describe relationships.
So I would argue any programmer could easily get along without knowing UML, because the most useful parts of UML are simply intuitive and easily understood. UML helped to codify everyones diagrams more universally understood, but the nature of the most used parts of such diagrams is such that anyone with but a few minutes explanation can understand different dialects f diagrams. After all, all diagrams are simply attempting to convey concepts underneath which are ALREADY universal in nature, so any diagram variant will be expressing well-known concepts!
on the other hand, the moment interesting amounts of sufficiently complex code get involved, my experience has been that peoples' ability to digest and understand enough of it that they can be useful drops off exponentially. in that case, a visual notation like uml becomes a really powerful tool to aid understanding./i
I have worked on very large systems myself (primarily Java). These systems were understood well through careful application of documentation, before UML ever took hold. What UML did however do in greatly increase the time it took to deliver projects because all sorts of additional artifacts had to be produced, and conform to UML. When you are doing custom documentation it's much easier to customize documentation to be useful for you, when you use UML in a large company that generally means RUPP and *that* means IBM coming in with a nice juicy software customization consultancy.
Again, UML in moderation is very useful, but almost no companies use UML in moderation, partly because they unfortunately succumb to the Great Lie that is Model Driven Development and seek to dictate how code is structured from the very top, almost beyond architects.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Dead, dead, dead. Good riddance.
So you don't actually know anything about UML do you?
I don't think UML is dead, I think they're just doing it wrong! Trying to generate code from UML diagrams is pretty useless. As pointed out by other posts, UML is pointless to try and use for systems of any real size, but is great for illustrating simple concepts (like the GOF use it for). I find that UML's real strength is when initially designing something - it's easy to get your ideas across about how the system should work in general.
It's turtles all the way down!
More than you apparently. I've used it on several large projects. I know enough to know how far to take it at any rate.
You appear to be one of the theorists who have read a lot about UML but have little practical application behind you in real companies. Or one of those that believes all went well with his project while leaving burning ruins behind him, I've seen enough of those as well.
I'll give you the last response. Since you appear to be only able to sneer and not give any kind of counter-arguments to my actual expereince, I see no need to read whatever further fantasy you feel like posting.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The discussion of UML's death has been very interesting. Along those lines, we invite you to participate in a survey of how Use Cases are used (within or outside UML). We would really like to hear your views about Use Cases and what you are doing with them. We have recently created a web survey and we would love to get your responses and ideas, no matter what you think! The survey can be found at: https://www.uleth.ca/survey/uml/ The survey is hosted by the University of Lethbridge in Alberta Canada. We are Brian Dobing, from the University of Lethbridge, and Jeff Parsons, Memorial University of Newfoundland. We are primarily researchers and teachers, not UML consultants or book writers. We have no preconceived notions of what distinguishes good vs bad Use Cases, when and how they should be used, etc. But we are very interested in your views. Some of our work was published in the Communications of the ACM and is available free online at: http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=461 We have recently completed a longer article based on this research and should be able to provide it to anyone interested in a few months. (It isnâ(TM)t published yet.) You can request a copy if you complete the survey â" but actually we will provide it free to anyone so please donâ(TM)t enter a lot of garbage data just to get the paper. Just send us an email (there are email links on the first page of the survey). We really welcome all opinions, including those that say weâ(TM)re asking the wrong questions etc. Our goal is to help the UML and Use Case community better understand what it going on. To that end, the OMG is supporting our research and has provided a link to our survey on their web pages (omg.org and uml.org). We look forward to hearing from you and providing you with some interesting feedback in return. Once again, the link is: https://www.uleth.ca/survey/uml/
I've been using it since 1996 and have lots and lots of experience in it.
Your arguments are silly. UML is no good because people don't have the time to keep up with it?
Are you for real?
UML isn't about being a pedist. It's about communication. If you're going to be a pedist you don't need UML to do that, you can just get on slashdot and discredit things you know nothing about.
If you had any experience using UML you'd know, it's possible to teach someone from scratch enough UML in 20 mins for them to gain real value from it, and that value just keeps giving, it doesn't stop because some minor revision of the syntax got released.
UML is about describing systems architecture, sure you can describe systems architecture in ways other than UML, but without explanation, UML diagrams are going to be more easily understood than some notation you've cooked up on your own and it will be a hell of a lot easier to understand than source code.
UML is a tool and in the right hands it can be a very good one. Any tool can be mis-used, a good tradesman doesn't blame his tools.
UML isn't good because too many people overuse it. You are totally misunderstaing what I say.
UML is about describing systems architecture, sure you can describe systems architecture in ways other than UML, but without explanation, UML diagrams are going to be more easily understood than some notation you've cooked up on your own
Anyone can figure out what a box is, and what a line means, in about five seconds. How do you imagine the world worked before UML? There were simply a number of other standards, or off the cuff diagrams. UML is simply more widey defined, to the point where in fact the UML diagrams are *not* going to be more easily understood than my own or others notation because some of it is not readily apparent and if I'm drawing adding my own notation I can understand what it means and explain things more clearly to others.
Hoist by your own petard, UML master of disaster!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This may stem from the Graphical Fallacy -- 'a picture is worth a thousand words'. While pictures often do help in understanding things, they are not nearly as expressive as human language, especially for abstract ideas of any complexity (if you don't agree, try drawing a diagram that self-evidently refutes this assertion!) From this perspective, it's not hard to see that diagram-based techniques, of which UML is one, can work for sketching, but run out of power if they are called on to substitute for language.
A lot of people misuse C#, C++, Java, AND VB. Is that any reason for not using them?
UML doesn't have a monopoly on bad developers.
So what if you can invent your own notation and explain your own diagrams more easily? When you leave your place of work, who will understand your diagrams then? Can people read books or find content on the internet about the format of your diagrams?
I think it is you has a deep misunderstanding about this topic.
Let me guess you develop using Microsoft? You're an agile zealot? You've gullibly believed everything an MVP has ever said about UML/RUP/Rational (now owned by IBM), without a thought to the motivation behind the rhetoric? You spend all day in Resharper, lost, madly navigating round and refactoring overly complex and mostly useless architecture? Refactoring is the tool of choice for the lost and blind!
You can hoist that where the sun don't shine.
A lot of people misuse C#, C++, Java, AND VB. Is that any reason for not using them?
It s if they are using them wrong. If some idiot tried to put together a crucial transaction oriented system in VB, I'd certainly tell them to stop. SImilarily when UML is used in ways that are not practical, the use of it (to the extent it has overstepped its bounds) must be stopped as well. Sadly that is impossible at many companies today.
UML doesn't have a monopoly on bad developers.
It does have a monopoly on inept management, as they are generally the ones that take it too far. Developers have sense enough to know what amount of use for a project is productive (though not always).
So what if you can invent your own notation and explain your own diagrams more easily?
Yeah, so what if you can make the thing that UML means to make easier. easier! Who cares I say!
And shaking my head, I leave you with that thought. You can continue your pointless assertions, my time is too valuable to waste on further pointing out what anyone who has worked with UML already knows.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I have read all the comments on this UML thread with interest. Most of my experience is in embedded systems and I have been trying to learn all I can about the various high level software modeling environments, both model driven (MDD) ones, such as UML and model based (MBD) ones such as Mathworkâ(TM)s Matlab/Simulink combo and National Instrumentâ(TM)s Labview. Why? For a number of reasons: (1) the day of the individual code developer is coming to an end with more and more development done by large teams often separated geographically around the world (2) systems, especially in the embedded world, are be coming more complex and require millions of lines of code running on multicore CPUs (3) as I learned from lectures by Richard Feynman at Caltech, the key to unraveling a systemâ(TM)s complexity is drawing pictures that clearly delineate patterns and relationships and (4) even if you get the code right, it seems to me the entire project could come to a halt if the system design and the relationships between entities are flawed.
An article on online at Embedded.com (MDD and IDEs: making the twain meet in embedded systems design) describes a bidirectional framework that allows developers to move back and forth between two environments, an embedded IDE for code development and an MDD such as UML at the system definition level. I was particularly struck by the following statement in the conclusion of the article:
>>>>>>>>>>>>>>>>>>>>>>>>>
The MDD tools within this bidirectional environment can then generate production quality C, C++, Java, and Ada source code automatically from the UML models, which can be fed into the IDE's C/C++, Java, and Ada compilers, and object code then transferred to the target. The developer can then take programs running on the target, set breakpoints on the graphics in the modeling environment, and have the program stop at the same point in the IDE's source-level debugger. Working from the other direction, a developer can load and debug the code in the IDE environment and set break points as well.
>>>>>>>>>>>>>>>>>>>>>>>>
Maybe the author is overstating the case but the move toward such merged IDE/MDD environments seems to be gaining ground: the one described in this article was developed for use with the open source Eclipse IDE. But I have heard that Wind River is moving in the same direction with the the Tornado IDE it has for both its Linux OSes as well as its Vxworks RTOSes. And Green Hills Software at one point was working with one of the UML providers to create a bidirectional framework between the UML system level environment and its proprietary MULTI IDE for developers using its Integrity, Velocity and micro-Velocity RTOSes.
UML does not have a "have a monopoly on inept management". Firstly, UML has nothing to do with management. UML is a development tool, not a management tool. Secondly there are plenty of badly managed companies out there with software development processes that don't include the use of UML. Believe it or not, there are people out there who can and do use UML in a professional, timely, efficient and effective way.
Alan Perlis: "A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures." (More wisdom of Alan Perlis)
Ezekiel 23:20