Forgot your password?
typodupeerror
Programming IT Technology

Is UML Really Dead, Or Only Cataleptic? 156

Posted by kdawson
from the pining-for-the-fjords dept.
danielstoner writes "Recently UML was pronounced dead as a tool for all programming needs by an article posted on Little Tutorials: 13 reasons for UML's descent into darkness. The author suggests UML was killed by, among other causes, greed, heavy process, and design-by-committee. Is UML really a fading technology? Is it useful beyond a whiteboard notation for designers? Is there any value in code generation?"
This discussion has been archived. No new comments can be posted.

Is UML Really Dead, Or Only Cataleptic?

Comments Filter:
  • Just le (Score:1, Funny)

    by Anonymous Coward
    Shit, i just learned UML :(
    • Re: (Score:3, Funny)

      by MR LOLALOT (1286276)
      shit, i just payed for a course :(
    • Re: (Score:3, Informative)

      by antek9 (305362)
      Dang, I just bought a book on UML 2. I should have read the writing on the wall, though: it was heavily discounted...
    • by Z00L00K (682162)
      Anyone remember Jackson Structured Programming?
      • by ahodgkinson (662233) on Sunday June 01, 2008 @03:46AM (#23615365) Homepage Journal
        > Anyone remember Jackson Structured Programming?

        ..or flow charts and those cool green templates from IBM for drawing them.

        This was all part of the set of diagraming methodologies for structured programming. They are all gone now, which is unfortunate, and they have lessons for today's object oriented world. Which is to say that we're now re-living the same evolution for object oriented systems. The results will probably be the same. System generation from diagrams (now called MDA) probably isn't worth it.

        For the uninitiated, Jackson (structure charts) and Ward & Mellow (real-time system modelling) were diagramming methodologies to help design systems written in structured languages (assembly, COBOL, FORTRAN, C, etc.). There were lots of others, but I can't remember all the names.

        It all culminated in CASE (Computer Aided Software Engineering). Which, in it's extreme form, called 'strong case', was trying to be a CAD system for replacing programming. Like today's UML the intent was to generate code directly from the diagrams. It didn't work too well on real projects and gradually faded away.

        There was also a 'weak case' faction, that wanted to use the diagrams merely to do early design and document the resulting system. The intent was to have a lingua-franca in which you could quickly express design concepts using a simple standardized notation. This is where ULM started. It not a bad idea, as long as you keep the diagramming system fairly simple, which means it won't be rich enough to generate code from.

        The 'strong case' equivalent in the object world is MDA (Model Driven Architecture), which from what I've seen and read about is doomed to failure. I believe that the diagram to code gap is just too large and the programming detail required to actually implement a system is too difficult to capture in simple diagrams (which is what you want in the design stage).

        Have a look at Pros and Cons of MDA Code Generators? [slashdot.org] and my experience on a MDA project [slashdot.org].

        I suspect frameworks, like Struts and the like, are a much better approach.

    • Re: (Score:3, Interesting)

      by Anonymous Coward
      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 th
      • Re: (Score:3, Interesting)

        by mabhatter654 (561290)
        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 (Score:5, Insightful)

        by EnglishTim (9662) on Sunday June 01, 2008 @04:57AM (#23615563)
        I would say that UML is useful just to make sure everybody's using roughly the same notation on their napkin diagrams.

        Oh, and there's already a bunch of software out there that makes it easier for you to draw UML when you store your docs on a Wiki or something, rather than a large napkin server...
      • by fbjon (692006)
        UML is really good for those napkin-sketches though. Also, it can form a documentation aid for newcomers to a system/app.
      • by jgrahn (181062)

        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?

        You know, you didn't have to answer that question.

  • by Anonymous Coward
    ...is it just pining for the fjords?

    Sorry :(
  • by FooAtWFU (699187) on Saturday May 31, 2008 @03:10PM (#23611577) Homepage
    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.
  • by gbr (31010) on Saturday May 31, 2008 @03:11PM (#23611589) Homepage
    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.
    • by legirons (809082) on Saturday May 31, 2008 @03:21PM (#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
    • by CastrTroy (595695) on Saturday May 31, 2008 @07:49PM (#23613435) Homepage
      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.
      • by Evil Pete (73279)

        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: (Score:3, Interesting)

        by xenocide2 (231786)
        The thing about UML is that it's supposed to be a step on the path to designing software automatically. Unfortunately, it very slanted towards translation into C++ (and maybe Java). This bleeds into the problems you mention with strictly defined semantics of visual cues developers treat loosely at best. Moreover, OOP is itself slowly dying for all the right reasons, though not as quickly as you might think.

        I've seen an interesting theory floating around in multiple places that dataflow languages, visually r
    • by SQLGuru (980662)
      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 moron
  • Annoying (Score:3, Interesting)

    by Lord Lode (1290856) on Saturday May 31, 2008 @03:12PM (#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 (Score:5, Insightful)

      by Yetihehe (971185) on Saturday May 31, 2008 @03:32PM (#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.
      • by EWIPlayer (881908)
        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.
      • by owlstead (636356)
        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 squ
      • by hey! (33014)
        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 madn
  • by SpaceLifeForm (228190) on Saturday May 31, 2008 @03:20PM (#23611679)
    Don't be confused.
  • in summary: (Score:5, Insightful)

    by blackcoot (124938) on Saturday May 31, 2008 @03:32PM (#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: (Score:5, Insightful)

      by SuperKendall (25149) on Saturday May 31, 2008 @03:54PM (#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: (Score:3, Insightful)

        by blackcoot (124938)
        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
        • Re:in summary: (Score:5, Insightful)

          by theCoder (23772) on Saturday May 31, 2008 @06:35PM (#23612953) Homepage Journal
          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.
          • 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

            • When I am reading things like this, I feel like a stupid caveman. Is there anything of what you said (half of which I do not understand) that would not be possible in a simple very-high-level textual description language? I, for one, would use Lisp macros and CLOS metaclasses for things of this kind. (Then again, UML seems to be quite limited to me - I do not think that it is possible to express CLOS hierarchies with it. So I probably have no other choice than not to use it at all, even if I wanted.)
          • 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.

            The only risk there is that it kind of sounds like you're trying to teach to the middle of the class. If it's an important enough concept to make a difference, it might be worth teaching the team members who don't get it.

            That said, there's certainly too much UML arcana and there are too many people who piss about wi

          • by GWBasic (900357)

            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.

            I completely agree with you. I've only used UML to communicate class structure and flow with co-workers; and I tend to be one of the few people who makes regular (semi-anual) use of it. To me, it's shocking that there's an 800-page spec, because I only use a small subset of it.

        • Re:in summary: (Score:4, Insightful)

          by SuperKendall (25149) on Saturday May 31, 2008 @08:38PM (#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.

        • by pla (258480)
          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.
          • by blackcoot (124938)

            But I can code just as well without even having heard of UML, as I could knowing it.

            i don't really believe that, at least not in the general case.

            understanding a single class, or even a small package of classes isn't too big a deal without tool support. so, to the degree that a person never has to understand large amounts of interesting code (say, 25+ nontrivial classes in 1000+ threads interacting asynchronously), i'll believe that a notation like uml won't necessarily have a significant impact.

            on the other hand, the moment interesting amounts of sufficiently complex code get involved, m

            • 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 ea
              • So you don't actually know anything about UML do you?
        • by LingNoi (1066278)
          wow that's fucking stupid, an MRI is operated by a specialist and has nothing to do with a notation language. What's the point of UML if only one guy on the team understands it.
    • by johannesg (664142)

      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.

      • by blackcoot (124938)
        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
        • by tomhudson (43916)

          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 4

        • by Forbman (794277)
          "if you bemoan the use of process, you have no business working in software or anything even vaguely related to engineering."

          Yeah, software & engineering?

          Pull my finger.
  • UML great for design (Score:5, Interesting)

    by fragmentate (908035) * <jdspilled@NOSPAM.gmail.com> on Saturday May 31, 2008 @03:36PM (#23611807) Journal

    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.

    • by GileadGreene (539584) on Saturday May 31, 2008 @04:04PM (#23612049) Homepage

      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?"
      • by Yetihehe (971185)

        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
        • 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 th

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

            Layne
      • by MadKeithV (102058)

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

        If you're writing the design in a precise language, you are already coding it, just not in the "final" language. You could call this prototyping, and it's an argument *against* modelling.

        • To me, a prototype is a small-scale implementation (potentially with reduced functionality) intended to prove out a concept. The prototype may do less, but it's developed at the same level of abstraction as the final implementation. In contrast, a model is an abstracted idealization of the final implementation (i.e. developed at a higher level of abstraction than the implementation). Of course, there's a lot of room for interpretation in those definitions. The difference between prototyping and modeling isn
  • We use it... (Score:2, Informative)

    by fitten (521191)
    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.
  • by quakeaddict (94195) on Saturday May 31, 2008 @04:07PM (#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.
  • by Tumbarumba (74816) on Saturday May 31, 2008 @04:11PM (#23612101) Homepage

    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.

    • 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.
  • by AmazingRuss (555076) on Saturday May 31, 2008 @04:36PM (#23612235)
    ...I write the code, and then generate UML with doxygen to figure out what the hell I just did.

    • by julesh (229690)
      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).
  • by benhattman (1258918) on Saturday May 31, 2008 @04:37PM (#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.
    • by mapkinase (958129)
      "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.
    • by dsanfte (443781)
      Or, to ignore the marketdrone cliche definition and take a step back into chemistry, Executable UML sounds like a solution of suck and fail.
    • Re: (Score:3, Interesting)

      by halcyon1234 (834388)

      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.

      And there's the issue. The only time I ever found UML useful in the context of an entire system was when I had a 20' long whiteboard at my disposal. The team and I were trying to figure out just exactly how the hell the system we were designing was going to work. What classes / associations / attributes did we need? We each grabbed a different color marker,

  • 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.
    • 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?
  • ...poised for a comeback!
    • by isj (453011)
      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"
  • - I'd like to start with a diagram.
    - It's a bunch of shapes connected by lines.
  • Hated it (Score:3, Interesting)

    by MBGMorden (803437) on Saturday May 31, 2008 @07:00PM (#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.
  • by rwa2 (4391) *
    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
  • 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.
  • 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.
  • 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 b
  • by mmcuh (1088773)
    Dead, dead, dead. Good riddance.

"When it comes to humility, I'm the greatest." -- Bullwinkle Moose

Working...