Slashdot Mirror
UML Fever
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."
I don't think his point is that projects are too unique to be guided by such rules. He's merely saying that design patterns are often useful, but don't make sacrifices in your own design to adhere to specific pattern rules. It would be foolhardy to think that most problems could be solved by using straight from the text patterns.
Also I think he's driving at another point: you should only model as much as you need to. I think modeling is useful to help everyone understand how the system works but it's not always necessary to model every behavior before you continue with the project.
Pretty widgets? What pretty widgets?
"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 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.
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,
"...In your answer, ignore facts. Just go with what feels true..."
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.
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?
Let's not forget that a pattern is a solution to a problem in a context. If the context does not match your situation, then don't use it - even if the problem is the same and the solution is attractive.
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.
UML is what self-important "software architects" are writing while the rest of us are getting work done.
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.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
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.
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)
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?
www.eFax.com are spammers
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.
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.
You never saw a fish on the wall with its mouth shut.
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 the brick and mortar crowd, but don't think they have all the answers.
People couldn't type. We realized: Death would eventually take care of this.
The way I read that quote, the idea is not to pick and choose the rules you like, but rather to throw out the whole thing if it is not working for you. If pounding nails in with the butt of a screwdriver is not getting the job done right, don't put a different handle on the screwdriver; get a hammer.
I see here a reaction to something I'd noted myself: for a number of developers, OO ceases to be a tool in the toolbag and becomes their religion -- they want to evangelize all of the unconverted, and strive to see every aspect of life through the OO lens. The book I'm reading right now contains some side-splitting examples of using the OO sledgehammer to crack a programming peanut, and I'm sorry to say that in my experience this practice is not confined to tutorial material.
There's a step that comes before "what's the best way to code this?" It's "what's the best way to *design* this?"
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)
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)
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.
Hey, that's my password you are typing
Who the fuck moderated you as flamebait? Oh well, I have been noticing that for some reason many people on /. seem to like UML in exactly the way the article describes as UML fever, so I guess the moderation shouldn't be a surprise to me.
Anyway, just wanted to say that you are right on. UML is good for standardizing the 30 years of experience in diagram drawing, but it won't fix a fucked up process. And when people ask questions like "Should designers or programmers draw diagrams?" my answer is: Find a job where that sort of a question does not pop in to your head! That question really shows that the their process in fucked in ways the no diagramming/modeling tool can help.
The main problem with UML is that many people have not understood that a hierarchical software development organizations do not work and UML can be used to hide the problems. I have seen "architects" and "project managers" that love UML, because with UML they don't really need to communicate with the Plug Compatible Programming Units under their command. This practice may be good for their career, but it's horrible for the project and for the company bottom line too.
> 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.
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?
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!)
Best Buy can have you arrested
IMHO, s/use/rely on/
I take your point, but there's nothing to say that you haven't just found a new context in which an existing pattern can usefully be applied. (After all, by definition something is a pattern in the first place only if it's got multiple real world applications.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That sounds suspiciously like the waterfall model.
And that sounds suspiciously like the big problem with the waterfall model...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
...and when the method fails the snake-oil salesmen blame the implementation of that method. UML bigots are exactly like Extreme Programming bigots; they believe the tool is a panacea, so any failure when using it must be the result of not using it properly. It's a great way to count all the hits and ignore all the misses, and for people who couldn't make a buck by selling drawing programs as drawing programs to make a buck by selling them as something much grander.
Slashdot - News for Herds. Stuff that Splatters.
Was the Tacoma Narrows collapse due to cutting corners? I thought it was more related to ignorance of how winds might effect a bridge as opposed to what might be thought of as lousy engineering. And at least civil engineers learned from the failure -- isn't wind tunnel testing a standard practice in bridge design these days?
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.
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.
Relationships between common parts often are not tree-shaped in the real world. Set theory would be more powerful for this than subtype theory, but nobody has figured out how to make polymophism work smoothly in set theory. Thus, one pretty much has to abandon OO inheritance and polymorphism to get the power of set thoery.
Table-ized A.I.
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 is actually necessary, and how the process is implemented and enforced is unique to each organization. UML can be a part of that process, or not. Depends on the people in your organization and what seems to work best.