Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Software IT Technology

UML Fever 192

Posted by Hemos from the hot-hot-hot-tonight dept.
CowboyRobot writes "Queue has a couple of articles about UML: Death by UML Fever by Boeing software architect Alex Bell describes the problems that can result from over-reliance on modeling tools, with lighthearted lessons for the software development process in general and numerous illuminating quotations, such as: "Good judgment comes from experience. Experience comes from bad judgment. - Jim Horning." Then, one of the developers of UML, Grady Booch of IBM, follows with The Fever is Real, in which he explains the motivations for creating the language, how it's used today, and where he expects it to go soon."
This discussion has been archived. No new comments can be posted.

UML Fever More

UML Fever

Comments Filter:

  • Acronyms (Score:3, Funny)

    by Space cowboy ( 13680 ) * on Monday April 12, 2004 @09:02AM (#8836781) Journal

    True linux-focussed geeks would have immediately wondered why user-mode linux was suddenly such a hot topic, and so dangerous to boot :-)

    Simon

    • Re:Acronyms (Score:3, Insightful)

      by dotz ( 683519 )
      If you don't know all the meanings of UML acronym, you can't be "true" and "geek" at the same time.

      Am I the only person, that finds all those oh-so-funny usermode-linux jokes really not-so-funny?

  • Re: Everything, including tools, in moderation! (Score:4, Interesting)

    by Face the Facts ( 770331 ) on Monday April 12, 2004 @09:04AM (#8836790) Journal
    Design patterns and UML were designed as practical tools, not dogma. If they help you do what you were doing anyway (and they often do), then great: use 'em. But if they don't, then don't. They're there to serve you, not the other way around.


    This is true, but note that the UML/patterns/OO newbie is in no position to determine that. One common mistake is to read the book, discard the parts you don't think is necessary, and then proceed with your design work. The rules that you chose to ignore were put there by pretty smart people, and there's a good chance they were put there for a good reason. When the design finally fails because you were missing something, the egotistical designer then blames the method.


    The point is, I think the parent post was suggesting that the programmers in question may simply have broken the rules, and not actually found some instance where the methods really apply poorly. It's ego-boosting to think that what you do is unique and beyond the reach of old stuffy rules, but the truth is that most of us are doing things that have been done before.


    This isn't to say that those cases don't exist, but that they're probably rarer than you think, especially if your team of programmers is trying it out for the first time, especially if you don't have a senior engineer already experienced in the method guiding your team. For the first time, at least, the instructions should be followed to the letter and strictly enforced. They should be dogma until you've at least went through a complete product life cycle with them.


    What you suggest we've already tried for decades. The result is prevasively poor documentation and fragile designs.

  • Software architect? (Score:5, Funny)

    by AtariAmarok ( 451306 ) on Monday April 12, 2004 @09:05AM (#8836793)
    Never forget Weinberg's Law:

    "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization"

    • Re:Software architect? (Score:5, Insightful)

      by spektr ( 466069 ) on Monday April 12, 2004 @09:17AM (#8836857)
      "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization"

      The leading building corporation would proclaim that there's nothing wrong with the buildings and a new market of woodpecker traps and anti woodpecker missiles would thrive.

      • I've gotten spams about these (Score:5, Funny)

        by AtariAmarok ( 451306 ) on Monday April 12, 2004 @09:47AM (#8837043)
        The leading building corporation would proclaim that there's nothing wrong with the buildings and a new market of woodpecker traps and anti woodpecker missiles would thrive.

        I've already gotten spams about these products concerning software woodpeckers. In fact, I got one this morning that had a title "SOLVE YOUR SOFT PECKER PROBLEMS"

    • Re:Software architect? (Score:5, Insightful)

      by His name cannot be s ( 16831 ) on Monday April 12, 2004 @09:21AM (#8836877) Journal
      Aye, laddie.

      Be thankful of the fact we've (as humans) have been building shelter for 20000+ years.

      As software developers, we've been making stuff for a little over 50 years.

      We are In the MudHut age of Software Development:

      Garrett's Rule #3: "MudHut software" We are continually re-writing software that performs the functionality we require, simply to make the software run on the platform that we rewrote, so that we can make better software.

      You see, 20,000 years ago, our clever, but inexperienced ancestors had to make new shelter every few days/months/years/whatever, simply because they made them from mud.

      When the next wind, rain or hail came, it outdated their technology, and forced them to upgrade.

      took thousands of years to make the difference, an build structures that could stand up to the changing environment.

      So, just when it looks like MS will rule the desktop forever, just remember, while some clever frickin' caveman probably added the first straw and dung to his hut, and improved it, it never lasted. Cooler heads prevailed.

      Now, for those who didn't catch it: I just compared MS products to shit and straw.

      Thanks,

      • Don't knock mud 'till you've tried it! (Score:5, Insightful)

        by Chemisor ( 97276 ) on Monday April 12, 2004 @10:34AM (#8837362)
        > You see, 20,000 years ago, our clever, but
        > inexperienced ancestors had to make new shelter
        > every few days/months/years/whatever, simply
        > because they made them from mud.

        Buildings made of mud (in adobe brick or rammed earth construction, as it is called these days) are much sturdier than the frame matchbox you are living in. In fact, rammed earth walls are so durable that some of them are still standing after 5000 years of rain/wind/hail etc. And they are more energy efficient too.
        • Don't knock mud

          yeah... or the entire wall will come down.
        • Buildings made of mud (in adobe brick or rammed earth construction, as it is called these days) are much sturdier than the frame matchbox you are living in. In fact, rammed earth walls are so durable that some of them are still standing after 5000 years of rain/wind/hail etc. And they are more energy efficient too.

          Erm... True, some are sturdier, and will last. So are the Mainframe apps from the 60's. You illustrate my point precisely.

          My point is, that we re-create the same dwelling/software over and over
          • > My point is, that we re-create the same dwelling/software over and over again.

            Pehaps you are just oscillating around an optimal point.

            > As for the energy efficiency, um, I'd have to call
            > bullshit there. Part of a energy efficent dwelling
            > has to do with the balance of breathability to airtightness.

            Breathability has nothing to do with energy efficiency (although it is still worth considering if you want to keep breathing :). Earthworks are energy efficient because their large mass stores t
        • In fact, rammed earth walls are so durable that some of them are still standing after 5000 years of rain/wind/hail etc. (emphasis added)

          What you don't see after 5000 years is all the hundreds of thousands of mud (rammed earth, etc) buildings that didn't stand up to five millenia of rain/wind/hail etc. There are some mud hills in the middle east that were pretty amazing structures in their day.

          I've heard similar marvelling over how the stone work of the Incas has amazingly survived some pretty severe ear

      • Re:Software architect? (Score:5, Insightful)

        by Kevin Stevens ( 227724 ) <kevstev&gmail,com> on Monday April 12, 2004 @12:34PM (#8838519)
        I often hear building type analogies like this, and IMHO always focus on the wrong aspects of software and architecture.

        The reason most software is late, over budget, and buggy is because the specs are not what the customer wants. Customers understand that when they are buildng a house, that the blueprints are of utmost importance, and that the blueprints are going to reflect the house that they are going to build, and go to great lengths to visualize the house depicted in the blueprints. They also have an understanding of building concepts, and know that they can not wait until the bathroom is finished, and then say "hey, I want the tub over on the other side of the room" without understanding that the bathroom will essentially have to be gutted. These same people will have no problem demanding significant overhauls of the layout of a gui or the basic fundamental requirements of the software. From my experience, customers will often blow right through a spec document, browsing it, and saying OK looks great! What is worse is, the more detailed (hence boring) the spec is, the less likely the customer is to really look at it. Begging, pleading, blackmailing, and torturing customers to read the specs is rarely effective, the best solution IMHO is the XP method of letting the customers see things as early as possible.

        This leads to another problem- software growing in scope and function well beyond its original intentions. People inherently understand that you can not take a basic mudhut or woodframe house and just keep adding to it indefinitely and still have a coherent structure- there is only so much the foundation can support, and only so much you can do to a house before you have to major extensive rennovations. The same thing occurs with software. Customers often say, "we like this, but we would really like this feature," and management will almost always cave in and say sure! Next thing you know, the system has a large patchwork of add-ons that sometimes have to be hacked in and make the code difficult to maintain, and make it even more rigid. People dont take trailers or sheds and try to make them into colonial two story homes, but they will often try to take simple reporting tools and make them into comprehensive organization wide information dashboards, one report or feature at a time.

        Design Patterns and frameworks try to attack the problem by telling us how to build even sheds with concrete and steel foundations, and modularized/interchangable parts so that further additions do not cause too many problems, which is a good thing. But until there is a universal general understanding of the software development process by the customers, these problems will persist in software, and the industry itself.

    • Programmers don't build programs (Score:5, Insightful)

      by wowbagger ( 69688 ) on Monday April 12, 2004 @09:55AM (#8837089) Homepage Journal
      This analogy is flawed.

      Programmers are NOT to programs what builders are to buildings.

      Programmers are to programs what ARCHITECTS are to buildings.

      Builders are to buildings what COMPILERS AND MAKE UTILITIES are to programs.

      Now, I suggest that you make an architect work under the same constraints as a programmer:

      1) I cannot tell you were the house will be built, so you cannot estimate heating/cooling, snow loads, etc. Can't it figure it out itself?
      2) I cannot tell you that the house won't be moved to a completely different climate once built - can't you make it automatically adjust?
      3) I cannot tell you what building materials will be available to build the house with. Can't you make your design work just as well with wood as with adobe?
      4) I cannot tell you how many rooms will be needed. Can't the house automatically add rooms as needed?
      5) I cannot tell you what services, such as electricity, water, and gas, will be available. Can't you make the house work just as well on wind power as grid power?
      6) I can tell you that whatever I told you is subject to change without notice.
      7) Oh, by the way, now that the house is almost designed - Add a hanger. No, I will NOT tell you whether the hanger is for a Cessna 182 or a 747 - can't you make the hanger figure that out when I park the plane?
      8) Oh, the house cannot cost more than US$10,000.
      9) Oh, and the house must be build on a quarter-acre lot.
      10) Oh, and the house must be ready to move in tomorrow. Morning. Before I go to work.
      11) Oh, and the house must be built by two dain-bramaged monkeys with Nerf Tools.
      12) Did I mention being earthquake-proof?
      13) Oh, the lot is in a floodplain. Can you make it water-tight? Or float? Or both?
      14) Hey, how about a houseboat?

      • In other words, the problem is not having a concrete set of requirements to begin with. Which means the problem lies with the management, and not with the programmers. If the management decides that its software requirements must be cast in stone, then the programmers are happy. If the management keeps changing requirements every morning, then we have all the usual problems.

        • Re:Programmers don't build programs (Score:5, Insightful)

          by WayneConrad ( 312222 ) * <`moc.ingay' `ta' `darnocw'> on Monday April 12, 2004 @01:33PM (#8839188) Homepage

          In other words, the problem is not having a concrete set of requirements to begin with.

          It's worse than that. The problem is that, for all but the most trivial of problems, you can't have a concrete set of requirements.

          If you could have a concrete set of requirements that would unambiguously result in code that met the customer's needs, then you could automate the process of turning the requirements into code. In other words, the requirements would be code.

          As much as management would love to be able to automate the process of turning requirments into code, they can't. Nor can they even create a process that someone can follow to turn requirements into code (if you could, you could automate following the process and not need the programmer).

          The bottom line is, you can't ever have a complete set of requirements. The best thing to do is to get over it and not work under fictional processes that assume you can ("If only we could get the requirements frozen, then we could ship on time"). Requirements change because writing code teaches the programmers and the business that the requirements were unimplementable in the time required, or that they don't actually meet the needs of the business. That's ok. It better be, because that's reality.

          • As much as management would love to be able to automate the process of turning requirments into code, they can't. Nor can they even create a process that someone can follow to turn requirements into code (if you could, you could automate following the process and not need the programmer).

            There is an excellent paper by David Parnas on this very same thing. Can't remember the name right at this moment...
          • It's worse than that. The problem is that, for all but the most trivial of problems, you can't have a concrete set of requirements.

            Bingo. Without a functioning system you can't even comprehend what the requirements need to be.

          • It's worse than that. The problem is that, for all but the most trivial of problems, you can't have a concrete set of requirements.

            I have very different experience. I work in the defense applications sector, and one thing I like about it is that every project has a well defined set of requirements, allowing the programmers to truly design an application up to the last bit.

            If you could have a concrete set of requirements that would unambiguously result in code that met the customer's needs, then you c

        • Re:Programmers don't build programs (Score:4, Interesting)

          by Bozdune ( 68800 ) on Monday April 12, 2004 @02:42PM (#8839940)
          That's certainly true, but the "usual problems" can be mitigated with careful thought and good design. I've built lots of software from inadequate specifications. It's possible to do a good job if you take the time to understand the problem domain, even if the specification is poor or nonexistent.

          Neither of the following examples involved me, but I was an interested contemporaneous observer of both.

          Case study #1: Web application (buying portal). The app was designed with J2EE tools, and the Architect allowed the tools to automagically generate the schema that supported the app. Problem: The Architect did not consider that reports would need to be generated from the schema, some day. When it came time to write them, the task was horrific and nearly impossible, and the team almost failed. Who is guilty, management, for not specifying all the reports up front, or the architect, for not anticipating the need for reporting? The Architect, of course, blamed management; management, naturally, blamed the Architect.

          Case study #2: A very arge commercial bank wanted a system for loan portfolio analysis. The Architect endured management displeasure over his long-ish timeline by designing a pseudo-language first, in which the team ultimately wrote the portfolio analysis package. The Architect did this because he envisioned massive downstream changes to the specification. Numerous changes to the specification then occurred over a two-year period, just as the Architect had predicted. Result: The Architect's company pocketed huge sums by bidding half of what the competition bid on the same project, and incurring almost zero cost, because the pseudo-language changes were so trivial to make.
      • ROFL!

        Anyway, a couple more "gotchas" with UML:

        1. It's a "visual" system. There seem to be more and more programmers who seem to be textually challenged. A class name by itself is incomprehensible; the same class name with a little box around it is somehow better. UML, being a visual system, plays straight into this. Note that the developers of UML sell UML software; they'd be out of work if all you needed to use it was a text editor.

        2. (more relevant to the parent post) In the Ivory Tower section
    • Tacoma Narrows anybody?

      I work with a couple of civil engineers and in a previous life I did some IT work at a construction company. What this has taught me is that Weinberg's Law was thought up by people who never stepped onto a construction site.

      Yes, there is a lot more formalized rules and many more years of experience in the construction industry, but people are still people and they get lazy and cut corners just like in any industry.

      I guess what I am trying to say is that we can learn a lot from t

      • Re:Software architect? (Score:3, Insightful)

        by shakah ( 78118 )

        ...but people are still people and they get lazy and cut corners just like in any industry.

        I heard/read a quote from someone to the effect that "anyone can build a bridge that will stand for 100 years -- it takes engineering to build one that will just barely stand for 100 years", with the point being that engineering consists of balancing/estimating/reconciling competing constraints (e.g. budgets, usage patterns, loads, schedules, etc.).

        Was the Tacoma Narrows collapse due to cutting corners? I though

  • UML (Score:3, Interesting)

    by JaxWeb ( 715417 ) on Monday April 12, 2004 @09:14AM (#8836842) Homepage Journal
    Who uses UML? The designers or the programmers?

    I should imagine the designers wouldn't be very good at it, and I should imagine that programmers would have better ways to express themselves.

    Sorry, this has just been a question I've wanted to know the answer to. And the story has been /.'ed.

    • Re:UML (Score:5, Informative)

      by mwheeler01 ( 625017 ) <matthew.l.wheeler@NOsPam.gmail.com> on Monday April 12, 2004 @09:18AM (#8836859)
      Who uses UML? The designers or the programmers?

      I should imagine the designers wouldn't be very good at it, and I should imagine that programmers would have better ways to express themselves.

      Actually a good designer probably has some experience coding. As to who uses it? Well ideally the designer or project leader should author it and the programmers should be able to read and understand it, so both parties technically use it.

    • Re:UML (Score:5, Insightful)

      by BigGerman ( 541312 ) on Monday April 12, 2004 @09:20AM (#8836870)
      I could not get the article either and there were only 7 slashdot comments...
      I personally (speaking from 12 years of experience) found UML useful in many situations when certain (already coded) solution was presented to someone else. So just to illustrate some point, it is much easier to sketch a few diagrams than to write a textual description.
      On the other hand I have seen environments where the UML was adopted as sort of cornerstone of top-down approach: all the design is done first and captured in UML. The problem is that disagrams become absolete very quickly and people stop referring to them which accelerates the decay even more.
      • On the other hand I have seen environments where the UML was adopted as sort of cornerstone of top-down approach: all the design is done first and captured in UML.

        That sounds suspiciously like the waterfall model.

        The problem is that disagrams become absolete very quickly and people stop referring to them which accelerates the decay even more.

        And that sounds suspiciously like the big problem with the waterfall model...

    • As a developer who designs things I find my own form of UML to be a helpful colaboration tool. It is nice to be able to draw boxes and lines on a white board to describe parts of a system. Generally I use UML where it makes sense... to help out with the picture is worth a thousand words scenario.

    • Re:UML (Score:3, Interesting)

      by sporty ( 27564 )
      As a programmer, who has used various UML tools, doing OOD (oo development) is a little easier with a graphical tool. It becomes REALLY easy to see how everything relates. Think of it like an ERD (entity relationship diagram) for a DB schema. Once I have my class diagrams and what not, i can generate java from them. I don't have to type out the class framework. Better yet, I can take an existing project and show how everything relates and in turn, have a map of an existing project.

    • Re:UML (Score:3, Interesting)

      by Woogiemonger ( 628172 )
      I've rarely seen where the designers aren't the programmers as well, at least somewhat. If there are people doing the design for a software, they're generally the lead developers and have a better chance at coming up with an intelligible, well-crafted set of UML diagrams than the programmers not involved in software architecting. When you say "better ways to express themselves", what ways are you referring to? While UML can be considered overkill, it certainly covers the bases.

    • Re:UML (Score:2, Insightful)

      by Oligonicella ( 659917 )
      Been designing and implementing systems for 35 years. I use portions of UML. I find chunks of it equivalent to blithering. Others are excellent ways to communicate to clients. Those parts happen to have existed since the 70-80's. Not much of use is really new here.

      I don't really see a significant distinction between "designers" and "programmers". One needs to know each to do well.

      • Re:UML (Score:4, Interesting)

        by plover ( 150551 ) * on Monday April 12, 2004 @12:41PM (#8838613) Homepage Journal
        Your post reminded me of my initial reluctance to adopt UML techniques. My first exposure to this was about 10 years ago when Booch, Rumbaugh, et al, were still busy duking it out whether you should draw relationships as dashed lines or dotted lines to red clouds or black boxes. There were some really heinous proposals floating around (Booch had some of the worst, as I recall, because they all centered on "you should draw this thing exactly this way," where a stray curlique on the left side of a comment box might mean "but only in odd years preceding a leap year.")

        UML still suffers from some of that: filled arrowheads vs. stick arrowheads, for example. Arrows do inherently express a relationship (at least to me,) but neither filled nor hollow represents "synchronous" vs "asynchronous". The UML is an 800 page standard, of which about 750 pages are useless detail fluff of this nature. Yet they're all "part of the standard" and thus are all equally important, at least to the AR+ people who religiously push these things. I understand that if you want to precisely express an idea that you should use the precise syntax in the language. But practical use of UML shouldn't require knowing all 800 pages, just as writing practical C++ code doesn't require an intimate knowledge of templates.

        Please don't dismiss me immediately as a UML critic (or a template critic!) One of the places that I find it of value is that it gives us developers a common ground on which to meet the analysts and business users. But much of the syntax is simply too cryptic to be of real working value in expressing ideas. And if you look at developers as the "compilers" of UML (the people who have to interpret it into code) we would have to know every last comma of the standard to perfectly implement it. Not a realistic assessment.

    • Re:UML (Score:3, Informative)

      by jeffy124 ( 453342 )
      if you've ever worked on a program by simply drawing boxes of components and drawing lines between them, you've engaged in modeling. Or even some simple flowcharting is also modeling. UML is a formalized method to stuff like that (your component diagram would be referred to as a structural model, the flowchart a behavioral model).

      Who uses UML? The designers or the programmers?

      Almost everyone in a development project. Designers, programmers, testers, etc. Even management and your customer can underst

    • Re:UML (Score:3, Interesting)

      by toesate ( 652111 )
      Before reading on, let me just say that I am a proponent of using UML/IDL/Design patterns. So..

      One of the idea of UML is that this framework allows for people of different roles to converse in a common modelling language.

      A business/product person will easily understand Use Case and high level sequence diagrams.

      A product architect/designer is able to transform these use cases and sequence diagrams into "lower level requirements" - more sequence diagrams, state diagrams, and define the IDL interfaces rela

    • Re:UML (Score:5, Insightful)

      by a!b!c! ( 137622 ) on Monday April 12, 2004 @09:57AM (#8837105)
      The main people who use UML are Consultant Software Architects, who come into a project. Create a solution, and provide the UML framework, and collect a big fat pay check. They then move on the next project.

      Meanwhile, the programmers who are stuck with this static UML framework, while the timeline, user and system requirements are changing, are put in a precarious situation where the design just doesn't work anymore, and often the project crumbles.

      Back to the Architects, who claim there design was adequate for the problem, and they don't understand how the project failed. Must be the programmers.
    • UML should be used as a round-tripping tool, otherwise
      it is soon irrelevant and misleading -- an impediment
      to understanding what the code is actually doing, and
      as much of a maintenance chore as bug fixing.

      Any other use of UML is pure crap. Thus, any designer
      worth her paycheck is a coder, and any coder worth their
      paycheck is a designer. Fire the rest of them.

    • Hopefully both designers and programmers. It would be pointless otherwise. People in the role of designers create it, and people in the role of programmers read it. Somtimes the different roles is held by the same person somtimes it is not.

      You may be right that programmers can express themselves in greater detail in a programming language. But just because eskimos have more than 50 different words for snow it doesn't mean that they can communicate well with other people with less expert knowledge in that f

  • Designs cast in Stone (Score:5, Interesting)

    by Titusdot Groan ( 468949 ) on Monday April 12, 2004 @09:15AM (#8836850) Journal
    My first encounter with a group using UML was when I was called in to review the design of a medical imaging system. I learned UML, thought it was pretty cool, and then reviewed the design.

    I found a significant design flaw with a pattern that they were using everywhere and raised it as an issue. Turns out they knew about the flaw but didn't want to fix it since they would have to redo all their UML diagrams for the bulk of the project.

    Then they had the nerve to ask me to signoff on the design. Further they had the nerve to ask me to use UML on my next project!

    UML is really great for communication of designs. But if you invest too much into the UML you end up "coding" the proposed design and it becomes too hard to modify.

    Where UML really shines is in HUGE projects, where systems analysts design the system in UML and programmers write the code. Anything else it's a little bit of overkill and a little dangerous.

    • Re:Designs cast in Stone (Score:5, Interesting)

      by naden ( 206984 ) on Monday April 12, 2004 @09:27AM (#8836916)
      Parent is exactly right:

      UML is perfect for HUGE projects where you have a large number of developers, designers and managers all of whom must understand what is going to be delivered.

      Everything smaller should be interface driven. That is, you do storyboards and interface mockups as the next step after the requirements specs. THEN you give those mockups to the programmers and tell them to implement it.

      This tends to result in the best quality programs because it comes from a user-centred point of view rather than a programming point of view.

      This is how you explain the difference between OSX (top down) versus Linux (bottom up) approach to developing the OS.

      • UML is perfect for HUGE projects where you have a large number of developers, designers and managers all of whom must understand what is going to be delivered.

        Everything smaller should be interface driven

        I disagree somewhat - UML can be quite handy in small projects. The trick is to make sure it is used as part of white board design discussions that help define the interfaces and communicate what we think we mean. My perspective may be a bit warped, however, as the only UML RAD tool I've ever used is

      • Re:UML for HUGE projects. (Score:5, Funny)

        by A55M0NKEY ( 554964 ) on Monday April 12, 2004 @10:57AM (#8837534) Homepage Journal
        I agree UML is fine for HUGE projects as long as HUGE is defined as 'just a little HUGER than the one we are working on'.
        1. Parent is exactly right:

        Actually, I don't quite agree with your parent's (original) post. But I agree with what you said about being interface driven...

        The original post suggested that a design flaw was spotted in the pattern(?), by _looking_ at the UML diagrams. And this actually illustrate one of the advantage of UML - spotting problem during design phase.

        However, the original poster associate the design flaw with the use of UML. Because the UML designers refused to make changes. And I think this

      • Story boards, Personas etc, is very good for catching how to design userinterfaces. But designing a user interface is quite different from designing an application. I certainly agree that the interactionn with the end user must work to make the application a success. But it is not the only thing needed.

        First of all, without a good conceptual model of whatever business setting the application is supposed to live in and what concepts that is supposed to be part of the system, it is harder to communicate wi
    • Actually, UML can also be useful for smaller projects, but used in a different way...

      For smaller projects, you can use UML in a UMLAsSketch mode (http://www.martinfowler.com/bliki/UmlAsSketch.ht m l). In this mode, all UML does is to allow for a common graphical "language" for expressing your ideas.

      For larger project, you can move on to UMLAsBlueprint (http://www.martinfowler.com/bliki/UmlAsBlueprint. html).

      For certain, very specific projects, with very well defined semantics, and very well defined tran

    • Re:Designs cast in Stone (Score:5, Insightful)

      by bluGill ( 862 ) on Monday April 12, 2004 @09:48AM (#8837051)

      With a good UML tool it should be very easy to make changes. UML is worthless if you are not making changes to the models. Indeed if your UML is set in stone you should throw those stone tablets away.

      UML used correctly is a good tool for getting your design down. Print that design poster size and hang it on your wall so you can at a glance see the design! However from several years of using UML I have discovered that you re-print that poster at least once a week because it goes out of date that quickly, and last weeks poster is useless. (even though that change is minor you can assume your work for the week will be based on the parts you changed)

    • UML is really great for communication of designs. But if you invest too much into the UML you end up "coding" the proposed design and it becomes too hard to modify.

      Couldn't agree more. It's all about communication and coordination. An overly detailed UML design can take as long (or longer) to put together as the code that implements it, and it can be an equally great pain to modify when the need arises. There may be no way around it for large projects involving disparate groups (development, marketing, pro

  • UML (Score:1, Insightful)

    by tkarr ( 459657 )
    UML is nice for modeling most aspects of a piece of software. It shows relationships between objects. UML mostly works best, in my opinion, with larger pieces of software. I think it would be nice to come up with another modeling technique so there would be more selection, but UML itself isn't all that bad.
    • UML *can* work for small stuff too. For instance, when you are writing on a whiteboard explaining a process it may be helpful to use some UML-ish diagrams. However, the whiteboard, when explaining processes, is about useful as UML ever gets.

      When a big company buys too deeply into the marketing spew emmitted by UML tool salesmen, the results are UML overuse which is counterproductive.

      Case in point: One of the first programming jobs I had was programming a large C++ project in a group of developers for a

  • Booch - there was nothing before he came along? (Score:3, Informative)

    by Anonymous Coward on Monday April 12, 2004 @09:26AM (#8836909)
    Contrary to his opinion, the one he never ceases to state, over and over again, there were modelling systems before he 'invented' them all. There have always been ways to annotate a software design with clarity and there always will be.
    Has anyone ever worked with anyone who is totally focussed on the UML? We've had to get rid of them as they don't contribute anything except endless debates and meetings that are way too long. Sometimes you have to deliver stuff. I bet he missed that bit while he was writing papers about how revolutionary he is.

  • Ground Realities (Score:5, Insightful)

    by frodo from middle ea ( 602941 ) on Monday April 12, 2004 @09:36AM (#8836966) Homepage
    All the so called goodies of UML asides, the fact is lot of projects have a very tight schedule and overlook lot of potential pitfalls.

    When these overlooked potential pitfalls, start to pust the project dates further and further away, the entire s/w development cycle is compromised and lot of design work is bypassed. Most of the functionality is directly coded from the requirement specs, bypassing all the UML stuff.

    And there is the issue of Change management, Over the lifetime of a project , lot of staff changes including developers and designers, and the documentation and UML stuff starts to lag behind the current implementations. There comes a time when the UML diagrams represention is no where near the current functionality of the Code.

    Having worked on two very long maintainace projects for very rich clients , I can tell you that initial project delivery is only the tip of the ice burgh. The real deal is maintaining and upgrading the project over a long time, and sadly UML is very inadequate for that.

    From a developer's POV , who needs to work on someone else's code ,Nothing and really Nothing is as useful as proper comments in a code.

    • Re:Ground Realities (Score:3, Insightful)

      by Malc ( 1751 )
      "Most of the functionality is directly coded from the requirement specs, bypassing all the UML stuff."

      In my experience that means the requirements have changed (feature creep, which kills many projects), or the implementation design wasn't done properly in the first place. You have to do the thinking at some point, and I would rather do as much as possible before I'm stuck in to the code. The code becomes easier to write, and the changes to the architecture are easier to make. Short sweet prototypes du

  • Boring, but true story (Score:5, Interesting)

    by smallfeet ( 609452 ) on Monday April 12, 2004 @09:42AM (#8837005) Journal
    A worked on a new development project a while back and we decided to try XP for the design and development cycle. Another project in the same department started at about the same time and used Rational Rose and produced a lot of UML design specs up front. We had part of our application up and running to the users satisfaction within 3 months, but then ran into a major design oversight that bogged us down for the next 3 months. The other project didn't start to program for 2 months and didn't have anything really to show the customer after 6 months. In the end both projects were killed.

    The moral: There are no magic bullets.

    • Re:Boring, but true story (Score:4, Insightful)

      by toesate ( 652111 ) on Monday April 12, 2004 @10:17AM (#8837249) Journal
      In the end both projects were killed.

      This is unfortunate..

      There are many reason why projects fail, so I do not want to speculate. But my favourite is Anti-Patterns in Project Management (review) [niwotridge.com]

      If it is a major design flaw discovered late, then this really sucks, especially if it is due to lack of foresights or experiences.. But hey, that is how we gain experiences.

      Actually my experience tells me that UML can be very suitable for fast prototyping. And one of the lethal combination for success, in my opinion is UML+IDL+CORBA(Java)+eXtreme Programming.

      It can be quite amazing how a prototyping team can churned out results, with the help of everything good, like generated skeletons, and stubs, and it helped us to get something very functional up and running, and then allows for subsequent iterative improvements that is almost transparent to the users, even changes implementation between C++ and Java. Of course, not forgetting dedicated engineers and everyone's commitment.

    • I think the moral is, that people who fart around all day determining which programming methodology to use are unlikely to be able to actually deliver a completed project. They are what is called 'poser retards using big words to look cool enough to continue recieving a large paycheck'. In life, the bigger the paycheck, the more of these buffoons are attracted like flies to it, and the more likely that the dollars will in fact go to feeding these parasitic maggots.
    • I find it odd that both projects were killed: obviously the XP project delivered *some* functionality in fairly short order (although three months is a bit on the *long* side with my experience with XP, so maybe you were in "kinda XP" mode, which is the kiss of death and why a lot of people think it is a failed process model). I work with both traditional forward design and XP projects, and XP projects should produce working code in weeks, not months. Sadly, design oversights occur in both traditional and X

  • UML and OO (Score:3, Interesting)

    by No. 24601 ( 657888 ) on Monday April 12, 2004 @09:45AM (#8837031)
    While UML is better suited to OO designs, it does provide facilities (activity diagrams) for designing algorithms in say C or Pascal and for describing system interaction with external components (sequence diagrams). However, UML is particularly directed at OO development and using it to develop software in non-OO languages requires a bit of a hack.

    One facility I think is particularly absent from UML is modelling of error conditions. In most cases it's awkward to indicate that an error might exist and how to handle it if does occur. Also, UML notation seems incredibly basic (gulp!) and simply can't tackle algorithmic modelling for complex applications like memory management or software interrupt handling in an operating system.

    If not already underway, the open source community should step forward and come up with a more advanced alternative to UML and then perhaps demonstrate its usefulness by applying it to a complete modelling of say.. oh.. umm... Linux ;)

    • If not already underway, the open source community should step forward and come up with a more advanced alternative to UML and then perhaps demonstrate its usefulness by applying it to a complete modelling of say.. oh.. umm... Linux ;)

      Hmm... You mean like well commented source code?
  • Check out a paper I wrote not too long ago with regards to UML Modelling and use of it in a Business Environment. Attached is its abstract.

    This paper explores the communications gap that exists between business clients and developers using Unified Modelling Language(UML) modelling tools to gather software requirements. A methodology for measuring how client expectations form after studying UML models is developed. The methodology provides a formalized measure to show that information loss occurs during the

    • Re:UML Modelling - Communications Gap (Score:5, Insightful)

      by gbjbaanb ( 229885 ) on Monday April 12, 2004 @10:09AM (#8837180)
      don't forget that UML usage is driven mainly by:

      a) the UML tools vendors who say its the best way to produce quality in your projects
      b) the people (managers usually) who believe all the stuff a) wrote.

      Personally, after seeing UML used to get nowhere, I would always go for a lightweight development methodology (like XP which I dislike, or Crystal Clear [cockburn.us])

  • Design is a Good Thing. (Score:3, Insightful)

    by Millennium ( 2451 ) on Monday April 12, 2004 @09:48AM (#8837049)
    UML and other design tools are Good Things, and they should be used more often. They really do tend to make things easier in the long run.

    However, they do have a major weakness: it's possible to become too reliant on design documents, such that one loses the ability to think on one's feet. It's an easy trap to fall into, but it has to be avoided. Otherwise, any design problem -and such problems are inevitable in any project of significant size- become paralyzing.
    • I have the same issue with front-loaded design that I have with heavily commenting code.. it's just one more thing to maintain.

      UML and various other design schemes have this funny habit of making you code every program twice. Once in a modelling language and once in actual code.. A change in requirements, methodology, bug fixes, or anything else that causes code modification requires you to not only update your code but your design diagrams as well. Throw in a heavy handed comment scheme (the comments have

  • From experience... (Score:3, Insightful)

    by IA-Outdoors ( 715597 ) on Monday April 12, 2004 @09:59AM (#8837115)
    I'm sure what I am about to say is covered in part by previous posts but I wanted to try and articulate it a little better. First, before there was UML Object Oriented Analysis (OOA) and Design (OOD) existed. I'm stating the obvious for some but this is often forgot. UML is just a standard language for doing OOA and OOD. UML does not tell you *how* to do the analysis or the design and, in fact, programmers that are perfectly capable of reading and implementing things represented in UML are unable to do the analysis and design needed to build the UML.

    So, as a software manager, when I hear an interviewee answer the question "What do you know about UML" and their answer is something like "I have done it using Rational's tools" I want to puke. UML automation tools are nothing more than long rope to hang yourself with when given to a programmer who knows nothing about OOA and OOD.

    My advice is to learn OOA and OOD independently from UML and then when you have a full grasp of that to look at how UML might help you in those efforts.
  • OK, that's not really two words, but two words with a colon after it is much funnier than one word with a colon after it. Anyway, folks from the Kansas City area are familiar with Sprint, for whom we've all worked occassionally. It's your typical environment where management is non-technical but deluded to the contrary and they overcommit to things like RUP, UML, and code generation toold. Some people will tell you there should be sequence diagrams for every single bit of logic in an application and so on

  • Is UML really a language? (Score:5, Interesting)

    by pohl ( 872 ) on Monday April 12, 2004 @10:13AM (#8837217) Homepage
    What is the justification for the 'L' in 'UML'. I realize that in the loosest sense, UML is intended to be a means of communicating ideas, but it feels extremely primitive, like cave drawings. There's not even a standard machine-parseable representation for UML so that various programs can generate/manipulate/transform UML models without reverse-engineering some proprietary cryptic file format. And as for communicating person-to-person, I find it much more practical to use design-pattern language and a few terms from The Jargon File to improve communication with my team. Think about the jargon used between surgeons and their assistants -- to me, that's the kind of language that actually improves communication where it matters...UML seem to take the part of the development cycle that proceeds at the most frustratingly glacial pace and make it even slower. And that seems to make it different from all of the other languages that I've learned.
    • Things are changing... Look at the Eclipse UML2 project (http://www.eclipse.org/uml2/).

      There is an OMG standard for the serialization of UML model: XMI. And there is an OMG guideline on transforming the models: MDA.

      Now, if only all tools adhered to the XMI standard as their main storage method... Although most can currently output some variant of XMI (although there's just too many right now).

      But then again, this is all about tools. There is nothing that would prevent you from using the UML notation on a
      • was that it was supposed to be heavily utilized by CASE tools. And the OMG never sat down and wrote a standard serialization format for it? That was an enormous blunder.

        Currently your best bet is to store them in Rational file formats and hope everyone else has Rational.

        Criminal.

  • Just use common sense! (Score:3, Insightful)

    by mrtom852 ( 754157 ) on Monday April 12, 2004 @10:52AM (#8837494)

    How many people use ad-hoc diagrams? Most of the best diagrams I've seen don't follow any standard but do a better job of documenting.

    Deployment diagrams are the best example I can think of as they are the most common to not be done in the UML yet they are always easy to understand. (I never could figure out how to describe clustered/redundant/distributed environments with the UML)

    I think class and sequence diags are the only ones worth standardizing and I actually like them. Maybe it's coincidence that these are the ones the 'analysts' don't understand.

    The only point in standardizing the other diagrams is so that they could be loaded in to any modelling app. Most UML apps don't even agree on what is/isn't UML anyway so why have them?

  • 24 years ago at Grumman Aerospace (Score:3, Insightful)

    by callipygian-showsyst ( 631222 ) on Monday April 12, 2004 @11:04AM (#8837591) Homepage
    I remember back about 24 years at Grumman Aerospace.

    Back then, it wasn't UML, but "Data Flow" diagrams that were all the rage. We all took this "Yourdan" course and learned how to draw data flow.

    What happened in practice was Management (including me ;-) drew these pretty little spider diagrams that were in a big thick book that pleased the Navy, and the programmers would write the actual working code that had little relation to the Yourdan diagrams.

    My brief experience consulting with IT groups today that use UML reveals the same patterns. Some people earnestly draw UML in the beginning, and tools automatically make UML diagrams based on the code, but other than for top-level interfaces, nobody cares too much about them. It's a checkbox item.

    (I'm glad I'm not an IT guy working in a UML sweatshop!)

  • I wrote a book on UML, but use it lightly (Score:4, Informative)

    by MarkWatson ( 189759 ) on Monday April 12, 2004 @11:11AM (#8837666) Homepage
    Paul Harmon and I wrote a book on UML about 5 years ago.

    At first, I thought that UML was a godsend because it did away with 12+ different modeling languages.

    Still, for most of my work, schedules are very tight and my customers usually want to spend as little money on development as possible, so I find myself only using what I consider to be the highest value diagram types: use cases, very general class diagrams, and sequence diagrams.

    -Mark

  • Hackles cartoon (Score:4, Funny)

    by Ellen Spertus ( 31819 ) on Monday April 12, 2004 @11:28AM (#8837820) Homepage
    UML Gone Wrong [hackles.org]

  • Why UML is bad... (Score:3, Informative)

    by MattRog ( 527508 ) on Monday April 12, 2004 @11:40AM (#8837926)
    I'll save the typing and just link:
    DbDebunk.com [google.com]

  • uml2code... (Score:4, Interesting)

    by StarBar ( 549337 ) on Monday April 12, 2004 @11:55AM (#8838061) Homepage Journal
    Unified Modelling Language is exacatly that, a unified way to build system descriptions with. Before UML people battled themselfs blue in the face about weather clowds or elipses were to be preferred when drawing systems graphically. The big problem with UML & co is how to generate code *and* get code changes back to the design at the UML level. No, you don't want to redraw the design and regenerate the whole program structure just because you found a small design flaw. Much of this requires expensive method specific tools (ie Rational's) that will wall you in like a whale.

    What I would like to see instead is an Open Source command line tool uml2code that will generate source code or patches to an existing code base from an XML description. This would not work unless there is a reverse tool code2uml to analyze code changes, with necessary markup of cource, and generate a change to the XML description. There are some work [pathfindermda.com] done in the area but no tools that I know of. This aproach would give the benefits of a common XML interface between the GUI and the code generation and also the freedom to work with any normal set of compiler and tools on the output. Hmmm, just dreams though...

  • Here is a really easy methodology: (Score:5, Interesting)

    by master_p ( 608214 ) on Monday April 12, 2004 @12:05PM (#8838134)
    I have used UML in the past, but it is an overkill for most projects. Here is a quick altenative which works and can be applied mechanically:

    1) write all functionality down as text
    2) scan the text and:
    a) note all nouns
    b) note all verbs
    3) make the nouns as objects
    4) make the verbs as methods
    5) write a dictionary.
    6) discard what's left.
    7) find the common parts between classes (find base classes)
    8) draw an inheritance diagram.
    9) draw an ownership diagram (the object model).
    10) make up some examples and act them out (either by yourself or with a team) to see if anything else is needed.

    It has worked for me quite well in the past for most cases. You can also repeat any number of steps any number of times desired, if cyclic developement is required.

    • 2) scan the text and: a) note all nouns b) note all verbs 3) make the nouns as objects 4) make the verbs as methods

      This tends to assume that the relationship between nouns and verbs is one-to-one (every verb has a single owner noun). It is often not so in the real world. And the ties are often temporary. This often results in excess coupling. It hard-wires soft or temporal relationships into the code structure.

      7) find the common parts between classes (find base classes) 8) draw an inheritance diagram

  • I've got UML Fever (Score:3, Funny)

    by Jafa ( 75430 ) <jafa@markante s . com> on Monday April 12, 2004 @12:54PM (#8838775) Homepage
    and the only prescription is more cowbell!

    (not funny to non-snl fans).

    J
  • People can, and will, abuse just about anything.

    Many of the "meta-fevers" described in the original article are not unique to UML. They are symptomatic of how people approach adopting many kinds of technology. I could easily make a few substitutions in the article, and poof, I'd have a "Death by XML Fever" article.

    Design is good. UML is just a tool that can aid design. There's no "one size fits all" for how UML is used by people or in projects.

    The amount of development process required what process i

  • Why Modeling (and UML) could be useful... (Score:4, Informative)

    by ndykman ( 659315 ) on Monday April 12, 2004 @07:52PM (#8842941)
    Well, I'm one of the authors of the UML 2.0 specification, so karma be damned. Here's a totally biased response.

    1. UML enables communication on design, architecture that everybody can contribute too. The standard notation and concepts in UML 1.x enabled a foundation for communicating in a team about aspects of software that are not easily gleaned from the code.

    I think this in itself makes standardization worth it. Also, it's not a secret language of architects. You read the same books they do.

    2. You don't have to have all in one place. The nature of modeling allows models to be developed across different diagrams. UML 1.x is incomplete in this area, UML 2.0 does better. Pushing this notion could lead to some to some interesting places, one could be AOP without requiring AOP code.

    3. Some changes are easier in UML. Tools don't do a good job of this, but I find it much easier to change object hierarchies and relationships in UML than in code. Imagine extending this to other areas besides the static layout of classes.

    4. Metamodeling. The problem with UML and it's tools right now is the complete lack of metamodel extensibility mechanisms. It's like XML, but you can only use a fixed set of schemas.

    This could be a real rat trap, but on the other hand, it could very cool. For example, imagine extending the base class metamodel to add what your project needs for persistence, integrity and object communication, and instead of writing code for every class to enable your special features, you use a model tool and templates to automate most of the process for every class.

    5. Little Languages that everybody can use. If metamodel holds promise, it is basis for providing Domain-Specific Modeling Languages that take advantage of common metamodel concepts and visual syntax to reduce the learning and usage curve for every language. Having standards in this area help ensure interoperability and lack of lock in.

    Oddly, Microsoft is the only vendor right nowthat really seems to be taking on the notion of metamodeling and DSMLs. I expect IBM and others in Eclipse to do the same around the EMF.

    6. Modeling could be a complementary abstraction to programming languages. With some exceptions, we rely on code to produce systems. In some areas, models can often provide additional information that is not "immediately clear" in the code, and can automate the generation of that code.

    An excellent example is E/R modeling. I would argue that E/R modeling serves as an good tool for designing relational databases, and shows things about the database that may not be clear from the set of DDL statements.

    Now, imagine having the ability to create a whole set of these models that all carry a common infrastructure and tool set. Your DB modeling tools is your XML modeling tool is your OO modeling tool is your Workflow modeling tool, and so on.

    The problem is that I view UML as "modeling middleware". I don't see it as just a notation, but I see it as a core infrastructure to base modeling tools on. This probably because I worked on the metamodel. In other words, I've spent too much time inside UML that I see the outside much differently.

    Granted, most tools make it seem that UML is pretty (expensive too) pictures. But, hopefully, with UML 2.0, people will understand the real promise of UML and modeling. I think it goes beyond the surface syntax.

    Now modeling is not UML. In fact, if Microsoft really pushes forward with Whitehorse, they may create the de-facto modeling standard.

    The UML community becomes much more aggresive about providing metamodeling capabilities. Also, XMI needs to improve big time. Also, the OMG and UML would be well served by reaching out to MS and staying in tune with where they are headed, so they don't get caught totally off-guard. There is hope, I think MS has does some good work for the W3C (and some bad work, of course).

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close