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."
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.
-- BSD or Bust
Never forget Weinberg's Law:
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization"
Don't blame Durga. I voted for Centauri.
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?
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.
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.
Pretty widgets? What pretty widgets?
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.
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.
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".
The moral: There are no magic bullets.
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"
Don't blame Durga. I voted for Centauri.
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.
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)
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.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
> 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.
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'.
Eat at Joe's.
...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.
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.
Rammed earth walls will survive much stronger earthquakes than frame construction
15,000 recently dead Iranians dispute that claim.
Granted, you can build earthworks that are stable with modern technology, using metal and concrete reinforcements and a better knowledge of materials science.
And one day, software engineers might be able to write a pile of C++ that doesn't fall down when pushed.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
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).