Uml Considered Harmful
Uml Considered HarmfulIt is my contention that UML leads one too quickly into too much detail.
Whilst I quite like the idea that we can all use a common visual language, I think that this is all that UML is. On the other hand, I see and hear far too many people placing way too much weight on what UML is/can do.
The whole UML religion seems to lead people into CookBookThinking?: everything can be solved by the application of some more-or-less simple recipes. They don't want to deal with the fact that design entails hard work, creative inspiration, talent, experience, rework, hard thinking and more hard work.
UseCase diagrams are too 'cute' and don't really tell me enough; UserStories, however let us write to exactly the level of detail we need.
ClassDiagrams are far too detailed -- they assume a leap straight from problem analysis to methods and data; CrcCards focus correctly on the responsibilities (behaviours) of a class.
Maybe DeploymentDiagrams? are useful; personally I've never come across the need to use them.
Overall, I am seeing a lot of people trying to use UML and UML drawing tools as a substitute for design, so have been forced to the position UmlConsideredHarmful. (See also CaseDelusions)
-- MikeMorris
I think UML as a "common visual language" is not harmful. For example, look ar MartinFowler's AnalysisPatterns - the diagrams there are very useful, at least to me, and having them in UML so I didn't have to learn yet another diagramming language would be advantageous.
So, I sort of agree that too many people are placing too much faith in what UML can do - but overall I think it's been beneficial, not harmful. This in no small part due to UmlDistilled - a subversive book. I don't think the ThreeAmigos got quite the "placeholder" book they seemed to have intended... -- PaulHudson
... too many people are placing too much faith in what UML can do - but overall I think it's been beneficial, not harmful. This in no small part due to UmlDistilled - a subversive book.
Does this mean that UmlDistilled has made UML beneficial or that it has caused people to place too much faith in UML? What does UmlDistilled subvert? -- PhilGoodwin
UmlDistilled was (we believe) expected to be a small placeholder until the big books came out to fill the true demand. What Martin teaches, however, is that you don't need to do everything in the UML to get the benefit ... as always, there's some kind of 80/20 (EightyTwentyRule) working. Use a little, get the bulk of the benefit at low, low cost. Wait, don't answer yet, you also get 300 free CRC cards! --RonJeffries
One day, after I write "'Little-bit-better' Practices in Software Development", and "The Laissez-Faire of Programming", I'll get around to writing "1-Bit Software Development", about how one can do much with little (it'll contain a chapter called "Ignorance-Driven Design", to be the sequel to the old 20th century "Responsibility-Driven Design"). Martin's book will be one of the examplars. In DesigningVsModeling, though, I comment on the value and limits of modeling. UML is a "modeling" notation, not a "designing" notation, so it provides those values and has those limits. -- AlistairCockburn
"The amateur software engineer is always in search of some sort of magic, some earthshaking technological innovation whose application will immediately make the process ot software development easy. It is the mark of the professional software engineer to know that no such panacea exists. Amateurs often want cookbook steps to follow; professionals know that rigid approaches to design only lead to largely useless design products that resemble a progression of lies, behind which developers shield themselves because no one is willing to admit that poor design decisions should be changed early, rather than late. Finally, when the amateur software engineer focuses upon creating the documentation for the design, he or she worries more about how it looks to the customer than about the substance it contains. The professional acknowledges that documentation is important, but does not let the required products drive the creative process of design itself.
The process of object-oriented design is the antithesis of cookbook approaches."
-- GradyBooch in OO Design with Applications (1st ed.)
There's also a danger when people believe that UML is a formal enough notation that they can specify precisely what they mean. This leads to people who on the one hand are aware that natural languages are always ambiguous but on the other hand believe that because the UML is a (more or less) formal syntax it eliminates ambiguity.
I've just finished teaching a week-long UML course and one of the points that came out of it was the realisation that it's very hard to precisely specify semantics with diagrams. There are long debates about how to interpret associations (such as the difference between the <<import> and <<access>> stereotypes) or when to use a dependency or one-directional association. Sooner or later people fall back to natural language text to illustrate/elucidate the diagrams. Then we're in a position where we are specifying the same thing twice. Once in the diagram and again in the accompanying text.
The canonical example would be the UML specification itself. If it were actually possible to precisely specify complex systems (such as a program or application) using diagrams then the UML would be defined as follows:
I would argue no. If you define that kind of simple notation, people will start to use it in inappropriate places. One big force that has to be remembered is that people will want to simplify things if possible. It's way too easy to think such simplification is the full truth, if you haven't seen the other viewpoint. A notation that contains such simplification without it being immediately obvious to everyone should not be used. -- EsaPulkkinen
UML is not harmful - one needs some matter to be harmful. Bricks falling from the sky are harmful - they have some mass and speed to harm. Over-detailed Use Cases are harmful - actually, the process instructing people to do so. It makes people to do extra work to early, and can result in AnalysisParalysis. UML pretty much tells you what shapes to draw for UseCases and Objects. That cannot harm.
The perception that UML is more then just an instruction on how to draw your models is truly harmful. Projecting the UML status of an uncontested standard to RationalUnifiedProcess is harmful. The belief that using UML in some form alone will bear some fruits in several years is very harmful. .
ClassDiagrams are far too detailed -- they assume a leap straight from problem analysis to methods and data; CrcCards focus correctly on the responsibilities (behaviours) of a class.
Never used CrcCards, but I never write detailed ClassDiagrams. Just put in what you need, and leave out the rest. I would never consider making a complete ClassDiagram in practice. --JimmyCerra
Just use PaintBrush?? Circles, rectangles, editboxes, pencils, connector lines, print feature [ joke ].
This is partly caused by the delusion that UML is only useful for modeling software. It's the software-centric view of UML that does it a lot of damage - particularly as I find that it gets less useful the closer you get to code.
I am yet to see an instance in which UML was in the slightest bit useful. It is perhaps not harmful because it is largely impotent. If instances of its usefulness exist, they are probably reflections of different skillsets, or incapacities, of certain people. For instance, some people might not be able to understand a concept in natural language. So, for them, boxes with arrows pointing at each other is more understandable.
See also: UmlCaseVultures, UnifiedModelingLanguage, TheAlmightyThud, UmlIsForPeople
EditText of this page
(last edited October 23, 2013)
or FindPage with title or text search